はじめに
「SaaS is Dead」が話題になってから数ヶ月が経った。
もちろん、現実にはそう単純ではない。セキュリティ、業務の複雑さ、責任の所在、既存システムとの統合など、さまざまな理由から、従来のSaaSや開発体制がそのまま生き残る領域もある。逆に、急速に置き換わる領域もある。
ただ、それでもひとつだけかなりはっきり言えることがある。 僕たちエンジニアリングチームの前提は、すでに大きく変わってしまった。
個人的にその変化を強く感じ始めたのは、2025年12月ごろだった。Opus 4.5を触り始めたあたりから、「これは単なる便利ツールの延長ではない」と思うようになった。社内でも何度かアラートを出したが、うまく伝えきれなかった感覚がある。
そして2026年に入り、「AIオーケストレーション」や「ハーネスエンジニアリング」といった言葉が現場で実体化し始めた。もしこれを読んでいるあなたが、まだその影響を実感していないとしたら、理由は2つ考えられる。まだ置き換えの波が到達していない、生成AIに対して鈍感な組織に所属しているか、組織の倫理観によって置き換えられていないかのどちらかだろう。
危機感を煽るのは好きではないので、これまであまり強く言わないようにしてきた。だが、2026年3月時点の感覚としては、いよいよ組織とキャリアのデッドラインが来てしまった、というのが正直なところだ。
何が変わったのか
これまでソフトウェア開発では、実装できる人数を増やすことに意味があった。実装量はそのまま開発速度につながり、チームを大きくすることにも一定の合理性があった。
しかし、生成AIによってこの「実装生産量が最大の制約」という前提が崩れた。
個人的に最近フルベットしている TAKT というOSSに代表されるような、ハーネスエンジニアリングの台頭だ。Issueを立てるだけで、AIがリポジトリのコンテキストを読み込み、数分でPRが提出される。しかも、そのコードレビューの精度や指摘の網羅性は、すでに大半の人間より上手い。暴れ馬のようなAIの出力を、いかに安全に本番環境へ繋ぎ止めるか（ハーネスするか）。その技術が確立され始めたことで、かつてミドル層が数日かけていたタスクが一瞬で終わるようになった。
コードを書くことそのもの、あるいは仕様に沿って一定水準の実装を量産することは、もはや希少な能力ではない。
すると何が起きるか。チームのボトルネックは「実装量」ではなくなる。代わりに、要件の整理、意思決定、責任の所在、品質保証、そしてコミュニケーションが前面に出てくる。
これからのチーム
この前提に立つと、これからのチームは極端に言えば「小さく」なければならない。むしろ、人数を増やすことはリスクになる。
理想形は、2人だ。
まずひとり、ビジネスを強く前進させられる人がいること。この人は必ずしもエンジニアでなくてもよい。重要なのは、顧客や業務の課題を掘り当て、何を作るべきかを決め、生成AIをオーケストレーションしながらプロダクトを前に進められることだ。これまでプロダクトの実装の推進はエンジニアに任せていた層の人たちが、自分たちでどんどん進められる時代が来た。
そしてもうひとりが、技術の責任を持てるエンジニア。 このエンジニアは、単なる実装者ではない。インフラからフロントエンドまで全方位の深い基礎知識を持ち、AIが吐き出したコードの「違和感」を瞬時に嗅ぎ取れるアーキテクト的な存在だ。保守性、セキュリティ、設計、運用、将来の変更容易性といった、プロダクトの土台を「成立させる」役割を担う。
最低限、この2人でかなりのところまで行けてしまう。あとはバス係数を上げるために、将来的に引き継ぎ可能なバッファとなる人材が数人いれば十分だ。バス係数というのは、チーム内で何人がバスに轢かれてもプロダクトが存続できるかを示すやや物騒な指標のことで、例えば1人バスで轢かれたらプロダクトが死ぬような体制はバス係数1と言われる。
逆に言えば、従来のようにビジネスサイドが複数人いて、エンジニアが4人、5人と並び、細かく役割分担してタスクを消化する体制は、終わってしまった。まだ終わってない組織は単に感度が低いか、合理性より倫理観を優先できているいい組織だと思う。だが、いずれにせよ、そういう体制は長くは続かない。数年後には、ほとんどの企業で、生成AIを活用した小規模なチームがプロダクト開発の主流になっているだろう。 人数を増やすことによる生産性向上よりも、コミュニケーションコスト（会議、認識合わせ、レビュー待ち）の増大のほうが圧倒的に大きくなるからだ。実装がボトルネックでなくなった今、組織を小さく保つことこそが最大の競争力になる。
シニアエンジニアやマネージャー層は、この現実を見て組織を再定義しなければならない。実装チームを管理するのではなく、AIと少数のスペシャリストで完結する体制へ移行させるのが急務だ。おそらく2026年中には組織を変えないといけない、という危機感を個人的に感じている。
大きな勘違い
ここで、若手やミドル層が陥りがちな大きな勘違いについて触れておきたい。
自分が生き残るために「生成AIのプロンプトエンジニアリングを極めよう」「AIツールを使いこなせるようになろう」と焦るのは、完全に見当違いだ。
そんなことをする暇があるなら、技術書を1冊でも多く読んだほうがいい。 ネットワーク、データベース、OS、アーキテクチャ、テスト、セキュリティ。そういった不変の基礎を徹底的に固めるべきだ。
基礎が十分にない状態で生成AIを使っても、もっともらしい嘘や、後々負債になる設計に気づけず、間違ったまま高速に進んでしまう。しかも自分ではうまくいっているように見えるからタチが悪い。
ビジネスサイドでの生成AIブームにも全く同じことが言える。生成AIツールの使い方を勉強するより先に、インターネットがどう構成され、コンピュータはどう動き、これまでSaaSは業務をどうやってプログラムに落とし込んできたかを理解した方が、はるかに生き残る力になる。
シニアエンジニアが生成AIを使って数十倍の生産性を出せるのは、ツールの使い方が上手いからではない。そもそも確固たる前提知識があり、アーキテクチャ全体を見渡せて、AIの出力の違和感に気づき、捨てるべきものを即座に捨てる「判断力」があるからだ。
土台の上にAIを載せたときの総合力。 これがすべてだ。
残念ながらミドルクラス以下のエンジニアの「仕事量」自体には、もう価値はない。量ではなく質。実装速度ではなく判断精度。ツールへの習熟ではなく、成立条件を見抜く力。生き残る方法は、ソフトウェアエンジニアリングの基礎という圧倒的な「質」を上げる以外にない。シニアの生産性は2026年上半期には数倍になると思う。そうなったときに生き残れないのは、基礎がない人だ。誤解してほしくないが、基礎を時間をかけて身につけろという話ではない。生成AIの成長はそんなに悠長ではないので、ここから1年でシニアレベルの基礎力を身につけるくらいの速度で成長しないと、2027年には本当に居場所がなくなってしまう。
これからのエンジニア
この変化の中で、いちばん厳しい立場に置かれるのは、基礎力を持たないジュニアやミドルのエンジニアだ。
仕様に沿って手を動かす。ある程度のコードを書く。既存のやり方を踏襲しながらタスクを進める。そうした仕事は、凄まじいスピードで代替されていく。
これから求められるのは、何を作るべきかを定義できる人、AIの出力を検証できる人、設計や運用まで含めて成立させられる人、そして「責任」を引き受けられる人だ。
要するに、単なる実装者から、判断する人、整える人、成立させる人にならなければならない。
今ジュニアやミドルにいる人に必要なのは、のんびり経験年数を積むことではない。1〜2年でシニア相当の視座と基礎力を身につけるくらいの速度で成長しないと、本当に居場所がなくなる。
成長の遅い業界に移るか、エンジニアリング以外の職種に軸足を移すか、あるいは短期間で死に物狂いで上に上がるか。 これは他人事ではない。僕自身も、従来の「技術職」という枠組みが再定義される中で、常に自分の立ち位置を問い直している。
急速に成長するしかない。 2026年、従来のエンジニアの終わりは、新しいサバイバルの始まりでもある。
生成AIの拡大によって、日々絶望を感じながら、それでもソフトウェアエンジニアとして生きたいと思っている個人のポエムでした。
