生成AIやコーディングエージェントの進化によって、ソフトウェア開発の前提が大きく変わり始めています。

最近では、コード補完にとどまらず、要件の理解、実装、テスト、修正、Pull Requestの作成までをAIが担うケースも珍しくなくなりました。

では、この先システムエンジニアの仕事はどう変わっていくのでしょうか。

本記事では、Powderworks Newsletter の “Tabs, Spaces, Hand Tools, and Seat Belts” を参考にしながら、ソフトウェア開発の「工業化」という観点から、今後のSEの役割を考えます。

参考・出典
Powderworks Newsletter
“Tabs, Spaces, Hand Tools, and Seat Belts”
https://newsletter.powderworks.dev/p/tabs-spaces-hand-tools-and-seat-belts

ソフトウェア開発は、さらに「工業化」していく

ソフトウェア開発の歴史を振り返ると、長期的には一貫して、

標準化
自動化
再利用
品質の定量化
属人性の排除

という方向へ進んできました。

コンパイラ、フレームワーク、OSS、CI/CD、クラウド、Infrastructure as Codeなどは、すべて「人間が毎回ゼロから手作業する範囲」を減らす技術だったとも言えます。

生成AIも、この流れの延長線上にあります。

AIがソフトウェア業界を突然工業化するというより、もともと工業化へ向かっていたソフトウェア開発に、AIが非常にうまく適合したと考えるほうが自然です。

その前提に立つと、今後は次のような変化が起きると予想できます。

1. AIモデルは、さらに賢く、速く、安くなる

AIモデルの性能向上は今後も続くでしょう。

同時に推論コストは下がり、レスポンス速度も向上していくと考えられます。

現在は「コストを意識してAIを使う」場面もありますが、将来的には、検索やコンパイルと同じように、開発プロセスの中で常時AIを利用することが当たり前になる可能性があります。

重要なのは、単に性能が上がることではありません。

十分に高性能なAIを、十分に安く、大量に使えるようになることが、開発プロセスそのものを変えます。

2. コーディングエージェントは、開発ツールから「作業主体」へ変わる

現在のAIコーディングツールは、すでにコード補完の範囲を超えています。

今後はさらに、

リポジトリ全体の理解
Issueからの実装
テストコードの追加
バグ修正
リファクタリング
Pull Requestの作成
CI失敗時の再修正

までを連続的に実行するようになるでしょう。

つまり、AIは「人間がコードを書くための補助ツール」から、

人間が仕事を依頼する実行主体

へ近づいていきます。

SEが直接コードを書く時間は減り、複数のエージェントへ仕事を割り振り、その結果を確認する時間が増えるかもしれません。

3. AIブームが終わっても、コーディングエージェントは残る

現在のAI市場には、期待が過剰になっている部分もあります。

今後、AI企業の評価額が下落したり、投資が冷え込んだりする局面は十分にあり得ます。

しかし、それによってコーディングエージェント自体が消えるとは考えにくいでしょう。

一度、

「自然言語で指示すれば、AIが実装・修正・テストまで行う」

という開発体験が成立してしまった以上、業界全体が以前の開発スタイルへ戻る可能性は低いからです。

GitやCI/CDが一度普及したあとに消えなかったように、コーディングエージェントも何らかの形で開発プロセスへ定着していくと考えられます。

4. 企業は「AIを使うこと」を前提に生産性を求める

コーディングエージェントの普及は、必ずしも開発者の負担軽減だけを意味しません。

経営側から見れば、AIは生産性を上げる手段です。

例えば、これまで5日かかっていた実装がAIによって1日で終わるようになれば、

「4日休める」

ではなく、

「では、残り4日で別の仕事も進められる」

と考える企業のほうが多いでしょう。

そのため今後は、

「AIを使ってもよい」

ではなく、

「なぜAIを使わなかったのか」

と問われるケースが増えていく可能性があります。

また、開発の技能障壁が下がれば、従来はエンジニアしか触れなかった領域へ、企画・営業・マーケティングなどの職種が直接変更を加えるケースも増えるでしょう。

SEの仕事は「コード変更を独占すること」ではなく、安全に変更できる仕組みを整えることへ移っていきます。

5. プログラミング言語のロックインは弱くなる

これまで、技術選定は非常に重要な意思決定でした。

一度ある言語やフレームワークを採用すると、別の技術へ移行するには大きなコストが発生するからです。

しかしAIによるコード変換の精度が上がれば、

「既存システムを別言語へ書き換える」

という作業のコストは大きく下がります。

特に小〜中規模のシステムでは、

言語やフレームワークが、従来ほど長期的な制約ではなくなる

可能性があります。

その一方で、AIが扱いやすい言語へ技術が集中する可能性もあります。

Zig、Clojure、Elixir、Haskellなどの比較的ニッチな言語で構築された業務システムは、明確な技術的理由がなければ、

Python
Ruby
TypeScript
Rust

など、モデルが多くのコード例を持つ言語へ自動的に移行されるケースが増えるかもしれません。

「技術として優れているか」だけでなく、

AIが安定して扱えるか

という観点が技術選定に追加されることになります。

