ソフトウェアエンジニアの仕事のうち、ゼロをイチにする業務の割合はかなり多かったはずです。初期のAIは、GitHub Copilotの行補完のように、その「ゼロをイチにする」ための作業を支援するツールでした。書きかけたコードを完成させるためのツールであり、コードをゼロから書くことを手伝ってくれるものだったと思います。
ですが、もはやそのフェーズは終わりつつあるように感じています。エンジニアがゼロからコードを書くことはなくなってきました。コードは「生成されるもの」になり、コードの保証も人間が一行ずつ確認するのではなく、AIへの指示やAI自動レビューによるフィードバックループのなかに入っています。現在は、コードをゼロから書くこと自体がなくなってきました。
この記事では、そうした変化のなかで「ゼロをイチにする仕事」がどうなっていくのか、そして「ソフトウェアエンジニア」という仕事そのものがどうなっていくのか、最近考えていることを記録しておきます。
なお、この記事のすべては2026年6月21日時点での私個人の見解です。
加速したのは実装、停滞したのはその前後
生成AIによって、SDLC(ソフトウェア開発ライフサイクル)における具体的な実装は大きく加速しました。そのお陰で、開発の前のフェーズと後のフェーズの停滞が、これまで以上に目立つようになってきています。
「何を開発するべきなのか?」が決まらないまま、それを待っているだけのエンジニアは、少しずつ不要になっていくのではないかと思います。業務委託という形態も、その性質上どうしても「指示を待つ」「指示をする」というやり取りが必要です。相手は人間なので、AIのように即座に・大量に指示を出すことはできません。
優れた正社員によって全てを効率化していくのか、それとも完全に仕事を切り出して外注する形になるのか。仮に後者になったとしても、ソフトウェアエンジニアの業務委託を増やすことは、経済合理性が次第に低くなっていくのではないでしょうか。そもそも、「業務委託を増やすかどうか」という問題解決のHOWを選んでいる時点で、状況の捉え方がずれているのかもしれません。
AIを待つ時間を減らす — 開発環境の健全性
AIエージェントが何かを待つ時間、待った結果として修正する時間は、減らしていかなければなりません。
たとえばCIです。CIを待たないようにする、そしてCIを高速化することはもちろん、フレーキーなCIはAIにとっても人間にとっても対応コストを増大させます。開発環境の健全性が、そのままAIエージェントの効率・コスト・成果に直結するようになってきました。これはもはや個人のローカル開発環境よりも広い範囲の問題です。
AIの待ち時間と、AIの作業完了を人間が待つ時間は、同じくらいムダなものだと考えています。そしてAIの作業完了を待つ時間が大きくなる原因の多くは、人間が作業の起点になっていることにあります。AIの作業開始はこれから自動化されていきます。人間がいちいち指示をしなくても、問題なくAIが作業を完了させられる状態を目指していくべきだと思います。
ガードレールは自然言語の外側で強制する
ガードレールやハーネスといったものは、最終的には自然言語以上のレベルで実装する必要があると思っています。
コードであればGit Hookで強制できればよいですし、日本語であればtextlintのように、解釈の余地なく実行を強制させる必要があります。その仕組みは、高速かつ正確に実行されなければいけません。そして、人間による既存のルール違反は残っていてはいけないのです。人間のルール違反は、AIによって高速に増幅されてしまうからです。
クリーンな状態を維持する仕組みによって、AIにも人間にも同じルールを強制する。BiomeやtextlintやKnipのようなものが、その役割を担っていくのだと思います。
局所最適化はボトルネックを移動させるだけ
ここで気をつけたいのが、局所最適化です。
局所最適化は、ボトルネックを移動させ、新たなボトルネックを発生させるだけになりがちです。開発だけを効率化しても意味がありません。全体最適を追求し続けなければいけない。そして、その最適化を最も阻害するのは、実は人間であるのかもしれないと感じています。パラダイムの古い人間がひとりいるだけで、全体の最適化が無効化されてしまう可能性は否定できません。
ビジネスは、開発だけ加速しても加速しません。全ての領域に入り込み全体像を理解し、その全体像の上に仕組みをつくらなければプロダクトの成功にはつながらないのです。単一のボトルネックらしきところを見つけてそこだけ改善しても大きな変化は生まれず、別の場所にボトルネックを移動させるだけになります。
律速になるのは組織構造
階層構造による組織管理も、これから機能しなくなっていくと思っています。
人間の指示を受けて人間が作業する、という入れ子構造は、アウトプットに対するレビューやフィードバックループを大きく遅くさせます。管理が必要な人間を減らし、できるだけフラットな状態にしなければ、組織構造そのものが律速の要因になってしまう。
AIの活用は、単なる開発組織内に閉じた問題ではなく、組織的な全体の問題であり、最終的には「人数」の話に帰着します。「AIが活用されていない」「変化が感じられない」のは、AIツールの問題ではなく組織的な問題である可能性が高い。現時点で顕在化していなかったとしても、いずれここに行き着くことになると思います。
ゼロをイチにすること自体は、もはやワンクリックで、高速に安価に実行できるようになっています。それをやらないのは完全に人間側の問題です。AIツール側に問題を探すのではなく、自分自身の考え方や仕事の仕方を改めたほうがよい。評論家やおどろき屋であり続けることは、いつまでもできるかもしれません。しかしそれでは何も前には進みません。前に進まない理由を探している、その理由は何なのかを考えたほうがよいと思うのです。
パクられない強みを持てるか
アイデアはAIによって高速に容易にパクられるようになります。パクられない強みを持たない企業は、ゆるやかに死んでいくのではないでしょうか。
スイッチングコストや、既存の契約・関係性が、ユーザーをつなぎ止める鎖になっているのかもしれません。しかし、そのスイッチングコストもAIによって限りなく減っていきます。これからは「スイッチングしてもらうための努力」と同じくらい、「スイッチングされないための努力」が必要になっていくはずです。
スイッチングされない自信や仕組みがあるからこそ提供できる機能、というものはあるのだと思います。マネーフォワードのAI Coworkのようなものでしょうか。大企業はその強みを活かして動くべきだと感じています。
残るのは「方向を決める」仕事
では、人間に残る仕事は何でしょうか。
方向性が決まった後の「ゼロをイチにする作業」は、AIに置き換えることが可能で、経済合理性もあります。一方で、ゼロ点からどの方向に進むのか、その最小単位を決める仕事は残り続けると考えています。
どの方向(ベクトル)に進むかには、無限の可能性と選択肢があります。その選択肢をしぼり込み、実行可能な単位に分割すること。ここには人間の決定が必要になります。実行可能な単位への分割は、もしかするとAIにもできるかもしれません。ただ、AIに作業させるには、組織やプロダクトのコンテキスト・ナレッジが必要です。
そしてそれを、機械可読な状態に整理し、維持し続ける必要があります。AI自身に実行時に調べさせることもできますが、トークンや時間の効率を考えると、特定の場所に整理された状態で置いておくのが望ましい。Devinの性能の高さの背景には、インデックスされ自動更新されるWikiやナレッジの存在が影響しているのだと思います。
「あとはやるだけ」の状態を整え続ける
人間の仕事は、「あとはやるだけ」の状態を整えること、「あとはやるだけ」を(AIに)やらせること、そして次の「あとはやるだけ」の状態を整えること、このループに集約されていくように思います。
方向性を示し完了条件を与えれば、ほぼ「あとはやるだけ」の状態をつくれます。そのプランを明確にし、自分で受け入れ可能であることを確認できれば、あとはAIがやるだけになる。
つまり、AIに実行させる「手前」をまず整える必要があるのです。そして、AIが実行時に余計なことをしない、迷わないように整える。AIの成果物を修正しなくてもよい状態にする仕組みをつくる。これが、これからの仕事の中心になっていくのではないでしょうか。
「ソフトウェアエンジニア」という名前の限界
これまでの「ソフトウェアエンジニア」は、細分化され、専門を深くしていく方向にありました。それぞれの領域が複雑化・高度化していたからです。そこに特化した人間が必要でした。
しかしAIによって、特定領域の仕事は効率化され、その仕事にかかる時間は短縮されました。この流れは続くと思われ、特定領域に閉じた専門家は少人数でもすむようになっていきます。そうなると、複数の専門を持った人間によって、単一領域の専門家は置き換えられてしまうかもしれません。フロントもバックエンドもできる人間ひとりで十分に仕事ができるなら、ふたりは必要ない。ふたりで役割分担しているうちは、片方がいなくなれば開発が止まってしまうという属人性も、結局は解消されていないのです。
領域ごとに個別最適化をしきったとしても、おそらく全体最適にはなりません。全体を見て最適化をする人間が必要になる。そして、その役割は「ソフトウェアエンジニア」の延長線上には存在しないのではないか、と思うのです。
「ソフトウェアエンジニア」という名前は、もう適切ではないのかもしれません。かといって「プロダクトエンジニア」も適切とは言えない。会社はプロダクトを中心としているかもしれませんが、全てがプロダクトであるわけではないからです。となると、この役割はどのような名前になるのでしょうか。ひとりがその役割を持つだけでよいのか。階層的な構造にすれば、また個別最適化の圧力がかかってしまう。まだ答えは出ていません。
変化しないことが、明確なリスクになる
「ソフトウェアエンジニア」という役割だけをしていくことは、これからできなくなっていくと思います。今はなんとかなるかもしれませんが、将来的にはなんともならなくなる。
より広いスキルでAIを使いこなす人間が出現し、そういう人間のほうが評価されるようになります。そのような評価基準を持てない会社は、いずれ他の会社に負けてしまうでしょう。現状維持でも評価されるのなら、変化するインセンティブはありません。しかし、今変化しないことは明確なリスクであると思うのです。変化に対応する会社と、しない会社。生き残るのは変化に対応する会社のほうである、ということは歴史を見れば明らかです。
ゼロをイチにする「だけ」の仕事は、もはや作業であり、AIのほうが上手に速くやってくれます。では、人間にどのような価値を見いだすのか。
そして、これまでにゼロをイチにしてきた人間と、したことのない人間とでは、AIの使い方は変わってくると思われます。この経験は、今はまだ必要なものだと考えています。ですが、最終的には不要になるのかもしれません。根本的に、世界が変わってしまったのですから。
なお、この記事は私自身が手書きしたメモを元にDevinによって作成した下書きをベースに記事化しました。 手書きメモ（5枚）の画像とプロンプトを以下の有料部分に置いておきます。
記事の有料販売ができる機能がついていたのでお試しです。投げ銭的なものと思ってもらえればと。
x5 
Help