SaaS is Dead論で揺れる採用市場、淘汰されないエンジニア像とは
「SaaS is Dead」論が広がる一方、SaaS企業の採用は止まらない。AIで誰でもアプリが作れる時代に、企業が求める人材の条件はどう変わったのか。「作れるだけ」が淘汰される理由と、生き残るエンジニアの3つの軸をSynthが整理します。
目次
- まず結論
- 1. 「SaaS is Dead」論って何を言ってるのか
- 主張の骨子
- でも、ちょっと待って
- 2. データで見る：SaaS採用は本当に止まったのか
- 採用市場の実態
- なぜシニア需要が増えているのか
- 3. 「作れるだけ」が淘汰される3つの理由
- 理由1：AIの方が「作るだけ」なら速くて安い
- 理由2：事業側がエンジニアに求めることが変わった
- 理由3：AIを使いこなせない人の生産性が、相対的に低くなる
- 4. 生き残るエンジニア像：3つの軸
- 軸1：設計の判断ができる
- 軸2：事業の言語で話せる
- 軸3：AIを使い倒せる
- 5. これからキャリアを考える人へ
- スタート地点別のアプローチ
- 学習リソースの選び方
- あなたへの影響
- まとめ
- 関連記事
- 参考にしたソース
まず結論
- 「SaaS is Dead（SaaSは終わった）」論がSNSや投資家向けの論考を中心に広がっている
- 一方で、SaaS業界の採用市場は縮小していない。むしろ採用を強化する企業も目立つ
- ただし、求める人材の条件が大きく変わった——「作れるだけ」のエンジニアは確実に厳しくなる
- 生き残る軸は3つ：①設計の判断ができる ②事業の言語で話せる ③AIを使い倒せる
- 「AIで仕事がなくなる」より「AIを使えない人とのギャップが拡大する」が正確な現状認識
ニュース元：「SaaS is Dead」でも採用激化？ 「作れるだけ」のエンジニアが淘汰されるワケ（ITmedia）
1. 「SaaS is Dead」論って何を言ってるのか
最近、AI界隈やスタートアップ界隈で「SaaS is Dead」という言葉を見かけませんか？ ぱっと見、「SaaSビジネスは終わり」という極論に聞こえます。でも実際に発信者の主張を辿ると、もう少し繊細な話が見えてきます。
主張の骨子
「SaaS is Dead」と言っている人たちの言い分は、ざっくりこういう内容です。
| 論点 | 主張 |
|---|---|
| 作る側のコスト | 生成AIで、SaaS的なアプリは個人でも数日で作れるようになった |
| 乗り換えコスト | カスタムSaaSをAIで作る方が、年額のSaaSを払い続けるより安い |
| マルチテナント前提の崩れ | 「みんなで同じUIを使う」前提が、各社カスタム生成で崩れる |
| 代表的な発言者 | Microsoft CEO ナデラ氏「SaaSはエージェントに置き換わる」（2024年末頃） |
つまり、「SaaSが消える」というよりは、「みんなで共通サービスを買う」モデルが終わり、「自分用に生成する」モデルに移るという主張です。これは確かに一理あります。
でも、ちょっと待って
ここがポイントなんですが、現実の採用市場はそんな単純な動きをしていません。「SaaSは終わる」と言われている裏で、SaaS企業の採用は止まっていないどころか、強化されている領域すらある。なぜか？
そこを丁寧に見ていくと、AI時代のエンジニアキャリアの輪郭が見えてきます。
2. データで見る：SaaS採用は本当に止まったのか
ITmediaの記事（「SaaS is Dead」でも採用激化？）が指摘していたポイントを整理します。
採用市場の実態
| 項目 | 2024年 | 2026年（現在） |
|---|---|---|
| 「作れるだけ」のエンジニア需要 | 中〜高 | 大幅減 |
| シニア / アーキテクト需要 | 高 | 高〜大幅増 |
| プロダクト思考できる人材 | 高 | 大幅増 |
| AI活用前提でチームを率いれる人 | 低〜中（言葉自体新しい） | 超高需要 |
| ジュニアエンジニア（独立志向） | 中 | やや減 |
要するに、「採用が減った人」と「採用が増えた人」が明確に二極化しています。「SaaSは終わる」という大雑把な言説では捉えきれません。
なぜシニア需要が増えているのか
AIでコードが書けるようになると、コードを書く工数は減る一方、設計判断の工数は増える——という現象が現場で起きています。
- 「このAPIをどう設計するか」
- 「セキュリティ要件と性能要件、どっちを優先するか」
- 「AIが提案する解決策の、どこを採用してどこを捨てるか」
これらはコードを書く能力ではなく、判断する能力です。そして判断するには経験が要る。だからシニア需要が増えています。
3. 「作れるだけ」が淘汰される3つの理由
ここからは、なぜ「作れるだけ」のエンジニアが厳しくなっているのかを、もう少し踏み込んで見ていきます。
理由1：AIの方が「作るだけ」なら速くて安い
正直に言うと、これに尽きます。「仕様書を渡してそのまま実装する」だけの仕事は、Claude CodeやCursor、Codexがすでに人間より速くやれる領域に入っています。
| タスク | 人間（中堅エンジニア） | AI（Claude Opus 4.7 等） |
|---|---|---|
| 簡単なCRUD実装 | 半日〜1日 | 数十分 |
| API設計（叩き台） | 1〜2日 | 数時間 |
| ユニットテスト追加 | 数時間 | 数十分 |
| バグの原因調査 | 数時間〜半日 | 数十分（ログがあれば） |
| 新機能の方針決め | 数日 | AI単体では難しい |
| 既存システムとの整合性判断 | 数日〜数週間 | AI単体では難しい |
下の2行が肝で、「判断」の領域だけはまだAIに置き換わっていません。
参考：GitHub Copilot vs Claude Code vs Cursor 徹底比較
理由2：事業側がエンジニアに求めることが変わった
これも大きい。これまでは「PdMが要件を決めて、エンジニアが実装する」が分業の基本でした。AI時代になって、この分業が崩れてきました。
| 旧来 | 現在 |
|---|---|
| PdMが要件定義 → エンジニアが実装 | エンジニアもAIと壁打ちしながら要件を決める |
| 要件確定後に見積もり | 試作品を1日で作って判断 |
| 「実装はあとから」 | 「設計と実装が一体」 |
| エンジニアは技術判断のみ | エンジニアも事業判断に関与 |
つまり、**「事業の言語が話せるエンジニア」**の市場価値が上がっています。逆に、「技術しかわからない」「事業の話には興味ない」というスタンスは、市場価値を下げる要因になっています。
理由3：AIを使いこなせない人の生産性が、相対的に低くなる
AIを業務で使い倒している人と、ほぼ使っていない人の間で、1日あたりの生産性が3〜5倍違う——という現場の声を、最近よく聞きます。
これは「AIを使えば誰でも超人」ではありません。使い方を知っている人だけが、その差を享受しているという話です。
💡 正直な本音 「AIで仕事がなくなる」というフレーズが嫌いです。実際に起きているのは「AIを使う人と使わない人のギャップが拡大する」という、もっと地味で残酷な現象です。前者は今までの仕事を3倍速で終わらせ、空いた時間で別の高付加価値の仕事をしている。後者は同じスピードで同じ仕事をしているだけ。市場価値の差は時間とともに開いていきます。
4. 生き残るエンジニア像：3つの軸
ここからは「じゃあどうすれば？」の話です。筆者が取材や肌感覚で見ている範囲だと、淘汰されないエンジニアには共通する3つの軸があります。
軸1：設計の判断ができる
「どう作るか」より「何を作らないか」を決められる人。
具体例：
- 「この機能、本当にユーザーが求めてる？」を最初に問える
- 「AIが生成したコード、ここは採用するけどここは却下する」が言える
- 「将来こう変えたいから、今はこのアーキテクチャにする」と言える
- 過剰設計と必要最小限のバランスを取れる
★希少度：★★★★★
軸2：事業の言語で話せる
「技術的に〇〇できます」だけでなく、「売上にどう繋がるか」「ユーザー体験がどう変わるか」を語れる人。
具体例：
- 「このリファクタは月間XXX時間の運用工数削減になる」と説明できる
- 「ユーザー定着率が改善するから、まずこの機能から実装すべき」と提案できる
- 経営層との会話で技術用語を翻訳できる
- PdM / マーケ / セールスとの距離が近い
★希少度：★★★★☆
軸3：AIを使い倒せる
これは「AIに詳しい」ではなく、「業務でAIを毎日3時間以上使い込んでいる」という意味です。
具体例：
- Claude Code / Cursor / Codex を全部触ったことがある
- プロンプトの設計を意識的に学んでいる
- AIの「ハルシネーション」を見抜ける
- 自社業務向けのAgentやSkillを作れる
★希少度：★★★★☆
参考：Claude Code 完全ガイド2026、ChatGPTの賢い質問8パターン
5. これからキャリアを考える人へ
3軸を見て「自分には足りないな」と思った方もいるかもしれません。でも、ここは正直に言うと、全部を最初から揃えている人はほぼいないです。誰もが今、走りながら身につけている段階です。
スタート地点別のアプローチ
| あなたの現状 | 最初に動く軸 | 期間目安 |
|---|---|---|
| プログラミング未経験 | まず作れるようになる（独学 or スクール） | 6ヶ月〜1年 |
| ジュニアエンジニア（〜3年目） | AI使い倒し→設計判断の経験を積む | 1〜2年 |
| 中堅（4〜8年目） | 事業の言語を学ぶ、AI活用を業務に組み込む | 半年〜1年 |
| シニア（9年目〜） | AIを前提にした組織設計、後輩へのAI活用浸透 | 継続 |
学習リソースの選び方
「未経験から始める」場合、独学 vs スクールで迷う人が多いと思います。正直、どちらでも辿り着けます。ただし、スクールを選ぶ場合は「相談先がある」ことに価値があります。AI時代のエンジニア学習は、「ググれば出てくる情報」より「自分の状況に応じた判断」が必要だからです。
💡 未経験から本気で目指したい人へ DMM WEBCAMP エンジニア転職 無料カウンセリング（PR） — エンジニア転職特化のスクール。「自分が向いてるか」だけ無料相談で確認するのも一手。ただし、申し込み前に他校（侍エンジニア・TechAcademy等）と必ず比較してから決めてください。スクール選びは合う合わないが大きい
💡 副業 / 学び直しから入りたい人へ デイトラ コース入会（PR） — プログラミング・AIライティング等を独学ペースで進められる。価格帯が抑えめなので、最初の一歩として試しやすい
⚠️ 注意点 スクールは「申し込めば自動で身につく」ものではありません。毎日1時間以上の学習を半年継続できる人でないと、どこを選んでも結果は出ません。逆にそれができる人は、独学でも辿り着けます。スクールは「ペースメーカー」と割り切るのが現実的です。
あなたへの影響
読者の立場別に整理します。
| あなたの立場 | 影響度 | 今やること |
|---|---|---|
| 未経験で勉強中 | 大 | 「作れるだけ」で止まらないキャリア設計を最初から意識する |
| ジュニアエンジニア | 大 | AI活用を本気で始める。3ヶ月で「使い込んでる人」になる |
| 中堅エンジニア | 大 | 事業の言語を学ぶ。PdMやマーケと話せる範囲を広げる |
| シニアエンジニア | 中 | 自分は安泰だが、後輩のAI活用浸透を担う責務が増える |
| エンジニアリングマネージャ | 大 | 採用基準を更新する。「作れる」より「判断できる」を重視 |
| 採用側（人事） | 大 | スキル要件を見直し。過去のJD（求人票）は通用しない |
| エンジニアを目指す学生 | 大 | コードを書くだけでなく、事業 / プロダクト視点も並行で学ぶ |
💡 正直な本音 「SaaS is Dead」という言葉に振り回されすぎないことが大事です。実態は「SaaSが死ぬ」のではなく、**「SaaSの作り方・売り方・使われ方が変わる」**という遷移期にいます。エンジニアにとっては、学ぶことが減るのではなく、学び方が変わる時代です。これまでの「言語1つ深く」より、これからは「AI＋事業＋技術判断の三位一体」が問われます。
まとめ
「SaaS is Dead」は半分本当で、半分は誤解です。SaaSビジネスが消えるわけではなく、「作る側・買う側・使う側」の構造が組み変わっている——これが現状です。
その結果として、エンジニア採用の市場も大きく動いています。「作れるだけ」では確実に厳しくなる一方、「設計の判断ができる」「事業の言語で話せる」「AIを使い倒せる」の3軸を持つ人材の市場価値は跳ね上がっています。
不安に振り回されず、自分の現在地から一歩ずつ動いていくのが、結局は一番強い選択肢です。今日からできる動きを、ぜひひとつ決めてみてください。
関連記事
参考にしたソース
- 「SaaS is Dead」でも採用激化？ 「作れるだけ」のエンジニアが淘汰されるワケ（ITmedia） — 採用市場の実態と求められる人材像の変化
- 「Gemini」「Claude Code」「Codex」全社展開・本番実装に役立つ5つのポイント（＠IT） — 生成AIの組織導入と現場活用の論点
- AIがコードを書く時代に、言語を選ぶ意味はあるのか？（＠IT） — プログラミング言語選択を巡る議論
- Cursorが新AIモデル発表、コスト1/10で最先端と互角の衝撃（explAIn） — AIコーディングの価格破壊の最新状況
- Microsoft CEO ナデラ氏「SaaSはエージェントに置き換わる」発言の解釈（Business Insider） — 「SaaS is Dead」論の元発言の文脈
ーー Synth
ヘッダー画像: Photo by cottonbro studio on Pexels
