AIネイティブ時代におけるジュニアエンジニアの生存戦略

こちらはラクスパートナーズ AdventCalender 2025 22日目の記事です。

はじめに

2025年現在、エンジニアリングの現場は変化の渦中にあります。生成AIとエージェントAIの実装により、「コードを書く」という行為の市場価値は急速に減ってきています。そこで1ジュニアエンジニアとして、これからのAIとの向き合い方や身につけるべきことについて考えてみました。

1. ジュニアエンジニアのパラドックス

1.1 比較的簡単なタスクの消失

AI時代における人材育成の最大のリスクは、ジュニアエンジニアが成長するために必要な「手頃な課題」が消滅しつつあることです。

• 伝統的な学習モデルの崩壊：
  ジュニアレベルのエンジニアはバグ修正、単純な機能追加、単体テストの記述といった、リスクが低く、かつシステム全体の理解を助けるタスクを通じてスキルを習得してきました。これらは、徐々にコアなタスクへと移行するための重要なステップでした。

  しかし、2025年の開発現場において、これらのタスクは生成AIが最も得意とする領域と完全に重複しています。AI駆動のツールは、これらの「初歩的なタスク」を瞬時に、かつ多くの場合において人間よりも正確に処理してしまいます。シニアエンジニアがAIを活用すれば、かつてジュニアエンジニアが1週間かけて取り組んでいたタスクを数分で完了させることができるため、組織的な観点からはジュニアにタスクを割り当てる経済合理性が低下しています。その結果、ジュニアエンジニアは実践的な経験を積む機会を奪われ、スキル習得の「空白地帯」に取り残される危険性が高まっています。

1.2 AIに頼りすぎることによる「思考力の低下」

さらに深刻なのは、AIへの過度な依存による「思考力の低下」です。

• コピー＆ペーストの罠：
  AIが生成したコードをそのまま貼り付けるのは、一見すると生産性を向上させるように見えますが、長期的にはエンジニアの思考力を奪います。AIツールに依存すると、一見動作するコードベースを作成できても、記述した内容の記憶定着率が著しく低下し、バグの修正や設計意図の説明を求められると「フリーズ」してしまいがちです。
• シミュレーションの欠如：
  「なぜ動くのか」を理解しないまま「動くもの」を作れてしまうため、脳内でコードの挙動をシミュレーションする能力が育ちません。これは、GPSへの依存が空間認識能力を低下させる（カーナビで目的地に着いても道を覚えたわけではない）現象と同様であり、エンジニアとしての基礎体力を奪う問題になり得ます。

生存戦略 1：「擬似的な失敗」の導入

この構造的な課題に対処するため、学習プロセスを意図的に「非効率」にする戦略が必要です。

1. カオスエンジニアリングの個人適用：
   Netflixが実践した「カオスエンジニアリング」の概念を個人の学習に応用します。学習用の環境で意図的に以下のような障害を発生させ、AIツールを一切使わずに復旧させます。

   • ネットワーク遅延の注入： 通信をわざと遅らせて、システムがどう反応するか（タイムアウト処理など）を確認する。
   • リソース枯渇のシミュレーション： メモリや保存容量がいっぱいになった状態をわざと作り出し、システムが停止した時の記録（ログ）を読み解く。
   • データベース接続断： データベースへの接続を切断し、エラーが適切に処理されているか、利用者に正しいメッセージが表示されるかを確認する。

2. 「AI断ち」の時間確保（意図的な摩擦）：
   「まずは自力で書く、詰まったらAIにヒントだけをもらう（答えはもらわない）」というルールを設ける。エラーが出た時、AIに貼り付ける前に、少なくとも15分間は自分でログを読み解き、仮説を立てる時間を強制的に確保します。個人開発でも同様の手法を用いることができると思います。

1.3 AIネイティブ世代に求められる「監査力」と「問いを立てる力」

ジュニアエンジニアに求められるスキルセットは、文法の暗記から、出力の検証・実践へとシフトしています。

• AIアウトプットの監査力：
  AIはもっともらしい嘘（ハルシネーション）をつくことがあります。また、セキュリティ上の弱点や、効率の悪い処理を含むコードを生成することもあります。ジュニアエンジニアは、AIの出力を鵜呑みにせず、批判的に検証し、修正する能力を持たなければなりません。これは、従来の「先輩が新人をチェックする」関係から、「全員がAIをチェックする」関係への変化を意味します。
