Team Topologies - ugo's 読書感想文

はじめに

チームトポロジーというのは、チームにおける形成図のようなものを指して、最適な組織構成とは何かを定義し、必要に応じて適用することで、チームの開発、運用、デリバリーを早く行えるようにする考え方を示している。

チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計

Amazon

この本には、主に各チームや機能の定義、どういった概念かの説明を行った上で

どういったフェーズに当てはまれば良いか、どういった適用の仕方が良いかを解説する。

チームトポロジーとは

チームは常に未完成だが、最善を尽くした状態でもある。

チームは独立して存在しているわけではなく、熱意を持ったメンバーで構成し、自律的で、長続きさせるべきである。

そして、顧客に価値を届けるためにチームのことを考え、チームを進化させなければいけない。

そのための明快なパターンを提供することが、チームトポロジーである。

チーム構造を最適化する方法を見つけ出そうと奮闘している組織や、チーム設計が特にビジネスアウトカムやソフトウェアに影響を与えることにまだ気づいていない組織に役に立つ。

チームトポロジーの考え

以下の4つの基本的なチーム - ストリームアラインドチーム - プラットフォームチーム - イネイブリングチーム - コンプリケイテッド・サブシステムチーム

以下の3つのインタラクションモード - コラボレーション - X-as-a-Service - ファシリテーション

チームトポロジーでは、技術や組織の成熟に応じてどう進化するかに目を向けている。

適応型モデルを重視し、チーム間の相互関係に積極的に優先順位をつけることで

ソフトウェアの比重が高い現代の企業がビジネスや技術の観点で戦略変更が必要になったことを感知するための、特定の技術に依存しない重要なメカニズムを提供する。

つまり、人間的なアプローチも重視しているということ。

同形力

組織の本当のコミュニケーションパスと、結果として得られるソフトウェアアーキテクチャーには強い相関関係がある。

理論上、理想的なシステムアーキテクチャーでも、組織モデルに合わなければ変えなければならない。

認知負荷

人間の認知容量には限界がある。

同時に、チームにも認知容量が存在する。

しかし、担当割り当ての際に、この認知負荷について議論されることは滅多にない。

認知負荷とはどんなもので、定量化することが難しいからだ。

チームへの要求というのは日々増え続ける。

だが、新規サービスの開発は、チームの時間は全て支えて、認知負荷が何もないかのように計画されることが多い。

チームは既存のサービスの修正や拡張も求められるが、それらは無視されているからだ。

これにより、チームのモチベーションの低下などが発生しうる。

私たちは、チームを最優先して、認知負荷を制限するよう呼びかけていく必要がある。

認知負荷をしっかり考えることは、チームサイズを決めたり、責任を割り当てたり、他のチームとの境界を設定したりする上で、とても役に立つ。

チームの認知負荷を制限し、チーム間のコミュニケーションを明確に設計する必要がある。

チームトポロジーのゴールは、コラボレーションが必要な場所やタイミング、実行に集中してコミュニケーションのオーバヘッドを減らすべき場所やタイミングを、組織が適応しながら動的に見つけられるようなアプローチとメンタルツールを提供すること。

チーム内のフローをよくするソフトウェアアーキテクチャー

チームの編成前に、どんなソフトウェアアーキテクチャが必要かを理解する必要がある。

コミュニケーションパスとインセンティブがソフトウェアアーキテクチャーを決定づけてしまうからだ。

そのためにはソフトウェアアーキテクチャのグッドプラクティスに従うと良い。

疎結合
高凝集性
明確かつ適切なバージョン互換性
明確かつ適切なチーム横断でのテスト実行

ものごとを分離し、チーム内にとどめておくことが重要。

組織設計には技術的専門知識が必要

アーキテクチャとチーム編成の間にある自己相似の力が現実のものであることを受け入れるなら、エンジニアリングチームに強い影響を持つのだということを受け入れなければいけない。

チームの編成

偶発的、行き当たりばったりでチームを編成するのではなく、断続的にチームを設計する必要がある。

