次の方を対象にしています！
- 書籍「チームトポロジー」の内容が知りたい
- 最適な組織構成を考えたい
- システム開発のチーム構成について知りたい
トポロジーとは、位相幾何学における, 各部のつながり方などの面から見た図形の性質。チームトポロジーとは、チームの形を表す。
企業によって組織やチームのあり方は違う。しかし、組織構成によって作られるソフトウェアシステムは大きく影響を受ける。
組織を最適な形にすることでより良いソフトウェアシステムが作られることを学ばなければならない。
では、最適な組織とはどのようなものだろうか。「チームトポロジー」を参考に紹介します。
参考：チームトポロジー
＼ 聞き流せる本！Audilbe無料体験期間中 ／
>> 詳しく知りたい方へ！Audibleで無料で本を聴く方法を徹底解説
目次
チームトポロジー。要約まとめ
チームトポロジーはコンウェイの法則によりソフトウェア開発の設計に取り組む。
コンウェイの法則は「チームの開発成果がその組織の内部的なコミュニケーションのあり方によって決まる」というもの。つまり、組織がシステム設計に大きく関係することを意味する。
チームには明確な境界があり、疎結合で凝集度（モジュールのまとまり）の高い構造を維持するのがよい。システム設計は疎結合を目指すのではなく、価値のある単一の仕事の流れに沿って働くチーム間の依存関係や調整を減らして、フローが向上するように分解していく。
次章から詳しく説明する。
チームトポロジー 要約｜組織の問題。まとめ
組織図を作っている企業は多い。しかし、組織図があって部署やチームがあった場合、チーム中だけでは完結せず様々なチームの人と関わるのではないだろうか？
疎結合にするためにチーム化されているのに、お互いのチームメンバーで連絡を取り合っている。この組織構造で良いのだろうか？この答えは組織は1つではなく、3つの組織構造がある。
- 公式な構造：コンプライアンス遵守を円滑にする
- 非公式な構造：個人間の影響力の領域
- 価値創造構造：個人間やチーム間の能力に基づいて、実際にどう仕事を終わらせるか
組織図は「公式な構造」である。そして、組織の成功の鍵は「非公式な構造」と「価値創造構造」にある。
必要なのは組織図だけの単一な構造ではなく、チームの成長やチーム間のインタラクションを考えた構造である。
組織設計における経験則。
- 止む終えない理由があるときに設計する
- 設計判断のために選択肢を用意する
- 適切な時期に設計する
- 整合性が取れていない箇所を探す
- 将来を見据える
コンウェイの法則
システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう。組織の構造によって、どのようなものができるかは決まってしまうのだ。
コンウェイの法則では「組織のコミュニケーション（価値造像構造）とそこから生み出されたソフトウェアアーキテクチャーには強い相関関係がある」と言っている。
理想的なソフトウェアアーキテクチャーを思いついても、それが組織に合わなければ、どちらに合わせなければならない。たとえば、運用できる人がいなければ、アーキテクチャーを見直すかもしれない。どちらにしても組織とソフトウェアアーキテクチャーは密接に関わっている。
認知負荷
最初は狭い範囲の仕事を行っていたが、次第に対応範囲が広くなり大変になった経験はないだろうか？
既存の修正から新規の開発まで行うようになるとチームの認知容量を大きく上回ってしまい、チームの品質低下、スケジュール治験、モチベーション低下へとつながる。この状態にならないことが望ましい。
次のようなことが障害となる。
- 不足の事態の多発（システム障害の多発など）
- ブロックされているフロー
- 苦痛な組織再編
- チームが引っ張りだこ
- 組織設計の選択による混乱
- チームにとって大きすぎるソフトウェア
- モチベーションの低いチーム
- コンウェイの法則への対抗
チーム負荷を制限するように呼びかけていく必要があり、チームサイズや役割、境界を定めることが大切だ。
＼ 聞き流せる本！Audilbe無料体験期間中 ／
>> 詳しく知りたい方へ！Audibleで無料で本を聴く方法を徹底解説
チームトポロジー 要約｜コンウェイの法則が重要な理由。まとめ
コンウェイの法則は「わたしたちの組織が原因で利用できない、より良い設計があるのではないか」と問い続ける義務を生み出す
12の教訓に学ぶアプリケーションの単純化
システムのアーキテクチャと組織のアーキテクチャが対立した場合は、組織のアーキテクチャが勝つ。データベース管理や品質管理などの形で配置された組織がエンドツーエンドのフローに適したシステムは作れない。また地域ごとに配置された組織が世界で戦えるはずもない。
そこで「逆コンウェイ戦略」がある。ソフトウェアの完成形に合わせてにチームを決めてしまうのだ。ソフトウェアに組織を合わせる考えが逆コンウェイ戦略。これによりコンウェイの法則である組織がソフトウェアアーキテクチャーしてもスムーズに開発、運用が進む。
ソフトウェアのグッドプラクティスは次の通り。
- 疎結合：コンポーネントは他のコンポーネントに強い依存性を持たない
- 高凝集度：コンポーネントは明確な責任の境界を持ち、内部要素は強い関連を持つ
- 明確かつ適切なバージョン互換性
- 明確かつ適切なチーム横断でのテスト実行
どのサービスを構築するか、どのチームが構築するかをマネージャが決めているなら、それはシステムアーキテクチャーをマネージャが決めているのと同じである。
そして、コミュニケーションを増やすことは必ずしもよいことではない。全員がチャットの全文を見るべきか？スタートアップミーティングや会議は全員でるべきか？全部がそうではないはずだ。適切なコミュニケーションを考える必要がある。特に日本は会議が多すぎるので気をつけたい。
また会社で使っているツールを全社共通として1つに絞ってしまうことがある。しかし、独立したチームであれば、チーム内で最も有効なツールを選べばいい。他チームとコラボレーションするなら共有できるツールを選ぶべきだ。1つのチームで閉じていれば、どんなツールを使ってもいいはずなのだ。
チームトポロジー 要約｜チームファースト思考。まとめ
大量の情報を必要とする問題解決には個人よりもチームで取り組む方が向いている。そして、効率的に働けるチームの人数は7〜9人だ。少ないから深い信頼が生まれる。とはいえチーム人数が増えていく場合がある。そのときはチームを分割していくのだ。チームサイズの制限は「ダンバー数」ともいう。
1つのチームが扱える認知負荷は限界がある。アレもコレもと対応しているうちにチームでは手に負えないほどのタスクが舞い込んでしまう。これはチームの認知負荷を超えている状態であり改善しなければならない。単一のチームが扱うドメインの複雑度を考慮しながら自分たちが扱えるサイズを決めていく。
一度自分たちの領域（サイズ）を決めたなら、そのドメインはそのチームが責任を持って進めていく。自分たちがオーナシップを持つことが大事である。1つのドメインに対して複数のチームが改善したりすると、オーナシップを失い、システムを理解し健全に保つための心理的な余裕も失ってしまう。
チームファーストで考える。チームファーストの組織では、チームのコンテキストのなかでスキルやプラクティスを磨く場所とサポートが提供される。
仕事ではチーム間のコミュニケーションを個人間のコミュニケーションよりも大切にする。チームで範囲を決め、コミットすることで成長していくのである。
チームトポロジー 要約｜静的なチームトポロジー。まとめ
チーム設計で2つのアンチパターンがある。
- 場当たり的なチーム設計
- 大きくなったチームをとりあえず分割したチーム
- 特定のソフトウェアの面倒を見るために即席で作られたチーム
- チームメンバーの入れ替え
- プロジェクトをリリースしたら終わったら少数を残して解散させる
すばやく安全に成果をだすために、どのようなチームにするかは熟考しなければならない。
＼ 聞き流せる本！Audilbe無料体験期間中 ／
>> 詳しく知りたい方へ！Audibleで無料で本を聴く方法を徹底解説
チームトポロジー 要約｜4つの基本的なチームタイプ。まとめ
4つのチームタイプで考える。
- ストリームアラインドチーム
- イネイブリングチーム
- コンプリケイテッド・サブシステムチーム
- プラットフォームチーム
チームタイプを増やしすぎず4つのタイプに絞ることでシンプルにできる。1つのチームタイプには複数のチームが存在する。
いままでの組織にあったようなサポートチーム、運用チームなどは作らない。
ストリームアラインドチーム
ストリームとは英語で「流れ」の意味。ビジネスドメインや組織の能力に沿った仕事の継続的な「流れ」を指します。
ストリームアラインドチームは、ストリーム（流れ）とアラインド（整列した）をあわせ持つチームだ。単一の仕事の流れに沿って働くチーム。
組織の根幹となるチームタイプで、他のチームタイプはストリームアラインドチームの負荷を減らすためにある。
ストリームアラインドチームはデリバリー（価値提供）全体に関わるため顧客の近くで働くことになる。本番環境を見ながら素早くフィードバックし改善していく。
システムに問題があればリアルタイムで対処もする。人数よりも少数でスキルの高い人材がいたほうが機能する。
これは今までと全くことなるアプローチだ。従来の組織では顧客から要望があったらプロジェクト化され、フロントエンド、バックエンド、データベース管理など複数チームで対応をしている。
しかし、ストリームアラインドチームはチームに所属する人だけですべてを行い、チーム内で完結させる。
AmazonのCTOであるワーナーヴォゲルスの「you build it, you run it（自分で作ったら、自分で運用する）」という言葉があるほどだ。
ストリームアラインドチームは次の能力を備えている必要がある。
- アプリケーションセキュリティ
- 事業成長性分析と運用継続性分析
- 設計とアーキテクチャー
- 開発とコーディング
- インフラストラクチャーと運用性
- メトリクスとモニタリング
- プロダクトマネジメントとオーナーシップ
- テストとQA
- ユーザーエクスペリエンス
1人で全部を身につけるわけではなく、チームがそれを理解し実行することが大事だ。
イネイブリングチーム
イネイブリングチームは特定のテクニカルなドメイン（領域）のスペシャリストで構成される。複数のストリームアラインドチームを横断的に支援する。
ストリームアラインドチームへのソリューションの提供ではなく、支援することでストリームアラインドチームの自律性を高める。イネイブリングチームが機能し、ストリームアラインドチームを支援すると、ストリームアラインドチームは自立し、イネイブリングチームの支援を必要としなくなる。
イネイブリングチームは先んじて専門知識を蓄えストリームアラインドチームに教えられるようになっておく。
コンプリケイテッド・サブシステムチーム
コンプリケイテッド・サブシステムチームは、システムのなかでスペシャリストの知識が必要となるパーツを開発、保守する責任を持つ。スペシャリストではなければ変更や理解が難しいサブシステムを担当する。
動画処理コーデックや数理モデルなどスペシャリストではければ対応できない場合にチームとする。ストリームアラインドチームにスペシャリストがいれば問題ないが全部のチームにスペシャリストを配置するのは難しい場合にコンプリケイテッド・サブシステムチームを作る。
プラットフォームチーム
プラットフォームチームは、ストリームアラインドチームが自律的に仕事をデリバリーできるようにすることである。内部サービスを提供することでストリームアラインドチームが下位サービスを開発する必要せいをなくし、認知負荷を下げる。
少数のサービスを高い品質で提供することに注力する。
プラットフォームが考えることはログインやモニタリング、テスト環境など。ストリームアラインドチームのために基盤を整えることがプラットフォームチームの役割。
たとえば Windows / Linux / Java 仮想マシン / Azure / Kubernetes などはプラットフォームとして成功している。
＼ 聞き流せる本！Audilbe無料体験期間中 ／
>> 詳しく知りたい方へ！Audibleで無料で本を聴く方法を徹底解説
チームトポロジー 要約｜チームファーストな境界を決める。まとめ
速い変更フローを実現するためにはチーム間の引き継ぎをなくす必要がある。ストリームにそって人員配置することが大事。
引き継ぎをなくすためには、担当するドメインが明確であり、自分たちだで改善できる必要がある。どこでシステムを分割すればよいのか。それは節理面である。
節理面はソフトウェア・システムを簡単に複数に分割できる自然なつなぎ目のこと。節理面はビジネスドメインで境界づけられたコンテキストに合わせるのが良い。
チームトポロジー 要約｜チームインタラクションモード。まとめ
ストリームアラインドチーム、イネイブリングチーム、コンプリケイテッド・サブシステムチーム、プラットフォームチームがどのようにインタラクションするかを説明する。
3つのインタラクションモードがある。
- コラボレーション：他のチームと密接に協力して作業すること
- 2チームが一定期間作業することで新しいパターンや手法を発見する。問題をはやく解決し、組織は学習する。
- X-as-a-Service：最小限のコラボレーションで何かを利用または提供すること
- 一方のチームから提供されたものを使用する（APIなど）。責任や境界で明確であれば素早いデリバリーが可能。
- ファシリテーション：障害を取り除くために他のチームを支援したり、支援を受けたりすること
- 一方のチームが新しい手法やアプローチを習得するのを、別のチームが支援する。できるだけ早く独り立ちさせるのが目標。
最適なインタラクションを見つけることで、デリバリーのスピードも上がっていく。
まとめると、チームを4種類（ストリームアラインドチーム、イネイブリングチーム、コンプリケイテッド・サブシステムチーム、プラットフォームチーム）に分け、チーム間のインタラクションは3種類（コラボレーション、X-as-a-Service、ファシリテーション）で最適なものを選ぶことで速い更新が可能となる。
参考：チームトポロジー
＼ 聞き流せる本！Audilbe無料体験期間中 ／
