ジュニアエンジニアを採用しないことは、あなたが抱えていると思っている問題を解決しない

ジュニアエンジニアを採用しないことは、あなたが抱えていると思っている問題を解決しない 2026年8月2日 最近ポッドキャストを聞いていたところ、非常に大きなテック企業のCTOに、ジュニアエンジニアをまだ採用しているかと尋ねられました。これが真剣な質問だったという事実に、私は驚きを隠せません。AIがソフトウェアエンジニアリングに与える変化の霧の中を、私たちは確かに進んでいます。企業は実験しており、大きな主張をする企業もあれば、適応に遅れを感じている企業もほとんどです。この不安は、企業が競争優位に立つことを期待する単純な賭けを見つけようとする中で、単純化された議論や決定（トークンマクシング！）につながります。「ジュニアエンジニアを採用すべきか？」という問いも、そのような問いの一つです。新参者は、テクノロジーの成長の鈍化や、彼らが実行するタスクを完了できるツールの登場により、現実の苦境に直面しています。それを軽視したいわけではありません。しかし、この枠組みは候補者にとって、そしてさらに重要なことには、企業にとって有害です。ジュニアエンジニアは今日必要とされており、今後も必要とされるでしょう。あなたの組織がそれに疑問を持っているなら、あなたは別の問題に直面しているのかもしれません。 これは新しいトピックではない 経験の浅いエンジニアを採用しないという動機は新しいものではありません。テクノロジー企業は、個人がエンドツーエンドで自分の仕事に責任を持つ必要があるという理論に基づき、長年経験豊富な従業員のみを採用することを目指してきました。これは私が以前働いていた会社での状況でした。私が参加したとき、ポリシーはシニアエンジニア以上のみを採用するというものでした。私たちのシステムの複雑さゆえに、ジュニアエンジニアは物事を壊す変更をリリースする可能性があり、リスクとなり得るとの議論でした。この決定の目に見える、そして皮肉な結果の一つは、マネージャーたちが単純なタスクを完了させるのに苦労していたことでした。なぜなら、誰もが自分たちはそれ以上の仕事をするべきだと感じていたからです。私たちはポリシーを変更しました。まず、経験の浅い人材を数名採用する実験を行い、その後、卒業生のエントリーポイントとなったインターンシッププログラムを設立しました。数年後、それらのインターンの一部は、シニアとして採用した人々を凌駕するミッドレベルエンジニアになっていました。この議論のAI版は、新しい洞察ではありません。それは、新しい服を着た、古い（そして間違った）好みです。 間違った仮定 ジュニアエンジニアの問題は、いくつかの仮定に基づいています。そして、それらはすべて欠陥があります。最も明白なのは、人材の定着問題です。あなたは人々を離職で失うでしょう。エンジニアは経験を積み、より大きな挑戦を求めるようになります。あなたはもっと多くの人を採用する必要があるでしょう。その時点で、あなたは市場に出て、システムを学ぶのに半年かかる誰かのために時間と採用コストを支払うか、すでにシステムを知っている人を昇進させるかのどちらかです。AIは確かにチームの規模に影響を与えていますが、その規模はゼロより大きくなるでしょう。もう一つの中心的な仮定は、業界が非常に変化しており、エンジニアの役割は非常に異なるものになるため、現在経験のない人を採用することは無駄になるかもしれないということです。彼らは変化に適応できないかもしれません。このトピックについて私がよく話す話は、私がコンサルタントとしてのキャリアを始めたとき、プロジェクトの最初の週は環境設定に費やしていたということです。クライアントは、ソース管理リポジトリとCIビルドを実行するために1週間かけているエンジニアチームに非常に高い料金を支払っていました。そしてそれは、コンピューターのプロビジョニングに数週間かかるような状況では幸運な方でした。おそらく現在では、プロンプトと10分待つだけで完了できるジョブです。私は生き残りましたが、サブバージョンリポジトリを設定する私のスキルは役に立たなくなりました。業界がそれほど速く変化しているなら、経験は減価する資産であり、ジュニアは適応できないと主張する人々は、最も多くのことを忘れなければならないでしょう。最後で、おそらく最も根深い前提は、エンジニアの仕事がプロンプト作成と、単純（かつ複雑）なタスクを実行するエージェントの管理になるなら、ジュニアエンジニアは何をするのかということです。この考え方の主な問題は、エンジニアの仕事をコードの提供に還元していることです。AI以前のエンジニアの役割は、ソフトウェアを構築することによって顧客価値を提供することでした。AI以後のエンジニアの役割は、コードを書くエージェントを通じて、依然として顧客価値を提供することです。目標は同じであり、判断は依然として必要です。現在、技術的な判断は依然として役割の主要な部分です。将来的には（別の投稿のトピックですが）最小限になるかもしれませんが、その場合は価値に焦点を当てた判断に置き換えられるでしょう。これは実際に問題を解決するのでしょうか？この変更は、既存の機能に適合するのでしょうか？完全にAIファーストの世界であっても、エンジニアの役割は価値を提供し続けるでしょう。そして、エンジニアの役割が複数のエージェントをオーケストレーションしてプロジェクトを単独でリードすることであるなら、ジュニアエンジニアの仕事は、複数のエージェントをオーケストレーションして単純なプロジェクトを単独でリードすることになるだろうと私には明白です。未来がどうであれ、実行されるタスクには、より単純なバージョンとより複雑なバージョンが存在するでしょう。 隠された問題 上記の仮定は、ジュニアエンジニアの問題が現在のテック業界の会話でしばしば誤解されていることを浮き彫りにしています。しかし、それらはまた、より深い問題も露呈しています。それは、テクノロジー企業がジュニアの居場所を見つけるのに苦労していることです。なぜなら、彼らはエンジニアリングをプロダクト開発における孤立した分野として見続けるからです。私たちは2026年です。業界がソフトウェアを効果的に提供する方法としてウォーターフォールを否定してから数十年経ちますが、私たちはそれに後戻りし続けています。ソフトウェアチームは依然として生産ラインのように見えがちです。そこでは、孤立したプロダクトマネージャーからの要件が、孤立したデザイナーによって設計に変換され、その後、作業を単純なタスクに分割して、チームの経験の浅いメンバーに割り当てるテクニカルリーダーに渡されます。もしそれがプロセスなら、最後のステップをエージェントで置き換えることができると考えるのは自然です。しかし、ここでの問題はジュニアエンジニアの役割ではありません。それはシステムです。プロダクト開発は、顧客価値を提供するためのプロダクト、デザイン、エンジニアリングの協力であるべきです。エンジニアは単にコードを書いているのではなく、顧客の問題を最も効果的な方法で解決する方法についての視点と代替案を提供しています。単純なタスクは、CSVエクスポートエンドポイントの追加ではなく、「顧客が請求履歴をエクスポートできるようにする」べきです。これには、そのエクスポートに何を含めるべきか、10年間のデータがあることを考慮した場合の許容されるパフォーマンス、およびそれが製品の他のエクスポート機能とどのように統合されるかについての検討が含まれます。そして、あなたが仕事をそのように枠組みするなら、AIファーストの世界であっても、複雑な戦略的イニシアチブを会社の技術的コンテキストでどのように提供するかといった、より複雑なエンジニアリングの問題が存在するでしょう。そして、上記の例のような、より単純なエンジニアリングの問題も存在するでしょう。あなたのチームのエンジニアが技術的なタスクに取り組んでいるなら、問題はジュニアやAIに関するものではありません。それはあなたのエンジニアリング組織の有効性に関するものです。あなたは、複雑さを管理する（そしてボトルネックになる）数人のエンジニアを他の人々のために抱えることになるでしょう。一方、あなたの競合他社は、すべてのメンバーが顧客価値に貢献しているでしょう。現在も将来も、生産性の高いチームには、ジュニアを含むすべてのレベルのエンジニアの居場所があります。