何が起きたか
Arvind NarayananとSayash Kappor両氏が、ソフトウェアエンジニアリングをAI代替の試金石として分析しました。規制障壁が極めて低く、AIに最も置き換わりやすいはずのこの職種ですら、データ上は大量解雇が観測されていないというのが主張の核です。
根拠の一つが、米国で初めて解雇通知にAIを理由として記載する欄を設けたニューヨーク州のWARN Act改正です。施行後の初年で160社超が通知を提出しましたが、AI欄にチェックを入れた企業はゼロでした。
なぜ重要か
「AIの能力が一定水準を超えれば大量失業が起きる」という言説に対し、両氏は「すでに棄却するに足る証拠が出ている」と踏み込みます。コーディングという最も自動化に近い職種で起きていないなら、規制や対人要素の多い他職種ではなおさら起きにくい、というロジックです。
ボトルネックはどこか
両氏はソフトウェア開発者の業務を質的に分解し、自動化に抵抗する3つのボトルネックを抽出しました。
- 何を作るかを決めて仕様化すること
- 出来上がったものを検証し、その責任を負うこと
- コードベース・事業・環境に対する深い人間的理解
コードを打ち込む工程はAIが加速しますが、開発時間の多くを占めるのは会議とデバッグです。会議の中身も、デバッグの判断も、上記3つの理解なしには成立しません。記事の著者Simon Willison氏自身も、AIは「決める」「検証する」工程を助けるが、価値の源泉は依然として深い人間的理解にあると述べています。
💼 事業会社視点：これは自社にどう効くか
日本の事業会社の役員にとって、この分析は「AIで開発要員を半減できる」という前提の経営計画を一度棚卸しする材料になります。とくに受託開発SIerやSaaS事業者は、コーディング工数の削減を売上減ではなく粗利改善の機会として再定義すべきです。要件定義・検収・運用責任といった「決める/検証する」工程こそが顧客が金を払う対象であり、ここを内製で握れているかが今後の交渉力を決めます。
EC・小売など事業会社のDX責任者は、ベンダーの「AIで開発が速くなる」という提案を鵜呑みにせず、「誰が仕様を決め、誰が検収責任を負うか」を契約段階で明示すべきです。コードを書くスピードではなく、自社業務とコードベースを深く理解した人材を社内に残せるかが、AI時代の競争優位を決めます。スタートアップ経営者は、エンジニア採用を「コード生産量」でなく「事業理解の深さ」で評価軸を組み替える時期に来ています。
