『チームトポロジー』マシュー・スケルトン

内容

3つの組織構造

１．公式な構造（組織図）：コンプライアンス遵守を円滑にする

２．非公式な構造：個人間の「影響力の領域」

３．価値創造構造：個人間やチーム間の能力に基づいて、実際にどう仕事を終わらせるか

コンウェイの法則

システムのアーキテクチャーは構築したチームの形に固められる──ルース・マラン、「コンウェイの法則」

コンウェイは1968年に発表した論文で、「どんなチーム編成にも、うまく活用できない設計形式の類は存在する。そのために必要なコミュニケーションパスが組織に存在しないためだ」と述べていて、いくつかのヒントを示している。

正式な指揮命令系統かどうかに関係なく、組織内のコミュニケーションパスが、組織が考案できるソリューションの種類を事実上限定する。

だが私たちは、戦略的優位のためにこれを利用してもよいのだ。

ある種の設計（たとえば、技術的な内部に焦点を当てすぎたもの）を使わせたくないなら、そうならないように組織を再編すればよい。

同じように、組織にある種の設計（たとえば、フローに適したもの）を発見し使わせたければ、そうなるように組織を再編すればよい。

もちろん、私たちが望む設計を組織が見つけて利用する保証はないが、少なくともコミュニケーションパスを形成することによってその可能性は高められる。

プロダクト開発手法であるスクラムの先駆者の１人でもあるマイク・コーンは、組織におけるチーム間のコミュニケーションの健全性を評価するためにこんな質問をする。

「その構造は、チーム間のコミュニケーションパスの数を最小化するような構造になっているか？その一方で、チーム間のコミュニケーションが必要な場合は、それを誘発するような構造になっているか？」

ダンバー数

効果的に働けるチームの最大サイズは、多くの組織では７人から９人だ。

有名な話として、Amazonではソフトウェアのチームのサイズはピザ２枚分までとしている。

スクラムのような人気のフレームワークでもサイズを制限するよう推奨している。

このようなサイズの制限は、グループの認知と信頼に関する進化上の限界から来ている。

この限界の数をダンバー数と呼ぶ。

文化人類学者のロビン・ダンバーにちなんで名づけられた。

ダンバーは、１人の人間が信頼できる人間の数は150人までであることを明らかにした。

そのうち、お互いのことを詳しく知って親密な関係を築けるのは、５人くらいだ。

・およそ５人：人が親密な関係、もしくはワーキングメモリーを保持できる人数の限界

・およそ15人：人が深く信頼できる人数の限界

・およそ50人：人が相互信頼できる人数の限界

・およそ150人：人が他の人の能力を覚えていられる限界

・単一チーム：5-8人（業界での経験から）

・高信頼組織：15人以内

・ファミリー（「トライブ」）：50人以内のメンバーからなるチームのグループ

・高信頼組織：150人以内のグループ

・部門／ビジネスライン／収益部門：150-500人以内のグループ

チームAPI

安定して長続きするチームが、ソフトウェアシステムの特定の部分のオーナーシップを持つことで、安定したチームAPIを構築できる。

チームの周りを囲むAPIだ。

API（アプリケーションプログラミングインターフェイス）とは、プログラムがソフトウェアとやりとりするための方法を記述した仕様のことだ。

ここで私たちはチームとのやりとりにAPIのアイデアを拡張することにした。

チームAPIには、以下が含まれる。

・コード：チームが作成しているランタイムのエンドポイント、ライブラリ、クライアント、UIなど

・バージョン管理：チームがコードやサービスの変更についてどうコミュニケーションするか（例：セマンティックバージョニングを「チームの約束」として扱い、壊さないようにする）

・Wikiとドキュメンテーション：特にチームがオーナーシップを持つソフトウェアについてのハウツーについて

・プラクティスと原則：チームが好む働き方について

・コミュニケーション：リモートコミュニケーションについてのチームのアプローチ。チャットツール、ビデオ会議ツールなど

・仕事に関する情報：チームが現在取り組んでいること、次にリリースされるもの、中長期の全体の優先度など

・その他：他のチームがこのチームとやりとりするために必要なことは何でも

