ツーピザチーム

ツーピザチームとは、特定のビジネス機能のソフトウェアを完全にサポートする小規模なチームです。この用語は、Amazonがソフトウェアスタッフをどのように組織していたかを説明するために使用されていたため、普及しました。

名前から、そのようなチームの最も明白な側面、つまりその規模が示唆されています。この名前は、チームは2枚のピザで賄える人数を超えてはいけないという原則に由来しています。（ここで言及しているのはアメリカのピザですが、私が初めてこちらで見たときは驚くほど巨大に見えました。）チームを小さく保つことで、チームの結束力を維持し、緊密な協力関係を築くことができます。一般的には、このようなチームは約5〜8人であると聞きますが、私の経験では、上限は約15人程度です。

名前は規模のみに焦点を当てていますが、チームの焦点も同様に重要です。ツーピザチームは、他のチームへのハンドオフや依存関係を最小限に抑えながら、ユーザーに価値のあるソフトウェアを提供するために必要なすべての能力を備えている必要があります。彼らは顧客のニーズを理解し、それをすぐに動作するソフトウェアに変換し、顧客のニーズの変化に応じてソフトウェアを実験および進化させることができます。

ツーピザチームは、活動指向ではなく、成果指向です。彼らはスキル（データベース、テスト、運用）のラインに沿って組織化するのではなく、顧客をサポートするために必要なすべての責任を負います。これにより、顧客への機能の流れにおけるチーム間のハンドオフが最小限に抑えられ、サイクルタイム（機能のアイデアを実行中のコードに変換するために必要な時間）を短縮できます。この成果指向は、彼らが本番環境にコードをデプロイし、そこでその使用状況を監視し、有名なことに、あらゆる本番環境の停止に対して責任を負うことを意味します（多くの場合、時間外サポートに対応する必要があることを意味します）。これは「あなたが作ったものは、あなたが動かす」という原則として知られています。

このように顧客のニーズに焦点を当てるということは、チームは長寿命であり、ビジネス機能がアクティブである限り、そのビジネス機能をサポートするビジネス機能中心のチームであることを意味します。ソフトウェアが「完成」したときに解散するプロジェクト指向のチームとは異なり、彼らは自分たちを長寿命の製品を可能にし、強化するものと考えています。この側面から、彼らはしばしばプロダクトチームと呼ばれます。

ツーピザチームが製品をサポートするために必要なスキルの範囲と責任の広さは、そのようなチームがチーム編成への主要なアプローチとなる可能性がありますが、適切に構築されたソフトウェアプラットフォームからのサポートが必要であることを意味します。小規模な組織の場合、これは最新のクラウドサービスなどの商用プラットフォームにすることができます。大規模な組織は、ツーピザチームが困難なハンドオフを作成することなく共同作業を容易にするために、独自の内部プラットフォームを作成します。チームトポロジーは、ツーピザチーム（チームトポロジーではストリームアラインチームと呼びます）をサポートするために必要なさまざまな種類のチームと相互作用について考えるための良い方法を提供します。

ビジネス機能中心のチームが効果を発揮するには、互いの機能を活用する必要があります。したがって、チームは、多くの場合、綿密に設計されたAPIを通じて、同僚に機能を提供する必要があります。同僚にサービスを提供するという、そのようなチームの責任は見落とされることがよくあります。それが起こらないと、硬直した情報サイロにつながります。

このようにビジネス機能を中心に人を組織化することは、コンウェイの法則の影響により、組織のソフトウェアの構成方法と深く相互作用します。ツーピザチームによって構築されたソフトウェアコンポーネントは、明確なAPIを使用して、同僚との適切に制御された相互作用を必要とします。この考え方はマイクロサービスの開発につながりましたが、それが唯一のアプローチではありません。モノリシックなランタイム内にある適切に構造化されたコンポーネントの方が適切な場合があります。