チームトポロジー、MVCやらDDDがプロダクト開発を成功させる確率を上げるためのフレームワークを提供してくれているのと同じで、それの組織設計版という理解をしている。アーキテクチャをシンプルに保ち続けるための概念や指針がたくさん提唱されているように、チームトポロジーは認知不可を最小にするためのチーム作りの概念や指針を提唱してくれている。

MVCみたいなノリでチームトポロジーがチームタイプとその責任領域、インタラクション方法を提案してくれているので、それに従ってチームを設計することで認知不可を下げることができると。

チームトポロジーはいい感じに4つのチームタイプを定義してくれていてそこに旨味があるように見えるけど、それらのインタラクションモードを定義してくれているほうにむしろ意義があるように感じる。1チームを3チームに分けてみたけど全員コラボレーションしてます、だと認知不可はあまり変わらない気がするし。

MVCでもModel、View、Controllerで分けましょうねーだけではなく、ModelがControllerやViewのことを知っている必要はない、みたいな依存の方向まで含めて定義してくれているからシンプルに保てるわけなので。

4つのチームタイプ

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

ビジネスの主な変更フロー(ストリーム)に沿って配置するチーム、ストリームはビジネスやサービスのこともあれば機能群、特定のペルソナの場合もある。職能横断型で他のチームを待たずにデリバリーできる。一番中心となるチーム。残りのチームはすべてストリームアラインドチームの負荷を下げるために存在しているという考え方。

プラットフォームチーム

インフラ、ツール、共通サービスなど内部サービスを提供するチーム。共通基盤。
ストリームアラインドチームは詳細を知る必要なく(認知不可を下げて)ツールやサービスを利用することができる。

イネイブリングチーム

他チームが新しい技術やスキルを身につけるのを支援するチーム。特定の技術や製品ドメインのスペシャリストから構成される、テクニカルコンサルティングのようなイメージに近い。通常、永続的ではなく短期的な支援になる。

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

複雑なサブシステムやコンポーネントを扱うチーム。イネイブリングよりさらに専門性が要求されるようなイメージ。スペシャリストでなければ扱えないような領域を担当する。動画処理、数理モデル、機械学習、など。必要な時だけ構成する。

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

コラボレーションモード

コラボレーションモードは2つのチームが探索を目的として協力しあう。責任境界が不明確になるので効率は悪いが学習は進む。1つのチームが同時にコラボレーションするのは1チームまでという制約がある。

X as a Serviceモード

一方のチームが他方のチームが提供するものをサービス(ブラックボックスなサービス)として利用する関係性。認知不可が制限されるが、境界やAPIのイノベーションは遅くなりがち。責任境界が明確でオーナーシップが明らか。同時並行で複数のチームとインタラクションする可能性がある。

ファシリテーションモード

一方のチームが他方のチームが新しく技術を身につけたり学習したりするためにファシリテーションする。他チームの障害を取り除く。経験豊富なスタッフが必要になる。同時並行で複数のチームとインタラクションする可能性がある。

チームトポロジー、完全に理解したと思って自分のプロダクトチームに対してトポロジー図を書いてみたりしたけど、ただ図示するというより時間軸に沿ってどう進化していくかを描くことが重要な気がした。

最初はコラボレーションからスタートするけど徐々にXaaSになっていくとか、そういう時間軸に沿ってどうインタラクションモードを進化させていくかまで意識して図示することをやっていきたい。

シュッと見れる動画もあるし、エッセンスを抽出する分には正直これで十分やw

StaticではなくDynamicが大事という意味がなんとなく分かった気がする。

インタラクションの制約を設けてくれているのも良い。「このインタラクション大丈夫か？」という視点を持つことができる。

チームトポロジー図、「私は事業の成果を最大化するためにチームをこのように進化させていこうと考えています」というお気持ち表明を具現化したようなものになりそうやし、そうなるべき。

APIドキュメントを書くように各チームの取扱説明書的なドキュメントがある方がよいか。まあ複雑になった場合だけで良い気もするが。

AチームとBチームのコラボレーション方法はxxです、みたいなインターフェースを定義する方がよいのかもしれない。