このような設計によるチーム構造のことをチームトポロジーと呼ぶ。

しっかりと思慮深く練られたチーム構成は成功する確率が高い。

フィーチャーチーム

職能横断型かつコンポーネント横断型のチームのこと。

一貫で、顧客に提供、使用状況、パフォーマンスを監視できるチームを指す。

しかし、自給自足、つまり他のチームを待つことなく機能を本番にリリースできる場合に限る。

エンジニアリングの成熟度が高くないと、ワークフローの自動化やボーイスカウトルールに従わなかったりなどが発生する。

プロダクトチーム

基本的にはフィーチャーチームと同じだが、1つかそれ以上のプロダクトの機能全体を担当するという点が異なる。

インフラ、プラットフォーム、テスト環境、ビルドシステム、デリバリーパイプラインなどに依存する。

ソフトウェア開発の構築と運用はとても不確実性が高いため、スケジュールに沿って、同じ仕事のストリームのなかで複数のチームが調整を行うのは難しい。

そのため、ブロッキングが発生してしまう。

ノンブロッキングにするには、セルフサービス型の能力という形を取ることが多い。

テスト環境の洗い出し、デプロイパイプラインの作成、監視など。

しかし、プロダクトチームが自律性を満たしていないシステムの一部でありながら、早くデリバリーするようにプレッシャーをかけられると摩擦が増えていく。

クラウドチーム

プロダクトチームは、必要に応じて新しいイメージやテンプレートを作り、自分達の環境やリソースをプロビジョニングできる自立性が必要になる。

そして、クラウドチームはそのプロビジョニングプロセスを引き続き担当し、

必要な管理
ポリシーの適用
監視

を確実に行えるようにする。

しかし、クラウドチームはプロダクトチームのニーズと適切なリスクおよびコンプライアンス管理のニーズに合うような、高品質のセルフサービスを提供することに注力すべきなのである。

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

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

価値のある単一の仕事のストリームに沿って働くチームのこと。

ストリームとは

機能一式のこともある

ユーザージャーニーや、ユーザーペルソナの一つのような場合もある

顧客やユーザーに価値を届けられるように、チームに権限が委譲されている

つまり、他のチームへの引き継ぎが発生しない

どのストリームでも、長期的に維持される仕事のポートフォリオもしくは、プログラムの一部として、予算が割り当てられる

これまでの、顧客からの大きな要望、複数の顧客からの小さな要望を、プロジェクトが承認され予算が割り当てられ、フロント、バック、データベースなどいくつかのチームに割り振られ、既存のバックログに追加されるというやり方とは全然異なる。

期待されるふるまいとしては以下のようなものがある。

フィーチャーデリバリーの安定したフローを作ること
最新の変更へのフィードバックに基づいてすばやく軌道修正できる
プロダクトの進化に実験的なアプローチを用い、常に学んで適応する
他のチームへの引き継ぎを最小限にする(理想はゼロ)
このチームが実現した変更フローの安定性と、技術面およびチームの健全性の観点での補助的なメトリクスで評価される
コードの品質変化(技術的負債)に対応するための時間を持たなければならない
積極的かつ定期的に支援を受ける他のチームタイプと連携する
メンバーは「自律」「熟達」「目的」を達成しようとしているか、達成していると感じる

イネイブリングチーム

複数のストリームアラインドチームの支援を行う

適切なツール、プラクティス、フレームワークなどのアプリケーションスタックのエコシステムに関する調査、オプションの探索、正しい情報に基づく提案などを行う

協調的な性格が強く、ストリームアラインドチームの課題や不足点を理解しようとする

サーバントリーダーシップとも考えられる

期待されるふるまい

ストリームアラインドチームのニーズを探索し、定期的にチェックポイントを設け、より多くのコラボレーションが必要になるタイミングについて合意する
専門領域での新しいアプローチ、ツール、プラクティスについて先んじる。
技術的な良いニュースも悪いニュースも伝える。技術的なライフサイクルマネジメントを支援するため
ストリームアラインドチームが直接使うのが難しい外部(もしくは内部)サービスのプロキシーとしてふるまうこともある
ストリームアラインドチームを横断した学習も促進するため、組織内の適切な情報共有を促すキュレーターとして活動する

