なぜAIはソフトウェアエンジニアに取って代わらないのか:'Decide-Execute-Deliver' サンドイッチ

AIはソフトウェアエンジニアに取って代わることはありません。なぜなら、コードを書くという行為は自動化できても、「何を構築するか」を決定し、その提供に対して責任を負うという高次の機能を自動化することはできないからです。現在の「AI主導のレイオフ」の波は、主に経営陣が財務的な制約を隠すために使用しているナラティブであり、実際の雇用動向を見ると、ソフトウェアの価格弾力性が高いため、ソフトウェアエンジニアリングの需要は依然として底堅いままです。

AI主導のレイオフという神話

テックセクターにおける多くの注目を集めるレイオフは、公的な声明ではAIのせいにされていますが、内部データや報道によれば、異なる要因が明らかになることがよくあります。いくつかのケースでは、CEOがステークホルダーを納得させるために、人員削減の理由としてAIを挙げることがあり、これは「AI washing」として知られる慣行です。

  • Block: AIを活用した「より小さく、よりフラットなチーム」を理由に4,000人のレイオフを発表しましたが、その後の報道によれば、会社はパンデミック時代の過剰雇用後の massive financial pressure に直面していました。
  • Snap: AIが新しいコードの65%を生成していると主張し、1,000人のレイオフの理由としてAIを挙げましたが、実際にはコスト削減を求める活動家投資家からの要求に従ったものでした。
  • Intuit: プレスリリースでは3,000人の削減をAI主導の再編として枠組み付けていましたが、CEOは、削減の対象はAIの実装ではなく、調整業務の多い役割や管理層であることを明示的に述べていました。

ニューヨークの WARN Act 提出書類がこれを裏付けています。大量レイオフの際にAI開示チェックボックスを追加した後、最初の1年目において、そのチェックボックスにチェックを入れた企業はほとんどおらず、これは実際のAIによる置換は、公的なナラティブとはかけ離れていることを示唆しています。

'Decide-Execute-Deliver' サンドイッチモデル

なぜAIがソフトウェアエンジニアに取って代わることができないのかを理解するためには、「コーディング」と「ソフトウェアエンジニアリング」を区別する必要があります。著者は、開発の「サンドイッチ」モデルを提案しています。

  1. Decide (トップレイヤー): 問題の定義、仕様策定、および計画。これには、ユーザーのニーズ、市場のシグナル、および規制上の制約を理解することが求められます。
  2. Execute (ミドルレイヤー): 設計と実装(コードを書くこと)。
  3. Deliver (ボトムレイヤー): テスト、検証、統合、およびメンテナンス。

AIは、Execute レイヤーを効果的に圧縮しました。100,000人の GitHub 開発者の研究によれば、AIエージェントは書かれたコードの行数において8倍の増加をもたらしましたが、実際のリリースはわずか30%の増加にとどまりました。これは、人間によるボトルネック、すなわち「何が正しいか」を決定し、「それが機能するか」を検証することこそが、生産性の主要な制約となっていることを示しています。

Agentic Engineering vs. Vibe Coding

プロフェッショナルがAIをどのように使うか、そしてアマチュアがどのように使うかには決定的な違いがあり、それがエンジニアの雇用保障に影響を与えます。

  • Vibe Coding: ユーザーがエージェントに指示を出し、厳密な検証や評価するスキルなしに、出力を受け入れること。このアプローチは、本番環境での脆弱性や失敗を招きやすい傾向があります。
  • Agentic Engineering: エンジニアがAIをツールとして使い、制御権を維持し、出力に対して責任を負うこと。このプロセスは、エージェントを監督するために、AIが「行き止まりの道」を追求することを防ぐための深いシステム理解が必要となるため、精神的に非常に消耗するものです。

SWE-chat データセットの証拠によれば、エージェントが生成したコードのわずか44%が最終的なユーザーコミットに生き残る一方で、「vibe-coded」なコミットは、人間のみのコードに比べて9倍の割合で脆弱性を導入します。

経済的要因とジェボンズのパラドックス

AIの効率性の向上は、職業を破壊するのではなく、ジェボンズのパラドックスに似た現象を通じて、ソフトウェアエンジニアの需要をむしろ増大させる可能性があります。AIの効率性が高まると、ソフトウェアの生産コストがコストが低下するため、ソフトウェアへの需要が増大します。

歴史的に、世界のソフトウェアへの渇望は底なしです。コーディングが安価になるにつれ、組織は、以前はコストが高すぎて構築できなかったような、単発のユーティリティや複雑なシステムを構築するようになります。これは、開発者とコード行数の比率は変わるかもしれませんが、「Decide」と「Deliver」 レイヤーを管理できる熟練したエンジニアの総量的な需要は成長するであろうことを示唆しています。

反論と業界の視点

ソフトウェアエンジニアリングの全般的な需要は依然として強力ですが、個別の経験は様々です。コミュニティの議論では、いくつかのリスクとニュアンスがニュアンスが議論されています。

  • Domain Displacement (ドメイン置換): AIを使う一般論的なエンジニアが、特定の分野(例:フロントエンド・ウェブ開発)のスペシャリストを置き換える可能性があると主張する人々がいます。
  • Greenfield Automation (グリーンフィールド自動化): 一部の開発者は、「greenfield」プロジェクト(ゼロからの構築)が現在、大幅に速くなっていると報告しており、新規構築のための人数を必要としなくなっています。
  • The Accountability Gap (責任のギャップ): 繰り返し指摘される点は、、組織はミッションクリティカルなコードに対して、責任を取る「身代わり」または免許を持つ専門家による承認を必要とするため、AIは、その役割をフィートアップすることができません。

"If you can understand it in your head, you can put it out into the world in 1/100th of the time... I feel like the general layer, the translator, between what the business goals are and what tech covers it the best way." — Community Contributor

最終的に、ソフトウェアエンジニアの役割は、手動のコーダーから、認知エージェントの監督者へとシフトしており、構文(syntax)よりも判断力、アーキテクチャ、および責任を強調するようになっています。

Sources