AIエージェント時代の「2枚のピザ」──作ってから書く、というプロダクト定義

AmazonのCTOだったWerner Vogelsが、同社に古くからある「ツーピザ・チーム(two-pizza team)」の考え方を、AIコーディングエージェントが当たり前になった今の文脈で捉え直している。テーマは組織論とプロダクト開発プロセスの両方にまたがる。エンジニアやテックリードにとって刺さるのは、「仕様書を書いてから作る」という長年の順番を、彼が明確にひっくり返している点だ。動くプロトタイプを一晩で作れる時代に、プロダクトの定義をどう変えるべきか。その具体的な提案が書かれている。

原文はこちら: https://www.allthingsdistributed.com/2026/06/return-to-two-pizza-culture.html

ツーピザ・チームが本当に守ろうとしていたもの

ツーピザ・チームは、ピザ2枚で足りる程度の少人数でチームを組むというAmazonの有名なルールだ。Vogelsによれば、その本質はピザの枚数ではなく、「同じ部屋にいる全員が、会議を開かなくても他の全員が何をやっているかを把握している」状態を保つことにあった。小さいからこそ意思決定が速く、実験と反復を高速で回せる。この自律性とスピードが初期のAmazonを駆動していた。

問題はスケールとともに訪れる。提供サービスが3つから200以上へと増える過程で、組織のエントロピーは自然に上がっていく。チーム間の横断的な調整が必要になり、承認のサイクルが生まれ、かつての速さが失われていく。これは避けがたい重力のようなもので、成長する組織なら誰もが直面する。

「作る前に書く」だったワーキング・バックワード

Vogelsは2006年に自ら言語化した「ワーキング・バックワード(Working Backwards)」というプロダクト定義プロセスに触れる。作り始める前に、プレスリリースを書き、FAQを用意し、顧客体験を定義し、ユーザーマニュアルを書く。顧客の側から逆算して考えるこの手法の利点のひとつは、コードが書けなくても実践できることだった。プロダクトの定義を、技術者だけの専有物にしない。長くAmazonの規律を支えてきた考え方だ。

AIエージェントが順番を逆転させた

記事の核心は、AIコーディングエージェントの登場でこの計算式が変わった、という主張にある。かつては、作るのが高コストだったからこそ、事前に文章で徹底的に詰めることに価値があった。だが今は、動くものを作るコストが劇的に下がっている。

Vogelsが挙げる例が、Amazon Quickのデスクトップチームの経験だ。Thomas DelteilがKiroを使い、一晩で機能するプロトタイプを組み上げた。それが数時間のうちにチームメンバーを引き寄せ、みんなが集まってきた。そこでチームが優先したのは、事前の計画づくりではなく、まず自分たちでそのプロダクトを触って体験することだった。

ここから導かれる運用原則はシンプルだ。長々と書いてから作るのではなく、まずプロトタイプを素早く作る。それを実際の顧客のように自分で使い込む。手を動かす中でギャップに気づく。そのうえで、想像ではなく現実に裏打ちされたドキュメントを書く。プロトタイプそのものが、事前に書かれたどんな文書よりも良い思考を生む、という発想である。

改訂版のプロセス

Vogelsが示す新しい順番は、従来を反転させたものだ。顧客の課題については強い確信を持ちながら、その解決策については本当の意味で未確定な状態から始める。まずプロトタイプを作り、徹底的に使い、同僚と共有し、そこで得た発見を文書化する。確信と不確実性の置きどころが、従来とは入れ替わっている点がポイントだと言える。

もっとも、これは「もう仕様書はいらない」という話ではない。ドキュメントを書く順番とタイミングを変えるという主張であり、書くこと自体は残る。この区別は読み違えないほうがいい。

スケールしても文化を失わないために

Quickデスクトップが数百人規模に育っても、ツーピザ・チームの構造を保ち、明確なオーナーシップと自律的な意思決定を維持することが不可欠だった、とVogelsは書く。狙いは、階層的な承認ではなく分散した自律によって「オーナーシップの文化」を守ることにある。

結論として彼が強調するのは、最終的な成功をもたらすのは、互いを信頼し、問題を端から端まで自分たちのものとして所有し、自らの確信に基づいて動く少人数のグループだ、という点だ。技術的な追い風は新しくなっても、この原則は変わっていない。

読んでどう受け止めるか

ここからは私の受け止めになる。この記事の実務的な含意は、プロトタイプを「捨てる前提の使い捨て」ではなく「思考の道具」として扱え、という点にあると思う。一晩で動くものが作れる環境は多くのチームに既にある。だとすれば、ボトルネックは実装力ではなく、作ったものから何を学び取れるかに移っている。Vogelsの言うオーナーシップとは、その学習のループを自分たちで回しきる胆力のことだろう。組織が大きくなっても小さく速いチームを守るという主張は目新しくないが、AIエージェントがその実現を後押しするという接続の仕方に、この記事の新しさがある。

出典: Werner Vogels「A return to two-pizza culture」。ニュースレター『Leadership in Tech』で紹介。原文: https://www.allthingsdistributed.com/2026/06/return-to-two-pizza-culture.html