9月7日、LeadDevが「Meta tried to shrink engineering teams around AI」と題した記事を公開した。MetaがAIを活用したエンジニアリングチームの小規模化を試みた実験が頓挫した経緯と、その教訓についてまとめたものだ。AI導入による「チームのスリム化」は多くの組織が検討するテーマだが、Metaの事例はその難しさを数字で示している点で注目に値する。
コード変更220%増、でも機能リリースは36%増止まり
Metaは今年初め、「AIネイティブなエンジニアリングチーム」の新モデルを試験した。従来の10〜20人規模のプロダクトグループを解体し、AIツールとエージェントで支援される3〜5人の「ポッド」に再編するというものだ。
数字だけ見れば結果は良好に映った。Reutersが報じたところによれば、社内インフラのコード変更数は前年比220%増を記録した。
しかし実態は異なった。
- ユーザーへの新機能・改善機能のリリース数の増加は36%増に留まった
- 重大な技術・セキュリティインシデントは40%増
- インシデントの対応（火消し）に費やすエンジニアの時間は70%増
コードは大量に生成されたが、組織として「有用なものを届ける能力」はほとんど伸びなかった。
「アウトプット」と「アウトカム」の混同
LeadDevはエンジニアリングリーダー向けのメディア・イベント運営組織で、今回の記事では複数の専門家へのコメントを交えてこの問題を分析している。
開発者インテリジェンス企業DX（Developer Experience企業）のDistinguished ScientistであるBrian Houck氏は、この問題の本質を次のように指摘する。
「私たちはアウトプットの数字に恋をしがちで、アウトカム（成果）の指標に十分な注意を払っていない」
DXが500以上の組織を対象に行った調査でも同様の傾向が確認された。週次のプルリクエスト数は4四半期で37%増となった一方、開発者体験の総合指標（Developer Experience Index）は67から65に低下。新機能の開発に費やすエンジニアリング時間の割合はほぼ横ばいだった。
コードを速く書けるようになっても、そのコードのレビュー・テスト・デプロイ・運用に時間を取られれば、組織全体のスループットは改善しない。Houck氏はさらに、「優れたエンジニアリングシステムの基本原則は変わっていない」としながらも、AIはこれまで軽微だった問題を深刻化させると警告する。例えば、シニアエンジニアが一人でレビューできていた変更量が、AI生成コードの洪水によって手に負えなくなるといった状況だ。
理想のチームサイズは「5〜8人」、縮小は最後
エンジニアリングチームのコーチング・採用支援を手がけるGather.devのCTOで、O'Reillyの近刊『Scaling AI Adoption in Engineering』の著者でもあるPeter Bell氏は、AI時代に特に重要になる2つのロールを挙げる。
- プロダクトエンジニア — 顧客とドメインを深く理解する人材
- プラットフォーム／開発者体験エンジニア — AI生成コードを安全に扱うための仕組み（ハーネス、評価基盤、pre-commitフック、マージキュー）を構築する人材
Bell氏が推奨するチームの適正サイズは5〜8人。同じリポジトリを直接触るのが1〜2人であっても、だ。理由は技術面と人間面の両方にある。複数のエンジニアがエージェントを使えば、同時並行の変更が簡単に手に負えない数に膨れ上がる。また「5〜8人という規模は人間にとって自然に機能し、つながりの感覚を生む」とBell氏は言う。
チームの縮小自体を否定するわけではないが、Bell氏は順序を重視する。まず小規模・低リスクの実験でエージェントに任せられるタスクを特定し、段階的に人間のレビューを減らしていく——これが正しい道筋だ。
Metaが行ったのはその逆だった。先に組織を抜本的に再設計し、テクノロジーが追いつくことを期待した。 その結果は上述の通りだ。
Bell氏も「これを正しくやるのは非常に難しく、最初は失敗する人の方が多い」と率直に認めている。
今回の実験は、コード出力量という単一指標でAI活用の価値を測ろうとした試みが、現場の複雑さに直面した構図として読み取れる。なお、Metaが一部のAI関連人事評価の仕組みを見直しているとも伝えられており、こうした実験の帰結と無関係ではないかもしれない。AI活用の効果測定をどう設計するかは、多くのエンジニアリング組織にとって引き続き難しい問いである。
詳細はMeta tried to shrink engineering teams around AIを参照していただきたい。