• ビジネスの文脈理解：
  AIはコードを書けますが、「なにを作るのか」「なぜその機能を作るのか」「それがビジネスの目標にどう役立つのか」を理解することはできません。ビジネスの背景を理解しているエンジニアは、AIには代えられない価値を持ちます。反対に、スコープ内のことをただ作れるエンジニアの価値は下がっていく一方です。

従来のスキルセット（〜2023）	AI時代のスキルセット（2025〜）
プログラミング言語の暗記	AIへの指示出し（要件定義）
ゼロからコードを書く	生成されたコードのチェックと修正
部品単位のテスト作成	システム全体の設計と統合・トラブル対応
技術的な答えを探す力（検索力）	ビジネス課題の解決策を提案する力

2. なぜ今、基礎知識が必要なのか？

2.1 CS（コンピュータサイエンス）の基礎知識は必要なのか？

「AIがコードを書くなら、コンピュータの専門知識なんて不要になるのではないか？」という議論がありますが、AI時代だからこそ、基礎知識はかなり重要になっていると考えています。

• AIは「確率」で動いている：
  AIは「次に来る言葉やコード」を確率で予測して生成しますが、そのコードが「効率的か」「無駄がないか」までは深く理解していません。例えば、大量のデータを処理する際に、AIが非常に効率の悪い処理方法（計算量が$O(n^2)$になるようなもの）を提案してくることがあります。基礎知識がなければ、AIの提案をそのまま採用してしまい、後でシステムが動かなくなるリスクを見抜けません。
• どれが最適かを選ぶ力：
  「データを並べ替えて」とAIに頼むとき、どの手順（アルゴリズム）を使うべきかは、扱うデータの量やコンピューターの性能によって変わります。AI任せにせず、状況に合わせて「こちらのやり方の方がいい」と判断するためには、基礎的な知識が不可欠です。

2.2 トラブルが起きた時、AIは助けてくれない

「抽象化の漏れ」という法則があります。これは、「便利な道具（AIなど）を使っても、中身の複雑な仕組みが顔を出してトラブルになることがある」という意味です。

• ブラックボックス化のリスク：
  AIを使えば複雑なシステムも簡単に作れますが、その分、トラブルの原因も複雑になります。システム同士の連携がうまくいかなかったり、データの整合性が取れなくなったりした時、AIは表面的な修正案しか出してくれないことが多いです。
• 「低レイヤー」知識の価値：
  システムが遅い、動かないといった根本的な問題が起きた時、最後に頼りになるのは「OS（基本ソフト）」や「ネットワーク」といった、コンピューターの奥底（低レイヤー）の知識です。これを知っているかどうかが、問題を解決できるエンジニアと、AIに翻弄されるエンジニアの分かれ道になります。

生存戦略 2：流行り廃りのない「本質」を学ぶ

技術の流行は激しいですが、コンピュータの基礎原理は数十年変わりません。

1. 基礎原理を味方につける：
   新しいツールの使い方（寿命数年）を覚えるのと同じくらい、データの構造やアルゴリズム、ネットワークの仕組みの学習に時間を使うこと。これらは、どんなAIツールを使うようになっても役立つ「持ち運び可能なスキル」になります。
2. AIに「解説」させる学習法：
   基礎知識を学ぶ時こそ、AIを活用できます。「なぜこの処理は遅くなるの？小学生でもわかるように教えて」「このコードがメモリ不足になる可能性はどこ？」といった問いを投げかけ、自分の理解と照らし合わせることで、かなり効率的に基礎を固めることができます。

3. これからのキャリア —— 「作る人」から「設計する人」へ

3.1 会社任せにせず、自分でキャリアを作る

エンジニアキャリアにおいて、「どの企業にいたか」よりも「そこでどんな経験をして、かつ再現性があるのか」のほうが大事です。

• キャリアのオーナーシップ（自分事化）：
  終身雇用が当たり前ではなくなる中、受け身でいるのではなく、自分の経験・技術で価値を証明する必要があります。
• 市場価値の可視化：
  自分のスキルや経験を分解し、世の中の需要や歩みたいキャリアを照らし合わせることで、「次に何を学ぶべきか」「どんなプロジェクトに挑戦すべきか」を自分で決める姿勢が求められます。

