フレームワーク活用ガイドひとことで言うと#
2枚のピザで全員が食べられる人数（6〜10名程度）をチームの上限とする、Amazonが実践するチーム設計の原則。ジェフ・ベゾスが「チームが大きくなるほどコミュニケーションコストが指数関数的に増える」という問題を解決するために導入した。
押さえておきたい用語#
- 2ピザルール
- チームの人数はピザ2枚で足りる規模に抑えるべきという原則。具体的には6〜10名が目安。
- コミュニケーションパス
- チーム内のメンバー間の情報伝達経路の数。人数nのチームではn(n-1)/2本になり、人数が増えると爆発的に増加する。
- シングルスレッド・リーダーシップ
- 1つのチームに1つのミッションと1人の責任者を置くAmazonの方針。2ピザチームとセットで運用される。
- オーナーシップ
- 自分のチームの成果に対する当事者意識と責任感。少人数チームほど一人ひとりのオーナーシップが高まる。
2ピザチームの全体像#
こんな悩みに効く#
- チームが大きくなって、会議が長くなり意思決定が遅くなった
- メンバーが「自分の担当範囲」しかやらず、当事者意識が薄い
- 組織をスケールさせたいが、どの単位でチームを分ければいいかわからない
基本の使い方#
2ピザチームは「小さくする」ことが目的ではない。ミッションに対して自律的に動ける最小単位にすることが目的。
- 1チーム = 1ミッション（例:「決済の成功率を99.9%にする」「新規ユーザーのオンボーディング完了率を上げる」）
- ミッションが曖昧だと、結局他チームとの調整が増えて小さくした意味がなくなる
- Amazonでは各チームが「自分たちのサービスのオーナーである」と言い切れる状態を目指す
外部への依存を最小化するために、チーム内に必要な職能を揃える。
- プロダクトマネージャー / デザイナー / エンジニア / データアナリスト等
- 全職能を1人ずつ揃える必要はない。兼務や80%の時間参加でも可
- 重要なのは「他チームの承認なしに意思決定→実装→リリースができる」こと
チームを小さくしても、チーム間の依存が多ければ結局遅くなる。
- API境界: チーム間のインターフェースを明確に定義する
- 共有サービス: 認証・決済などの共通機能はプラットフォームチームが提供し、各チームは利用するだけ
- 定期同期: チーム間の同期は週1回30分のリード会議に限定する
具体例#
Amazonの商品検索チームはかつて30名以上の大組織だった。検索アルゴリズムの改善提案が実装されるまでに平均 6週間 かかっていた。
ジェフ・ベゾスの指示で、検索組織を5つの2ピザチーム（各6〜8名）に分割。
| チーム | ミッション | 人数 |
|---|---|---|
| 検索ランキング | 検索結果の関連性を最大化 | 7名 |
| 検索UI | 検索体験のUI/UXを改善 | 6名 |
| 検索インフラ | 検索速度のSLA維持 | 8名 |
| オートコンプリート | 入力補完の精度向上 | 6名 |
| 検索広告 | スポンサー商品の表示最適化 | 7名 |
分割後、改善提案から実装までの平均時間は 6週間 → 9日 に短縮。各チームが自分のミッションに集中でき、年間の検索改善実験数は 3倍 に増加した。
従業員200名のアパレルEC。カスタマーサポート部門（25名）が1つのチームで運営されていた。問い合わせ対応の平均解決時間は 48時間、顧客満足度は 3.2/5.0。
2ピザルールに従って3チームに再編。
| チーム | 担当 | 人数 |
|---|---|---|
| 注文・配送チーム | 配送状況・返品・交換 | 8名 |
| 商品チーム | サイズ相談・商品情報 | 7名 |
| VIPチーム | リピーター上位10%の専任対応 | 6名 |
各チームに判断権限を委譲し、マネージャー承認なしで返金・交換を即決できるようにした。
3ヶ月後の結果:
- 平均解決時間: 48時間 → 8時間
- 顧客満足度: 3.2 → 4.4
- VIPチームの専任対応で、上位顧客のリピート率が 67% → 82% に向上
少人数チームにしたことで「自分たちの顧客」という意識が芽生えたのが最大の変化だった。
国立大学の情報工学研究室。教授1名・准教授1名・博士課程3名・修士課程12名・学部生6名の計23名。全体ミーティングが週2時間あるが、自分に関係ない発表を聞く時間が大半で、修士学生から「時間の無駄」という声が出ていた。
2ピザルールを参考に、研究テーマごとに3つのサブチームに再編。
| チーム | テーマ | 人数 |
|---|---|---|
| NLPチーム | 自然言語処理 | 8名 |
| CVチーム | コンピュータビジョン | 7名 |
| システムチーム | 分散システム | 8名 |
各チームは週30分のスタンドアップと月1回の深掘り議論を行い、全体ミーティングは月1回の成果共有会に縮小。
結果として、論文投稿数は前年比 1.6倍 に増加。修士学生の満足度調査も 2.8 → 4.1（5段階）に改善された。「自分のチームの成果に責任を持つ」という意識が、学生の研究モチベーションを引き上げた。
やりがちな失敗パターン#
- 人数だけ減らしてミッションを分けない ── 8名にしただけで依然として複数の目標を追っていると、小さいのにバラバラなチームになる
- チーム間の依存関係を放置する ── デプロイに他チームの承認が必要、データベースを共有している、といった依存があるとチーム分割の効果が半減する
- 全チームを同じサイズにする ── ミッションの複雑さによって最適な人数は異なる。「6名」に固執せず、6〜10名の幅で柔軟に調整する
- スペシャリスト不足を無視する ── デザイナーが1名しかいないのに3チームに分けると、デザインがボトルネックになる。共有リソースの配分も同時に設計する
まとめ#
2ピザチームはAmazonが実践する「少人数×自律」のチーム設計原則。核心は「ピザ2枚で足りる人数」という覚えやすいルールで、コミュニケーションコストを抑えつつオーナーシップを最大化すること。チームを小さくするだけでなく、1チーム1ミッションの原則と、チーム間依存の最小化をセットで実行することが成功の条件になる。