生成AIがエンジニアの仕事に与える影響について、「なくなる」「なくならない」という議論が続いています。ただ、キャリアの判断に必要なのはその二択の結論ではありません。
必要なのは、自分の仕事のうちどの部分の価値が下がり、どの部分が下がらないのかを分解することです。
何の価値が下がっているのか
生成AIによって明確に効率化されたのは、「仕様が決まっているものを、コードにする」作業です。
これは実装作業の中でも、判断を必要としない部分です。既知のパターンの適用、定型的な変換、ボイラープレートの生成といった領域では、人が書く必然性が薄れています。
ここで注意したいのは、これが「実装力が不要になった」ことを意味しない点です。生成されたコードが妥当かどうかを判断するには、結局のところ実装力が必要です。変わったのは、実装力の使いどころです。
書く力から、読んで判断する力へ。同じ実装力でも、評価される用途が移っています。
影響は職種ではなく工程で決まる
「フロントエンドは危ない」「インフラは安全」といった職種単位の議論は、あまり役に立ちません。同じ職種の中でも、担当工程によって影響がまったく違うためです。
| 工程 | 影響 | 理由 |
|---|---|---|
| 決まった仕様の実装 | 大きい | 判断が不要なため代替されやすい |
| 既存コードの調査・理解 | 中程度 | 補助はできるが、文脈の判断は残る |
| 設計・技術選定 | 小さい | 制約条件の把握と責任の引き受けが必要 |
| 要件の確定 | 小さい | 決めるべきことを決める行為そのもの |
| 障害対応・原因特定 | 中程度 | 仮説は出せるが、本番環境の判断は人が行う |
| 組織・チームの運営 | 小さい | 対象が人であり、代替の対象になっていない |
自分の業務時間のうち、上の表のどこに何割を使っているか。これを出すのが、いちばん実用的な現状把握です。上段に偏っている場合、担当範囲を変える必要があります。
「AIを使えること」は差別化にならない
生成AIを業務に取り入れることは、すでに差別化要素ではなくなりつつあります。使っているかどうかではなく、使ったうえで何を出せるかが問われる段階です。
したがって、キャリアの観点で意味があるのは次のような能力です。
- 生成されたものを検証できる: 動くコードと、運用に耐えるコードの区別がつく
- 問題を分解して渡せる: 曖昧な要求を、解ける単位に切り分けられる
- 判断の責任を持てる: なぜその方式にしたのかを、後から説明できる
- 人と合意を作れる: 技術的な選択肢を、非エンジニアが判断できる形で提示できる
これらはいずれも、生成AI以前から評価されていた能力です。新しい能力が必要になったというより、以前から差がついていた部分の差が、より見えやすくなったという表現のほうが近いと感じています。
キャリア判断への落とし込み
不安の解消として何かを学ぶより、次の順で確認するほうが判断につながります。
- 自分の業務時間の内訳を出す: 上の表のどの工程に、何割使っているか
- 代替されやすい工程の比率を見る: 半分以上なら、担当範囲を変える交渉を先に行う
- 現職でずらせるかを判断する: 設計や要件確定に関われる余地があるか
- ずらせない場合に、外に出る選択肢を検討する
3の段階で「うちでは役割は変えられない」となる会社は少なくありません。その場合、能力の問題ではなく機会の問題なので、環境を変えることが解になります。
予測に賭けないこと
生成AIが数年後にどこまで到達するかは、誰にも正確には分かりません。したがって「AIがここまでしかできないから安全」という前提でキャリアを組むのは、賭けに近くなります。
より安全なのは、AIの進歩速度に依存しない部分を厚くすることです。事業の理解、業務ドメインの知識、組織を動かす力。これらは、仮に生成AIがさらに進歩しても、価値が急落しにくい領域です。
技術を学ばなくてよいという意味ではありません。技術だけを積むと、供給が増えた瞬間に相対価値が下がる、という構造を認識しておくという話です。
よくある質問
- 若手エンジニアは特に不利になりますか?
- 「決まった仕様を実装する」工程が担当の中心になりやすいため、影響を受けやすい立場ではあります。設計や要件の議論に早い段階から参加できる環境かどうかが、以前より重要になっています。
- AIエンジニアに転向すべきですか?
- 転向自体が目的になると、既存の強みを捨てることになりかねません。現職のドメイン知識と組み合わせられるかを先に検討してください。
- 何を学べばよいですか?
- 一般解はありませんが、担当工程を上流にずらすために必要なもの(設計、ドメイン知識、要件定義)は、AIの進歩に左右されにくい領域です。
