〜開発組織が陥りやすい6つの罠〜
AI導入を進める現場で、似たような壁にぶつかる組織が増えている。
ツールは入れた。使っている。
それでも「開発が速くなった」と言い切れる組織は、ほとんどない。
結論はシンプル。
失敗の原因はAIではない。フローを設計していないことにある。
この記事は、AI導入を推進しているEM・テックリード向け。
入門者向けではない。
ツールを配り終わって「次に何をすべきか」を探している段階の人を想定している。
現場で繰り返し見るのは、たいてい同じ6つのパターン。
順に整理する。
1. なぜ、AI導入は9割失敗するのか
理由はシンプル。
「ツールは速くなった。組織は速くなっていない」から。
AIを導入した瞬間、変わるのは実装速度だけだ。
コードは速く出る。PRも増える。
しかしその先にある、
- レビュー
- 設計判断
- 進捗確認
- 意思決定
ここの速度は、人間のままだ。
AIで生まれた「速さ」は、フローのどこかで詰まる。
詰まった瞬間、開発は導入前より遅くなる。
兆候は分かりやすい。
AIがコードを書く速度が上がり、PRが大量に上がる。
しかし、レビューする人数も時間も変わらない。
その瞬間、PR待ちの山ができる。
同じ時期に、設計を理解せずPRを出す実装者、コメント往復だけが伸びるレビュー、
「もうすぐ終わります」と報告される動かない実装、
これらが連鎖的に表面化する。
AI導入で起きているのは、
「ツールの導入」ではなく「ボトルネックの移動」だ。
ここを設計せずに走り出した組織が、9割失敗する。
2. 現場で繰り返される、6つの失敗パターン
パターン1. ツールだけ配って、フローを設計していない
最も多い失敗。
「ツールを導入すれば、現場が勝手に使いこなす」と期待してしまう。
実際に起きるのは逆だ。
ツールは配れば終わり。
変化は、設計しないと起きない。
使う人と使わない人で生産性に差がつき、
「結局、属人的じゃないか」という声が出る。
そこで止まる組織が多い。
機能した現場でやったことはシンプルだ。
「悩んだら、まずAIに聞く」をルールにする。
言語化できなくてもいい。ポエムのように思っていることを吐き出せば、それで足りる。
- 議論が10分止まったらAIに渡す
- 仕様が曖昧ならまず壁打ちする
- まとまらなければポエムで吐き出す
精度より、まず言語化。
ツールではなく、文化と動線を設計する。
ここから始めないと、ツールはどれだけ配っても定着しない。
パターン2. 設計レビューを飛ばして、実装レビューで消耗する
AIが書いたPRは、実装の細部はだいたい合っている。
だからレビュー対象は、
- DB設計
- アーキテクチャ
- インターフェース設計
ここに絞るべきだ。
しかし現場では逆をやる。
細かい実装に対してコメントを往復させる。
そして肝心の設計判断は、誰も見ていない。
結果として
「AIが書いたコードを、設計レベルで誰も見ていない」
状態が完成する。
3ヶ月後、誰も理解できないコードベースが残る。
機能するレビュー設計は、対象を絞るところから始まる。
- DB設計とアーキテクチャは厳格にレビューする
- 実装レベルは個人に任せる
- mustでない指摘は、その場で通さずチケット化する
「実装を最初から完璧に」を捨てる代わりに、短期で成果発表会を入れる。
リリース後のリファクタリングを必ず通す。
設計が守られていれば、実装の粗はあとから直せる。
パターン3. PRを24時間で流す仕組みがない
AIで実装が速くなる。
PRが増える。
レビューは詰まる。
このとき必要なのはレビュー精度ではなく、ルールだ。
- PRは24時間以内にマージする(レビューが揃わなくてもマージする)
- mustでない指摘はチケット化する
- コメントが往復し始めたら、すぐmeetで5分話す
ルールがない組織では、PRはレビュー待ちの山に積み上がる。
速くなったはずのチームが、PR詰まりで導入前より遅くなる。
ルールを入れた途端、PRは流れ始める。
完璧でなくてもマージされ、必要な議論はチケットで残る。
言語化が苦手な人とテキスト議論を組み合わせると、終わらない。
止まりそうになった瞬間に、同期で話す。
完璧なコードより、止まらない開発の方が、結果として品質が高い。
「止めない」を仕組みで担保すること。
パターン4. 要件が曖昧なまま、AIに実装させる
AI開発で一番難しいのは、実装ではない。
要件定義だ。
要件が曖昧だと、
曖昧な要件 → 曖昧な設計 → 曖昧なコード、と崩れていく。
そして、それぞれのフェーズでAIが「それっぽい」アウトプットを出してしまうから、
問題が最後まで顕在化しない。
機能するのは「LLMを編集者として使う」フローだ。
- ChatGPTかGeminiで、作りたいものを壁打ちする
- もう一方のLLMで相互レビューさせ、粗を出す
- 元のLLMで再整理し、要件を固める
- テンプレート化された要件定義手法(BMADなど)に載せる
- cc-sdd / kiro のような仕様駆動開発フローに乗せ、Requirements を生成する
- Codexなどでもう一度レビューし、納得できる状態でFR(Functional Requirement)に落とす
人間1人より、LLM2つの方が要件の粗が見える。
ここを飛ばすと、kiro のコマンド一発で design も tasks も実装も走り、
数日後に「動かない」が降ってくる。
要件定義に時間をかける方が、結果として総時間は短い。
パターン5. AI修正ループに入り、デバッグ思考を放棄する
AI開発で最も危険な行動。
とりあえずAIに直させる。
動かない → AIに修正依頼 → 別の場所が壊れる → また修正。
このループに入ると、永遠に終わらない。
実際に2週間溶けた現場を見たことがある。
Taskは完了している。デイリーでは「もうすぐ終わります」と本人が報告している。
しかし動かない。
「動かない」とだけ伝えて修正させているから、AIは全体仕様を踏まえずに局所だけ書き換える。
別の場所が壊れ、また修正させる。
原因はシンプル。
AIは「修正」はできるが、「原因特定」はしていない。
それっぽいパッチを当てているだけで、問題の構造を理解しているわけではない。
抜け出すきっかけは地味だ。
FR(要件)を1項目ずつ確認し直す。
何ができていて、何ができていないかを人間が把握する。
エラーログを読み、再現条件を確認し、テストケースを潰していく。
普通のデバッグだ。
AI時代でも、デバッグの基本は変わらない。
切り分けがない修正依頼は、ほぼ確実にループに入る。
パターン6. Task完了を「完成」と扱い、動作確認を進捗にしない
AI開発で最も信用できない指標が、
- Task完了数
- PR数
- コミット数
この3つだ。
AIはコードを書ける。
だから、これらの指標は簡単に増える。
増えるが、動いているかは別の話だ。
現場でよく聞く報告がある。
「もうすぐ終わります」
この報告から、2週間終わらない。
本人もそれっぽく動くまで詰めているが、仕様通りには動いていない。
そしてAIに修正をループさせている。
ここで効くのが、コードレビュー会だ。
実装した本人に説明させると、AIが書いたコードを理解しているかが一発で分かる。
説明できなければ、Taskが完了していようと、その実装は終わっていない。
ブラックボックス化したエンジニアの開発状況は、
設計やコードを読めるEMが場を作るだけで、ほとんど可視化できる。
AI時代のEMに最も求められるのは、現場感だ。
進捗管理は、報告ではなく現場で見る。
進捗は、Taskではなく動作で見る。
- 仕様通り動く
- テストが通る
ここまでが「完成」だ。
進捗管理を、動作確認に置き換える。
まとめ
繰り返しになるが、AI導入の失敗は構造的に決まっている。
原因はAIではない。フローを設計していないこと。
整理すると6つ。
- ツールだけ配って、フローを設計していない
- 設計レビューを飛ばして、実装レビューで消耗する
- PRを24時間で流す仕組みがない
- 要件が曖昧なまま、AIに実装させる
- AI修正ループに入り、デバッグ思考を放棄する
- Task完了を「完成」と扱い、動作確認を進捗にしない
**派手な仕掛けはない。
ただ、現場で機能するフローを設計するだけ**だ。
各パターンの掘り下げは、これから1本ずつ別記事にしていく。
このシリーズが、AI導入で同じ罠に落ちる組織を1つでも減らせれば十分だ。
関連記事
(関連記事は順次追加します)
最新の現場ログはXで
開発フローや組織のリアルを毎日発信しています。