重要なのは、異なるチームから似たようなスキルや専門知識を持った人が集まり、お互いから学んだり、プロとしての技能を身に付けたりできるように、時間、場所、お金を提供することだ。

チームや人がお互いにコミュニケーションしながら学ぶための時間と場所を明示的に確保しておくことで、組織では、効果的なチームインタラクションを促す学習と信頼構築のリズムが作れるようになる。

チームが信頼関係を築き新しいことを学ぶのを助けるには、２つのことが必須になる。

１．意識して設計された物理環境および仮想環境

２．ギルド活動のためにデスクから離れる時間。コミュニティオブプラクティス（自主的に定期的に集まって興味のあるドメインについて一緒に学んだり、内部の技術カンファレンスを開いたりして、知識を共有するグループ）

チーム間の依存関係と待ち時間責任が明瞭で、独立して作業可能で、フローに最適化したチームにするには、チーム間の依存関係と待ち時間の検出と追跡が不可欠だ。

ドミニカ・ディグランディスは『Making Work Visible』のなかで、「チームをまたぐ重要な情報を見える化することは、チーム間のコミュニケーションに役立つ」としており、物理的な依存関係マトリクスやカンバンカードの「依存タグ」を使って依存関係を明らかにして追跡し、その依存関係がうまく機能するのに必要なコミュニケーションを推測することを推奨している。

ダイアン・ストルードとシッド・ハフが2012年に発表した論文「A Taxonomy of Dependencies in Agile Software Development（アジャイル開発における依存関係の分類）」では、依存関係には、知識、タスク、リソースという３つの異なるカテゴリがあるとしている。

このような分類は、チーム間の依存関係と、それがフローに与える潜在的な制約を前もって特定するのに役立つ。

ストリームアラインドチームストリーム

ストリームアラインドチームストリームとは、ビジネスドメインや組織の能力に沿った仕事の継続的な流れのことだ。

継続的なフローにするには、目的と責任を明確化し、複数のチームがそれぞれの仕事のフローを扱いつつ共存できるようにしなければいけない。

ストリームアラインドチームとは、価値のある単一の仕事のストリームに沿って働くチームのことだ。

ストリームとは、仕事やサービスの場合もあるし、機能一式のこともあり、ユーザージャーニーやユーザーペルソナの１つのような場合もあるだろう。

さらに、なるべくそのチームだけですばやく安全に顧客やユーザーに価値を届けられるように、チームに権限が委譲されている。

他のチームへの仕事の引き継ぎは必要ないということだ。

ストリームアラインドチームは、組織で根幹となるチームタイプで、残りの基本的なチームタイプの目的は、ストリームアラインドチームの負荷を減らすことにある。

本章の後半で見ていくが、たとえばイネイブリングチームのミッションは、ストリームアラインドチームが欠いている能力をすばやく獲得するのを助けることにある。

調査や試験の作業を行い、役に立つプラクティスを準備するのだ。

プラットフォームチームのミッションは、下位の詳細な知識（プロビジョニング、監視、デプロイなど）を引き取り、使いやすいサービスを提供することでストリームアラインドチームの認知負荷を減らすことだ。

ストリームアラインドチームは、デリバリー全体に関わるため、必然的に顧客の近くで働くことになり、本番環境のソフトウェアを監視しながら、すばやく顧客からのフィードバックを取り込めるようになる。

そのようなチームは、システムの問題にほぼリアルタイムに反応し、仕事の方向性を修正できる。

ドン・レイネルトセンの言葉を借りれば、「大きなチームより、スキルの高い人からなる小さなチームのほうが、本番環境での方針変更をすばやくできる」。

組織のなかでは複数のストリームが共存できる。

特定の顧客向けのストリーム、ビジネスエリアごとのストリーム、地理的ストリーム、プロダクトストリーム、ユーザーペルソナストリームなどがあり、規制の多い業界であればコンプライアンスストリームさえある（さまざまなストリームでの仕事を整理する方法については、Chapter6を参照）。

さらには、巨大企業のなかで、新規プロダクトのイノベーションを行うといった独立した目的とフォーカスを持つ小さな企業のような形を取ることもある。

