【新刊】チームトポロジー

みどころ

みなさんは「コンウェイの法則」について聞いたことがあるでしょうか？ これは「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」という法則で、1968年にメルヴィン・コンウェイが書いた論文が元になっています。 50年も前にできた法則が今どう関係あるの？と思うかもしれませんが、現代のソフトウェアにおいてもこの法則は当てはまります。 ソフトウェアのアーキテクチャーとチーム構造は不可分（自己相似形）であり、アーキテクチャーにあわないチーム構造を選択したり、チーム構造にあわないアーキテクチャーを選択すると問題が起きます。

例えば、伝統的な（古典的な）ソフトウェア開発の現場で、コンポーネント単位のチームや専門スキル別のチームに分けてしまうと、さまざまなチームが集まって調整を行ったり、日々の仕事のなかでチームをまたいでコミュニケーションを行ったりする必要が出てきます。 しかし、このようなやり方は、コミュニケーションコストが高く、常に何かを待つことになり、ソフトウェアを出荷するのは大変な苦労が伴います。 関係者は多くのことを知らなければならず、認知負荷も高くなります。 こうなると、ビジネスの要求する速度に追随することもできません。

チームトポロジーは、このコンウェイの法則を踏まえたチームファーストのアプローチです。 「チーム構造と組織構造を進化させて、望ましいアーキテクチャーを実現する」という逆コンウェイ戦略を実現するために、4つのチームタイプと3つのインタラクションモードを定めています。 それをもとにフローを最適化する組織を設計しようというのが肝です。 なお、組織の設計は固定的なものであるべきではなく、組織やプロダクトの進化に応じて、漸進的に変化していかなければいけない、という点についても強調しています。

本書で紹介しているチームタイプは4種類で、開発組織のチームは4種類のうちのどれかになります。

• ストリームアラインドチーム: ビジネスの主な変更フロー（つまりバリューストリーム）に沿って配置するチーム。職能横断型で、他のチームを待たずにデリバリーできる。いちばん中心となるチームタイプ
• プラットフォームチーム: インフラやツール、共通サービスなどを提供するチーム。これによってストリームアラインドチームは詳細を知る必要がなくなり認知負荷が下がる
• イネイブリングチーム: 他のチームが新しい技術やスキルを身につけるのを支援するチーム。永続的に支援するのではなく、短期的な支援となるのが普通
• コンプリケイテッド・サブシステムチーム: 名前のとおり複雑なサブシステムやコンポーネントを扱う専門チーム。必要なときだけ構成する

インタラクションモードは3つです。インタラクションモードとはチーム同士の関与の仕方、関係性を表したものです。

• コラボレーションモード: 2つのチームが探索を目的として協力しあう。責任境界が不明確で効率は悪いが学習は進む
• X-as-a-Serviceモード: 一方のチームが他方のチームが提供するものをサービスとして利用する関係性
• ファシリテーションモード: 一方のチームが他方のチームが新しい技術を身につけたり学習したりするためにファシリテーションする

4つのチームのうち、ストリームアラインドチームが根幹となるチームで、このチームが素早くデリバリーできるようにするために他のチームが周りにいて、規定したやり方でコミュニケーションするという構図になります。 本書では、さまざまな事例を交えながら、このアプローチの有効性を解説しています。 事例には、Amazon、Adidas、Spotifyなども登場します。

本書の翻訳にあたっては、角谷信太郎さん、粕谷大輔さん、後藤優一さん、竹葉美沙さん、常松祐一さん、西谷圭介さん、松木雅幸さん、吉田真吾さんに翻訳レビューにご協力頂きました。この場を借りて御礼申し上げます。

企画、編集は、日本能率協会マネジメントセンターの山地淳さんが担当されています。

是非お手にとって頂ければ幸いです。

• 出版社（日本能率協会マネジメントセンター）のサイト
• Amazonで購入する