2枚のピザチームにはウィキが必要です

Amazonの「ピザ2枚ルール（two-pizza team）」モデルは、現代の組織設計において最も影響力のあるアイデアの1つです。チームの規模は、ピザ2枚で全員のお腹を満たせる程度の小ささ（おおむね5〜8人）に抑えます。そして、定義された領域の明確な所有権を各チームに与えます。中央の権限からの承認を待つことなく、自分たちで意思決定を行い、自律的に運営させます。

このモデルは機能します。研究によると、明確な所有権の境界を持つ小さな自律的なチームは、大規模なチームよりも1人あたりの生産性を高く維持できることが一貫して示されています。彼らはより効率的にコミュニケーションをとり、意思決定を迅速に行い、より頻繁に成果をリリースします。大規模なチームの足を引っ張るコミュニケーションパスの爆発は、各少人数チームの管理可能なパス数の範囲内に抑えられます。

しかし、このモデルには組織設計の文献でほとんど議論されない依存関係があります。それは、チーム間の知識レイヤーが、少人数チーム構造によって生じるチーム間の調整を処理できるほど強力である場合にのみ機能するということです。

チーム間の問題

30人のチームを6人のチーム5つに分割すると、チーム内の調整コストは劇的に削減されます（435のパスから、15のパスが5セットになります）。しかし、新しい調整のインターフェースが生まれます。それがチーム間の境界です。

チームAは決済サービスを所有しています。チームBはユーザーサービスを所有しています。チームCはAPIゲートウェイを所有しています。各チームは自らの領域内で自律しています。しかし、これらの領域は相互に作用します。APIゲートウェイはユーザーサービスと決済サービスの両方にリクエストをルーティングし、決済サービスはユーザーサービスからのユーザーデータを必要とします。これらの相互作用にはチーム間の調整が必要であり、その調整の質は、各チームの知識が他チームからどれだけアクセスしやすいかに依存します。

もしチームAの決済サービスに関する知識がチームAのメンバーの頭の中にしかない場合、チームBは決済の仕組みを理解する必要があるたびに、チームAの手を止めなければなりません。調整コストは少人数チーム構造によって排除されたわけではありません。チーム内からチーム間へと移動しただけであり、日々の文脈を共有していない人々が関わるため、チーム間の調整は往々にしてよりコストがかかります。

ドキュメンテーションへの依存

少人数チームが機能するのは、各チームの領域知識が十分にドキュメント化されており、他のチームが会議やSlackのスレッドを必要とせずにアクセスできる場合です。

これは、各チームが以下を必要とすることを意味します：

サービスが何を行い、どのように機能し、どのように相互作用するかを説明するシステムドキュメント。単なるAPIドキュメントだけでなく、アーキテクチャの背景も含みます。なぜそのように構築されたのか、どのような制約のもとで動作しているのか、そしてその挙動について特定の前提を置くと何が壊れるのか、といった内容です。

意思決定記録（Decision Records）。主要な技術的選択の背後にある理由を説明するものです。チームBがチームAのサービスで予期しない事態に遭遇したとき、チームAとの会議を設定するのではなく、意思決定記録を読むことで、なぜそのように動作しているのかを理解できるべきです。

何が変更され、なぜ変更されたのかを記録する変更ドキュメント。チームAがチームBに影響を与える形でサービスを変更する場合、その変更と影響はチームBが見落とす可能性のあるSlackメッセージではなく、ドキュメントで確認できるようにすべきです。

チームの境界を越えてアクセスできる検索可能な知識。チームBは、自チームのドキュメントと同じくらい簡単にチームAのドキュメントを検索できるべきであり、さらにその検索は、必要な情報を見つけるためにチームAの命名規則を知る必要がないよう、意味（セマンティック）に基づいて機能すべきです。

イネーブラーとしての「自己執筆（Self-writing）」

多くの少人数チームの導入において、チーム間のドキュメンテーションへの投資が不足する理由は、ドキュメント作成の負担が、すでに自身の業務で忙しい個々のチームにかかるためです。6人のチームに対し、自分たちの機能をリリースすることに加えて、他チームのために包括的なドキュメントを維持することを求めるのは、ドキュメントの優先順位を永久に下げてくれと言っているようなものです。

自己執筆型ドキュメンテーション（Self-writing documentation）はこの方程式を変えます。各チームのドキュメントは、既存の活動（PR、Slackの会話、会議など）から自動生成されます。ドキュメントは、別個のタスクとして維持されるのではなく、業務そのものから派生するため、常に最新の状態に保たれます。また、組織全体にまたがる統一された知識レイヤーの一部となるため、他のチームもそれを検索することができます。

ピザ2枚チームモデルは組織の戦略です。そして自己執筆型ドキュメンテーションは、それを機能させるための知識インフラです。これなしでは、少人数チームはただの小さなサイロ（孤立した組織）になり下がり、調整コストは縮小するのではなく、場所を移動するだけになります。

よくある質問

チームのAPIや契約（コントラクト）はどうですか？ APIドキュメントやサービス契約は不可欠ですが、それだけでは不十分です。それらはインターフェースを説明するものであり、その背後にある理由を説明するものではありません。他チームのAPIが何をするかは知っていても、なぜそのように動作するのかを知らないチームは、不完全な理解に基づいて連携の意思決定を行ってしまいます。意思決定記録やアーキテクチャドキュメントがこのギャップを埋めます。

チーム間の依存関係はどのように処理しますか？ 依存関係を共有レイヤーに明示的に記録します。チームAが、チームBが自社サービスの特定の挙動に依存していることを知っている場合、その依存関係をドキュメントで確認できるようにし、影響を与える変更がリリース前にフラグ付けされるようにします。

これは非エンジニアリングチームにも適用されますか？ 小さな自律的チームを採用しているあらゆる組織に、同じ力学が当てはまります。マーケティングポッド、セールスチーム、プロダクトスクワッドなど、すべてのチームが、頻繁な会議を開くことなくチーム間の境界を越えて調整を行うために、共有された知識レイヤーを必要としています。

関連の読み物：知識のスケーリング問題、ブルックスの法則は今でも正しい、エンジニアリングチームをスケールする方法。関連ページ：自己執筆ドキュメント、ワン検索、エンジニアリングチーム向け。