/note/tech

AI時代のジュニアエンジニア育成で、『自走』をどう見極めるか

要約:

■ 1. AI導入後の開発組織が抱える課題

  • Claude Codeの全面採用:
    • 開発部では今期からClaude Codeを全面採用し、開発工程の効率が上がり一定の成果を出している
  • ミドル層・シニア層のボトルネック化:
    • レビュー・テスト工程をこなせるミドル層・シニア層が不足している
    • AIによる速度改善を十分に活かしきれていない
  • 短期と長期の2つの対応:
    • 短期的には、レビュー・テスト工程にAIをどこまで取り込むかを議論している
    • 長期的には、狭いボトルネックを広げる必要がある
  • ジュニアエンジニア育成の必要性:
    • ミドル層・シニア層の採用も選択肢の一つだが、この層の不足はIT業界全体の課題
    • AIの進化で不足はさらに深刻になり、採用難易度も上がっていく
    • ボトルネックを広げる本質的な手段はジュニアエンジニア育成
  • 育成で見えてきた課題:
    • ジュニアエンジニアからの質問が減った

■ 2. 質問しなくなるジュニアエンジニア

  • AIで進められる場面の増加:
    • コードの読み解き、エラー調査、実装案の検討、テストコード作成をまずAIに聞けば進められる
    • 以前は先輩やマネージャーに聞いていた内容もAIで済む
  • 自走しているように見える状態:
    • 質問が減るとタスクが止まりにくくなり、PRが早く出てくる
    • 一人で完了できる仕事が増え、外からは自走できるようになったように見える
    • これが本当に自走なのかは疑わしい

■ 3. 「自走」の判断基準の揺らぎ

  • 従来の自走のサイン:
    • 自分で調べられる
    • 細かく聞かなくても進められる
    • 一人でタスクを完了できる
  • AI時代に生じた疑問:
    • AIが書いた設計・実装・テストについて、なぜそうしたのかをジュニアが理解できているかは不明
  • ジョブサポートの調査:
    • 新人・若手エンジニアの61.4%が、出力されたコードの仕組みや根拠を理解していない
  • BairesDevの調査(77か国・1,569人):
    • ジュニアの85%が、AIでソフトウェア開発への理解が深まったと回答
    • 同じジュニアと働くシニアのうち、ジュニアがAI生成コードを完全に理解していると回答したのは16%
  • ICERに投稿された初心者プログラマー21名の観察研究:
    • 21名中20名がAIを使って課題を完了できた
    • 一部の参加者に、自身の問題解決能力を過大評価する「illusion of competence(能力の錯覚)」が見られた
  • 「できた」と「わかった」の乖離:
    • AIによって「できた」という結果と、「わかった」「できるようになった」という成長が乖離しやすくなった
  • 現場での実例:
    • 自走のサインを満たしていても、実装理由を聞くと「AIがそう言ってたから」と答えるジュニアが一定数いる
  • 外から判断できない要素:
    • 本人が理解して進めているのか、AIに逐次聞きながら進めているのか
    • 正しい問いを立てているのか
    • AIが出した答えを検証できているのか
  • 再現しやすくなったサイン:
    • AIによって、自走しているときに現れるサインだけを再現することが簡単になった

■ 4. AI時代に必要な「評価する力」

  • Scienceに掲載された2026年の研究:
    • 生成AIを最も頻繁に利用していたのはジュニアエンジニア
    • 測定可能な生産性向上が確認されたのはシニアエンジニア
    • ジュニア育成について断定はできないが、AIを使うことと適切に判断する能力は別物と考える材料になる
  • supervisory engineering work:
    • AIコーディング支援を使うプロのエンジニアを追った研究の概念
    • 仕事の重心がコードの生成から、AI出力の指示・評価・修正へ移っている
  • 重要になる能力:
    • 作れること以上に、出てきたものを評価できることが重要になる
    • ジュニア育成では、評価するための物差しをどう身につけるかが問題になる

■ 5. AIが補完する「問いを考える力」

  • AIの利点:
    • ジュニアが整理できていない問題でも、ある程度補完しながら前へ進めてくれる
    • タスクをこなす点では大きなメリット
  • 育成上の問題:
    • ジュニアは必ずしも正しい問いを立てられない
  • ずれた問いの例:
    • 仕様を確認するべき場面で、エラーの直し方を聞く
    • 設計を疑うべき場面で、実装を通す方法を聞く
  • 人間とAIの違い:
    • 先輩やマネージャーは、聞きたいことや前提が合っているかを問い返せる
    • AIも問いを修正することはあるが、常にではなく、ずれた問いにもそれらしい答えを返す
  • ChatGPTと人間のチューターの比較研究:
    • ChatGPTを使った学生は短いプロンプトを投げ、問いをあまり洗練しない傾向がある
    • 初歩的な質問では、対人的な不安が少ないためChatGPTを好む傾向もある
  • 見えにくくなる不足:
    • AIは答えだけでなく問いを考える力まで補完し、その不足を本人にも他人にも見えにくくする

