記事をシェアする
第4回：開発が遅い会社の共通点──技術ではなく構造が原因である理由
「なぜ、こんなに開発が遅いのか分からない」
そう感じている経営者や事業責任者は少なくありません。
エンジニアは優秀なはず。採用もしている。外から見ると、そこまで致命的な技術課題があるようにも見えない。それなのに、リリースは遅れる。仕様はなかなか固まらない。会議は増えるのに、前に進んでいる感覚がない。現場は忙しそうなのに、事業側から見ると成果が見えにくい。
この状態になると、多くの会社は最初に「技術の問題」を疑います。スキルが足りないのではないか。人員が足りないのではないか。ツールが悪いのではないか。技術選定が間違っていたのではないか。
もちろん、そうした要因がゼロとは言いません。ただ、実際にはそれだけで説明できないケースが非常に多いです。
開発が遅い会社の本当の原因は、技術そのものではなく、構造にあります。
まずは現状を客観的に確認してください。
この記事では、開発が遅い会社に共通する構造的な特徴を整理しながら、なぜ人を増やしても改善しないのか、なぜ会議を増やすほど遅くなるのか、そして何から立て直すべきかを解説します。
結論：開発が遅い原因は「技術力不足」ではなく「構造の詰まり」である
開発が遅い組織を見ると、表面にはさまざまな現象が出ています。仕様変更が多い。見積もりがぶれる。優先順位が揺れる。障害対応で予定が崩れる。会議で結論が出ない。採用も難しい。こうした状態が続くと、経営者は「誰かが弱いのではないか」と考えがちです。
しかし、現場で本当に多いのは、誰か一人が極端に悪いケースではありません。むしろ、みんなそれぞれ頑張っているのに、構造が悪いために全員の努力が相殺されているケースの方が多いのです。
たとえば、CEOは市場機会を逃したくないから急ぎたい。PdMは顧客要望を取り込みたい。CTOは品質と将来の技術負債を守りたい。エンジニアは無理な仕様や曖昧な要件のまま実装したくない。どれも正しい。ところが、この正しさ同士を整理する設計がないと、全員が正しいことを言っているのに、組織だけが遅くなります。
つまり、開発の遅さは「能力不足」よりも、「役割」「意思決定」「優先順位」「感情」の設計不在によって生まれることが多いのです。
開発が遅い会社に共通する7つの特徴
1. 誰が決めるかが曖昧で、意思決定が遅い
最も多い原因がこれです。
開発が遅い会社では、議論はたくさんあります。しかし、最後に誰が決めるのかが曖昧です。CEOが決めるのか、PdMが決めるのか、CTOが決めるのか、現場リーダーが決めるのか。その境界線がはっきりしていない。
すると何が起きるか。会議が長くなります。持ち帰りが増えます。決まったはずのことが後から覆ります。現場は「まだ変わるかもしれない」と思うので、本気で前に進めません。結局、開発速度は落ちます。
ここで大事なのは、意思決定が遅い会社は、会議の数が多いから遅いのではないということです。決定権と判断基準が曖昧だから遅いのです。
2. CTOがいるのに、経営と技術の翻訳がされていない
CTOがいるのに開発が遅い会社は珍しくありません。むしろ多いです。
問題は、CTOが存在していることと、CTOが機能していることは別だという点です。技術的に優秀でも、経営の意図を技術の言葉に翻訳できない。逆に、技術の制約を経営判断に翻訳できない。そうなると、CEOと開発組織の間にズレが生まれます。
CEOは「なぜこんなに遅いのか」と感じる。CTOは「この要求は無理がある」と感じる。現場は「上で何が決まっているのか分からない」と感じる。この状態では、全員が自分の立場で合理的に動いているのに、全体としては遅くなります。
このテーマは、次の記事でも詳しく扱っています。
3. 技術とビジネスの優先順位が分断されている
開発が遅い会社では、技術側と事業側で「何を優先しているか」が違っていることが多いです。
事業側は、顧客要望や売上インパクトを優先します。技術側は、品質、保守性、負債、事故リスクを優先します。どちらも間違っていません。ただし、これが統合されていないと、毎回の仕様調整が摩擦になります。
仕様を決めるたびに押し問答が起きる。優先順位の認識が合わない。結果として、議論コストが増え、決定が遅れ、着手も遅れます。
開発が遅いのは、単に実装時間が長いからではありません。実装に入るまでの摩擦が大きすぎることも、大きな原因です。
4. 会議が多いのに、問題が整理されていない
遅い会社ほど、会議で何とかしようとします。会議を増やし、連携を強め、認識合わせを丁寧にしようとする。一見すると正しい対応に見えます。
しかし、問題が整理されないまま会議を増やすと、むしろ遅くなります。なぜなら、論点が曖昧な会議は、情報共有の場にはなっても、前進の場にはならないからです。
ありがちなのは次の状態です。
- 何を決める会議か分からない
- 誰が最終判断するか分からない
- 懸念は出るが優先順位が決まらない
- 結局、次回に持ち越される
この状態が続くと、会議は「進める場」ではなく「止める場」になります。会議が多い会社が遅いのではなく、設計されていない会議が多い会社が遅いのです。
5. 感情が詰まっていて、本音が上がってこない
ここが本質です。
開発が遅い会社では、感情が詰まっていることが非常に多いです。表面上は技術や仕様やスケジュールの話をしていても、その奥には別のものがあります。
- また無茶を言われるのではないかという警戒
- 言っても変わらないという諦め
- 否定されたくないという遠慮
- 責任だけ負わされることへの不信感
こうした感情があると、問題は小さいうちに上がってきません。相談が遅れます。本音が出ません。結果として、後工程で一気に問題が噴き出し、さらに遅くなります。
つまり、開発が遅い会社は、単にタスク消化が遅いのではなく、感情が詰まって情報流通が遅いことが多いのです。
この背景は、次の記事とも深くつながります。
6. 採用がうまくいかず、残った人にしわ寄せが来る
開発が遅い会社では、採用も難航しやすいです。候補者は、思っている以上に組織のズレを感じ取ります。面接官ごとのメッセージが違う。意思決定が遅い。CTOとCEOの話に一貫性がない。こうした小さな違和感が、優秀な候補者には伝わります。
採用が決まらないと、現場の負荷はさらに上がります。忙しさが増え、対話の余白が減り、ますます構造問題が見えなくなります。そして「忙しいから整えられない」「整っていないから忙しい」の悪循環に入ります。
7. 問題を人のせいにして、構造を見直していない
最後に、これが最も危険です。
開発が遅い会社ほど、「誰が悪いか」を探しがちです。PdMが弱い。CTOがダメだ。現場のスキルが低い。採用担当が弱い。もちろん個別課題はあるでしょう。
しかし、本当に見るべきは「なぜその問題が再現しているのか」です。同じような詰まりが何度も起きているなら、それは個人の問題ではなく、構造の問題です。人を替えても再発するなら、なおさらです。
なぜ人やツールを増やしても解決しないのか
開発が遅いとき、多くの会社は次の打ち手を選びます。
- エンジニアを増やす
- プロジェクト管理ツールを入れる
- 会議を増やす
- ルールを追加する
これらは悪い施策ではありません。ただし、構造問題が解けていないまま実行すると、逆効果になることがあります。
人を増やしても、意思決定が曖昧なら連携コストだけが増えます。ツールを入れても、誰が何を見るかが決まっていなければ情報が増えるだけです。会議を増やしても、感情が詰まっていれば本音は出ません。ルールを追加しても、信頼がなければ運用されません。
つまり、打ち手が効かないのではなく、打ち手が刺さる前提条件が整っていないのです。
本当の解決策は「構造を整えること」
では何をすべきか。結論はシンプルです。
役割、意思決定、優先順位、感情の流れを整えることです。
具体的には、少なくとも次の三つが必要です。
1. 役割を明確にする
CEO、CTO、PdM、EM、テックリード。それぞれが何を決め、何に責任を持つかをはっきりさせる。ここが曖昧だと、どんな優秀な人がいても遅くなります。
2. 意思決定を設計する
どの会議で何を決めるのか。どの条件がそろえば決定とするのか。誰が最終責任を持つのか。こうした設計があるだけで、スピードは大きく変わります。
3. 感情の詰まりを言語化する
ここを飛ばすと再発します。何に不安があるのか。どこで遠慮が生まれているのか。誰が何を諦め始めているのか。これを扱わない限り、また同じ場所で止まります。
それでも多くの会社が止まる理由
ここまで読むと、「やるべきことは分かった」と感じるかもしれません。けれど、実際には多くの会社がここで止まります。
なぜか。
自分たちだけでは、自分たちの構造が見えにくいからです。
経営者は経営の責任を負っています。CTOは技術の責任を負っています。現場マネージャーは日々の運営で手一杯です。みんな当事者です。当事者であるほど、問題を全体地図として見るのが難しくなります。
しかも、そこに感情の履歴が重なります。前に否定された。説明しても伝わらなかった。方針が後から変わった。そうした蓄積があると、本質に踏み込みにくくなります。
ここで必要になるもの
必要なのは、外部の視点です。利害から少し距離を取りながら、構造として問題を見られる視点です。
たとえば、経営者の壁打ち役となるメンター、あるいは実務まで踏み込める外部CTOです。
外部の視点があると、「何が遅さの原因なのか」を個人攻撃ではなく構造整理として扱えるようになります。これが大きいのです。
重要なのは「早く気づくこと」
開発の遅さは、最初は軽く見えます。「少し詰まっているだけ」「今期は忙しいだけ」「あと一人採れれば変わる」。しかし、放置すると感情が文化になり、文化が構造を固定化します。
ここまで行くと、立て直しコストは一気に上がります。だから大事なのは、問題が軽いうちに扱うことです。まだ役割整理で戻せる段階、まだ会議設計の見直しで改善できる段階、まだ人が諦め切っていない段階で手を打つことです。
開発が遅い会社ほど「忙しさ」を理由に整備を後回しにする
もう一つ見落としやすいのが、「忙しいから今は仕方ない」という感覚です。たしかに忙しいのは事実でしょう。ただ、忙しさは免罪符ではありません。むしろ忙しいときほど、役割の粗さ、意思決定の曖昧さ、感情の詰まりが表面化します。
忙しいから会議を短くする、ではなく、何を決める会議かを明確にする。忙しいから採用を急ぐ、ではなく、どんな人が機能する組織かを定義する。忙しいからこそ、構造を整える必要があります。ここを飛ばすと、忙しさは一時的ではなく、常態になります。
最後に
開発が遅いのは、必ずしも技術が悪いからではありません。
構造が詰まっているからです。
そして構造が詰まると、いくら優秀な人がいても、いくら頑張っても、前に進みにくくなります。逆に言えば、構造が整うだけで、同じメンバーでも驚くほど進むことがあります。
もし今、開発が遅い。組織に違和感がある。原因が分からない。そう感じているなら、その感覚を軽く見ないでください。小さな違和感の段階で整理することが、最もコストの低い改善策です。
ご相談
もし今、
- 開発が遅い
- 組織に違和感がある
- 原因が分からない
- 社内だけでは整理しきれない
そう感じているなら、一度整理する価値があります。
グロースウェルでは、開発組織の停滞を、単なる技術論ではなく、役割・意思決定・感情の構造から整理する支援を行っています。壁打ちレベルでも構いません。原因が見えるだけでも、次の一手はかなり打ちやすくなります。
エンジニア組織崩壊シリーズ
- 第1回：優秀なのに嫌われる上司
- 第2回：CTOが機能しているかチェックリスト15
- 第3回：エンジニア組織崩壊チェックリスト20
- 第4回：開発が遅い会社の共通点
- 第5回：CTOがいるのに事業が進まない理由
- 第6回：メンターがいない経営者はなぜ詰むのか
- 第7回：外部CTOは必要か？
- 第8回：なぜ組織は感情で崩壊するのか
- 第9回：EQはどう使うのか
上から順に読むと理解が深まります。
