『チームトポロジー』の見どころ

背景

この記事はLIFULL社内で共有された感想文を少し書き換えたものです。

社内でもプロダクトマネジメントやそれを支える組織の話の議論が進んできつつあるように感じる。

そして私も「 『EMPOWERED』の見どころ」でまとめた内容の通り、「ソフトウェア開発チームに制度や体制が必要だ」と思いつつ、それを支える考え方を整理する必要を感じていた。

そこでちょうど『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』が発売され、うまく整理するフレームワークやデザインパターンを用意してくれているように思えたので紹介してみる。

この要約では役割分担の話を重視してまとめて、全体設計やチームの分割みたいな話はごっそり抜けているので、興味ある人は自分の目で確かめてほしい👀

この本はどういう趣旨なのか？

ソフトウェア企業で働いている人は、「コンウェイの法則」というものを耳にしたことがあると思う。

システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう

この本では「逆コンウェイの法則」として、「望ましいアーキテクチャの実現のために、チームや組織構造を進化させる」方法を紹介している。

チーム構造とコミュニケーションパターン

4つの基本的なチームタイプ

多くの組織にはさまざまな種類のチームがあり、「組織全体を見渡せているのか？」「適切なチームが配置できているのか？」「誰も対処していない領域があるのではないだろうか？」などの悩みがある。

その議論をするためには、4つの基本的なチームタイプに減らして整理するとよく、すべてのチームはこの4つのどれかに引き寄せられるはずだ。

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

ストリーム（ビジネスドメインやそ組織の能力に沿った仕事の流れ）に沿って働くチームのことで、組織の根幹をなす。プロダクトのデリバリー全体に関わり、本番環境のソフトウェアを監視しながら、すばやく顧客からのフィードバックで改善する。

期待されるふるまい

• 安定したデリバリーを作ることを目指す
• 最新の変更に対するフィードバックを基にすばやく軌道修正する
• 他のチームへの引き継ぎを最小限にする（理想はゼロ）
• このチームの実現した変更フローの安定性と、技術面およびチームの健全性で評価される
• コードの変更が簡単・安全に行える状態を保つため、「技術的負債」に対応するための時間を待たなければならない
• 積極的かつ定期的に他のチームタイプと連携する
• 「自律」「熟達」「目的」を達成する、もしくは達成しようとしている

そして、他のチームはストリームアラインドチームをサポートすることを目的にしている。

イネイブリングチーム

特定のテクニカル（プロダクト）ドメインのスペシャリストから構成され、能力ギャップを埋めるのを助ける。これによりストリームアラインドチームは、多大な能力をかけずに能力を獲得し、進化できる。

期待されるふるまい

• 積極的にストリームアラインドチームのニーズを探索し、定期的にチェックポイントを設け、より多くのコラボレーションが必要になるタイミングについて合意する
• 実際に必要になる前に専門領域の新しいアプローチ、ツール、プラクティスについて先んじておく
• 技術面でのライフサイクルマネジメントのため、良いニュース（例: 「50%テストコードが削減できる新しいUI自動化フレームワークがある」）も悪いニュース（例: 「広く利用されているJSフレームワークは積極的にメンテナンスされていない」）も伝える
• ストリームアラインドチームが直接使うのが難しいサービスのプロキシとしてふるまうことがある
  イネイブリングチーム内の学習だけでなく、ストリームアラインドチームを横断した学習も促進するため、組織内のキュレーターとして活動する

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

システムのなかでスペシャリストの知識が必要となるパーツを開発・保守する責任を持つ。このチームの目的は、複雑なサブシステムを含んだり利用するシステムの担当となるストリームアラインドチームの認知負荷を減らすことだ。

期待されるふるまい

• 担当するサブシステムの開発業務を意識して、適切にふるまう。初期は密接にコラボレーションして、サブシステムが安定してきたら、インターフェイスと機能の使用状況と進化に集中する
• サブシステムのデリバリー速度と品質は、ストリームアラインドチームが開発した場合より明らかに向上する
• サブシステムを利用するストリームアラインドチームのニーズを尊重し、適切に優先順位をつけて変更をデリバリーする

プラットフォームチーム

API、ツール、サービス、知識、サポートからなる基盤で、使用が強制される内部プロダクトとして用意される。
（※ただし、どこまでをプラットフォームとするかの境界は、組織ごとに大きな幅がある）
ストリームアラインドチームは、プラットフォームを利用することで調整ごとを減らしつつ、自律的に仕事を届けられるようにすることを目指す。

期待されるふるまい

• ストリームアラインドチームと密接にコラボレーションし、ニーズを理解する
• 高速プロトタイピングの手法を使い、ストリームアラインドチームのメンバーを巻き込み、何がうまくいって何がうまくいかないかのフィードバックを素早く得る
• プラットフォームをプロダクトとして扱い、提供するサービスのユーザビリティと信頼性に強くフォーカスする。
• プラットフォームチームは、手本を示すことでリードする。提供したサービスを可能ならストリームアラインドチームと一緒に使い、可能な限り（他のチームが主管の）下位のプラットフォームを利用する
• 新しい内部サービス採用には他の新技術と同じく時間がかかること、テクノロジー採用ライフサイクルの採用曲線に沿って進化することを理解している。

3つのチームインタラクションモード

ソフトウェアを構築する際にチームがインタラクションする方法を形式化することで、チーム間のインターフェイスを明確に定義でき、ソフトウェアデリバリーにおけるさまざまな側面の有効性が評価しやすくなる。

結果的に、コンウェイの法則通り、これらのインターフェイスは構築するソフトウェアシステムに反映される。

インタラクションモードは3つに分類できる。

• コラボレーション: 他のチームと密接に協力して作業すること
• X-as-a-Service: 最小限のコラボレーションで何かを利用または提供すること
• ファシリテーション: 障害を取り除くために他のチームを支援したり、支援を受けたりすること

各チームタイプが基本的に利用するインタラクションモードは次の通りである。

	コラボレーション	X-as-a-Service	ファシリテーション
イネイブリングチーム	偶発的		典型的
コンプリケイテッド・サブシステムチーム	偶発的	典型的
プラットフォームチーム	偶発的	典型的
ストリームアラインドチーム	典型的	典型的	偶発的

所感

• 私が過去に所属していたチームでは、当時は「コンプリケイテッド・サブシステムチーム」と「イネイブリングチーム」の両方を目指しており、「全社を教育しなきゃ」とか「APIとして提供しなきゃ」とやることが多かったように思う
• ストリームアラインドチームの項目にある通り、ひとつのチームがデリバリーまでの全体の流れのオーナーシップを持つべきである
• チームによってはこれらの役割が混在していて、大変さの源泉になってそう
• LIFULLでは「20%ルール的な学習時間」を取っているチームもあるが、それらの学習は個人でやるより、積極的にイネイブリングチームと交流するほうが効率がいいような気もしてきた
• コンプリケイテッド・サブシステムチームとプラットフォームチームはインタラクションモードが近いこともあって「本当に分ける必要あった？」って感じもある