■ 6. 失われる育成のタイミング

  • 育成の判断基準の喪失:
    • タスク完了と問題の理解は別物であり、成果物から能力を判断する基準が一つ失われた
  • AI導入以前の「詰まり」:
    • 理解できないところで仕事が詰まり、先輩やマネージャーに質問していた
    • 質問によって答えを教わったり、問いや理解のズレを修正されたりした
    • AIはこの詰まりを削ってしまう
  • 能力の境界が露出する瞬間:
    • 詰まることは一見非効率だが、能力の境界が露出する瞬間であり、育成のタイミングだった
    • 質問が来なくなることは、育成タイミングの喪失を意味する

■ 7. 見えなくなるジュニアの「問い」

  • 質問に表れる情報:
    • どこまで理解できているか
    • 何を問題だと思っているか
    • どこで前提を間違えているか
    • 何を疑問にすら思っていないか
  • 質問の背景の重要性:
    • 育成側にとっては、質問に答えるより、なぜその質問をしたかを考えるほうが重要な場合がある
  • AIとの間に閉じるやり取り:
    • 質問の一次受けをAIが担うと、やり取りはジュニアとAIの間に閉じる
    • 先輩やマネージャーに見えるのは完成したコードとPRだけになる
    • 質問数ではなく、ジュニアの思考過程そのものが見えなくなっている

■ 8. 育成方法の3つの転換

  • AIによって失われるもの:
    • 成果物から本人の能力を推測する材料
    • 詰まりをきっかけにした育成のタイミング
    • 本人の考えを把握するための情報
  • AI禁止は非現実的:
    • 小学生でもChatGPTを使っており、以前の状態に戻すことはできない
    • これまで自然に得られていた育成上の情報や機会を、別の場所で取り戻す必要がある
  • 3つの方向性:
    • 「成果」ではなく「判断」を見る
    • AIとの間に閉じた「問い」を可視化する
    • 意図的に「考える機会」を作る

■ 9. 「成果」ではなく「判断」を見る

  • 本人の言葉で説明してもらう内容:
    • なぜこの実装を選んだのか、他にどんな選択肢があったのか
    • AIの回答をどう検証したのか
    • どこにリスクがあると考えたのか
  • 判断基準の有無:
    • 大事なのは正しい答えを知っていることより、自分で判断する基準を持っていること
  • シニアとジュニアの違い:
    • シニアはAI出力を評価する物差しを持ち、出力を疑い、必要なら修正できる
    • ジュニアはその物差し自体をこれから作る必要がある
  • 評価の観点:
    • 一人で仕事を終えられるかではなく、AIを使いながら最後の判断を自分でできるかを見る

■ 10. AIとの間に閉じた「問い」の可視化

  • 確認の場:
    • AIとの会話ログをすべて追うのは非現実的なため、レビュー、ふりかえり、1on1で確認する
  • 見るべき対象:
    • AIの利用履歴ではなく、本人が何を問題として認識していたか
    • 正しい問いを立てられているか、間違った前提に気付けているか
    • 疑問に持つべきことを見落としていないか
  • 問いを会話へ戻す:
    • 質問が人間に届かない以上、問いを意識的に会話へ戻し、理解度の情報を取り戻す

■ 11. 意図的に「考える機会」を作る

  • 育成側の役割:
    • 詰まりの減少は開発効率としては良いことだが、考え、質問し、問い返される経験も減る
    • その機会が減るなら、育成側が意図的に考える機会を作る必要がある
  • 具体策:
    • 仕様の解釈が必要な場面では、まず本人の解釈を聞く
    • 設計では、複数案とそれぞれのメリット・デメリットを考えてもらう
    • AIの案を採用した理由、採用しなかった理由を説明してもらう
    • 前提が変わったらどうするか、条件を変えて考えてもらう
    • AIに聞く前に、自分なりの仮説を一度持ってもらう
  • ICER 2026で発表された研究:
    • 学習者にAIが生成した複数のコード候補を比較させ、なぜ別の案が良くないのかまで考えさせた
    • 複数案を提示された参加者の多くが、立ち止まって批判的に考えるきっかけになったと振り返った
  • AIとの付き合い方:
    • AIを使わせないのではなく、積極的に使いながら思考までAIに肩代わりさせない仕掛けを作る

■ 12. 育成側の負荷と今後

  • 育成側の負荷増加:
    • こうした育成方法への転換は育成側の負荷を上げる
    • ジョブサポートの調査でも、多くのOJT担当者が指導負担の増加を感じている
  • 介入ポイントの絞り込み:
    • すべてを人間が確認するのではなく、判断過程を外化し、人が介入するポイントを絞る
    • PRや設計メモに判断理由を残す
    • 仕様解釈や設計判断など、育成効果の高い場面だけ人が深く関わる
  • 見るべきものの転換:
    • 質問しないことや一人で完了できることを、そのまま自走と評価しない
    • 代わりに問い・判断・説明を見る
    • 開発の進め方が変わったように、育成で見るべきものも変える必要がある
  • 今後の取り組み:
    • AI時代に合った自走の見方と育成方法を、現場で試しながら更新していく