10年、受託でつくり続けて分かった"良い開発組織"の条件

1. 問い

受託開発で10年やってきた。ゲームUIから始まり、コーポレートサイト、EC、受託管理システム、そして自社サービス。100人以下の組織で、右往左往しながら、それでもお客様と手を組んでものを作る仕事を続けてきた。

その中で、ずっと思ってたことがある。「良い開発組織」って、なんだろう。

キラキラしたスローガンや、新しいフレームワークの導入だけで語れる話じゃない。10年、毎朝出社して人と向き合い続けた結果、手触りとして分かってきたことを、そろそろ言葉にしておきたい。 Wantedlyの記事として書くからには、求職者に向かって正直に書く。同時に、これは社内の自分たちへの手紙でもある。

2. 最初の10年——「言われたものを作る」歯車感

ISHを立ち上げた頃、受託の世界は分業が細かかった。デザイナーはデザインだけ、エンジニアはコードだけ。クライアントの要望を聞いて、仕様を起こして、納品する。歯車の一部が綺麗に回る感覚はあった。でもそれは、仕事の「上流」から自分を切り離す感覚でもあった。

ある日、納品したECサイトの数字がまったく伸びない話を聞いた。クライアントは「仕様通りだった」と言い、私たちは「仕様通り作った」と答えた。誰も悪くない。でも、売上は伸びない。

あの時の気まずさは、10年経っても忘れない。「言われたものを作る」を続けている限り、私たちはクライアントの事業に深く関われない。歯車の精度を上げる作業に、自分の時間を溶かし続けることになる。

ある晩、納品後にクライアントの担当者と飲んでいて、本音がぽろっと漏れた。「正直、リリースしてから自分たちのサイト見返す余裕もないんだよね」。その一言に、コップを持つ手が一瞬止まった。作って終わり、では、その後の物語には関われない。次から次へと新しい案件を抱えて、自分の手を離れたものに集中する時間なんて、本来的にはない。あの日の帰り道、自分は何かをやり残している感覚のまま、家路についた。

チームの誰かが「次は何やるの?」と聞いてきた時、いつも「次案件のこと、まだちょっと分からないんだよね」としか答えられなかった。自分の今手がけているものが、クライアントの事業のどこでどう使われているのか、知らないまま走り続ける。その無力感は、忙しさが加速するほど大きくなる一方だった。

3. 事業成果に踏み込む受託へ——本質転換の瞬間

転機は、あるプロジェクトで「要件定義から入ってほしい」と言われたことだった。

それまでの受託は「作ること」が仕事だった。これからは「事業成果にコミットする仕事」にしたい。そう考えた時、会社としてのコンセプトを「カルチャライズカンパニー」と定め、文化そのものをプロダクトとして捉える方向に舵を切った。

具体的には三つ。

要件定義前の壁打ちに同席させてもらう
数字が思うように動かないとき、改修提案まで踏み込む
リリース後、効果検証まで期間を置く

「要件定義から入ってほしい」と言われた時のことを、今でもよく覚えている。クライアントは事業部の責任者。会議室には私と、その方と、デザイナーだけが集まっていた。「正直、今ある資料だけじゃ形にできない。誰か一緒に整理してくれる人いないかな」。図々しい相談だったかもしれない。でもその瞬間、自分の胸の奥で、何かが動く感覚があった。「ここで断ったら、いつまでも同じ仕事しかできない」。契約条件も、見積もりも、その場で決めず、議論を続けさせてもらった。

初回の壁打ちで書いたホワイトボードの写真、今でも手元にある。顧客の言葉の断片と、矢印と、消し残しのマーカー。それを読み返すと、あの日の緊張がよみがえる。「ここまで踏み込ませてくれるのか」。同時に、「ここまで踏み込まないと、価値は出せないのか」。受託という仕事の輪郭が、その一枚の写真で確かに変わった瞬間だった。

小さな案件からだんだん大きく。これを続けるうちに、歯車として回る感覚は、いつの間にか消えていた。代わりに、手応えが残る。自分が関わった仕事が、クライアントの売上や業務に効いている、という手応え。

受託から事業のパートナーへ。肩書きは受託のままだが、仕事の中身は確実に変わった。

4. 良い開発組織の条件①:心理的安全性——土台の一つ

よく「心理的安全性が最重要」と言われる。GoogleのProject Aristotleの調査が有名だ。

ただ、私たちの実感としては、心理的安全性って「最優先の条件」じゃない。複数の必要条件の一つだと捉えている。心理的安全性がないと本音が出ないのは事実。でも本音を出した先に、ビジョンの共有も、技術的な厳しさも要る。

大事なのは、失敗や違和感、分からないを、早めに口に出せること。「それ前も困ってたよね」「それ俺も思ってた」が、打ち合わせのテーブルの上で自然に出る。批判するためじゃなく、次の手を打つための情報交換として。

