AIがコードを書く時代に、若手は何ができれば「一人前」なのか

はじめに

プロダクト開発にAIのコーディング支援を導入した組織では、若手エンジニアの書くコードが増え、機能のリリースも速くなりました。開発自体は順調に見えても、若手がAIの生成したコードをどこまで理解し、どの範囲まで任せられるようになったのかが分かりません。

業務へのAI活用は進んできましたが、若手の育成を見直す動きは遅れているように思います。IPAの「DX動向2026」(2026年7月公開)で、その差が見えます。AIを導入または試験利用している企業は58.0%。一方、AIの影響を踏まえて、新たに必要な人材育成の方法に着手している企業は7.1%でした。若手の開発研修に限った調査ではありませんが、AIを使う仕組みと、人を育てる仕組みの整備には隔たりがあります^*1。

開発を速くすることに力を注ぐほど、若手が経験を積む道筋が見えにくくなりました。AIを前提として、若手の育て方を根本から考え直す必要があります。最初に問い直したいのは、「一人前のエンジニア」とはどういう人物なのか、という育成の到達点です。

*1: IPA 「DX動向2026 — 広がるAI導入、DXは変われるか」(2026/7/30)。本文p.25 図表3-1、p.54 図表4-1、p.64 図表4-13。

「理解しなくてもよくなる」は、どこまで当たったか

2025年の春、私は、あと1年ほどでAIが人間の介入なしにコーディングを終えられるようになり、コードレビューも不要になると、かなり楽観的に見ていました。

AIに指示すれば経験の浅い人でも動くものを作れるようになり、細かな実装の知識より、何を作るかを決める力が重要になる。そう考え、ビジネス志向で採用した新卒にも、本人が望めばエンジニアリングを学べる道を用意する方針を立てました。

2026年9月現在、約1年半を振り返ると、見立ては半分当たり、半分外れていました。当たったのは「開発の入門の敷居が低くなる」という部分です。2025年に入社した開発未経験の新卒は3ヶ月の研修を経て実務に入り、配属後の半年で複数のAIエージェントのリリースに携わりました。コードを書いた経験の有無だけで候補者を分けていたら、出会えなかった開発者たちです。

外れたのは「コードの理解が不要になる」という部分でした。AIが書いたものを本番リリースする判断の多くは、いまも人間が担っています。目の前の変更が何をするのか、既存の機能と矛盾しないか、問題が起きた際にどこまで影響するか。そこを説明できなければ、動くコードを生成できてもリリースはできません。

もちろん、構文を暗記する量や資料を探す時間は少なくなります。それでもソフトウェアがどう動き、なぜその設計を選び、どこに危険があるのかを学ぶ必要は残ります。学ぶ内容の配分は変わっても、一人前になるために理解すべきことが大幅に減ったとは、私は感じていません。入門の敷居が低くなりましたが、高い学習能力は引き続き必要とされます。

動くものはできたのに、説明できない。
“理解負債”がたまっていく

入口は低くなり、若手でも動くものを作れるようになりました。ところが、その中身を聞かれると、説明できない。理解が必要なことは変わらないのに、理解を得る機会が減っているからです。

なぜ減ったのか。以前は「書く」「動かない」「調べる」「直す」という繰り返しが仕事の中にありました。エラーメッセージを読み、原因の見当をつけ、直した結果を確かめる過程で、最初は意味の分からなかった仕組みが自分の知識になっていきます。AIが実装と修正まで済ませると、この往復を通らずに成果物だけを受け取れるようになります。

失敗がなくなるわけではありません。失敗に向き合う相手が、若手からAIに変わったのです。若手が原因を考える前にAIへ渡せば、問題は解決しても本人の経験にはつながりにくくなります。これは若手個人の問題ではなく、私自身がAIで開発を高速化するよう促してきたからです。

難しい仕事はシニアに任せるかAIで済ませたほうが速く、これまで新人に渡していた小さな修正も、AIなら短時間で終わります。目の前の納期だけで判断すると、難しい仕事も易しい仕事も若手が考える前に片づいていきます。その結果、人が育つための仕事が組織の中から減っていきます。こうして、成果物はできあがるのに理解は身につかない、ということが起きました。

私が注目したのは、この2つが別々に進み得る点です。動くものを出せても、その中身を説明できるとは限りません。この「作ったもの」と「理解できていること」の差が、近年では＜理解負債＞と呼ばれる類のものです。

この差を示す実験があります。Anthropicが2026年1月に公表したものです。Pythonの経験がある52人に、初めて使うライブラリで課題を解いてもらいました。AIの助けがある人と、ない人に分けて比べています。AIを使った人は平均で約2分早く終えましたが、この差は誤差の範囲で、はっきり速くなったとは言えません。一方、課題のあとの理解度テストでは、正答率がAIを使った人で50%、使わなかった人で67%。いちばん差が開いたのは、不具合の原因を探す問題でした。「AIを使っても速くなるとは限らず、身についたことは少なかった」ことを示す結果です。ただし、小規模で短期の実験なので、長期の成長を測った結果ではありません^*2。

理解負債はコードの問題であると同時に、人の育成の問題でもあります。分からないまま放置した箇所は、次の変更や障害のときに問題となって現れます。しかし、不具合なく動いている間は、本人も周囲もその存在に気づきにくいままです。以前ならエラーやレビューのやり取りから見えていたつまずきが、完成した成果物の陰に隠れてしまいます。

