SREとして事業会社で働きながら、副業で個人事業主としても活動している山口と申します。
仕様駆動開発や、superpowersのようなスキルフレームワークを使ったAI駆動開発が当たり前になったIT業界を改めて振り返り、どうキャリアプランを立てるのか。生成AIを使わずに考えてみました。
（書き終えた後に誤字脱字の訂正と簡単な校正だけやってもらいました）
ご参考までにこれまで書いてきた記事です。
現状と見立て
ちょっと前までは「どうやって生成AIで開発や業務を効率化するか」を考えていたのに、今は「生成AIをどう駆動させ、その中で人に何をやらせるのか」を問われているIT業界。
さらに、その人だけが持っている暗黙知をナレッジ化するサービスも次々と登場しており、どのITエンジニアにとっても悪夢のような状況です。
特にここ数ヶ月、ClaudeCodeでOpusを使って開発している人は、自分の存在意義を見失い、モチベーションを落としているケースも多いかと思います。
以下、キャリアと業種ごとに現状と今後の戦略を掘り下げます。
ジュニアエンジニア
完全に代替可能なのはもちろん、一部では採用活動がストップするなど、不安定な状況にいます。
昔ながらの「OJTで作業しながら工数を請求する」スキームが塞がれつつあり、大手以外は教育コストを捻出しづらいのが最大のネックです。
AIを使った教育プログラムを導入し、採用後に一年ほどふるいに掛けて残す手法が一般的になりそうです。
採用後の教育カリキュラムの内容、IT以外にどんなドメイン知識を習得できるかなど、会社選びがより重要になるのは間違いありません。
そんな中でも、休日にAIを使って自主的に勉強できる人は、どこでも活躍できるかと思います。
シニアエンジニア
AI駆動開発への過渡期ということもあり、そこまで追い込まれている印象はありません。
生成AIの推論に対して、IT技術とドメイン知識の両面からしっかり指摘できる人材は、今後も希少な存在であり続けます。
AI駆動やAIオーケストレーションの仕組みを一人で構築して運用できることも大きいです。
その反面、AIレビューを担当する人はAIが次々提案してくる新しい技術を理解しないと業務が成り立たず、キャッチアップの工数が膨れ上がっています。
ジュニアが生成AIでアウトプットしたものへのレビューが集中する問題も、しばらくは解消しないでしょう。
（生成AIのレビュー結果を生成AIでレビューする仕組みを用いても、ネストが深くなってSSoTが分かり辛くなり、かえって負担が増える）
ただし、生成AIの推論に対して何も指摘ができない場合は、会社から厳しい目で見られることは間違いないですね。
SIer
もっとも厳しい状況に追い込まれているといっても過言ではないでしょう。
今はまだ生成AIで圧縮した開発コストが利益になっていますが、個人事業主やベンチャー型SIerは生成AIを前提とした見積もりへ移行しつつあります。
事業会社側でもAI駆動開発が推進されているため、今後は実装やテストで従来の数分の一程度しか費用を請求できなくなるはずです。
今後は、言われたことしかできない、ITのことしか知らない、生成AIで代替できるSIerは淘汰され、ビジネスやドメインの観点から革新的な提案ができるSIerが台頭してくると思います。
顧客向けに構築したサービスが生む利益から一部を報酬として受け取る、成果報酬型のSIerも増えていきそうです。
事業会社
これまで内製開発を行っていなかった会社ほど恩恵を受けており、良くも悪くも大きな影響が出ています。
自分たちの業務や業界を一番理解していることがより強みとなり、AIオーケストレーターとして更に活躍できるはずです。
一方で、SIerと比較してITエンジニアのスキルが劣るのは確かで、AI駆動開発において開発はもちろん、リリースしたサービスの運用をどうするかという人の課題を抱えています。
この辺の解決が今後のSIerの役割になっていくかもですね。
経験がなくてもしっかり資格を取っていく人、生成AIを活用した生産性向上の手法を社内に展開できる人は、今後も重宝されるでしょう。
そして、ITシニアエンジニアの求人が急増しそうです。
最後に
この状況は突然なのか？
意見が分かれそうですが、私は必然だと思っています。
昔のITは必要な仕組みやライブラリをすべて自作する必要があり、状況によって言語を使い分けるのはもちろん、ポインタやスレッドの理解、時にはフレームワークの自作まで求められました。
クラウドがなかった時はサーバ管理も自前で、コマンドラインは当然として、ファイルシステムやカーネルの仕組みを理解していなければ仕事ができませんでした。
それがいつからかOSSの利用が前提となり、車輪の再発明は悪とされ、サービスの実装はベンダーが用意したAPIを呼ぶだけになりました。アプリケーションもSpringやReactといったフレームワークが前提となり、著名なエンジニアが抽象化した概念やルールを学ぶことがメインになる。ビルドするために複雑な環境構築の仕組みをキャッチアップする。ある意味、ITの本質からは離れていった感覚があります。
インフラもTerraformで数行HCLを書ければおしまいで、構築するだけなら高校生でも十分できるほど参入障壁は下がりました（インフラ全体を最適化した上で設計してHCLを実装するのとは、まったく別の話ですが）。
これだけエコシステムが充実した中で、自動化が来るのは必然だったと思います。
もちろん、人の思考がニューラルネットワークによってベクトルで表現され、LLMが言葉を理解して代替できるようになるとは思ってもいませんでしたが。
AI駆動開発は何をもたらすのか？
生産性の向上はもちろん、それと合わせてITエンジニアの淘汰が進みます。
生成AIがユーザーに課題や要求をヒアリングし、要求定義・要件定義・設計・実装以降を担っていく中でタスクはどんどんなくなり、レビュー、オーケストレーションの仕組みの構築、サービス運用の意思決定あたりだけが残るでしょう。
そうなった場合、そのポジションに残るのは十分にITを理解しているITエンジニアだけで、それ以外はむしろ不要という世界観になるのではないでしょうか。
一部のITエンジニアは淘汰され、生成AIが苦手とする分野へ配置転換が進んでいく。
そしてこれは、ある意味IT業界をあるべき姿へ戻す「再編」に繋がると思います。
そしてこれはただの始まり
IT業界が生成AIによってこれほど急速に変革できたのは、0か1しかない世界であること、OSSという部品を共有する考え、GitHubというコードから意思決定までオープンな場、ブログなどで学んだ知識をアウトプットする文化、そしてそれらがLLMを学習させる仕組みそのものに利用されていたこと。これらが揃っていたことが大きいと思います。
これによって生成AIはITという万能な武器を手に入れ、ついでに業界を自動化するプロセスまで理解しました。
その結果、他のあらゆる業種にAI駆動のためのエコシステムが構築され、人の代替が進んでいくのは時間の問題です。
これからは、生成AIから逃れた先もすでに生成AIによって代替されていた、ということも十分起こり得ます。
個人的には今の状況は割と楽しんでいる方なので、AI駆動開発のトレンドを追いつつ、オーケストレーションの可能性を探索して行きたいと思っています。