3.2 全体像を描く力が価値になる

AIがコードの実装（実際に作ること）を担うようになる中で、人間の役割は「アーキテクト（設計者）」へとシフトします。

• 「作る」から「設計する」へ：
  「手を動かしてコードを書くこと」自体の価値は下がってきています。これからは「現場の指揮官」として、システム全体の設計や、どの技術を使うかの選定、そして「そもそも何を作るべきか」を決めることに価値を置く必要があります。
• 実績の再定義：
  これからの実績アピールは、「どれだけコードを書いたか」「経験年数がどれだけあるか」だけでなく、「どのような課題に対し、どう解決したか」というプロセスを見せることが重要になります。

4. 「AIより劣っている」という不安を超える

4.1 「自分は不要かも？」という不安

「AIの方が自分より賢いのではないか？」という不安（インポスター症候群）は、特にジュニアエンジニアにとって避けられない課題です。私も自信の低さからAIの出力に対して過大な信頼を置いてしまうこともあります。

• 比較の罠：
  常に完璧な回答を即座に出すAIと比較し、「自分はAIよりも遅い」「自分の知識はAIに負けている」と感じてしまいがちです。特に、「AIを使えば誰でも開発できる」という風潮は、技術職としてのプライドを傷つけます。
• 不安のポジティブな側面：
  しかし自分の能力に不安を持つことは、周りへの配慮やチームワークを良くする側面もあります。重要なのは、この不安を「もっと学ぼう」というエネルギーに変えることです。

4.2 「わからない」と言えるチームが勝つ

AI導入にあたって必要なのは、高い「心理的安全性」です。

• 実験の場を作る：
  失敗が許されない空気だと、エンジニアはAIを使っていることを隠したり（Shadow AI）、怖がって新しいツールを使わなくなったりします。「失敗しても良い練習環境」を作ることが重要です。

生存戦略 3：あえて「繋がらない」時間を持つ

AIで生産性が上がると、逆に「常に作り続けなければならない」というプレッシャーが生まれます。

1. 意識的なオフライン：
   AIのおかげで待ち時間がなくなり、思考の切れ目がなくなったことで、脳への負担は増えています。長く働き続けるためには、デジタル機器から離れる時間（デジタルデトックス）や「つながらない権利」を行使し、脳を休ませる時間をスケジュールに組み込むことがプロとしての管理術です。
2. AIを「相談相手」にする：
   AIを「競争相手」ではなく「壁打ち相手（相談相手）」として捉え直す。リモートワークで孤独になりがちな時、AIにアイデアを話して整理してもらうことで、精神的な詰まりを解消することができます。

5. AIへの指示出しと責任 —— 言葉にする力が武器になる

5.1 指示出し（プロンプト）は「説明力」そのもの

「プロンプトエンジニアリング（AIへの指示出し）」は、一時的なテクニックではなく、高度なコミュニケーションスキルです。

• 曖昧さをなくす：
  AIに思い通りのものを作らせるには、前提条件やルール、期待する形を論理的に言葉にする必要があります。これは、人間に対して仕事をお願いしたり、仕様書を書いたりするのと同じです。つまり、プロンプト力を磨くことは、エンジニアとしての基礎的な「言語化能力（説明力）」を磨くことと同じです。ClaudeCodeだと、各マークダウンファイルでコントロールできます。

5.2 最後の責任は人間が取る

AIがコードを書く時代になっても、最終的な責任は人間が負います。

• 倫理的なチェック：
  エンジニアには、コードが正しく動くかだけでなく、それが社会的にOKか、法律的にOKかを判断する能力が求められます。AIが著作権を侵害したコードを書いていないか、偏見（バイアス）を含んだ判断をしていないか。これらをチェックする「倫理的な眼」は、AI時代において人間だけが持ちうる重要なスキルです。

5.3 「話す力」こそが最強のスキル

ソフトスキル（ヒューマンスキル）の重要性は高まっています。

• 共感と調整：
  AIはコードを書けますが、関係者との利害調整や、チームのやる気アップ、ユーザーの気持ちへの共感はできません。技術的なハードルが下がるほど、こういった人間的なスキルの価値が相対的に上がっていきます。

最後に

私自身もまだまだエンジニアとして未熟であり成長途中ですので、AIを活用して爆速で成長していきます！