AI時代、ジュニアエンジニアはどこで経験を積むのか
生成AIによって、スキルの低いエンジニアは仕事を失うのだろうか。仕事を失わないとしても、悪い条件で働くことになるのだろうか。
一部の作業が減り、実装速度だけで評価される仕事の条件が厳しくなる可能性は、否定できないと思う。ただし私は、エンジニアという人間が単純に「代替される人」と「高度人材」に二分されるというより、一つの職種に含まれていた作業の価値が組み替わっている、と見ている。
AIがコードや設計案を生成するようになっても、それを納品してよいか判断し、本番で問題が起きたときに原因を追い、次の失敗を防ぐ仕事は残る。生成が速くなったぶん、その仕事の重要性はむしろ高まる。
では、まだ長い経験を持たないジュニアは、どこでその判断を身につければよいのか。私は、いきなり最上流へ飛び級することではなく、「品質を引き受ける場所」から始めるのが一つの活路だと考えている。
「ローエンドエンジニアは代替される」という記述
経済産業省とIPAによる「ITエンジニアリング人材の育成に関するタスクフォース」の第2回会合に、「ローエンドエンジニアは代替され、新たな価値を創造する高度エンジニアが不足する」と記した資料が提出されている（IPAの開催資料一覧、松田委員提出資料）。これはタスクフォース全体の最終結論ではなく、情報サービス産業協会（JISA）の松田委員による提出資料に書かれた現状認識である。
「ローエンド」という語は、人を固定的な階層へ置くようにも読める。だが、実際に代替される単位は、まず人ではなく作業なのではないか。
仕様から定型的なコードを生成する。既存コードに似た修正を作る。テストのひな型やドキュメントの下書きを作る。こうした作業はAIによって速くなる。一方で、顧客が何を必要としているかを確かめ、曖昧な要求の扱いを決め、生成物を検証し、運用上の結果を引き受ける仕事まで、同じように消えるとは限らない。
二極化を「能力の低い人が不要になる」とだけ読むと、ジュニアに残された答えは、短期間で高度人材になることだけになる。しかし、そこには経験をどう獲得するかという問題が残る。
生成できることと、判断できることは同じではない
私は一介のWebアプリケーションエンジニアである。技術力がずば抜けて高いわけではないが、20年ほどかけて上流から下流まで一通り経験してきた。現在はビジネスアナリストやプロジェクトマネージャーとして、クライアントと要求・要件を整理しながら、自分または少人数のメンバーで設計、実装、テスト、運用まで行っている。
その開発では、要求整理や設計、実装、テストなどの進め方を再利用可能にしたAIスキルやハーネスを40以上作り、多くの工程をAI化・自動化している。オントロジー、ドメイン駆動開発、仕様駆動開発、テスト駆動開発が主な軸である。
個人がAIを使って複数の工程をつなげられるようになると、作業を細かく分けたり、人を増やしたりすることが、かえって連絡や認識合わせの負担になる場面がある。それでも、人が必要だと思う場面はなくならない。
AIの解釈が仕様からずれていないか。正常系だけを見て、異常系を落としていないか。本番環境で問題が起きたとき、どの情報から調べるか。顧客の言葉と実装上の概念が食い違ったとき、どちらをどう直すか。こうした判断には、対象への理解と、過去の失敗を含む経験が要る。
一部では、AI時代にはジュニアも一足飛びに最上流の仕事ができなければならない、と言われる。しかし、それは難しい要求だと思う。シニアが10年、20年かけ、失敗や障害対応を通じて得た判断を、短期間で身につけろと言っているようなものだからである。
AIを使えば、設計書らしいものや、動くコードを早く出せる。だが、生成できる成果物の水準と、その成果物について説明し、問題が起きたときに対処できる水準は別である。この点は「ジュニアに設計を任せる前に、自分で説明できるかを見る」でも扱った。
では、最上流へ飛び級しないなら、ジュニアはどこから始めればよいのか。私は次の五つを、一続きの経路として考えている。
1. AIの出力を、納品できる品質まで確かめる
最初の入口は、丹念にテストすることである。
AIスキルやハーネスを整えても、それだけで納品できる品質になるとは限らない。仕様の読み違い、抜け漏れ、既存機能への影響、画面間の不整合は起こる。人間の仕事は、AIが出したものを眺めて承認することではなく、何をもって完成とするかを確かめ、完成していない点を具体的に示すことである。
受入条件を満たしているか。正常系だけでなく、入力の欠落、権限の違い、外部サービスの失敗、同時実行などを考慮しているか。仕様の記述だけでは判断できないなら、推測でテスト結果を合わせるのではなく、上流の担当者に確認する。
これは、決められたテスト項目を消化するだけの仕事ではない。テストを通じて、「このシステムでは何が正しいのか」を明らかにする仕事である。仕様の曖昧さに気づいて問いを返すことは、すでに要求分析の入口に立っている。
2. 発見したことを、自動テストとして残す
次は、一度の確認で得た知識を再利用可能にする。
ユニットテスト、結合・APIテスト、E2Eテストを使えば、多くの確認を自動化できる。E2Eテストの操作を録画し、受入条件と照らして確認することもできる。AIに実行結果や画面を渡し、差異の候補を挙げさせることもできる。ただし、何を不具合とみなすか、どこまでを受け入れるかの判断は人間に残る。
価値があるのは、AIより速くテストコードを書くことではない。どの条件が成立すれば正しいといえるかを定め、発見した不具合が再発しない形で残すことである。
その過程で、同値分割、境界値分析、状態遷移、デシジョンテーブルといったテスト設計技法も役に立つ。異常系やセキュリティの観点を学ぶと、テストしやすい要件、設計、実装とは何かも見えてくる。テストは開発の最後に置かれた検査ではなく、上流へ遡って設計を学ぶための場所になる。
3. 本番で何が起きたかを追えるようにする
システムは、作って終わりではない。使われ始めてからが本番である。
運用中の不具合では、ユーザーがどの操作をし、システム内部で何が起きたかが、開発環境のようには見えない。ログ、データ、メトリクス、トレースなどから判断することになる。実装時から、障害が起きたときに必要な情報へ辿れるようにしておく必要がある。
ここでいう記録は、ユーザーの行動を無制限に保存することではない。プライバシー、セキュリティ、保存費用に配慮し、必要な情報だけを適切なログレベルで記録する。リクエストIDや処理IDを使って一連の処理を結び、個人情報や秘密情報を残さず、どの段階で失敗したかを追えるようにする。
本番の問題を調べると、設計時には見えていなかった現実に出会う。想定外の操作、データ量、通信の遅延、外部サービスの停止、運用手順との食い違いである。その一つひとつが、次の設計判断に使える経験になる。
4. 担当機能ではなく、システムを理解する
自分が変更した箇所だけでなく、その変更がシステム全体のどこに位置するかを理解する。
主要なデータはどこから入り、どこへ流れるのか。重要な業務ルールは何か。外部システムとはどこで接続するのか。権限はどのように決まるのか。障害が起きたとき、どの利用者と業務に影響するのか。
既存のドキュメントだけでは足りなければ、コード、データベース、ログ、チケットなどから、AIを使って調査の下書きを作ることもできる。私の場合、未知の領域を扱うときは、少なくともユビキタス言語と主要な業務ロジックを整理したドメインモデルを作るようにしている。
目的は、何でも暗記している人になることではない。この人に聞けば、根拠となるコードや仕様へ辿って説明してくれる、という状態を作ることである。システムへの理解は、AIの提案がその場では動くだけのものか、既存の仕組みに適合するものかを判断する基準にもなる。
5. 発見を、開発プロセスへ戻す
最後は、個別の失敗や工夫を、チーム全体が使える形へ変える。
テストで仕様の抜けが見つかったなら、その案件だけを直して終わらせない。要求定義の質問項目、受入条件の書き方、レビュー観点、AIへの指示、テスト生成の手順へ反映できないかを考える。運用でログ不足に困ったなら、実装やレビューの基準へ戻す。
開発チーム内でAIスキルやハーネスを共有しているなら、そこへ改善を提案する。まだ存在しないなら、小さなものを自分で作って試してもよい。ジュニアであっても、テストや運用で得た具体的な発見を持っている。その発見は、上流担当者やシニアが見落としている工程上の問題を明らかにすることがある。
ここまで来ると、ジュニアは作業の受け手だけではない。チームの失敗を減らし、次の開発を改善する主体になっている。
五つの活路は、一つの循環になる
五つは、独立した生存戦略ではない。
テストすると、仕様の曖昧さに気づく。仕様を確認すると、業務とシステムへの理解が深まる。本番を意識すると、設計時に考えるべき失敗条件が増える。そこで得た知識を自動テストやAIスキルへ戻すと、次の開発の品質が上がる。
テストする
→ 仕様の曖昧さに気づく
→ システムと運用を理解する
→ 発見をテストと開発プロセスへ戻す
→ より上流の判断ができる範囲が広がる
この循環によって、納品できる品質を引き受ける範囲が少しずつ広がる。テスト担当のまま留まるという話ではない。テストを、仕様、設計、実装、運用をつなぐ学習の入口として使うという話である。
これはジュニアだけの責任ではない
ただし、以上を「ジュニアが勤務時間外に努力して身につけるべきこと」で終わらせてはいけない。
シニアのレビューを受けられること。本番運用や障害対応を知る機会があること。担当範囲の外側を学ぶ時間があること。生成したコードの量やチケットの消化数だけでなく、検証、理解、判断、改善を評価すること。失敗が致命傷にならない範囲を設け、そこで判断を試せること。これらはチームや組織が用意する必要がある。
AIによって定型的な実装が減れば、かつてジュニアが経験を積んだ仕事も減る可能性がある。その一方で、経験を積む前のジュニアへ設計や採否の責任だけを渡しても、育成にはならない。AIが短縮するのは生成に必要な時間であって、判断を形成する経験まで自動的に短縮するわけではない。
ジュニアの活路を考えることは、個人の生存戦略だけを考えることではない。人が育つ工程を、AIを前提に作り直すことでもある。
品質を引き受ける場所から始める
AI時代に必要なのは、全員が短期間でシニアになることではない。自分が検証し、説明し、結果を引き受けられる範囲を、一つずつ広げていくことだと思う。
丹念なテスト、運用への関心、システム全体の理解、開発プロセスの改善は、一見すると地味である。しかし、これらはすべて、生成物を受け取る人から、何を採用するか判断できるエンジニアへ移っていくための経験になる。
AIが普及していく流れを止めることは難しい。現在はIT業界が早く影響を受けているが、いずれ多くの業種と職種でも、従来ジュニアが担ってきた定型的な仕事が圧縮される可能性がある。そのとき、シニアの経験をどうすれば早く、しかし責任だけを飛び級させずに獲得できるのかは、社会全体の課題になる。
私はこの問題を、AIに作業を委ねながら、人間が判断と責任を保持するための条件という観点から研究している。その一つが『答え責任と外部化の線引き：AI協働における認知作業の委譲原理』である。
AIへ任せる作業が増えるほど、人間には何も残らないのではない。どこまで任せ、どこから自分が答えるのかという境界が、これまで以上に問われる。ジュニアが経験を積む場所も、その境界の上に作り直す必要がある。