「2枚のピザチーム」とは、特定のビジネス機能のソフトウェアを完全にサポートする小さなチームのことを指します。Amazonがソフトウェア人材の組織化について説明するときに用いたことから有名になりました。

名前が示すように、こうしたチームの最も明らかな特徴は規模です。 これは「チームは2枚のピザで満足できる人数を超えるべきではない」の原則に由来しています （アメリカのピザの話です。はじめて見たときにはびっくりするほど巨大に思えました）。 チームを小さく保つことで、結束力が高まり、緊密な協力関係が生まれます。 通常は5〜8人程度になると思いますが、上限は15人程度になるでしょう。

名前が示しているのは規模だけですが、同じくらい重要なのはチームのフォーカスです。 チームは、他のチームへの引き継ぎや依存関係を最小限に抑えながら、価値のあるソフトウェアをユーザーに届けるために必要な能力をすべて備えている必要があります。 つまり、顧客のニーズを把握し、それを動作するソフトウェアにすばやく変換し、 顧客のニーズの変化に応じてソフトウェアの実験と進化を行なっていくことができるチームです。

2枚のピザチームは、アクティビティ指向ではなくアウトカム指向です。 スキル（データベース、テスト、運用）によって組織化されているのではなく、顧客をサポートするために必要なすべての責任を引き受けます。 こうすることで、 顧客に機能が届くまでの流れのなかで、チーム間の引き継ぎを最小限に抑え、 サイクルタイム（機能のアイデアを本番環境のコードに変えるまでに必要な時間）を短縮できます。 このアウトカム指向とは、 コードを本番環境にデプロイし、 そこでの使用状況を監視することも意味します。 本番環境で発生する障害の責任者になる（営業時間外でもサポートする）ということです。 「あなたが構築し、あなたが実行する（you build it, you run it）」の原則です。

顧客のニーズにフォーカスするというのは、 ビジネス機能が生きている限りサポートするビジネス機能中心の長寿なチームであるという意味です。 ソフトウェアが「完成」すると解散するプロジェクト指向のチームとは違い、 彼らは寿命の長いプロダクトの存続と強化のために自分たちは存在すると考えています。 こうしたことから、プロダクトチームと呼ばれることがあります。

プロダクトをサポートするには、幅広いスキルと責任が必要です。 したがって、2枚のピザチームは第一のアプローチになりますが、 適切に構築されたソフトウェアプラットフォームのサポートも必要です。 小規模な組織の場合は、最新のクラウド製品などの商用プラットフォームになるでしょう。 大規模な組織の場合は、 面倒な引き継ぎをすることなく、 2枚のピザチーム同士が協力しやすくなるように、 独自の社内プラットフォームを構築することになるでしょう。 チームトポロジーでは、 2枚のピザチーム（チームトポロジーではストリームアラインドチームと呼ばれます）をサポートするさまざまな種類のチームやインタラクションが提供されています。

ビジネス機能中心のチームが効果的であるためには、 チーム同士がお互いの能力を利用する必要があります。 したがって、チームは慎重に設計されたAPIを使用して、 自分たちの能力を仲間に提供する必要があります。 他のチームにサービスを提供するという責任は見過ごされがちですが、 これをやっておかないと情報のサイロ化につながってしまいます。

このようにビジネス機能を中心にチームを組織することは、 組織のソフトウェアの構造と深く関係しています。 コンウェイの法則の影響があるからです。 2枚のピザチームが構築したソフトウェアコンポーネントは、 明確なAPIを使用して、制御されたインタラクションを行なう必要があります。 こうした考え方がマイクロサービスの開発につながりました。 しかし、マイクロサービスがすべてではありません。 モノリシックなランタイムで適切に構造化されたコンポーネントを使用するほうが良いでしょう。