どのようなストリームでも、ストリームアラインドチームは、短期のプロジェクトではなく、長期的に維持される仕事のポートフォリオもしくはプログラムの一部として、予算が割り当てられる。

ストリームアラインドチームが備える能力

一般的に、ストリームアラインドチームは初期の要求探索の段階から本番運用まで作業を進めるのに必要な能力一式を備えている必要がある。

そのような能力には以下のようなものが含まれる（これに限らない）。

・アプリケーションセキュリティ

・事業成長性分析と運用継続性分析

・設計とアーキテクチャー

・開発とコーディング

・インフラストラクチャーと運用性

・メトリクスとモニタリング

・プロダクトマネジメントとオーナーシップ

・テストとQA

・ユーザーエクスペリエンス（UX）

それぞれの能力を個人が担当するわけではないと理解しておくことが重要だ。

能力ごとにメンバーがいるとしたら、上のリストに挙げた能力だけでも９人が必要になるが、そうではなく、これらの能力をチームとして理解し実行できるようになるということだ。

ジェネラリストと少数のスペシャリストの混成チームになるかもしれない。

特定の能力だけを持つ専門ロールだけにすると、忙しいスペシャリストが常にボトルネックとなる状況を招いてしまう。

イネイブリングチーム

イネイブリングチームは、特定のテクニカル（プロダクト）ドメインのスペシャリストから構成され、能力ギャップを埋めるのを助ける。

複数のストリームアラインドチームを横断的に支援し、適切なツール、プラクティス、フレームワークなどアプリケーションスタックのエコシステムに関する調査、オプションの探索、正しい情報に基づく提案を行う。

そうすることで、ストリームアラインドチームは、多大な労力をかけずに能力を獲得し進化できる（私たちの経験では、能力獲得と進化を自分でやる場合に必要な労力がチームに与える影響は、10～15倍過小評価されている）。

イネイブリングチームは協調的な性格が強い。

効果的なガイダンスを提供するために、ストリームアラインドチームの課題や不足点を理解しようとする。

ユッタ・エクスタインは、イネイブリングチームを「テクニカルコンサルティングチーム」と呼んだ。

コンサルティングチームは内部、外部に関わらず、実作業ではなくガイダンスを提供するという点で、私たちの定義と一致している。

イネイブリングチームは、知識の「象牙の塔」になったり、チームに技術的な判断を押し付けたりしないように十分に注意しつつ、組織全体の技術的な制約をチームが理解し守るのを助ける。

個人ではなく、チーム単位での「サーバントリーダーシップ」とも考えられる。

イネイブリングチームの最終的なゴールは、ストリームアラインドチームへのソリューションの提供ではない。

ストリームアラインドチームの課題に注力することで、ストリームアラインドチームの自律性を高めることである。

イネイブリングチームがうまく機能すれば、ストリームアラインドチームは、イネイブリングチームからの支援を数週間から数か月で必要としなくなるはずだ。

イネイブリングチームへの継続的な依存関係は作るべきではない。

期待されるふるまいここまで見てきたように、イネイブリングチームのミッションは、ストリームアラインドチームがその時点で持っていない必要な能力を獲得するのを助けることだ。

通常は、特定の技術領域やプロダクトマネジメント領域に関わることが多い。

効果的なイネイブリングチームには、どんなふるまいやアウトカムが求められるかを以下に示す。

・イネイブリングチームは、積極的にストリームアラインドチームのニーズを探索し、定期的にチェックポイントを設け、より多くのコラボレーションが必要になるタイミングについて合意をする

・イネイブリングチームは、ストリームアラインドチームが実際に必要とするより前に、専門領域での新しいアプローチ、ツール、プラクティスについて先んじておく。これまでは、アーキテクチャーチームやイノベーションチームが担当していたミッションだが、他のチームの支援にフォーカスすることで、より良い関係性を生み出せる

・イネイブリングチームは、良いニュース（例「テストコードを50%削減できる新しいUI自動化フレームワークがある」）も悪いニュース（例「現在広範囲で利用しているJavaScriptフレームワークXは、積極的にメンテナンスされないことになった」）も伝える。技術面のライフサイクルマネジメントを支援するためだ

