記事をシェアする
開発が止まっていた組織が3ヶ月で動き出した話──CTOが機能しなかった会社の転換点
「開発が進まない。でも、なぜ進まないのかが分からない」
今回の事例は、まさにその状態から始まりました。
エンジニアは優秀でした。採用も一定できていました。プロダクトにも市場性があり、資金面にも今すぐの大きな不安はありませんでした。外から見ると、むしろ順調に見える会社です。
それなのに、内部ではじわじわと停滞が進んでいました。リリースは遅れる。仕様は固まらない。会議は増える。採用候補者に辞退される。現場では疲弊感が増しているのに、経営側から見ると「なぜこんなに遅いのか」がうまく説明できない。
この状態は、珍しいものではありません。むしろ、成長途中の会社でかなり頻繁に起きます。
まずは、同じような症状が出ていないか確認してください。
Before：表面的には問題が少なく見える会社だった
この会社には、いわゆる「分かりやすい失敗要因」はありませんでした。
- CTOがいる
- エンジニアの人数も一定数いる
- プロダクトも市場から一定の反応を得ている
- 経営陣も本気で事業を伸ばそうとしている
- 現場もサボっているわけではなく、むしろ忙しく働いている
こうした状況だと、経営者は「では何が悪いのか」と迷います。人材が弱いわけではない。技術選定に明確な失敗があるわけでもない。お金が尽きているわけでもない。だからこそ、問題が見えにくいのです。
しかし内部では、次のような状態が起きていました。
- 意思決定が遅い
- CTOとCEOの会話が噛み合わない
- 現場が何を優先すべきか分からない
- 会議で結論が出ず、持ち帰りが増える
- 採用面接で会社の魅力が一貫して伝わらない
- 優秀な人ほど疲れて静かになる
つまり、表面上は「問題のない会社」に見えても、内側では典型的な構造問題が起きていたのです。
最初に見えていた問題は「開発が遅い」だった
経営陣が最初に強く感じていたのは、シンプルに「開発が遅い」ということでした。
出したい機能が予定どおり出ない。仕様の確認に時間がかかる。作る前の調整が長い。いざ着手しても、後から前提が変わる。優先順位が揺れる。リリースの確度が低い。結果として、営業もマーケもプロダクト戦略も、全部が遅れていく。
こういうとき、多くの会社はまず「技術の問題」を疑います。スキルが足りないのではないか。人が足りないのではないか。開発プロセスが未熟なのではないか。もちろん、それらが一切関係ないとは言いません。
ただ、この会社で深掘りして見えてきたのは、別のものです。
問題は、開発そのものより前にありました。
つまり、開発が遅い原因は、実装速度ではなく、実装に入るまでの構造が詰まっていたことだったのです。
問題の正体は、3つのズレだった
整理すると、この会社では大きく3つのズレがありました。
- CEOの焦り
- CTOの防御
- 現場の諦め
1. CEOは焦っていた
事業を伸ばす責任を持つ立場として、CEOが焦るのは自然です。競合が動いている。顧客の期待も高い。採用市場も厳しい。プロダクトのタイミングを逃したくない。そのため、なるべく早く出したい、なるべく前に進めたいという圧力が強くなっていました。
ただし、その焦りは社内では「無理な要求」や「急な優先順位変更」として受け取られやすくなっていました。
2. CTOは守ろうとしていた
一方でCTOは、品質や再現性を守ろうとしていました。今ここで無理をすると後で壊れる、技術負債が蓄積する、障害が起きる、採用後の立ち上がりも難しくなる。そうした現実が見えていたからです。
しかし、その慎重さは経営側には「遅い」「守りすぎ」「話が前に進まない」と映っていました。
3. 現場は諦め始めていた
一番危険だったのはここです。現場は表立って反抗していたわけではありません。むしろ静かでした。ただ、静かなことが問題でした。
どうせまた変わる。どうせ上で決まらない。相談しても前提が変わる。そうした感覚が少しずつ広がり、提案が減り、本音が減り、無難な行動が増えていたのです。
これは、努力不足ではありません。構造的に諦めが生まれていたのです。
よくある誤解：CTOを替えれば解決するわけではない
この状態になると、多くの会社は「今のCTOでは難しいのではないか」と考えます。あるいは、もっと強い人を採用すればいい、人を増やせばいい、制度を変えればいい、と考えます。
しかし、この会社でやったのは、そこではありませんでした。
人を替える前に、構造を見直しました。
なぜなら、同じようなズレが何度も起きているなら、それは個人ではなく土台の問題だからです。仮にCTOを替えても、CEOの焦りがそのままで、意思決定の設計が曖昧で、現場の諦めが残るなら、同じことが再発します。
この会社でも、誰か一人が極端に無能だったわけではありません。全員それぞれの立場で合理的に動いていました。ただ、その合理性同士をつなぐ設計がなかったのです。
やったことは、意外なほどシンプルだった
では何をやったのか。派手なことはしていません。むしろ、かなり基本的なことを整えました。
① 役割の再定義
最初にやったのは、「誰が何を決めるのか」を明確にすることでした。
CEOが決めること、CTOが決めること、PdMが決めること、現場で判断できること。この境界線が曖昧だったために、すべての議論が長くなっていました。そこで、意思決定の対象ごとに責任範囲を整理しました。
これだけでも、会議の長さと持ち帰りの数はかなり変わりました。なぜなら、議論の終わり方が見えるようになるからです。
② 意思決定の設計
次に、会議を減らすのではなく、「決める会議」に変えました。
会議の目的を、共有なのか、相談なのか、決定なのかで分け、決定会議では何をもって結論とするのかを事前に明確にしました。また、会議後に方針が覆ることを減らすため、判断基準も共有しました。
結果として、会議数そのものが大きく減ったわけではありませんが、会議の意味が変わりました。「話しただけ」で終わる場が減り、前に進む会議が増えたのです。
③ 感情の言語化
これが一番大きかったです。
CEOは何に焦っているのか。CTOは何を守りたくて止めているのか。現場は何に疲れ、何を諦め始めているのか。ここを言葉にしました。
重要なのは、感情を吐き出す場を作ることだけではありません。感情が意思決定や関係性にどう影響しているかを整理することです。
たとえば、CEOの焦りは優先順位変更として現れていた。CTOの警戒は慎重なレビューや保留として現れていた。現場の諦めは提案減少として現れていた。これが見えるようになると、初めて対策が打てます。
3ヶ月後、何が変わったのか
もちろん、3ヶ月ですべてが理想状態になったわけではありません。ただ、組織の動きは明らかに変わりました。
- 意思決定が速くなった
- 会議で結論が出るようになった
- 優先順位の変更が減った
- 現場からの提案が戻ってきた
- 採用面接でのメッセージがそろい始めた
- 開発の見通しに対する納得感が上がった
数値だけでなく、もっと重要なものも変わりました。
空気です。
会議での緊張感が減り、確認ではなく相談が増え、意見のぶつかりが「対立」ではなく「論点整理」として扱える場面が増えました。これは、単に仲良くなったという話ではありません。組織が機能し始めたということです。
なぜ変わったのか
理由はシンプルです。
構造が整ったからです。
そして、感情が整理されたからです。
この二つは分けて考えられません。役割や意思決定だけ整えても、感情が詰まったままでは前に進みません。逆に、気持ちのケアだけしても、構造が曖昧なままでは再発します。この会社では、その両方に手を入れたから変わりました。
この事例で本当に大事なポイント
この事例で強調したいのは、誰も無能ではなかったということです。
CEOも本気でした。CTOも本気でした。現場も手を抜いていませんでした。それでも止まっていた。だからこそ、開発が遅い会社を見るときに「誰が悪いか」から入ると、本質を見誤ります。
本当に見るべきなのは、なぜその詰まりが再現しているのかです。なぜ同じようなズレが何度も起きるのか。なぜ会議が長くなるのか。なぜ本音が上がらないのか。ここを見ないと、また別の人を悪者にして終わります。
つまり、開発が止まる会社は、人が弱いのではなく、構造が弱いことが多いのです。
あなたの会社でも起きている可能性がある
もし今、次のような状態があるなら、この事例は他人事ではありません。
- 開発が遅い
- CTOと噛み合わない
- 仕様変更が多い
- 会議が長いのに決まらない
- 採用がうまくいかない
- 現場に疲弊感がある
こうした状態は、単発ではなく、同じ根から生まれている可能性があります。特に「開発が遅い」「CTOが機能しない」「組織の空気が悪い」が同時に起きているなら、かなりの確率で構造問題です。
関連する背景は、次の記事でも整理しています。
なぜ事例が重要なのか
理論だけを読んでも、人はなかなか動きません。「なるほど」で終わるからです。しかし事例になると、急に自分ごとになります。なぜなら、「うちも同じかもしれない」と感じられるからです。
この会社も、最初から大きな障害が起きていたわけではありません。少しずつ遅れ、少しずつズレ、少しずつ空気が重くなっていた。多くの組織が、まさに同じように崩れていきます。だから、違和感の段階で立ち止まれるかどうかが決定的に重要です。
事例の価値は、成功自慢ではありません。「問題が見えれば、打ち手はかなり明確になる」ということを示せる点にあります。しかも、その問題は往々にして、技術ではなく構造にあります。
小さな違和感を軽く見ないことが、結果的に最短ルートになる
経営の現場では、「今は忙しいから」「もう少し様子を見よう」と判断してしまうことがあります。実際、その気持ちはよく分かります。目の前の商談、採用、資金繰り、顧客対応、プロダクト改善。やることは山ほどあるからです。
ただ、開発の遅さだけは、放置コストが非常に高い問題です。なぜなら、遅さはそのまま機会損失になり、さらに組織不信にもつながるからです。営業は売りづらくなり、採用候補者には将来性が伝わりにくくなり、現場はまた無理な前倒し要求を受ける。その悪循環に入る前に、原因を整理することが何より重要です。
逆に言えば、違和感が小さいうちなら、打ち手はまだ軽く済みます。役割の明確化、会議の設計、優先順位の整理、感情の翻訳。こうした基本を整えるだけで、見違えるように前進する会社は少なくありません。だからこそ、「まだ大丈夫」と思える段階で立ち止まれるかどうかが、経営の大きな分岐点になります。
問題を後回しにすると、開発だけでなく、採用、評価、事業計画まで連鎖して重くなります。逆に、早めに構造として捉え直せば、改善は想像以上にシンプルになることがあります。
最後に
組織は、意図しないと壊れます。
でも、意図して整えれば戻せます。
大事なのは、問題が大きくなる前に、構造として見えるようにすることです。開発が遅い原因を、スキルや気合いの問題にせず、役割・意思決定・感情の流れとして捉え直すことです。
そうすると、打ち手は驚くほど明確になります。
ご相談
もし今、
- 同じ状態かもしれない
- 開発が遅い理由を整理したい
- CTOや組織の問題を言語化したい
- 社内だけでは原因が見えない
そう感じているなら、一度整理する価値があります。
グロースウェルでは、開発組織の停滞を、単なる技術論ではなく、構造と感情の両面から整理する支援を行っています。壁打ちレベルでも構いません。原因が見えるだけでも、次の一手はかなり打ちやすくなります。