ストリームアラインドチームへのインタラクションは、短期間(数週間〜数ヶ月)にとどめる方が良い。

新しいスキルを身につけたら、日常的なインタラクションはやめ、別のチームにフォーカスするようにする。

CoP(コミュニティオブプラクティス)も、同じように知識を広めるためのチーム。

イネイブリングチームが短期的に目的を達成するものとしたら、CoPは長期的に広く行う部隊。

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

複雑なサブシステムを含んだり利用するシステムの担当となるストリームアラインドチームの認知負荷を減らすことにある

習得や育成の難しいスキルや専門能力を活かして、担当するサブシステムの複雑さに取り組む

期待されるふるまい

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

プラットフォームチーム

ストリームアラインドチームが自律的に仕事を届けられるようにすることで、ストリームアラインドチームは本番環境のアプリケーションの開発、運用、修正を含む全体のオーナーシップを持つ。

ストリームアラインドチームが下位のサービスを開発する必要性をなくし、認知負荷を下げる。

提供するサービスが目的に一致し、信頼性が高く、使いやすいプロダクトになるように扱う必要がある。

基本的に、少数のサービスを高い品質で提供することに集中する必要がある。

期待されるふるまい

ストリームアラインドチームが必要とする下位の内部サービスを提供することで認知負荷を減らし、ストリームアラインドチームがより上位のサービスや機能を提供できるようにする。

そのために以下のことを行う

ストリームアラインドチームのニーズを理解する
高速プロトタイピングの手法を使い、ストリームアラインドチームのメンバーを巻き込んで何がうまくいって何がうまくいかないかのフィードバックを素早く得る。
プラットフォームをプロダクトとして扱い、ユーザビリティと信頼性に強くフォーカスする。定期的にサービスが目的にあってるか、使いやすいかを検査する
手本を示すことでリードする。可能な限りストリームアラインドチームと一緒に使い、下位のプラットフォームを利用する
新しい内部向けサービスの採用には他の新技術と同じように時間がかかること、テクノロジー採用ライフサイクルの採用曲線に沿って進化することを理解する。

プラットフォームをプロダクトやサービスのように管理する

プラットフォームにはユーザー（開発チーム）がいて、運用対応の時間（開発チームが使う時間）も決まっている。

開発チームがなるべく効果的に働けるようにするには、次のことを行う必要がある。

プラットフォームを稼働中のシステムとして扱い、ダウンタイムを計画し管理する。
ソフトウェアプロダクトマネジメント、サービスマネジメントのテクニックを使う。

プラットフォームチームの主要顧客はプロダクトチームになる。

運用対応の時間を決め、インシデントやサポートの対応期限を定め、プラットフォームサポートのオンコールのローテーションを設定、適切なコミュニケーションチャネルを用意、インシデントや計画買いダウンタイムを管理を行う必要がある。

開発チームと定期的に話し合いを行い、何が必要かを理解しようとする。

機能の利用度合いをメトリクスとして追跡し、対話と優先度設定に利用したりもする。

モノリス

アプリケーションモノリス

多くの依存関係や責任を持つ単一かつ巨大なアプリケーションで、多くの錆巣やさまざまなユーザージャーニーを公開しているもの。

ユーザーはデプロイの間、アプリケーションを使えない。

本番環境相当の環境でテストしていたとしても、そのあと変わってしまっているため、予期せぬ問題に悩まされる。

データベース結合モノリス

同一のデータベーススキーマと結合している複数のアプリケーションやサービスから構成される。

それぞれ別々に変更、テスト、デプロイが難しい。

データベースをコアのビジネスのエンジンと考えている場合に発生する。

人手が足りていないことが多く、デリバリーにおける大きなボトルネックになる。

モノリシックビルド