・イネイブリングチームは、ストリームアラインドチームが直接使うのが難しい外部（もしくは内部）サービスのプロキシーとしてふるまうこともある

・イネイブリングチームは、イネイブリングチーム内の学習だけでなく、ストリームアラインドチームを横断した学習も促進するため、組織内の適切な情報共有を促すキュレーターとして活動する（トム・デマルコとティモシー・リスターが「キー学習機能」と呼んだ機能をサポートする）

コンプリケイテッド・サブシステムチーム

コンプリケイテッド・サブシステムチームは、システムのなかでスペシャリストの知識が必要となるパーツを開発、保守する責任を持つ。

ほとんどのチームメンバーがその分野のスペシャリストでなければ、理解や変更が難しいようなサブシステムを担当する。

このチームの目的は、複雑なサブシステムを含んだり利用するシステムの担当となるストリームアラインドチームの認知負荷を減らすことにある。

このチームは、習得や育成の難しいスキルや専門能力を活かして、担当するサブシステムの複雑さに取り組む。

効果的なコンプリケイテッド・サブシステムチームには、どんなふるまいやアウトカムが求められるかを以下に示す。

・コンプリケイテッド・サブシステムチームは、担当するサブシステムの開発状況を意識して、適切にふるまう。初期の探索や開発の段階では、ストリームアラインドチームと密接にコラボレーションする。サブシステムが安定してきたら、インタラクションを減らし、サブシステムのインターフェイス、機能の使用状況と進化に集中する

・コンプリケイテッド・サブシステムチームが担当することで、サブシステムのデリバリー速度と品質は、ストリームアラインドチームが開発した場合（分割の判断をする前）より明らかに向上する

・コンプリケイテッド・サブシステムチームは、サブシステムを利用するストリームアラインドチームのニーズを尊重し、適切に優先順位をつけて変更をデリバリーする

プラットフォームチーム

プラットフォームチームのミッションは、ストリームアラインドチームが必要とする下位の内部サービスを提供することで認知負荷を減らし、ストリームアラインドチームがより上位のサービスや機能を提供できるようにすることだ。

効果的なプラットフォームチームには、どんなふるまいやアウトカムが求められるかを以下に示す。

・プラットフォームチームは、ストリームアラインドチームと密接にコラボレーションし、ストリームアラインドチームのニーズを理解する

・プラットフォームチームは、高速プロトタイピングの手法を使い、ストリームアラインドチームのメンバーを巻き込んで、何がうまくいって何がうまくいかないかのフィードバックをすばやく得る

・プラットフォームチームは、プラットフォームをプロダクトとして扱い、提供するサービスのユーザビリティと信頼性に強くフォーカスする。定期的にサービスが目的にあっているか、使いやすいかを検査する

・プラットフォームチームは、手本を示すことでリードする。提供したサービスを可能ならストリームアラインドチームと一緒に使い、可能な限り（他のプラットフォームチームがオーナーである）下位のプラットフォームを利用する

・プラットフォームチームは、新しい内部向けサービスの採用には他の新技術と同じように時間がかかること、テクノロジー採用ライフサイクルの採用曲線に沿って進化することを理解している

ソフトウェアを速く安全にデリバリーできている組織では、ほとんどのチームはストリームアラインドチームだ。

ストリームアラインドチーム以外のチームの数は、ストリームアラインドチームの７分の１から10分の１にすぎない。

成功している組織についての報告を踏まえると、ストリームアラインドチームとそれ以外のチームの数の比は、６：１から９：１になるのが適切だろう。

ソフトウェアの責任と境界

『LeanとDevOpsの科学』が取り上げた研究では、密結合のアーキテクチャーが、責任が明確で自律的なチームを持つ上で悪影響を与えることを実証している。

著者は、そのようなアーキテクチャーを分離するのに役立つアーキテクチャー的なアプローチについて、「目指すべきは『〈チーム間のコミュニケーションをさほど要さずに、設計からデプロイまでの作業を完遂できる能力〉を促進するアーキテクチャを生み出すこと』なのである。

