この記事は連載「生成AI時代、エンジニアは何で食っていくのか」の実践編 #05（最終回）です。
- 導入編はこちらからどうぞ。
- 実践編 #01 「全員がAIを使える」チームは、なぜ崩壊するのか
- 実践編 #02 誰もやらなかった仕事をやる人が、次の時代のキーマンになる
- 実践編 #03 「AIネイティブチーム」の現場で何が起きているか
- 実践編 #04 PGからプロンプトアーキテクトへ。キャリアを変えた人たちの話
- 実践編 #05 組織がAIを導入して半年後、生き残ったエンジニアの共通点 ← 今ここ
半年というタイムラインの意味
「AIが普及したらエンジニアはどうなるか」という議論は多い。でも実際に「AIを導入してから半年後の組織で何が起きたか」という話は、まだあまり表に出てきていません。
この記事では、AI導入から半年以上経過した複数の現場を観察・ヒアリングした結果をもとに、「生き残ったエンジニアの共通点」を整理します。
「生き残る」という言葉は少し物騒ですが、正確には「AIが入ったことでむしろ評価が上がったエンジニア」の特徴です。
最初の3ヶ月に何が起きるか
AI導入直後の組織に共通するフェーズがあります。
第1フェーズ（0〜1ヶ月）：熱狂期
全員が「すごい」と言ってAIを使い始める。生産性が上がったように見える。経営層も「やっぱり入れて正解だった」という雰囲気になる。
第2フェーズ（1〜3ヶ月）：混乱期
品質のムラが出始める。AIが書いたコードの不具合が本番で出る。「誰がレビューしたんだ」という議論が起きる。「AIを使えばいい」という空気と「本当に大丈夫か」という不安が混在する。
第3フェーズ（3〜6ヶ月）：淘汰期
チームとして「AIとの付き合い方」が整理されていく。この時期に「いてよかった」と思われるエンジニアと、「いてもいなくても変わらない」と見られるエンジニアの差が明確になってくる。
生き残ったエンジニアの多くは、第2フェーズで何らかの「貢献」をしていました。
共通点①：「混乱期」に動いた人
第2フェーズの混乱期——これが最大の分岐点です。
多くのエンジニアは「AI導入は経営の判断だから」「自分には関係ない」という態度をとりました。一方で生き残ったエンジニアは、この混乱を「自分が役に立てる場面」として捉えた。
具体的には——
- AIのアウトプットで品質問題が出たとき、「なぜ起きたか・どう防ぐか」を自分で考えてまとめた
- チームのAIの使い方にばらつきがあると気づいて、共通ルールの叩き台を作った
- 「AIに頼んだらこうなった、自分ならこうする」という比較を言語化してチームに共有した
「自分ごとにした人」が評価された。
受け身でいることが最大のリスクだった、という言い方もできます。
共通点②：「AIが苦手なこと」を自分の仕事にした
半年後に高評価だったエンジニアは、AIができることを競いに行かなかった。むしろAIが苦手なことを意識的に自分の担当にしていたのが共通しています。
AIが苦手なこと（半年の観察から）
1. 文脈を持つ意思決定
「このチームの歴史上、このアプローチは過去に試して失敗した」「このクライアントはこういう判断をする傾向がある」——蓄積された文脈を使った判断は、AIには難しい。
2. 「言語化されていない問題」の発見
ユーザーが「なんか違う」としか言えない不満の本質を見つける、チームの空気から「何かおかしい」に気づく——これはまだ人間の領域です。
3. 責任を持った最終判断
「AIはこう言ってるけど、自分はこう判断する」と言えること。そしてその判断の根拠を説明できること。責任を引き受けられる人間が、AIが増えるほど希少になっていきます。
4. 「例外」の処理
AIは「平均的なケース」に強い。でも現場には必ず例外がある。「このユーザーは通常のフローではなく、こういう事情があるから特別対応が必要」——これを判断できるのは、現場を知っている人間だけです。
共通点③：「AIを使って出したもの」に責任を持ち続けた
これは態度の話です。
半年経って評価されていたエンジニアの多くが、「AIが書いたコードでも、自分が出したものとして責任を持つ」という姿勢を一貫して持っていました。
「AIが生成したので」は理由にならない。逆に言えば、「このコードはAIで生成しましたが、こういう点を確認してリリースを判断しました」と言える人が、信頼を積み上げていった。
技術力の問題ではなく、プロフェッショナリズムの問題です。
共通点④：学習の姿勢が「技術」から「判断力」にシフトしていた
半年前と後で、学習の方向が変わっていたエンジニアが多かった。
半年前に学んでいたこと： 新しいフレームワーク、言語の新機能、ツールの使い方
半年後に学んでいること： ドメイン知識の深掘り、AIのアウトプットを評価するための原理原則、コミュニケーションの精度を上げる方法
技術のキャッチアップを完全にやめたわけじゃない。でも、「AIが補えない部分」を意識して学習する方向にシフトした。
これは意識的な戦略というより、「AIが増えた環境でどう価値を出すか」を考えた結果、自然にそうなった、という人が多かった印象です。
共通点⑤：「AI時代の自分の役割」を言語化できていた
最後の共通点は、少し抽象的です。
半年後に評価されていたエンジニアは、「自分はこのチームでAIに対してこういう役割を果たしている」を説明できました。
これは自分のブランディングの話ではなく、役割が明確だからこそ、チームがその人に頼る場面が生まれる、ということです。
逆に言うと、役割が言語化されていないエンジニアは、「何を頼めばいいかわからない人」になってしまった。AIが何でもそこそこやってくれる環境では、「何を頼めばいいかわからない人」への依頼は減っていきます。
「生き残る」ための本質
5つの共通点を振り返ってみると、根っこにあるのは一つのことだと思っています。
「自分の仕事が何であるか」を、AI時代の文脈で再定義できた人が生き残った。
技術が変わったのではない。「何をするべき人か」の定義が変わったのです。
コードを書く人、から。判断する人、文脈を持つ人、責任を引き受ける人、AIと人間の間を設計する人——そういう「定義の更新」ができた人が、半年後の評価につながっていました。
この連載を通して伝えたかったこと
実践編5本を書いてきて、伝えたかったことを最後にまとめます。
生成AIの普及は、エンジニアにとっての「脅威」ではないと思っています。少なくとも、単純な脅威ではない。
変化の本質は、「何を作れるか」から「何を判断できるか」への価値の移動です。
作ることはAIが補ってくれる。でも、何を作るべきか、作ったものが正しいか、誰のために作るのか——これらの判断は、文脈と責任を持った人間にしかできない。
そして、その判断力は経験と思考の積み重ねによってしか育たない。AIがいくら賢くなっても、「あなたの10年間の現場経験」はAIには再現できません。
まとめ：生き残ったエンジニアの5つの共通点
| 共通点 | 一言で言うと |
|---|---|
| ① 混乱期に動いた | 受け身でいなかった |
| ② AIが苦手なことを担った | 競わずにポジションをとった |
| ③ 責任を持ち続けた | プロフェッショナリズムを貫いた |
| ④ 学習の方向をシフトした | 「判断力」を育てる学びに変えた |
| ⑤ 自分の役割を言語化した | 「何を頼める人か」を明示できた |
導入編から実践編まで、全8本を読んでいただいた方、本当にありがとうございました。
この連載は「答えを出す」ことより、「一緒に考える」ことを目的に書いてきました。変化の最中にいる私自身も、まだ正解を持っているわけじゃない。
コメントや反論、「うちの現場はこうだった」という声が、この連載を続けていく燃料になります。ぜひ聞かせてください。
続編の予定は未定ですが、現場で新しい発見があれば書きます。フォローしておいていただけると嬉しいです。
株式会社なかのひとカンパニーでは随時エンジニアを募集しています。詳しくは採用情報ページをご確認ください。