新バージョンのために、単一の巨大な継続的インテグレーションでビルドを行う。

アプリケーションモノリスが、モノリシックビルドをもたらすが、小規模なサービスでも同じ問題は起こりうる。

コンポーネント間の依存関係を管理する標準的な仕組みを使うのではなく、コードベース全体をビルドするようなビルドスクリプトになっている場合。

モノシリックリリース

全てをまとめてリリースする

小さなコンポーネントをまとめてリリースする

サービスのモックは使わずに、共有の固定環境でしかテストできない場合

全コンポーネントの最新バージョンをまとめて同一の環境に導入することになる。

コンポーネント一式をひとかたまりとしてデプロイすることで、テストしたものが本番環境でも実行されるという確証を得る。

QAチームによってテストを担当される場合もあるが、キャパシティが限られていて、複数のサービスの変更をまとめて行うことが理にかなっていると考えるため。

モノシリックモデル

単一のドメイン言語と表現(フォーマット)を多くのさまざまなコンテキストに強制的に適用しようとするソフトウェアのこと。

小さな組織では、チームが明示的に同意している場合であれば、この手の一貫性を重視するのは理にかなっている。

だが、組織内のチームやドメインが片手で収まらない数になると、意図せずアーキテクチャーや実装の制約になる可能性がある。

モノリシック思考

チームの「画一的」な考え方のこと。

技術面やチーム間の実装アプローチのばらつきを最小限にするための標準化をおこなう。

しかし、優れたエンジニアは新しい技術を学ぶことができるし、学習したがる。

そういった機会を単一の技術スタックやツールを強制し、チームの選択の自由を奪う。

仕事で適切なツールを使う能力に大きな悪影響を及ぼし、モチベーションを阻害したりもする。

モノリシックワークスペース

地理的に同じ場所にいるすべてのチームや個人に適用する単一のオフィスレイアウトのパターンのこと。

オープンプランオフィスがコラボレーションを促進するという通説もある。

だが、採用した2つの組織での調査の結果、それは否定されていて、対面でのやりとりが大幅に減少し、電子的なやりとりが増えたのだ。

それは、場所を同じにするだけでなく、目的を同じにすることによるものだ。

リスク

継続的デリバリーができているかにも大きく影響を与える。

疎結合のシステムアーキテクチャのもとで継続的デリバリーが実現できているのであれば、小さな変更を頻繁にデプロイするリスクは実際に減少する。

ユーザーの数によって許容できるリスクもある。

数百万の無料ユーザーと、数百人の有償ユーザーを仮定したとき

数百万人に影響のあるリスクは潜在有償ユーザーの損失が大きいが

数百人の有償ユーザーのみに影響がある場合、個別対応なども不可能ではないと考えると、優先度としては下がったりもする。

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

以下の3つのインタラクションモードの組み合わせが多くの企業に必要。

1つのチームが2つの異なるチームに対して別のインタラクションモードを利用することもある。

どのチームがどのチームに対して、どのインタラクションモードをすれば良いか、何を期待されているだろうかということを意識するようにならなければならない。

それぞれの定義から書いて、それぞれの立ち振る舞いを書いていこうと思う。

定義

コラボレーション 2チームが一定期間密接な作業をすることで、新しいパターンや手法や制限を発見する。責任は曖昧になるが、問題を素早く解決し、素早く学習を促進させる。
X-as-a-Service 一方のチームが別のチームから「サービスとして」提供されたもの(サービスやAPIなど)を使用する。責任は明確に定義されている。利用する側のチームはすばやいデリバリーが可能になる。サービスの提供者はいかに利用しやすくするかを目指す。
ファシリテーション一方のチームが、別のチームが新しいアプローチを学習したり習得したりするのを一定期間支援する。ファシリテーションを行う側のチームは相手チームを早く独り立ちさせることを目標として、ファシリテーションをされる側のチームは学習に対してオープンな態度を取る。

コラボレーションモード

イノベーションとすばやい探索を行う。

