1. 30分で分かった気になる チームトポロジー 2022/3/16 株式会社アトラクタ 吉羽龍太郎 (@ryuzee)
2. 吉羽 龍太郎 (@ryuzee) ✤ 株式会社アトラクタ取締役CTO/アジャイルコーチ ✤ Scrum Alliance ✤ 認定スクラムトレーナー Regional (CST-R) ✤ 認定チームコーチ (CTC) ✤ 『SCRUM BOOT CAMP THE BOOK』 『スクラム実践者が知るべき97のこと』 『みんなでアジャイル』 『プロダクトマネジメント』 『レガシーコードからの脱却』ほか ✤ @ryuzee / https://www.ryuzee.com/ 2
4. 今日の話: チームトポロジー ✤ 2021/12/1 日本能率協会マネジメントセンター刊行 ✤ マシュー・スケルトン、マニュエル・パイス著 ✤ 原田騎郎、永瀬美穂、吉羽龍太郎訳 ✤ 担当編集: 山地淳さん ✤ Kindle版もあります ✤ まだお持ちでない方、是非お買い求めください ✤ 本スライド掲載の図表は本書より引用しています 4
5. 今の世の中 ✤ 技術、人、ビジネスにおける変化の速度はますます速くなった ✤ プロダクトの大規模化が進み、モバイル、クラウド、IoTなどのさまざまな技術の組み合わせが 必要にもなった ✤ それにともなってシステムの構築や運用に多くの人が必要になった ✤ 一方で、従来の組織構造や仕事のやり方は、この状況に対応できるようになっていない ✤ 企業が存続するためには、価値を素早く生み出して顧客に届け続けなければいけない 5
6. 4つのキーメトリクス / LeanとDevOpsの科学(Accelerate) ✤ デリバリーのリードタイム ✤ デプロイの頻度 ✤ サービス復旧の所要時間（MTTR） ✤ 変更失敗率 出典：『LeanとDevOpsの科学』（ニコール・フォースグレン、ジェズ・ハンブル、ジーン・キム著、武舎広幸、武舎るみ訳、インプレス 、2018、p21） 6
7. つまり？ 顧客に「素早く」「頻繁に」「安定的に」価値を届ける 問題があれば素早く復旧する 7
9. 速いフローを阻害する主な要因 ✤ コンウェイの法則を無視 ✤ 間違った組織設計による混乱 ✤ 数年ごとの苦痛な組織再編 ✤ チームがひっぱりだこ ✤ チームにとって大きすぎるソフトウェア ✤ 不測の事態の多発 ✤ モチベーションの低いチーム ✤ ボトルネック 『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、p14）を加筆修正 9
10. チームトポロジーとは？ ✤ フローを実現するためのもの ✤ 適応型の組織設計モデル ✤ 普遍的な公式ではなくパターン ✤ チームの目的と責任を明確にし、チーム間の相互関係の効果の向上を目指す ✤ 技術、人、ビジネスの変化に継続的に対処できるようにする ✤ 構造は静的なものではなく、状況に応じて変化させていく 10
11. フロー実現の上でチームトポロジーが中心に据えたもの ✤ 1. コンウェイの法則 ✤ 2. チームファースト ✤ 3. チームAPI ✤ 4. 4つのチームタイプ ✤ 5. 3つのインタラクションモード ✤ 6. 組織的センシング ✤ 7. トポロジー進化 11
12. 1. コンウェイの法則 “ システムを設計する組織は、 そのコミュニケーション構造をそっくり まねた構造の設計を生み出してしまう メルヴィン・コンウェイ 1968 ” 12
13. コンウェイの法則 ✤ 組織設計はソリューション探索空間の制約になり取りうるソフトウェア設計を限定する ✤ つまり、従来型職能別組織では、多くのコミュニケーションが必要な複雑なシステムが出来上 がってしまう ✤ ルース・マラン「システムのアーキテクチャーと組織のアーキテクチャーが対立する場合、組織 のアーキテクチャーが勝つ」 13
14. コンウェイの法則による組織構造→アーキテクチャーの例 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、p22-23） 14
15. 逆コンウェイ戦略 ✤ コンウェイの法則を踏まえて、それを戦略的に活用した組織設計を目指す ✤ 「組織はチーム構造と組織構造を進化させて、望ましいアーキテクチャーを実現す ✤ すばやく価値を届けることを前提として組織を設計する ✤ 人的資源の効率的な活用よりも、価値の効果的なデリバリーを優先する き」 べ 15
16. 逆コンウェイ戦略によるアーキテクチャ→組織構造の例 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、p24-25） 16
17. 2. チームファースト ✤ 組織図やマトリクスに依存した組織構造では、素早いデリバリーやイノベーションは無理 ✤ 権限とスキルを持つチームこそがアジリティの土台となる ✤ つまり、チームを基本的な構成要素として扱う ✤ 成果ってなんだろう？ ✤ ✤ 顧客にすばやく継続的に価値を届ける ✤ これを組織全体で目指す必要がある ✤ たくさん作る => ビルドトラップ 不確実性の高い世の中だからこそ、良いチームが必要 17
18. よくある落とし穴 ✤ 「チーム間の情報共有を増やそう！」 ✤ 「チーム間の連携やコミュニケーションを活発にしよう！」 ✤ これらは必ずしも良いとは限らない 18
19. コミュニケーションの複雑性を抑える ✤ ✤ 1チームは10人程度までが適正 ✤ 人数が増えるとコミュニケーションのオー バーヘッドが増える ✤ ダンバー数（5人まで、15人まで……） チーム同士のコミュニケーションも、対象の チームが増えると複雑になり、動きがどんどん 遅くなる ✤ プロジェクトの規模を小さくする必要 ✤ チーム間を疎結合にする必要 fl 出典 https://stackover ow.com/questions/984885/how-do-i-explain-the-overhead-of-communication-between-developers-in-a-team 19
20. The API Mandate (ジェフ・ベゾス) 1. すべてのチームは、今後、サービス・インターフェースを通じてデータや機能を公開する 2. 各チームはこれらのインターフェイスを通じて相互に通信しなければいけない 3. 他の形式のプロセス間通信は一切認めない。ダイレクトリンク、他のチームのデータストアの直接読 み込み、共有メモリモデル、バックドアなどは一切認めない。唯一許される通信は、ネットワークを介 したサービス・インターフェース・コールによるものとする 4. どのような技術を使用するかは問わない。HTTP、Corba、PubSub、カスタムプロトコルなど、何でも 構わない 5. すべてのサービスインターフェースは、例外なく、外部化可能なように一から設計しなければいけな い。つまり、チームは、外部の開発者にインターフェイスを公開できるように計画・設計しなければい けない。例外はない 6. これに従わない人は解雇する 出典: https://api-university.com/blog/the-api-mandate/ 20
21. Amazonのチーム構造の例 ✤ 1チーム10人程度までのサイズで構成される。複数チームを兼任することはない ✤ 1つのチームが1つのプロダクトもしくは機能群の塊を担当する ✤ ✤ ✤ EC2 Windowsチーム、EC2 Linuxチーム……など ✤ 各チームは独立して開発した機能群をリリース可能 ✤ 多いときでAmazon全体で１時間に10,000デプロイすることもある チーム間の人的コミュニケーションは原則として極力減らす（遅くなるから） ✤ AWSの各サービスも内部的にAWSを利用するが、一般ユーザーと同じAPIを利用する ✤ CI/CD、グローバルへの展開、監視などは共通基盤があり、利用が必須 開発言語や開発プロセスは、各チームに裁量がある 21
22. タックマンモデル 形成期 混乱期 統一期 機能期 解散期 人が集まるがまだ独立 しておりコミュニケー 意見を言うようになる が、一方で自分と違う 一緒に活動し、異なる 意見を受け入れる。 よく機能するチームと なる。チームには一体 目的を果たし、チーム が解散する時期 ションが少ない 意見に抵抗を示すよ うになる 目的や期待値などが 一致する 感がある。自立性が 高い 22
23. 機能しているチームを長く保つ “ ハイパフォーマンスなチームを解散する のは、単なる破壊行為では済まない。企業 レベルのサイコパスと呼ぶべきものだ アラン・ケリー 『Project Myopia』 ” 23
24. チームに仕事が流れ込むようにする ✤ ✤ チームを安定させて「チームに仕事が流れ込む」ようにする ✤ 必要に応じてゆっくりメンバーを入れ替える ✤ Pivotalでは9～12ヵ月ごとにメンバーはチームを移動している チームがソフトウェアのオーナーシップを持つ ✤ ✤ 同一箇所について複数のチームがオーナーシップを持つのを避ける チームが重要であり、個人のニーズよりチームのニーズを優先する ✤ 個人ではなく、チームに報いる 24
25. チームの認知負荷を考慮する ✤ 人間が脳にとどめておける情報の量には限りがある ✤ 同じことはチームにも言える ✤ チームの責任範囲や担当範囲が広がりすぎると…… ✤ ✤ コンテキストスイッチが大きくなる ✤ 優先順位がつけられなくなる ✤ 結果としてモチベーションも低下する 内発的動機の3要素（ダニエル・ピンク） ✤ 自律・熟達・目的 25
26. 認知負荷の種類 ✤ ✤ ✤ 課題内在性負荷 ✤ 問題領域のタスクに関連するもの ✤ 研修、適切な技術選定、雇用、ペアプロなどを通じて負荷を下げる 課題外在性負荷 ✤ タスクが実施される環境に関連するもの ✤ 自動化などによって負荷を下げる 学習関連負荷 ✤ 学習を進めたり、高性能を実現したりする上で特別な注意が必要なタスクに関連するもの ✤ ビジネスドメインもこれに含まれる。ここになるべく時間を使えるようにしたい 26
27. 認知負荷に合うように責任範囲を制限する ✤ チームが扱うソフトウェアの(サブシステムの)サイズを制限する ✤ チームの認知負荷にあわせてソフトウェア境界を選ぶ ✤ ソフトウェアの認知負荷の計測には、ドメイン複雑度に特に注目する（それだけではない） ✤ チームが扱うドメインの種類を制限する ✤ シンプル（これは1チームで複数担当できることもある） ✤ 煩雑（これに該当する複数ドメインに大きなチームで取り組むより、チームを分割する） ✤ 複雑（このドメインは集中して取り組む必要がある） 27
28. チームの境界を決める節理面（ドメイン以外にも） ✤ ビジネスドメインのコンテキスト境界 ✤ 規制遵守 ✤ 変更のケイデンス ✤ チームの地理的配置 ✤ リスク ✤ パフォーマンス ✤ 技術（依存関係が残るためフローが低下する可能性があるため限定的） ✤ ユーザーペルソナ ✤ ほかにもあるかもしれない 28
29. 3. チームAPI ✤ チームの周りを取り囲むものをAPIとして定義する ✤ ✤ 自分たちのコード、ドキュメント、ユーザーエクスペリエンス、仕事のやり方などなど ほかのチームとのやりとりにもAPIの考え方を用いる ✤ 他のチームが自分たちのチームと一緒に働くときに、やり方が明確で簡単か？ ✤ Amazonは激しい例 29
30. チームAPIの例 ✤ チーム名/注力領域: ✤ Wikiでの検索キーワード: ✤ チームタイプ: ✤ ✤ プラットフォームの一部か？ (y/n) 詳細: ✤ ほかのチームにサービスを提供しているか？ (y/n) 詳細: チャットツールのチャネル: #_____________ #_____________ #_____________ ✤ 日次の同期ミーティングの時間: ✤ 現在取り組んでいること ✤ ✤ ✤ ほかのチームは私たちに対してどんなサー ビスレベルを期待しているか？ このチームが所有し進化させているソフト ウェア: バージョニングの方法: ✤ ✤ 私たちのサービスとシステム: ✤ 働き方: ✤ チーム間または組織的な改善: 現在または将来やりとりするチーム: 出典: https://github.com/TeamTopologies/Team-API-template 30
31. 4. 4つのチームタイプ ✤ 多くの組織にはさまざまな種類のチームがある ✤ ✤ ✤ チームの役割を無計画に拡張して、誰も全体がわからない チームの種類を4つに絞ることでこの課題に対処する ✤ ストリームアラインドチーム ✤ プラットフォームチーム ✤ イネイブリングチーム ✤ コンプリケイテッド・サブシステムチーム チームタイプに応じた目的、役割、責任を担う 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、p.xv） 31
32. ストリームアラインドチーム ✤ ✤ ビジネスの主な変更フロー（つまりストリーム）に沿って配置するチーム ✤ ストリームは、ビジネスやサービスのこともあれば、機能群のこともあれば、特定のユーザー ジャーニーや特定のペルソナのこともある ✤ つまり組織の中では、さまざまなストリームが併存する 職能横断型で、他のチームを待たずにデリバリーできる ✤ ✤ 要求探索から本番運用まで、デリバリーに関わる能力一式を持っている必要がある いちばん中心となるチームタイプ ✤ 残りの種類のチームは、すべてストリームアラインドチームの負荷を減らすために存在する 32
33. プラットフォームチーム ✤ インフラやツール、共通サービスなどの内部サービス（プラットフォーム）を提供するチーム ✤ プラットフォーム ✤ セルフサービスAPI、ツール、サービス、サポートなどから構成される基盤 ✤ 使用が強制される内部プロダクト ✤ これによってストリームアラインドチームは詳細を知る必要がなくなり認知負荷が下がる ✤ プラットフォームチームは、サービスが使いやすくて信頼性が高くなるようにする 33
34. イネイブリングチーム ✤ ✤ 他のチームが新しい技術やスキルを身につけるのを支援するチーム ✤ 特定の技術や製品ドメインのスペシャリストから構成される ✤ ツール、プラクティス、フレームワークの調査や提案、オプションの探索を行う ✤ テクニカルコンサルティングチームとも言える ✤ 実作業をするのではなく、ガイダンスの提供を行う 永続的に支援するのではなく、短期的な支援となるのが普通 34
35. コンプリケイテッド・サブシステムチーム ✤ 名前のとおり複雑なサブシステムやコンポーネントを扱う専門チーム ✤ ほとんどのメンバーがその分野のスペシャリストでなければ理解や変更が難しいような領 域を担当する ✤ 動画処理、数理モデル、機械学習、特殊技術、特殊パッケージ…… ✤ これによってストリームアラインドチームの認知負荷を減らす ✤ 必要なときだけ構成する ✤ 初期の段階はストリームアラインドチームとコラボレーションするが、サブシステムの境界が明 確になって安定してくればサブシステムに集中する 35
36. 5. 3つのインタラクションモード ✤ チーム間の関係性において、相手とコラボレーションするか、サービス・プロバイダーとして使 うかが判断の分かれ道 ✤ ✤ すべてのチームが他の全チームとやりとりするのは避けなければいけない チームがインタラクションする3つの基本的なモード ✤ コラボレーション ✤ X-as-a-Service ✤ ファシリテーション 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、p164） 36
37. コラボレーションモード ✤ 2つのチームが探索を目的として協力しあう。責任境界が不明確で効率は悪いが学習は進む ✤ 利点 ✤ ✤ ✤ 引き継ぎが少なく、すばやいイノベーションと探索が可能 弱点 ✤ チーム間で責任を共有するため責任分界点が不明確 ✤ チーム間でコンテキストや詳細の共有が必要となり、認知負荷の増大を招く ✤ コラボレーション中はオーバーヘッドがあるので生産性は落ちる 制約 ✤ 1つのチームが同時にコラボレーションできるのは1チームまで 37
38. X-as-a-Serviceモード ✤ 一方のチームが他方のチームが提供するものをサービスとして利用する関係性 ✤ 利点 ✤ ✤ ✤ 責任境界が明確なため、オーナーシップが明らか ✤ チーム間の詳細やコンテキストの共有が減ることで認知負荷が制限される 弱点 ✤ 境界やAPIのイノベーションは遅くなりがち ✤ 境界やAPIが効果的でないと、フロー全体に影響を及ぼす 制約 ✤ 同時並行で複数のチームとX-as-a-Serviceモードでインタラクションする可能性がある 38
39. ファシリテーションモード ✤ 一方のチームが他方のチームが新しい技術を身につけたり学習したりするためにファシリテーショ ンする。他のチームの障害を取り除く ✤ 利点 ✤ ✤ ストリームアラインドチームの障害を取り除きフローを増やす ✤ コンポーネントやプラットフォームにおけるギャップ、整合性の取れていない能力や機能を検出 できる 弱点 ✤ ✤ 経験豊富なスタッフが必要 制約 ✤ 同時並行で複数のチームとファシリテーションモードでインタラクションする可能性がある 39
40. チームタイプ別の主なインタラクションモード コラボレーション X-as-a-Service ファシリテーション ストリームアラインドチーム 典型的 典型的 偶発的 イネイブリングチーム 偶発的 コンプリケイテッド・ サブシステムチーム 偶発的 典型的 プラットフォームチーム 偶発的 典型的 典型的 あるチームとインタラクションするときに、一時的にモードを変えることもある 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、p.176） 40
41. チーム構成の例 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、p165、p177） 41
42. 6. 組織的センシング ✤ 環境の変化を感知できなければ、やることは意味をなさない ✤ 本番環境のソフトウェアの動きから学ばなければいけない ✤ ✤ 運用中のシステムから情報を得る。つまり開発と運用の断絶は望ましくない チーム内外のコミュニケーションを組織の感覚器官として利用する ✤ チームのインタラクションから情報を得る 42
43. 7. トポロジーを継続的に進化させる ✤ トポロジーは静的なものではなく動的なもの ✤ プロダクトやサービスの成長、チームの学習などに合わせて適応していく ✤ チーム間の相互関係を明瞭で動的なものにし続ける ✤ でもビッグバンで変えてはいけない 43
44. チームインタラクションの進化の例 ✤ 密接なコラボレーションによってすばやく探索する ✤ プロダクト境界やサービス境界が見えてくるにしたがって、APIを定義しながらX-as-a-Service に移行していく ✤ 別の課題や探索のときに、またコラボレーションすることも当然ある 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、p196） 44
45. チームトポロジーを見直すきっかけ ✤ 1チームで扱うにはソフトウェアが大きくなりすぎている ✤ デリバリーのリズムが遅くなり始めている ✤ 複数の業務サービスが大量の下位サービス群に依存している 45
46. まとめ ✤ 今日はかいつまんで概要をお話しました ✤ 詳細は是非書籍を御覧ください ✤ Kindle版もあります ✤ 感想などを書いていただいた場合は、@ryuzee（ぼく）、 @EYamaji（担当編集の山地さん）までお知らせいただくと すごく喜びます 46