6. コードを書く自由度は下がり、ガードレールは増える

AIが大量のコードを生成する世界では、生成されたコードをすべて人間が詳細にレビューすることは困難です。

そのため、コードは今後さらに厳しい制約の中で生成・変更されるようになるでしょう。

例えば、

Lint
型チェック
Unit Test
Integration Test
E2E Test
セキュリティスキャン
依存関係チェック
API互換性チェック
パフォーマンステスト
アーキテクチャ制約

などです。

重要なのは、

「人間が注意深くコードを書く」

ことから、

「間違ったコードが通過できない仕組みを作る」

ことへ品質保証の中心が移る点です。

AIが自由にコードを書くほど、その外側には強いガードレールが必要になります。

7. コードレビューは「読む」から「検証する」へ変わる

AIが生成するコード量が増えると、人間のレビュー能力がボトルネックになります。

AIが数分で数千行の変更を生成しても、人間がそれを理解するには数時間かかる可能性があります。

その結果、レビューの対象そのものが変わっていくでしょう。

これまでは、

コードを読んで正しいか判断する

ことが中心でした。

今後は、

テスト、型、静的解析、実行結果、差分の影響範囲から正しさを判断する

方向へ移ります。

極端に言えば、十分に小さな変更で、すべての自動検証を通過しているなら、

人間がコードを一行ずつ読まずにマージする

ことも珍しくなくなるかもしれません。

これは一見危険に見えますが、製造業では一般的な発想でもあります。

製品の品質を熟練者の目視だけで保証するのではなく、工程そのものによって保証する。

ソフトウェア開発も、同じ方向へ進む可能性があります。

8. 手書きプログラミングは「仕事」より「趣味」に近づく

プログラミングには、職人的な楽しさがあります。

難しい問題を考え、美しい抽象化を作り、少ないコードで問題を解決する。

こうした行為そのものがなくなるわけではありません。

ただし、ビジネスとしてソフトウェアを開発する場合、

「AIで10分で生成できるものを、人間が2時間かけて手書きする」

ことを企業が許容し続けるとは限りません。

経済合理性の観点では、

AIに任せられる作業はAIに任せる

ことが標準になっていくでしょう。

その結果、「自分の手で一からコードを書く」という行為は、仕事よりも個人開発やOSS、趣味の領域で残る可能性があります。

9. SEの中心業務は「実装」から「品質と制約の設計」へ移る

では、SEの仕事そのものはなくなるのでしょうか。

私はそうは考えていません。

むしろ、役割が変わります。

今後重要になるのは、

何を作るべきかを定義する
業務要件をシステム要件へ変換する
AIに適切なコンテキストを与える
AIが守るべき制約を設計する
テスト戦略を作る
品質基準を定量化する
AIによる変更の影響範囲を判断する
例外や障害時に最終判断を下す

といった仕事です。

言い換えると、SEは、

「コードを書く人」から「AIが安全にコードを作れる開発システムを設計する人」へ変わる

ということです。

コードを書く能力が不要になるわけではありません。

コードを理解できなければ、AIの出力を正しく評価することも難しいからです。

ただし、「自分で何行書いたか」は、エンジニアの価値を測る重要な指標ではなくなっていくでしょう。

SEにとって重要になるスキル

この未来を前提にすると、SEが伸ばすべき能力も変わります。

特に重要になるのは、次の領域だと考えています。

要件定義力
曖昧な要求を、AIが実行できるレベルまで具体化する能力
アーキテクチャ設計力
AIが部分最適なコードを書いても、システム全体が壊れない構造を作る能力
テスト設計力
「正しく動いている」を自動判定できる仕組みを作る能力
品質基準の定量化
可読性、性能、安全性、互換性などをルールへ落とし込む能力
業務理解力
AIが簡単には取得できない、企業固有の業務や背景を理解する能力
AIへのタスク分解能力
大きな問題を、エージェントが安全に処理できる単位へ分解する能力

これらは、従来のSEにも必要だった能力です。

ただしAI時代には、その重要度が大幅に上がると考えられます。

まとめ

ソフトウェア開発は、今後さらに工業化していくでしょう。

生成AIはその流れを生み出したものではなく、長年続いてきた「標準化・自動化・属人性の排除」という方向を急激に加速させる存在です。

その結果、SEの価値の中心も変わります。

これまでは、

「自分で正しいコードを書く能力」

が非常に重要でした。

これからは、

「AIが正しいソフトウェアを継続的に作れる仕組みを設計する能力」

が重要になります。

つまり、AIによってソフトウェア開発からクラフトマンシップが消えるのではありません。

クラフトマンシップの対象が、コードそのものから、AI・テスト・制約・品質保証を含む開発プロセス全体へ移る。

私は、これが今後のシステムエンジニアに起きる最も大きな変化だと考えています。

参考・出典

本記事は、以下の記事で提示されているソフトウェア開発の将来予測を参考にし、日本のシステムエンジニアという観点から要約・再構成し、考察を加えたものです。

Powderworks Newsletter
“Tabs, Spaces, Hand Tools, and Seat Belts”
https://newsletter.powderworks.dev/p/tabs-spaces-hand-tools-and-seat-belts