チームトポロジー

https://m.media-amazon.com/images/I/51JxJVl5YXL.jpg https://www.amazon.co.jp/dp/B09MS8BML8

組織図の構造に基づく意思決定は、組織の一部分のみに最適化されがちで、上流と下流への影響は無視される。局所最適化は直接関係のあるチームにとっては役に立つが、顧客への価値のデリバリー全体を改善するのに役立つとは限らない。

チーム構造は要求されるソフトウェア構造と一致しなくてはならない

コンウェイの法則は「私たちの組織が原因で利用できない、より良い設計があるのではないか」と問い続ける義務を生み出す。

モノリシックなシステムがあったときにマイクロサービス化したいとすれば、システムを分割する前にチームを分割すれば自然と分かれる

コンウェイの法則の示す重要な点は、すべてのコミュニケーションとコラボレーションがよいとは限らないということだ。したがって「チームインターフェイス」を定義し、どんな仕事には強力なコラボレーションが必要で、どんな仕事には必要ないのかという期待値を設定することが重要になる。多くの組織はいつでもコミュニケーションは多いほうがよいと考えるが、実際にはそうではない。

「全員がチャットの全メッセージを見るべき」とか、「大規模なスタンドアップミーティングに全員出席すべき」とか、意思決定のために「全員が会議に出るべき」と組織が期待しているなら、組織設計上の問題があるのだ。コンウェイの法則は、こういった多対多のコミュニケーションは、速いフローをサポートしない、モノリシックで、こんがらがっていて、結合度が高く、相互依存するシステムを生み出す傾向にあることを示している。コミュニケーションを増やすことは必ずしもよいことではないのだ。

SREチームは必須ではなくオプションだ。Googleでもすべての開発チームがSREを使っているわけではない。SRE at Googleのなかで、ヤナ・ドガンは「プロジェクトの規模が小さくなっているなら、SREのサポートも減らす。規模的にSREのサポートが不要になれば、開発チームがSREの作業を担当する」と言っている

AmazonのCTOであるワーナー・ヴォゲルスが語ったことで有名になった「you build it, you run it（自分で作ったら、自分で運用する）」の原則に従って、サービスチーム（内部での呼称）は職能横断型で、サービスの管理、仕様決定、設計、開発、テスト、運用（インフラストラクチャーのプロビジョニング、顧客サポートを含む）を自分で行える能力を持っていなければいけない。