この記事は連載「生成AI時代、エンジニアは何で食っていくのか」の実践編 #01 です。
- 導入編はこちらからどうぞ。
- 実践編 #01 「全員がAIを使える」チームは、なぜ崩壊するのか ← 今ここ
- 実践編 #02 誰もやらなかった仕事をやる人が、次の時代のキーマンになる
- 実践編 #03 「AIネイティブチーム」の現場で何が起きているか
- 実践編 #04 PGからプロンプトアーキテクトへ。キャリアを変えた人たちの話
- 実践編 #05 組織がAIを導入して半年後、生き残ったエンジニアの共通点
「うちのチームは全員Copilot使ってます」
最近、こういう話を聞く機会が増えました。ツールは揃っている。メンバーも前向き。導入も完了。でも——なんとなくチームがうまく回っていない。
そういう現場、実は増えています。
AIツールを「全員が使える」状態にしたのに、なぜかうまくいかない。その理由を考えてみると、共通したパターンが見えてきました。
崩壊パターン①：「誰もコードを理解していない」問題
AIが書いたコードを、誰もレビューできない。
これが起きるのは、チーム全員がAIに頼ってコードを書くようになったとき。PGがAIに実装させ、SEがAIに設計書を書かせ、PMがAIに議事録を作らせる。それ自体は悪くない。
問題は、誰もそのアウトプットを「自分の言葉で説明できない」状態になることです。
あるチームで聞いた話です。レビューでコードの意図を聞くと「AIが出したのでよくわからないですが、テストは通っています」という返答が増えた。リリース後に不具合が出て原因調査をしたとき、誰も「なぜこのコードがここにあるのか」を説明できなかった。
製造業で言えば、機械が作ったものを誰も検品せずに出荷している状態です。
どう対処するか
コードレビューのルールを「動くかどうか」から「説明できるかどうか」に変える。
「このロジックを自分の言葉で説明してください」をレビューの必須項目にするだけで、AIへの丸投げに歯止めがかかります。最初は時間がかかっても、これをやり続けると「理解してから使う」文化が育ちます。
崩壊パターン②：「責任の所在がない」問題
AIが作ったものの責任は誰が持つのか。これが曖昧になると、チームは機能不全に陥ります。
「AIが出したので」「Copilotが書いたので」という言葉が免罪符になり始めたら要注意です。
不具合が出たとき、セキュリティ問題が発覚したとき、「でもAIが書いたコードだから」で片付けようとする空気が生まれる。これはツールの問題ではなく、チームの責任文化の問題です。
AIはあくまで道具。そのアウトプットに責任を持つのは、それを使った人間です。
どう対処するか
「AIを使ったコードの責任者は誰か」を明示するルールを作る。
たとえばプルリクエストに「このコードのAI使用率と、自分でレビューした観点」を書く欄を設けるだけでも変わります。形式的に見えるかもしれないですが、「自分が責任を持った」という意識が生まれることが重要です。
崩壊パターン③：「スキルの空洞化」問題
これが一番じわじわと怖いパターンです。
AIを使い続けることで、チームの地力が下がっていく。特に若手・経験の浅いメンバーへの影響が大きい。
コードを書きながら理解する、という学習プロセスをAIがショートカットしてしまう。「動くものが作れる」けど「なぜ動くのかわからない」エンジニアが量産されていく。
5年後にそのメンバーが中堅になったとき、チームの技術的な判断力はどうなっているか。これは今すぐ数字に出ないから見落とされがちですが、長期的にはチームの土台を蝕む問題です。
どう対処するか
AIを使わない時間を意図的に作る。
全否定ではなく、「この課題はAIなしで考えてみる」という習慣を若手に持たせる。AIのアウトプットを見る前に「自分ならどう書くか」を5分考えてみる、というだけでも違います。
学習のプロセスは省略できません。AIはあくまで「作業の補助」であって、「理解の代替」ではない。
崩壊パターン④：「コンテキストの断絶」問題
AIを使い始めると、チーム内のコミュニケーションが変質することがあります。
「仕様を決めたい」→「AIに叩き台を作らせる」→「それをSlackに貼る」→「みんなAIのアウトプットをベースに話す」
こうなると、「なぜその仕様なのか」という文脈がチームの中に蓄積されなくなります。
AIが作った叩き台は、そのチームの歴史や背景を知らずに作られたもの。それをそのまま採用し続けると、意思決定の文脈が失われていく。半年後に「なんでこういう仕様になったんでしたっけ」と誰も答えられない状態が生まれます。
どう対処するか
AIのアウトプットをベースにする場合でも、「なぜこれを採用したか」「どこを変えたか、なぜか」を必ず言語化して残す。
ツールはNotionでもConfluenceでもいい。大事なのは「人間の判断の記録」を意識的に残すことです。
共通する本質：「AIは個人を賢くするが、チームを賢くするとは限らない」
4つのパターンを見てきて、共通していることがあります。
AIは個人の生産性を上げます。でも、それをチームの知恵として蓄積させる仕組みがないと、「個々人はAIで強化されているのに、チームとしては弱くなっている」という逆説が生まれます。
チームとは何か。それは個人の集合ではなく、文脈・責任・信頼の共有体だと思っています。AIはその「共有」を助けてはくれない。そこは人間が意識的に設計しないといけない。
まとめ
| 崩壊パターン | 本質 | 対処の核心 |
|---|---|---|
| 誰もコードを理解していない | 説明責任の消失 | 「説明できるか」をレビュー基準に |
| 責任の所在がない | AIへの責任転嫁 | アウトプットの責任者を明示する |
| スキルの空洞化 | 学習プロセスの省略 | AIなしで考える時間を意図的に作る |
| コンテキストの断絶 | 判断の文脈が残らない | 人間の意思決定を必ず言語化・記録する |
次回 #02 では、こうした変化の中で「新しいキーマン」になっていく人たちの特徴と、そのなり方を書きます。
あなたのチームでは似たような現象が起きていますか？「うちはこう対応した」「こんなパターンもあった」という声、ぜひコメントで聞かせてください。
株式会社なかのひとカンパニーでは随時エンジニアを募集しています。詳しくは採用情報ページをご確認ください。