AIエージェント時代のツーピザ文化──作ってから書くプロダクト定義

Amazonの元CTO・Werner Vogelsが提唱してきた「ツーピザ・チーム」という組織文化がある。小人数で意思決定が速く、実験と反復を高速で回す、あの考え方だ。彼が最近改めて論じているのは、この文化がAIコーディングエージェントの登場でどう変わるべきか、という問題である。従来のAmazonが重視していた「Working Backwards」というプロセスがある。作る前に、プレスリリースとFAQ、顧客体験、ユーザーマニュアルを文章で徹底的に詰める。何を作るかを仕様書として完全に定義してから、実装に入る。このやり方が有効だった理由は単純で、作るのが高コストだったからだ。事前に文章で徹底的に詰めることに、それだけの価値があったのである。

AIエージェントが登場した今、この計算式は変わった。プロトタイプを作るコストが劇的に下がり、一晩で動くものが作れるようになった。Vogelsが取り上げている例では、Amazon Quickのデスクトップチームが一晩でプロトタイプを組み上げ、朝にはチーム全員がそれを触って、議論が始まっていた。ここが面白いところだ。チームが優先したのは、事前の計画ではなく、作ったものを実際に手を動かして使うことだった。従来型のプロセスが「仕様書をまず完全に書く」なら、新しいプロセスは「まずプロトタイプを作り、それを徹底的に使う」という順序だ。できたものが、事前に書かれたどんな文書よりも、思考を生む道具になる。

この転換は、単に「実装が速くなった」という話ではない。何が本当に価値を持つのか、という経営判断そのものが変わったということだ。従来は「作る前に完全に決める」ことが賢さだった。今は「決めきる前に試す」ことが賢さになった。中小企業がこれを実務に活かすなら、問うべきは「我々のプロダクト定義は、まだ仕様書ファーストのままでないか」という点だ。AIツールが安くなった今、試作から本番まで加速できる環境は既に手元にある。ならば、意思決定と学習のループを回すタイミングも、一緒に早めるしかない。