気がつくとチームから新卒・第二新卒が消えていた、という感覚を持つEMが増えている。
採用枠がなかったわけではない。AIが生産性を上げたので「今年は採用を抑えよう」という判断を繰り返していたら、ふと気づけばチームの最年少メンバーが入社4年目になっていた——そういう話だ。個社の事情のように見えて、実はグローバルで起きている構造的な現象である。
グローバルの大手テック企業における新卒採用は過去3年で50%超減少しており（Rest of World, 2025）、Stanford Digital Economy LabによるADP給与データの分析ではエントリーレベルの開発者採用が2022年ピーク比で約67%減少したとも報告されている。日本でも、AIを組織的に活用する企業の55.4%が新卒採用を削減していると2025年9月のアカリク調査（対象: 採用担当者112名）が明らかにした（HRpro, 2025）。
この記事では「なぜ育成パイプラインが崩壊しつつあるのか」を掘り下げ、EMが組織設計レベルで今すぐ取れるアクションを提示する。
なぜ「採らない」が合理的に見えてしまうのか
採用担当者の70%が「AIはインターンの仕事をこなせる」と考えており、37%は「新卒よりAIを使いたい」と回答している（Stack Overflow Blog「AI vs Gen Z」, 2025）。現場のシニアエンジニアがAIツールと組み合わさることで、ジュニア数人分のアウトプットを出せる状況では、採用しない判断が短期的には正しく見える。
Salesforceのマーク・ベニオフCEOが「2025年はエンジニアをほぼ採用しない」と公言したのは象徴的だった（IT Pro, 2025）。採用を絞った分、AIエージェントへの投資で穴を埋める——そのロジック自体は、四半期で評価される組織の中では通りやすい。
問題は、この判断が5〜7年後に爆発することだ。
AWSのCEOマット・ガーマンは、2025年のインタビューで繰り返しこう警告している。
「ジュニアをAIで代替するのは私が聞いた中で最もバカげたことの一つだ。育成パイプラインがなく、ジュニアをメンタリングして育てる仕組みがなければ、最終的にその全体が自爆する。」（Fortune, 2025）
通常、ジュニアがシニアになるには5〜7年かかる。今年ジュニア採用を止めた組織は、2031〜2032年にシニアの補充が効かなくなる。これが業界で「ミッシング・ジェネレーション」と呼ばれる問題の本質だ。
崩壊の構造的原因
育成パイプラインの崩壊は、「採用が減った」という表層の話ではない。採用できたとしても育てられない問題が同時に起きている。
「最初の階段」が消えた
ジュニアエンジニアが従来担っていたタスク——バグ修正、ユニットテスト作成、ドキュメント更新、データ移行スクリプト——は、まさにAIが最も得意とする作業群と重なる。これらは単純作業ではなく、「基礎を手で積み上げる教育的なタスク」だった。
Microsoft Azure CTOのマーク・ラッシノビッチとVPのスコット・ハンセルマンは、Communications of the ACM（2026年4月号）に掲載された査読論文でこの現象を「ナローイング・ピラミッド仮説」と命名し、学習の梯子の最初の段が取り除かれた状態だと警鐘を鳴らした（InfoQ, 2026）。
入門的な実装機会を失ったジュニアが「AIの出力をレビューする役割」だけをこなしていると、何を基準に良し悪しを判断するのかがわからないまま時間だけが過ぎていく。
「教える時間」がシニアから消えた
AIツールはシニアエンジニアの生産性を上げると同時に、メンタリングをしないインセンティブも生み出した。自分がAIを使えば数時間でこなせる仕事を、ジュニアに説明しながら一週間かけて任せる理由が薄くなる。
LeadDev「AI Impact Report 2025」（880名対象）の調査では、技術リーダーの38%が「AIツールによってシニアからジュニアへの直接メンタリング量が減少した」と回答している。加えて、シニアはAI生成コードのレビュー負担が集中する役割にシフトしており、「シニアが問題をどう考えるか」をジュニアが目撃する場面も減った。
AIへの依存が「考える筋肉」を奪う
MIT Media LabのKosmynaらによるEEG研究（54名対象, 2025年）では、LLMを使って文章を書いた参加者は、後でAIなしで同じタスクをすると、AIを使わなかった参加者より有意にパフォーマンスが低下することが示された（Your Brain on ChatGPT - MIT Media Lab）。早期キャリア開発者に関する80件の研究のシステマティックレビュー（2025年）も、AIツールは成果物の提供を加速させる一方で「内省とスキル成長を犠牲にする」と指摘している（BCG, 2025）。
プロンプトだけで実装してきたジュニアは、本番バグに直面したとき手がかりを失う。そのコードを自分で書いた経験がないため、どこから疑えばいいかがわからないのだ。
EMが今から手を打つべき設計
原因がわかれば、対策も同じレベルで考える。個人のメンタリング改善ではなく、組織の仕組みとして設計する話だ。
タスク設計——ジュニア専用の「学習ゾーン」を組み込む
バックログのタスクをすべてAIエージェントに割り当て、ジュニアがそのレビューだけを担当する構造はアンチパターンだ。レビューには「元から理解している人間」でなければ機能しない。
私が推奨するのは、バックログを「AI解放タスク（AIを自由に使ってよい）」と「ジュニア学習タスク（AIは補助のみ）」に分けてタグ管理することだ。ジュニア学習タスクに向くのは、デバッグ、インフラ診断、ログ分析、ドメイン理解が深まるリファクタリングといった作業だ。
週1回のペアプロまたはモブプロでシニアがAI活用の判断基準を実演・言語化する場を設けることも効果が大きい。「なぜここでAIに任せるのか、なぜここでは手を動かすのか」を言語化する機会そのものが、ジュニアにとっての教科書になる。「AIに聞く前に10分考える」ルールを明示的に設けているチームも存在する。強制ではなく、考える習慣を構造として埋め込む発想だ。
クラシルでは月額10万円までのAI開発ツール費用を全社員に提供しながら、エンジニア・デザイナー・PM・マーケターが単一のビジネスKPIに向かって動く職種横断スクラム体制を採用している。ジュニアが自然に「何を作るべきか（事業視点）」を習得できる環境設計として参考になる（Findy Media, 2025）。
評価設計——「教える時間」を業績評価の正式項目にする
現在の多くの組織では、シニアエンジニアのメンタリング時間は評価されない「ボランティア」扱いだ。AI時代にシニアは自分のアウトプットをAIで最大化できるため、メンタリングをサボるコストが見えにくい。評価に組み込まない限り、メンタリングは自然に消える。
よくある失敗は「週1回30分の1on1を義務づけたが形骸化した」というパターンだ。評価に反映されなければ、シニアにとってメンタリングは「タスク外の作業」であり続ける。
私が推奨するのは、シニア・スタッフエンジニアの半期評価に「育成貢献」セクションを正式追加することだ。「担当ジュニアの6ヶ月後の自律度変化」「ジュニアの昇格推薦数」「1on1・ペアプロ実施時間のログ」を評価項目にする。また、メンタリング工数（週2時間程度）をスプリント計画・工数見積もりに公式に組み込むことで、「忙しくてできなかった」という言い訳を構造として防ぐ。
チームレベルでモニタリングするKPIも定義しておくと育成の状態が見えてくる。「ジュニア→ミッドレベル昇格率（12〜24ヶ月以内）」「ジュニアの2年定着率」「自律度スコア（1〜5段階）」がその起点になる。EMの評価そのものにこれらのKPI達成状況を連動させることで、育成は「やれたら良いもの」から「組織の正式ゴール」になる。
ポジション設計——ジュニアのロール定義を書き直す
「ジュニアの仕事 = コードを書く」という前提が崩れたまま採用・評価し続けると、ジュニアは自分の貢献領域を見失う。採用前に「ジュニアに何をやってもらうか」を再定義する作業が先行して必要だ。
Optimum Partnersの提言が参考になる（Optimum Partners, 2026）。彼らが提唱する「AI Reliability Engineer（ARE）」の仕事は、AIエージェントの作業を誘導する技術仕様（Technical Spec）の作成、AIが生成したコードのハルシネーションチェック（外部ライブラリが正規のものか、ビジネスロジックが要件と一致しているか）、エッジケースの特定と複合インテグレーションテストの担当だ。コーディングスキルよりもドメイン理解と批判的思考が問われる仕事で、ジュニアが担えるし担うべき領域だ。
採用評価の方法も変える余地がある。従来のアルゴリズム実装テストではなく、「意図的にバグや設計上の問題を仕込んだAI生成コードを渡し、アーキテクチャ上のリスクと改善点を特定させる」レビューシミュレーション形式への移行が有効だ。
サイバーエージェントは2026年より、「ビジネスリードエンジニア（新設）」「テックリードエンジニア」「スペシャリスト」「エンジニアリングマネージャー」という4つのキャリアラダーを整備している。「AIが正しくアウトプットを出せているか評価できる基礎的な技術力こそが重要になる」というスタンスのもと、ジュニアの基礎技術力強化への継続投資を明確にしている（CyberAgent Developers Blog, 2026）。
やってはいけないアンチパターン
AI禁止で「昔に戻そう」とする
「AIを使わせなければ昔と同じように育つ」という発想は、現実の開発環境と乖離したジュニアを生む。チームに配属された際のギャップが大きく、自信喪失・早期離職につながりやすい。
「AIを使う判断力」こそが今後のシニアに必要なスキルだ。AIをいつ使い、いつ使わないかを判断する経験を積む機会を、環境として設計する必要がある。禁止ではなく、「使わない場面を意図的に作る」という設計が正しい。
メンタリングを義務化して形骸化させる
評価インセンティブなしにメンタリングを義務づけると、週1回の形式的なチェックインで終わる。技術的な指導が行われないまま「やっています」という状態になりがちだ。義務化するなら、必ず評価設計とセットで動かす。
EMが今週できること
設計を変えるには時間がかかるが、動き出すのは今週からできる。
まずバックログを開いて、タスクを「AI解放」「ジュニア学習」の2種類にタグ付けしてみてほしい。1時間もあれば終わる。分類の基準を考えること自体が、「ジュニアに何を経験させたいか」を問い直す機会になる。
並行して、直近の半期評価シートを確認してほしい。シニアエンジニアの評価項目に「育成貢献」の欄はあるか。なければ、次の評価サイクルに間に合うよう人事へ提案を上げる準備を始めるタイミングだ。
Microsoftのラッシノビッチらが医療の「プレセプター制度」をヒントに提唱したモデルのように、「育成を組織の明示的なゴールにする」という視点でパイプラインを設計し直す。それが今のEMの仕事だと筆者は思っている。
5〜7年後に誰がチームを支えるかを決めるのは、今年の採用決定と育成設計だ。
コメント