AIでチームが壊れる理由｜「自分で書くベテラン」と「AI任せの若手」をどう動かすか｜AI時代のPM生存戦略③
「AIを使えば、もっと楽になるはずだった」 そう思って導入したはずなのに、 なぜかチームの空気がギクシャクし始める。
ベテランは「自分で書いた方が早い」とAIを避け、 若手は「AIがやってくれるので大丈夫です」と中身を見なくなる。気づけば、同じチームの中で「前提が違う人たち」がバラバラに動き、 進捗も品質も、どこか噛み合わない状態に陥っている。
そんな違和感を感じていないでしょうか。
第2回では、「ハイブリッドWBS」や「QAのルール」といった仕組みの作り方を解説しました。 しかし、どんなに優れた仕組みも、それを動かす「人」が変わらなければ機能しません。
第3回の今回は、AI導入によって顕在化したチーム内の「分断」の正体を明らかにし、 PMがどうチームを再構築すべきか、そして何をもってエンジニアを評価すべきかを解説します。
現場を停滞させる「2つの極端なアンチパターン」
あなたのチームにも、こんな2極化が起きていないでしょうか。
パターンA：「自分で書く」に固執するベテラン
「AIのコード？信用できないでしょ。自分で書いた方が早いし安心だから」
職人気質のシニアエンジニアやベテラン層に多いパターンです。長年自分の腕一本でやってきたという強いプライドもあり、こうしたエンジニアはAIが吐き出したコードを警戒し、プロンプトを試行錯誤するくらいなら、最初から最後まで自力でコーディングしてしまいます。
PMから見たこのパターンのリスクは、「プロジェクトのボトルネック化」です。 こうしたベテランが書くコードは確かに高品質かもしれません。しかし、AIをフル活用して数倍のスピードで実装を進める競合他社や若手メンバーに比べると、圧倒的に作業スピードが遅くなり、結果的にチーム全体の足を引っ張ることになります。
パターンB：「AIに丸投げ」する若手
「AIがこう言ってるんで大丈夫です。ちゃんと動いてますし」
こちらは逆に、AIを過信しているパターンです。AIを使えば簡単にそれらしいものができてしまう「手軽さ」もあり、指示を出せば猛スピードでコードが返ってくるため、コードの内部ロジックやアーキテクチャの背景をまったく理解しないまま「完成しました」と提出してきます。
PMから見たこのパターンのリスクは、「当事者意識の欠如と時限爆弾」です。 このタイプの若手はバグが起きたときに自力で原因を切り分けられません。さらに恐ろしいのは、「AIが出したコードだから、自分に責任はない」という無意識の責任転嫁が起きてしまうことです。
エンジニアの「価値」を再定義する
この「自分で書きたがるベテラン」と「AI任せの若手」の分断は、なぜ起きるのでしょうか。
それは、そうしたメンバーの中にある「エンジニアの価値＝自力でコードを書くこと（タイピングの速さや正確さ）」という古い固定観念がアップデートされていないからです。
コードを大量に生み出すこと自体の価値は、AIによって限りなくゼロに近づきました。これからのエンジニアに求められるのは、クリエイター（創る人）から「ディレクター・監査役（指揮し、検証する人）」への役割シフトです。
具体的には、「AIへの指示設計」「出力の妥当性判断」「非機能リスクの指摘」といった役割です。
- ベテランに求めるシフト
自らコードを書くプレイヤーを卒業し、長年の経験と勘を活かして「AIの出力をレビューする強固な監査役」、あるいはシステム全体を見渡す「アーキテクチャ設計」に専念してもらう。 - 若手に求めるシフト
AIの出力を鵜呑みにするオペレーターではなく、エッジケースを想定したテストコードを自ら設計し、AIを厳しく検証・指揮する「ディレクター」としての責任を持たせる。
明日から使える「新しい評価基準」マトリクス
役割が変われば、当然「何をもって優秀とするか」という評価基準も変えなければなりません。
このままでは、「頑張って自力で書いた人ほど損をし、丸投げした人が評価される」という歪んだ状態になりかねません。
これまでの「どれだけ早く実装できたか」「バグを出さなかったか」という基準を廃止し、「どうAIを指揮し、リスクを制御したか」を評価の中心に据える必要があります。
AI時代のエンジニア評価基準（Before/After）
PMやマネージャーが、メンバーとの1on1や人事評価ですぐに使える「AI時代のエンジニア評価基準」のBefore/Afterをまとめました。
| 評価の観点 | ❌ 従来評価（Before） | ⭕ AI時代評価（After） |
|---|---|---|
| 生産性 | 自力での実装スピードが速い／コードの記述量が多い | AIに適切な指示（プロンプト）を出し、再現性とスピードのある成果を出せる |
| 品質担保 | 自身のコーディングスキルで、バグのないコードを書ける | テスト設計を緻密に行い、AIが引き起こす未知の不具合を未然に防げる |
| 専門性 | 特定の言語やフレームワークに詳しい | AIの出力に潜むリスク（性能要件、セキュリティ脆弱性など）を指摘し、修正できる |
「AIを使わないベテラン」には、AIを使えばもっと生産性が上がることを評価基準で示し、「AIに丸投げする若手」には、品質担保とリスク指摘ができなければ評価されないことを明確に伝えます。
まとめ：チームのカルチャーを作り変える
「コードを書くチーム」から「AIを乗りこなすチーム」へ。
PMの重要な仕事は、AIと競おうとするベテランのプライドを解きほぐし、AIに依存する若手にプロとしての責任を持たせることです。このカルチャーの変革こそが、AI時代の真のチームビルディングと言えます。
AI時代において問われるのは、「どれだけ書けるか」ではありません。 「どれだけ責任を持って判断できるか」です。 そしてその判断の質こそが、これからの市場価値を決めます。
さて、ここまではプロジェクトの管理手法やチームのマネジメントについて語ってきました。 では、この激動の時代において、私たち「PM自身」のキャリアはどうなっていくのでしょうか？
次回はいよいよ最終回（第4回）。AI時代に淘汰されるPMと、市場価値が上がり続けるPMの違い。「PM自身のキャリア生存戦略」について解説します。
シリーズ：AI時代のPM生存戦略
【第1回】実行型AIで再定義されるシステム開発の3つの常識
【第2回】「AIに任せました」で炎上させない。ハイブリッドWBSとQAの再構築
【第3回】AIでチームが壊れる理由｜「自分で書くベテラン」と「AI任せの若手」をどう動かすか（本記事）
【第4回】AIに駆逐されるPM・無双するPMの違いと、次世代のキャリア戦略