必要なのは、いたずらに理解のために開発を遅くすることではありません。AIで速く作る流れの中に、本人が考え、説明し、確かめる機会を設けることです。学ぶ速さをAIで上げられる可能性も含め、成長の道筋を作り直す必要があります。

*1: Anthropic 「How AI assistance impacts the formation of coding skills」(2026/1/29)

若手の仕事がAIで終わるなら、
若手を採る必要はあるのか

若手に渡す仕事がAIで片づくなら、若手を採用せず、経験者だけで回したほうがいい。そう考えて、採用そのものをためらう組織も出てきていています。短期の計算としては理解できます。海外で見聞きするジュニア採用を絞る動きにも、将来の担い手をどう育てるのかという不安があります。

それでも私は、若手の採用と育成を広げる側を選びました。理由は2つあります。国内では経験者を必要なだけ採用するのが難しいこと。そして、いま採用しなければ数年後に困るためです。

1つめ。採用の合理性は国や企業の人材需給によって異なります。経験者を確保できる海外の市場を前提にした判断を、そのまま国内に持ち込むことはできません。同じIPA調査では、DXに取り組む企業の85.5%が、推進人材不足を感じています^*1。

シニアエンジニアだけを対象とした数字ではありませんが、必要な人を外から十分に確保できるという前提は置きにくいのが実情です。私も、経験のあるエンジニアを必要なだけ採れるとは考えていません。人口が減る国内で事業を続ける以上、育成は余裕ができてから取り組むこともできません。

2つめ。いま採用しなければ、足元で教える手間は省けます。しかし、数年後には難しい判断を任せられる人材も少なくなってしまいます。次の世代が経験を積む挑戦機会を閉じた影響は時間差で現れると私は考えています。

もう1つ、AIが開発のハードルを下げたことも、採用と育成を広げることを選んだ理由です。これまでエンジニアを目指さなかった人まで育成の対象にできるからです。ただし、使える道具を渡して採用人数を増やすだけでは足りません。理解を確かめる仕組みを伴わなければ、理解負債を組織ぐるみで積み上げることになります。だから「誰を採用するか」と「どう育成するか」は、一緒に設計する必要があります。

「一人前」とは」企画から改善まで一周を回せる人

採用を広げるなら、育てた先に「何ができる人になってほしいのか」を決めておく必要があります。私の答えは、「小さくてもよいから、一周を回し切れる人」です。一周とは、企画、開発、リリース、反応、学び、そして次の企画へ戻るループを指します。

AIを使う現場を見ていると、フロントエンド、バックエンド、インフラといった担当の境界を越えて、1人が扱える範囲が広がっています。AI時代には、工程ごとに仕事を分けて引き継ぐ分業が、開発のスピードを著しく下げます。

引き継ぎには、背景の説明、認識のすり合わせ、順番待ちが必要です。分業するチームがそれを終えるころ、引き継ぎのないチームはAIで実装し、結果を確かめ、直すループを何周も回すことができます。一方がようやく次の担当者に仕事を渡したとき、もう一方は何度も改善した成果を出しています。私は、この差が10倍以上の生産性の差につながると考えています。

私が信ずるこの答えをたどると、創業期の少人数での開発という原体験にあります。ユーザーからバグ報告を受け、その数分後には修正したバージョンをリリースしていました。困りごとを聞いた人が直し、そのまま届けるというテンポを今も忘れられません。1人が扱える範囲が広がったいま、全員にそのようなテンポで開発してほしいと考えています。

一周を任せることは、1人で何でも抱え込ませることではありません。難しい設計では専門家に相談し、危険な変更ではレビューを受けるようにします。それでも、何を解決したくて作り、結果から何を学んだのかをつなぐ判断は、本人の手元に残します。

一人前かどうかを見るときも、書けるコードの量だけでは判断しにくくなります。依頼の背景を確かめたか、AIの出力を評価できるか、使う人の反応を受けて次に変えることを選べるか、という判断が一周の中につながっていることを、育成の到達点に置きたいと考えています。一周の大きさは組織や本人の経験に合わせて選べます。最初から大きなプロダクトを丸ごと任せる必要はありません。まずは、自社にとっての「一人前」を1文で定義してみてください。

この先の本連載で書くこと

育成の到達点を変えただけでは、消えた成長機会は戻りません。第2回では、AIの利用を前提に、本人の理解を確かめる仕組みを書きます。先にAIで作る楽しさを経験してもらい、その後は完成した答えを渡さない使い方へ切り替える順序と、説明できないコードをそのまま通さない運用について紹介します。

第3回では、未経験者が学ぶ速さを上げる条件と、研修を設計して初めて分かったつまずきを扱います。最終回では、どんな一周から任せ、どこで助け、どの判断には手を出さないのかを考えます。

AIのモデルの進歩もすさまじく、私の現場でも研修の運用を見直し続けています。本稿は2026年9月時点のスナップショットです。変化の途中でも、育成がうまくいかないと感じたときには、まず「何をもって成長とするのか」を問い直す必要があります。

次回は、多くの育成担当者が迷う「若手にAIを禁止すべきか」という問いから始めます。