この戦略を可能にするアーキテクチャ面でのアプローチとしては『コンテキスト境界とAPIにより、大規模なドメインを、より小規模、より疎結合なユニットに分割する』（中略）などが挙げられる」としている

インタラクションモード

ソフトウェアシステムのためのチームトポロジーモデルをいつどのように適用するかを理解するには、チームファーストの力学とコンウェイの法則を考慮した上で、チームがインタラクションする３つの基本的なモードを定義し、理解することが必要だ。

・コラボレーション：他のチームと密接に協力して作業すること

・X-as-a-Service：最小限のコラボレーションで何かを利用または提供すること

・ファシリテーション：障害を取り除くために他のチームを支援したり、支援を受けたりすること

・コラボレーション：２チームが一定期間密接に作業をすることで、新しいパターンや手法や制限を発見する。責任は共有され境界は曖昧になるが、問題はすばやく解決し、組織はすばやく学習する

・X-as-a-Service：一方のチームが別のチームから「サービスとして」提供されたもの（サービスやAPIなど）を使用する。責任は明確に定義されており、境界が効果的であれば、利用する側のチームはすばやいデリバリーが可能になる。サービスを提供する側のチームは、サービスをできるだけ利用しやすくすることを目指す

・ファシリテーション：一方のチームが、別のチームが新しいアプローチを学習したり習得したりするのを一定期間支援する。ファシリテーションを行う側のチームは相手チームをできるだけ早く独り立ちさせることを目標とし、ファシリテーションをされる側のチームは学習に対してオープンな態度を取る

４つのチームタイプと３つのチームインタラクションを組み合わせることで、多くの組織が経験するような曖昧さや対立は避けられ、明確で強力な方法によってチームベースの組織の有効性が高まる。

４つの基本的なチームタイプは以下のとおりだ。

・ストリームアラインドチーム：ビジネスの主な変更フローに沿って配置されるチーム。職能横断型で、他のチームを待つことなく、利用可能な機能をデリバリーする能力を持つ

・プラットフォームチーム：下位のプラットフォームを扱うチームで、ストリームアラインドチームのデリバリーを助ける。プラットフォームは、直接使うと複雑な技術をシンプルにし、利用するチームの認知負荷を減らす

・イネイブリングチーム：転換期や学習期に、他のチームがソフトウェアを導入したり変更したりするのを助ける

・コンプリケイテッド・サブシステムチーム：普通のストリームアラインドチーム、プラットフォームチームが扱うには複雑すぎるサブシステムを扱うためのチーム。本当に必要な場合にだけ編成される

速いフローで効果的なソフトウェアのデリバリーを行うのに必要なのは、これらのチームの組み合わせだけだ。

だが、効果的なソフトウェアデリバリーとは何なのかを理解し、それを実現していくには、４つの基本的なチームタイプ間のインタラクションモードも極めて重要である。

・コラボレーションモード：特に新しい技術やアプローチを探索している間、２つのチームがゴールを共有して一緒に働く。学習のペースを加速する上で、このオーバーヘッドには価値がある

・X-as-a-Serviceモード：あるチームが、別のチームが提供する何かを利用する（API、ツール、ソフトウェア製品全体など）。コラボレーションは最小限になっている

・ファシリテーションモード：あるチーム（通常はイネイブリングチーム）が、新しいアプローチの学習と適用を促すため、他のチームをファシリテーションする

これらの３つのインタラクションモードから外れるチーム間のインタラクションは無駄であり、チームの責任境界や目的が適切に割り当てられていないことを意味する。

「モダンでハイパフォーマンスな組織になる３つの方法」を定義している。

１．システム思考：組織のごく一部だけでなく、全体の速いフローを最適化する

２．フィードバックループ：運用部門からの情報と指導による開発

３．継続的な実験と学習の文化：すべてのチームインタラクションに対するセンシングとフィードバック

２つ目と３つ目の方法は、 OpsとDevの強力なコミュニケーション経路に依存する。

面白かったポイント

良書。

4つのチームタイプと3つのインタラクションモードの整理は美しい。

ソフトウェア開発以外の組織設計にも考え方は応用できそう。

組織設計をする時はこの本を読み返したい。

満足感を五段階評価

☆☆☆☆☆