しかし、境界は曖昧である。

主に、やることとしては他のチームとの協業である。

新しいものをいち早く取り込み、他のチームへ展開する役割を果たす。

異なるスキルの人たちで構築されたチームによって運用され、さまざまな経験や知識を融合して、難しい問題解決にアプローチする。

他のチームへの学習を促すのもこのチームの役割である。

そして、チーム間の協力がほぼ全面的なのを示す。

異なるスキル感のチームが二つ存在していても、一つのチームとしてみなす。

重点分野と責任範囲の重なりが少ない場合でも、多い場合でも全体的なアウトカムに対して共同責任を負うことになる。

コラボレーションという行為が、責任境界を曖昧にするためだ。

そのため、コラボレーション中においては、認知負荷はずっと高くなる。

他のチームの学習において責任を伴う形で行う必要があるからだ。

これはオーバーヘッドが高くなることを示唆する。

しかし、新しいプラクティスを学ぶ機会にもなり、2つのチームのインタラクションを起こすことで、一緒に働くことにより有効性を高めることができる。

そのため、チーム間の摩擦は全くなくすか、極力少なくする努力は必要になってくる。

X-as-a-Serviceモード

あまり、手間をかけずに「まずは動く」コードライブラリ、コンポーネント、API、プラットフォームを必要とするチームがいるという状況に適している。

他のチームに使われるような場合である。

システム開発の後期フェーズや、新しいアプローチの探索より、こちらのアプローチが必要とされる時期に効力を発揮する。

これにより、デリバリーチームは自分達の仕事のコアでない側面について理解する必要がなくなり、よりすばやいデリバリーを可能にする。

認知負荷の観点では、より低いものになる。

これは、優れたクリーンなAPIがあるためだ。

そのかわり、デベロッパーエクスペリエンス(DevEx)は非常に魅力的なものにしなければならない。

提供されるサービスは、使用、テスト、導入、デバッグが容易である必要がある。

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

1つ以上のチームが、別チームから積極的に作業の一部をファシリテーションまたは、コーチしてもらう場合に適している。

主に、イネイブリングチームにより運用される。

他チームの支援と能力を提供し、生産性と有効性を高める助けとなる。

他チームが使用している既存のコンポーネントやサービスのギャップや不整合を発見することもある。

そのため、どちらかというと、主要なソフトウェアシステムや付随するコンポーネントやプラットフォームの構築は行わず、それぞれの構築を行うチーム間のインタラクションの品質に注目する。

チーム間のコミュニケーションを、システムが求めるアーキテクチャに基づいて定義し、明確化するのに役立つ。

必要なインタラクションモード

チームが達成すべきことによって、必要なインタラクションモードは異なる。

最終的には、特定の理由でチームインタラクションがコラボレーションとX-as-a-Serviceの間を行き来することを期待される。

そうすることで組織はアジリティを獲得できる。

多様なトポロジーと多様なチームインタラクションは、組織の各所での目的や状況に応じて、それぞれのタイミングで進化させなければいけない。

そのためには、「自分達は何かを発見しようとしているのか？」「どれくらいの速さで？」といった自問をしなければいけない。

組織のチームトポロジーは、数ヶ月にわたりゆっくり変化するのだ。

チームトポロジーの変化のきっかけ

兆候としてあるのが以下 - スタートアップ企業が成長し、15人を超える - 1チームの変更により、他のたくさんのチームが長く待たされる - システム内の特定のコンポーネントやワークフローへの変更は、多忙だろうと不在だろうと、いつも決まって同じ人に割り当てられる。 - チームメンバーはドキュメントの不足に不満を持っている。

これは「今優先すべき仕事は何か」ではなく「分かっているのは誰か」に計画が左右されることによる兆候になる。

これが常態化すると、個人のモチベーションに悪影響を与える可能性がある。

そして、結果としてシステムの大きさやコードの大きさが、大きくなりすぎていることに全体像を把握しきれなくなって初めて気が付くようになる。

また、兆候としてあがる側面に