記事をシェアする
第3回：エンジニア組織崩壊チェックリスト20──あなたの会社はすでに崩壊しているかもしれない
エンジニア組織崩壊チェックリスト20──あなたの会社はすでに崩壊が始まっているかもしれない
開発が遅い。採用が決まらない。会議は長いのに、何も前に進まない。
もし、そんな違和感があるなら、それは単なる一時的な不調ではないかもしれません。エンジニア組織の崩壊は、ある日突然起きるわけではありません。小さなズレ、小さな不信感、小さな諦めが積み重なり、気づいたときには「なぜここまで悪くなったのか分からない」状態になっていることが多いのです。
そして厄介なのは、崩壊の初期症状ほど「よくあること」に見える点です。開発が少し遅れている。採用で少し苦戦している。会議で少し意見が出にくい。こうしたことは、単発で見れば珍しくありません。しかし、それが同時多発的に起きているなら、問題は個人ではなく構造にあります。
この記事では、エンジニア組織が崩壊に向かうときに現れるサインを20項目に整理しました。あなたの会社にいくつ当てはまるかを確認しながら、現状を客観的に見てみてください。読み終わる頃には、「何となくうまくいっていない」の正体が、かなり言語化できるはずです。
まず結論──組織崩壊は「人の問題」ではなく「構造の問題」で起きる
エンジニア組織がうまくいかなくなったとき、多くの会社はまず「誰が悪いか」を探し始めます。CTOが弱いのではないか。VPoEが機能していないのではないか。現場のエンジニアが受け身なのではないか。採用担当が弱いのではないか。
もちろん、役割ごとの課題はあります。ただ、実際には一人の能力だけで説明できるケースはそれほど多くありません。むしろ多いのは、役割期待が曖昧なまま、感情のズレと意思決定のズレが放置され、その結果として組織全体が弱っていくパターンです。
だから大事なのは、犯人探しではありません。サインを早めに見つけ、どこから崩れ始めているのかを把握することです。以下の20項目は、そのためのチェックリストです。
エンジニア組織崩壊チェックリスト20
1. 会議が長いのに、結論が出ない
議論はしているのに、最後の意思決定が曖昧なまま終わる。持ち帰りが増える。次回会議で同じ論点をもう一度話している。これは、単なる進行の問題ではありません。誰が決めるか、何を基準に決めるかが曖昧になっているサインです。
2. 決まったはずのことが、あとから覆る
一度決めた方針が、翌週には変わる。あるいは、現場は決まったと思って動いているのに、経営はまだ議論中のつもりでいる。こうしたズレが起きる組織では、意思決定の確定条件が共有されていません。現場の疲弊が一気に進む典型です。
3. CEOとCTOの会話が、どこか噛み合わない
同じ場にいて会話もしているのに、話し終わったあとに見えている景色が違う。CEOは市場と成長を見ている。CTOは品質とリスクを見ている。どちらも正しいのですが、その翻訳がないまま会話すると、両者は少しずつ「分かってもらえない」と感じ始めます。
4. 技術の話は盛り上がるのに、事業の話になると温度が下がる
技術選定、設計、開発プロセスの議論は活発なのに、ユーザー価値や事業優先順位の話になると急に熱量が落ちる。これは、開発組織が内向きになっているサインです。技術が目的化すると、組織は一見高度でも、事業には効きにくくなります。
5. 面接で候補者に惹かれてもらえない
技術的には魅力があるはずなのに、候補者に刺さらない。面接後の辞退が多い。優秀な人ほど決まらない。これは採用広報の弱さだけではなく、組織の一貫性の弱さが見えている可能性があります。候補者は、思っている以上に組織のズレを感じ取ります。
6. 面接官ごとに評価がバラバラ
ある面接官は高評価、別の面接官は低評価。その理由を聞くと、見ているポイント自体が違う。これは採用基準が言語化されていない状態です。採用基準が曖昧な組織は、組織の価値観そのものも曖昧になりやすく、入社後のミスマッチも増えます。
7. 優秀な人ほど、静かに辞めていく
問題を起こす人ではなく、むしろ真面目で優秀な人から辞めていく。これは非常に危険です。優秀な人ほど、将来の詰まりを早く察知します。「ここでは良くならないかもしれない」と感じた人から、静かに離れていくのです。
8. 現場からの提案が減っている
以前は改善提案や新しいアイデアが出ていたのに、最近は言われたことをこなす空気が強い。これはモチベーションの問題に見えて、実際には心理的安全性や期待値設計の問題であることが少なくありません。提案しても変わらない、拾われない、評価されない。そう感じると、人は受け身になります。
9. 仕様変更が頻発し、現場が振り回されている
市場変化に応じて方針が変わること自体は悪くありません。しかし、背景説明のない仕様変更が続くと、現場は「また変わるのだろう」と学習します。その結果、主体性も品質意識も落ちていきます。変化よりも、変化の扱い方に問題がある状態です。
10. 技術負債の話が、いつも先送りになる
今は忙しいから。リリースが優先だから。売上が先だから。そうして技術負債が積み上がるのは、よくあることです。ただ、それを毎回同じ言い方で先送りし続けているなら、すでに危険信号です。将来の負債は、ある日突然、今のスピードを奪います。
11. 開発スピードが落ちているのに、理由が説明できない
前より遅い。なのに、なぜ遅いのかを誰もうまく説明できない。タスクが複雑だから、案件が重なっているから、人が足りないから──どれも一部は正しいかもしれません。しかし本当の問題は、遅さの正体が分解されていないことです。分解できない組織は改善できません。
12. 役割分担が曖昧で、責任の所在もぼやけている
CTO、EM、PM、テックリード、それぞれが何を決め、何に責任を持つのかが曖昧になっている。すると、重要な論点ほど宙に浮きます。誰かがやるだろう、誰かが見ているだろう、で進んでしまう。これは成長フェーズの組織で非常に起きやすい崩れ方です。
13. 1on1が形骸化している
予定は入っている。時間も取っている。しかし話している内容が、業務進捗の確認だけで終わっている。違和感や感情の揺れが扱われていない。1on1が単なる報告会になると、組織は小さな不信感を拾えなくなります。
14. 問題が起きたとき、学習より責任追及が先に来る
障害や失敗が起きたとき、「次にどう防ぐか」より「誰の判断だったのか」が先に話題になる。これが続くと、現場は防御的になります。報告は遅れ、チャレンジは減り、リスクの共有も弱くなります。責任を明確にすることと、犯人探しをすることは別です。
15. マネージャーが現場と経営の板挟みで消耗している
中間層が疲れている組織は危険です。上からの期待と下からの不満を一身に受け、翻訳もし、調整もし、説明もし、感情の受け皿にもなっている。こうした状態が続くと、マネージャー自身が摩耗し、最終的には組織全体の接着剤が失われます。
16. 数字は見ているのに、感情を見ていない
バーンダウン、採用数、離職率、リードタイム。こうした数値は重要です。ただ、数字だけを見ていると、組織の本当の危険信号を見逃します。不満、不信、遠慮、諦めは、数字に出る前に空気に出ます。空気を読めない組織は、数字が悪化してからしか動けません。
17. 「忙しい」が免罪符になっている
対話が減った理由も、設計が荒れた理由も、採用基準が曖昧な理由も、すべて「忙しいから」で片づけられている。忙しさは事実かもしれません。しかし、忙しいときほど構造の粗さが出ます。忙しいことを理由に整えるべきものを放置すると、さらに忙しくなります。
18. 現場が経営を信用していない、または経営が現場を信用していない
これは明言されないことが多いですが、かなり本質的なサインです。現場は「どうせ分かってもらえない」と思い、経営は「任せると遅い」と思っている。この状態では、どれだけ制度を整えても機能しません。信頼がなければ、すべてがコスト高になります。
19. CTO自身が孤立している
CTOが強く見える組織でも、実は本人がかなり孤立していることがあります。経営からは結果を求められ、現場からは期待と不満を向けられ、どこにも本音を出せない。するとCTOは、論理と正論で自分を守り始めます。それがさらに距離を生む。孤立したCTOは、組織の要ではなく、ボトルネックになりやすいのです。
20. 「このままではまずい」と感じているのに、誰も全体を整理していない
実は、これが一番危険です。違和感がある。少しずつ悪くなっている気がする。なのに、誰も立ち止まって全体を見ていない。目の前の案件、採用、障害対応に追われ、構造の見直しが後回しになっている。この状態は、崩壊の直前というより、すでに崩壊が始まっている状態です。
何個当てはまりましたか？
目安として、次のように考えてください。
- 0〜3個：現時点では大きな崩れは見えません。ただし、同じ項目が繰り返し起きていないかは要確認です。
- 4〜7個：注意が必要です。すでに組織のどこかで構造的なズレが起きている可能性があります。
- 8〜12個：かなり危険です。個別対応ではなく、組織全体の見直しが必要な段階です。
- 13個以上：崩壊は将来のリスクではなく、現在進行形で始まっていると考えた方がよい状態です。
重要なのは、点数そのものよりも、どの領域に偏っているかです。意思決定なのか、採用なのか、信頼関係なのか。偏りを見れば、どこから立て直すべきかが見えてきます。
ここまで読んで、「いくつか当てはまる」と感じた場合、
原因は個人ではなく、組織の構造にある可能性が高いです。
特に多いのが、「CTOが機能していない状態」です。
なぜ崩壊は起きるのか──本質は「感情のズレ」と「翻訳不足」にある
ここまでの20項目を見ると、技術、採用、会議、役割、評価など、問題が散らばって見えるかもしれません。しかし、根っこは意外と共通しています。それは、感情のズレが放置されていること、そして経営と技術の翻訳が足りないことです。
CEOは焦っている。CTOは守ろうとしている。現場は疲れている。マネージャーは板挟みになっている。採用担当は違和感を言語化できていない。こうした状態で、ロジックだけで前に進もうとしても、組織は動きません。組織は、論理だけでなく感情でも動くからです。
だから必要なのは、表面的な改善策を1つ打つことではありません。役割期待を整理し、意思決定ルールを明確にし、感情と違和感をきちんと扱い、必要なら外部の視点も入れながら、構造を立て直すことです。
最後に──崩壊は、早く気づけば立て直せます
エンジニア組織の崩壊は、突然起きるように見えて、実際にはずっと前から始まっています。そして幸いなことに、早い段階で気づければ立て直せます。問題が大きくなってから人を替えるより、崩れ始めた構造を見直す方が、はるかにコストは低く、効果も大きいからです。
もし今、この記事のチェック項目に複数当てはまり、「うちも少し危ないかもしれない」と感じたなら、その感覚は無視しない方がいいと思います。必要なのは、誰かを責めることではなく、今の組織で何が起きているかを整理することです。
よくある誤解
最後に一つだけ補足すると、組織が崩れ始めたときに最も危険なのは、「まだ何とかなるだろう」と曖昧に捉えることです。採用を強化すれば解決する、制度を整えれば改善する、優秀な管理職を一人入れれば変わる。こうした打ち手が効くこともありますが、根本の構造を見ないまま部分最適を重ねると、むしろ複雑さが増して立て直しが難しくなります。
特に、CTOやマネージャー個人の努力に依存している状態は危険です。頑張っている人が支えている組織は、一見回っているように見えて、実際にはかなり脆い。仕組みとして回る状態に変えない限り、同じ問題は形を変えて繰り返されます。
ご相談について
グロースウェルでは、CTO・VPoE・開発組織に関する違和感を、単なる技術論ではなく、組織構造と感情の両面から整理する支援を行っています。
- CTOが機能しているのか客観的に見たい
- 経営と開発のズレを言語化したい
- 採用や組織づくりまで含めて相談したい
- 外部CTO・技術顧問の活用を考えたい
もし今、エンジニア組織に違和感があるなら、まずは壁打ちレベルでも構いません。問題を整理するだけでも、次の一手はかなり見えやすくなります。
エンジニア組織崩壊シリーズ
- 第1回：優秀なのに嫌われる上司
- 第2回：CTOが機能しているかチェックリスト15
- 第3回：エンジニア組織崩壊チェックリスト20
- 第4回：開発が遅い会社の共通点
- 第5回：CTOがいるのに事業が進まない理由
- 第6回：メンターがいない経営者はなぜ詰むのか
- 第7回：外部CTOは必要か？
- 第8回：なぜ組織は感情で崩壊するのか
- 第9回：EQはどう使うのか
上から順に読むと理解が深まります。
