【AIに仕事を奪われた新卒】をどう成長させていけば良いのか？
■はじめに
直近生成AIの爆発的な広がりによりエンジニアの仕事にも大きな変化が起きてきています。そのなかでも新卒や若手エンジニアをどう育てていったらよいかが課題になってきています。
育成課題がでてきた流れは、ざっと下記のようになります。
シニアエンジニアのほうが生成AIで生産性があがる
↓ジュニアが低品質コードを量産し、シニアがレビューで疲弊する
↓ジュニアが経験を積むのにちょうどよいタスクが生成AIに奪われる
↓シニアエンジニアだけ取ればよいのではないか？となる
↓しかしシニアエンジニアのパイは限られており、頭数が足りない
↓シニアエンジニアの採用難易度と年収レンジが高騰
↓若手が入らないと将来のマネジメント人材を失い空洞化が起きる
↓若手がもつ時代トレンド・文化潮流を知る「顧客に近い目線」を失う
↓イノベーションを積極的に使う若手がいないと組織がレガシー化する
↓新卒やジュニアは取っていった方が良いとなる
↓AI時代に新卒やジュニアの育成はどうしていったらよいか？
ポイントは、「2.ジュニアが低品質コードを量産する」のだが、7~9の将来のマネジメント人材、若手の顧客目線、若手のイノベーション期待の理由で「10.新卒やジュニアは取っていった方が良い」が「11.育成はどうしていったらよいか？」という課題です。
今回はAI時代において、新卒やジュニアエンジニアをどう育成していくべきかについて考察をします。
このブログが良いなと思ったら、noteやXをフォローしてくれると嬉しいです。
※本稿ではシニア、ジュニアは年齢ではなく経験、スキルがある人をシニア、少ない人をジュニアとしています
※年齢については新卒・若手、中堅、ベテランとします
■今後新卒や若手エンジニアをどう育てていけばいいのか？
OpenAI のサム・アルトマンは、スノーフレークサミット2025で「AIがすでに若手社員と似たように振る舞い始めている」と語っています。またGoogle のジェフ・ディーンも、AI が若手ソフトウェアエンジニアのスキルを再現できる可能性について言及したとされています。
スタンフォード大学の研究チームが 2022年〜25年半ばの給与データを分析し、生成AIの導入によって、AI に影響を受けやすいソフトウェア開発や顧客サービス職種で若年層（22～25歳）の雇用を減少させている点を報じてもいます。
この研究では、最も AI に影響受ける職域において、若年層の相対的雇用が 13 ％ 程度 減少しているという見解を示しています。つまり海外では既に新卒レベルのタスクはAIに奪われ始めているのです。
2022年10月（ChatGPT公開時期）を1として正規化
22-25歳、26-30歳が影響を受けていることが見える
出典：https://spectrum.ieee.org/ai-impact-on-job-market
それに対してGitHubのCEOや、AWSの責任者も下記のように若手は取るべきだという警鐘を鳴らしています。
□GitHub CEOが若手が必要だと思う理由
GitHub の CEOトーマス・ドムケ (Thomas Dohmke) は、AI が進展している時代でも新人エンジニア（ジュニア・インターン層）を継続的に採用すべき と主張しています。
彼は若手エンジニアには以下のような価値があると述べています。
新鮮な視点・エネルギー を組織に持ち込む
大学等での最新技術や知見をアップデートしていることが多い
先入観に囚われず、AI を自然に受け入れ使いこなす姿勢
彼は、GitHub 内で「若手とベテランのバランス」を意図的に保つべきだとし、両者の融合からイノベーションが生まれると見ているとのことです。
またAI がどれだけ進化しても、エンジニアリングの本質（高度なシステム設計・スケール拡張など）には人間の経験・判断力が不可欠だと主張しています。
生成AIが進化してもすべてを丸投げできるようにならなかったり、ITエンジニアの仕事が亡くならない理由については下記の記事でも考察しているので、興味がある方は読んでみてください。
□AWS 責任者が若手が必要だと思う理由
アマゾンWebサービス（AWS）のクラウド部門責任者である マット・ガーマン（Matt Garman） が、人員削減の手段として「若手社員をAIに置き換えるのは、これまで聞いた中で最も愚かなことの一つ」などと発言をしています。
彼の主張は次のようなものです
若手社員は、AIツールを最も使いこなせる可能性が高い人材である
今教育や経験を積ませなければ、将来、技術者・経営層など育たない
ジュニアレベルを削ってしまうと、「人材プール（才能を発掘・育成する基盤）」が枯渇するリスク
特定の学位・スキルに対する依存を避け、倫理的思考能力、創造性、環境変化への適応能力が重要
その一方で、ジュニアエンジニアが育つために必要なちょうどいい簡単な開発タスクは生成AIに奪われてしまうというジレンマを抱えています。これはITエンジニアに限らず、全職種で起き始めています。
■今後ジュニアエンジニアをどう育てていけばいいのか？
このような環境の中でジュニアエンジニアや新卒エンジニアの育成はどうしていくのが良いのでしょうか。
冒頭で示したポイントを振り返ってみると「新卒やジュニアは取っていった方が良い」のだが、「ジュニアエンジニアが低品質コードを量産し、シニアエンジニアがレビュー疲弊する」という課題です。この課題は下記のnote記事でも取り上げ、非常に大きな反響をいただきました（noteの先月もっともよまれた記事のひとつだったという通知もいただきました）。
ここから導き出される答えは、人間がコードをレビューする必要がある限りは、ジュニアエンジニアが生成AIに依頼を丸投げした低品質コードを量産しないようにした方が良いということです。
ジュニアエンジニアが生成AIを使わずコードを書いても低品質かもしれません。しかしコードを自ら書くことで、よく分かってない点が浮き彫りになり、学習しながら書くことになるため、ジュニアエンジニアの学びにつながります。
一方生成AIベースだと、ジュニアエンジニアは依頼を少しだけ加工して生成AIに投げて、でてきた中身は良くわからないのでそのままレビューにだす、ということになります。これだとコードの生産スピードは上がるかもしれませんが学習には全くならず、ずっと使えないままです。
生成AIを使うことで上司と生成AIの間の伝書鳩なのであれば介在価値はゼロです。それどころか理解度・解像度が低いままプロンプトを書くと、生成AIが出してくる成果物の品質も下がるため、介在価値がマイナスになりかねません。
ジュニアの育成は、自ら考えてアウトプットし、それを世に出して、その反応がわかることにこだわるべきです。生成AIに聞けば出てくるタスクをお願いするのであれば依頼者がプロンプトを書いたほうが確実に生産性は高くなります。
エンジニアに限らず、ジュニアは自らアウトプットしたり、顧客折衝したり、ユーザーの反応が得られる小さいキャンペーンを企画実行したり、という、生成AIに聞くだけで得られないことを自ら主体となってやらなければ学びがありません。
その文脈で考えると、リサーチや議事録作成はジュニアに依頼しない方が良い時代になったのだと思います。
もともと新卒は、育成時に生産性は低かったはずです。今に始まった話でもありません。多少非効率であっても生成AIに聞いても出てこない生の反応、手応えが得られることをやったほうが良いのです。
エンジニアであれば、幸いコードは実行した瞬間に結果がえられるので、自らコードを書いたほうが学びにつながります。また小さくてもそれを世の中に出して、どういう反応があるのかなどを体験することは非常に重要なことです。
また、人の手で書くか、生成AIに書かせるか、のように二元論で考えるのではなく、その場に応じて最適な手法を取った方が良い、という考え方が現在開発の現場では出てきています。
育成においても同じで、人の手で書くか、生成AIに書かせるかのどちらか二者択一で考えるのではなく組み合わせていった方が良いと思われます。
■３パターンのコーディング手法を統合・協調させる
コードを書く手法は現在下記の3パターンがあると思われます。
オーガニックコーディング
人間がプログラムを書いてコーディングする。生産性は低いが、学びは最も多くなります。バイブコーディング
開発者主導・AIは補助。生成AIと対話しながら生成AIにコーディングさせる。とっつきやすいが、設計力・経験の差が如実に出る。エージェンティックコーディング（細分化すると伴走型、委託型がある）
AI主導・人間が監督。人間が「目標・仕様」を提示すると、AIが自律的にタスク分解・実行・検証まで行う方式。速度は上がるが、いきなり巨大なシステムが出てくるため、内容を読み解ける能力、経験が必要。
これらの手法は、どちらか一つを選ぶのではなく、それぞれの手法を統合・協調させることが今後重要になります。
特に育成の場では、生産性は低いが学びが多いオーガニックコーディングをあえてやるのは非常に重要です。自分で書いてみる（アウトプットしてみる）ことで得られることは非常に大きくあります。
分かってるつもりでも、書いてみることで曖昧な点がわかり、そこから色々調べることで対象の解像度を圧倒的に高めることができます。
バイブコーディングでは簡単にアプリを作れる一方で、保守性や非機能要件を見落とすと、思わぬ問題に直面することもあります。
バイブコーディングは、そうした生成AI開発の利点と課題の両面を体験できる学習機会として捉えることもできます。初学者が素早く設計に触れたり、非機能要件を意識しないとどんな不具合が起こるのかを短期間で学べることは、従来の教育では得にくかった体験です。
エージェンティックコーディングは生成AIが自律的に開発タスクを進めてくれますが、途中での監視や、アウトプットされたものが意図通りのものかを確認するためにそれなりの経験やコードを読み解くスキルが求められるため、育成期間中は積極的には使わないほうが良いと思われます。
育成期間中はオーガニックコーディングでプログラミング基礎の自力をつけつつ、以前はたどり着くまで数年かかっていた設計経験をバイブコーディングで早い段階から身につけていく、というのが良いのではないかと考えています。
また設計段階において、経験が浅いとどういった手法で実装するかの持ち手札が少なく、最適なカード切れていない場合がよくあります。一旦自分で考えてみてから生成AIに相談をしてみ、よりよいやり方がないかを聞いてみるのは良い方法だと思われます。
実現したいことから今考えている実装方法外により良い方法がないか問うことで、自分が何を知らないのか知ることができ、知識の幅を広げ、手札を増やすことが出来ます。
生成AIがあれば、色々な実装方法を実際に実装してもらい比較することも比較的容易に可能になります。
つまり、育成・学習フェーズにおいては、早くアウトプット作ることではなく、最も早く最も深く学びが得られる方法に生成AIを使っていくのが最善なのです。
■生成AIを使って学びを最大化させる
生成AIを使って学習量を増やす方法として最も良いのは、コードに限らず、自分で一回考えてアウトプットをしてみることです。
アウトプットをしてみると良くわからない点が出てくるので、その点を生成AIに理解できたと思うまで聞いていきます。
その後もう一度、生成AIに理解できたことを「こう考えているが、その理解でおかしくないか、ずれていないか？」を聞いてみると、自分の理解度をはかることが出来ます。
理解が間違っていれば、その点をもう一度生成AIにきいて、アウトプットし、正しい理解に至るまでこのループを繰り返します。
これは生成AIの事前学習と似たステップです。生成AIは事前学習のときに自己教師あり学習で、すでにあるテキストの一部をマスキングして予測して、答え合わせして学習をしていきます。
それと同じように、人間も、色々知らないことを生成AIに聞いて調べて理解をしたら、その理解をアウトプットして答え合わせをしてみるのは非常に有用です。
生成AIはソフトウェア開発、プログラミングの初学者にとって大きな味方になりえます。生成AIは何回聞いても怒らず、ふわっとしたあいまいな質問から専門用語にたどり着けることは非常に学習者にとってありがたい環境です。
■まとめ
生成AIにタスクの委託はできても、理解の委託はできません。生成AIをつかって自分の理解をどう深めていくかが、育成・学習局面にとって非常に重要なのです。
生成AIに聞けばわかるタスクは新人育成には向かないので、育成に携わる方は、どうしたら新人の理解か深まるかについて考えて育成プロセスを考えてみると良いと思います。
最後までお読みいただきありがとうございました。この記事が良いなと思ったら、ぜひnoteやXをフォローしてください。
ちなみに、paizaはIT・AIエンジニア向け国内最大の転職・就職・学習プラットフォームです（paiza.jp）。生成AI講座も無料で学べるので、よかったら使ってみてください。
