チームトポロジーを簡単にまとめてみた

# はじめに
マネージメント経験のないエンジニアが
社内勉強会用にチームトポロジーを読んで簡単にまとめたものです

:::note alert
かみ砕いてまとめているため、主観が入っている可能性があります
正しい情報は以下の書籍をご確認ください
:::

https://www.amazon.co.jp/%E3%83%81%E3%83%BC%E3%83%A0%E3%83%88%E3%83%9D%E3%83%AD%E3%82%B8%E3%83%BC-%E4%BE%A1%E5%80%A4%E3%81%82%E3%82%8B%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%82%92%E3%81%99%E3%81%B0%E3%82%84%E3%81%8F%E5%B1%8A%E3%81%91%E3%82%8B%E9%81%A9%E5%BF%9C%E5%9E%8B%E7%B5%84%E7%B9%94%E8%A8%AD%E8%A8%88-%E3%83%9E%E3%82%B7%E3%83%A5%E3%83%BC%E3%83%BB%E3%82%B9%E3%82%B1%E3%83%AB%E3%83%88%E3%83%B3-ebook/dp/B09MS8BML8

# チームトポロジーとは？
近年、システムは複雑化して、大規模になっている
そんな世の中においても
ユーザに対して「素早く」「頻繁に」「安定的に」価値を届けたい点は妥協したくない
この
> ユーザに対して「素早く」「頻繁に」「安定的に」価値を届けたい

に焦点を当てた**組織を作るためのテンプレート・パターンのことをチームトポロジー**と呼ぶ
具体的にはチームの種類とチーム間コミュニケーションの種類があり、その組み合わせで表現する
また、最適解はなく、サービスの規模やフェーズ、
様々な要因によって最適を模索して、各組織の状態によって変化させていく必要がある

# コンウェイの法則と逆コンウェイ戦略
チームトポロジーが生まれる要因となったものが、コンウェイの法則みたい
### コンウェイの法則
チームをスキルによって分断すると、
ユーザに価値を届けるまでに登場するチームが多くなって、
コミュニケーションが増加、ユーザに価値を届けるのが遅くなるよねってことらしい
### 逆コンウェイ戦略
コンウェイの法則から、コミュニケーションを小さく、チーム内に閉じさせれば、
ユーザに価値を早く届けれるよねっていう戦略
つまり、マイクロサービス化することになる
この戦略のチームがチームトポロジーの核となるチームになっている

# チームファースト思考
そのままの意味、重要そうなものを抜粋
- チームは信頼関係のある5人程度で作成する
（信頼関係を築くために時間がかかるため、解散はしない、変化はゆっくり）
- 1チーム・1ドメイン
（チームの認知負荷、ソフトウェアの境界）
- チーム間コミュニケーションはチームAPIを定義する
https://github.com/TeamTopologies/Team-API-template

# チームの種類
４種類あり、１つの主人公的チームとその他のサポートチーム（なのでいなくても良い）で構成される

:::note warn
図示できることが重要なのですが、今回は書いていません
参考文献の[30分で分かった気になるチームトポロジー](https://slide.meguro.ryuzee.com/slides/109) 31p を参照してください
:::
#### ストリームアラインドチーム
1チームでユーザに価値を届ける
中心となるチームで、他チームはこのチームのためにある
逆コンウェイ戦略のチーム

#### プラットフォームチーム
ストリームアラインドチームの負荷を下げるために内部サービスを提供する
(個人的なイメージ : インフラ、モバイル)

#### イネイブリングチーム
他のチームが新しい技術を取り入れるのを支援する
(個人的なイメージ : SRE）

#### コンプリケイテッド・サブシステムチーム
特殊なスキルを必要とするサブシステムを提供する
(個人的なイメージ : アルゴリズム、データ）

# チーム間コミュニケーションの種類
３種類で構成される

:::note warn
図示できることが重要なのですが、今回は書いていません
参考文献の[30分で分かった気になるチームトポロジー](https://slide.meguro.ryuzee.com/slides/109) 36p を参照してください
:::
#### コラボレーション
他チームと協力して作業する
- チーム間の境界が曖昧
- コラボレーション先のチームについても知らないといけないため、認知負荷があがる
- コミュニケーションは増えるため、生産性は下がるかも
- イノベーションがおきるかも
#### X-as-a-Service
他チームのサービスを利用する
- チーム間の境界が明確
- X-as-a-Serviceとして利用できているということはマイクロサービス化されているため、組織がチームトポロジーとして成熟するほど多くなるはず
#### ファシリテーション
他チームを先導する
- ストリームアラインドチームへの技術導入、障害解決支援、etc..
- スペシャリストが必要

# 感想
 - 可視化できるメリットは相当大きい
 チームトポロジーとして組織を構成していなくても、当てはめて可視化してみるのは良いと思った
     - 共通認識ができる
     - 現在の組織状態が見える
     - 現在の組織構成と移行したい組織構成差分が見える
 - 大規模組織向けかなと感じた
 ユーザに対して「素早く」「頻繁に」「安定的に」価値が届けられなくなった、なりそうな段階で導入を考えるのが良さそう、最初から導入すると人的リソースが足りなくて、チームファースト思考が疎かになる
 - モバイルはどうすべきか難しいと感じた
 組織の大きさ、人的リソースによって、ストリームアラインドチームに入れるか、プラットフォームとして独立させるか、両方か、どう構成するか組織の色が色濃く出そう（最適解はないので、チームトポロジーを当てはめない選択肢もある）
 - エンジニアは何となく知っているだけで、視野が広くなりそう、ただし、チームトポロジー自体が認知負荷とも言えそうなので知らなくてもOK
 
# 参考文献

https://www.amazon.co.jp/%E3%83%81%E3%83%BC%E3%83%A0%E3%83%88%E3%83%9D%E3%83%AD%E3%82%B8%E3%83%BC-%E4%BE%A1%E5%80%A4%E3%81%82%E3%82%8B%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%82%92%E3%81%99%E3%81%B0%E3%82%84%E3%81%8F%E5%B1%8A%E3%81%91%E3%82%8B%E9%81%A9%E5%BF%9C%E5%9E%8B%E7%B5%84%E7%B9%94%E8%A8%AD%E8%A8%88-%E3%83%9E%E3%82%B7%E3%83%A5%E3%83%BC%E3%83%BB%E3%82%B9%E3%82%B1%E3%83%AB%E3%83%88%E3%83%B3-ebook/dp/B09MS8BML8

https://slide.meguro.ryuzee.com/slides/109

https://www.youtube.com/watch?v=uJL3M7R8MLc&pp=ygUY44OB44O844Og44OI44Od44Ot44K444O8