ISHでは会議で偉い人の顔色を窺う文化を、できるだけ作らないようにしている。誰かが「それは違うんじゃないか」と言えること。それは「言いたいことを言い合う」こととはちょっと違う。「事業のため、クライアントのため、次のメンバーのために、本音で話す」こと。温度と緊張感、そのバランスが難しい。

5. 良い開発組織の条件②:要件の曖昧さと会議過多は、組織設計の問題

受託をやっていて痛感するのは、開発の足を止めるものの大半が、個人のスキルじゃなくて組織設計だということ。

要件が曖昧で炎上する。会議が多すぎて手が止まる。技術的負債が溜まって保守が怖い。これらは「もう少し頑張れば」「勉強すれば」解決する類のものではない。Findy調査の回答者でも、要件の曖昧さが開発阻害要因の上位に挙がっていた。要件が壊れているのは、たいてい上流のプロセスや役割分担がそうなっている、という話だ。

だからISHでは、要件を固める工程を軽視しない。クライアントとの壁打ちに時間を使い、認識のズレを言語化し、開発の途中でも「それ本当にやりたいこと?」と確認する。会議は減らす一方だが、必要な会議は長くやる。

技術的負債は、非エンジニアには見えづらく、事業言語への翻訳が要る。それを「見えないから片付ける」の繰り返しではなく、可視化して計画に組み込む。

これは、個人の根性論じゃなく、組織設計の話。

ある案件で、毎週のように定例会議が入っていた時期があった。終わったあと、誰も「で、次に何するんだっけ」と言い出せない空気が残っていた。ある日、進行役の自分が「今日の結論を一言で言ってください」と参加者に振った。少し長い沈黙のあと、ベテランのエンジニアが静かに「たぶん、決めたいことが決められてないんだと思います」と言った。会議の長さじゃなかった。決めるべき論点が、決める権限を持った人に届いていなかった。

以来、議事録には必ず「決定事項」「保留事項」「次回までの宿題」を色分けして書くようにした。誰がいつまでに何を決めるか、そこに尽きる。会議を長くするんじゃなく、会議の外で決めることを増やす。設計と同じで、構造で解決すべき問題は、構造で解く。

6. 良い開発組織の条件③:技術研鑽は、福利厚生ではなく誇り

「うちの会社、勉強会あります」「資格取得補助あります」。こういうの、福利厚生として悪いとは言わない。ただ、それだけだと「会社から与えられたもの」になる。

ISHで技術研鑽を位置づけるなら、それは「定着と誇りの仕組み」にしたい。学んだことが、その人の評価やキャリアの選択肢に、ちゃんと繋がる流れにしたい。学んだことをチームに還元する流れがある。本人が「この会社で技術者として強くなれる」と感じられる状態。

受託開発は、案件ごとにドメインも技術スタックも変わる。同じことの繰り返しではない。だから、変化を楽しめる人にとっては、むしろ最高の環境になる。逆に、同じことの安定を求める人には、少し退屈かもしれない。

7. シニシズムを生まない運営——対等な関係と育成投資

組織が大きくなって怖いのは、シニシズム(冷笑)が広がること。「どうせ言っても無駄」「上の人は現場を見ていない」。これが蔓延すると、心理的安全性も、技術研鑽の仕組みも、全部形骸化する。

パーソル総研の調査でも、シニシズムを抑え込む要因として、対等な関係と育成投資が挙げられていた。私たちも、その実感を持っている。

ISHのカルチャーは3つ。①コミュニケーションを大事にする。②チームで動く。③お互いにプロフェッショナルであること。

短い言葉だけど、この3つから外れることは、役職に関わらず指摘する。代表が偉いわけじゃない。クライアントの顔色を窺って仕事を変えるわけでもない。メンバーは「歯車」ではなく「専門家」として扱う。育成はコストではなく、未来への投資。

ある時、メンバーから「正直、最近の現場、つまらないです」と言われた。新しい技術に触れる機会が少ない、と。言いにくいことを本人も言いにくそうにしていた。でも、この一言が出ない組織のほうがありえない。翌日に役員メンバーで集まって、案件の選び方を話し合った。単価だけでない、技術の幅が出るか、任せられる範囲はどこか。一件、一件の顔を、見直す作業が続いた。「どうせ言っても無駄」と思われた瞬間、シニシズムは一瞬で広がる。逆に言えば、言いにくいことを言い合える組織は、簡単には崩れない。

あの日の「つまらないです」は、その後は新しい領域の案件を任せる形で応えた。ずっと同じ顧客、同じドメインにいたメンバーには、意図的に別の文脈を渡す。キャリアの選択肢を狭めないこと。会社の側にも、メンバーに「次」を用意する責任がある。