チームトポロジー

大規模なソフトウェア開発、たとえば大企業向けのソフトウェア開発では、多くの人を必要とします。 多くの人が関与するときには、うまくチームに分ける方法を考える必要があります。 ビジネス機能中心のチームを作れば、顧客のニーズに対応したソフトウェア開発ができるでしょう。 しかし、求められるスキルの範囲が膨大になります。 チームトポロジーとは、ソフトウェア開発チームの組織化を記述するモデルです。 Matthew SkeltonとManuel Paisによって開発されました。 チームトポロジーでは、4つの形態のチームと3つのインタラクションモードが定義されています。 ビジネス機能中心のチームが価値あるソフトウェアの流れを提供できるように、 健全なインタラクションを促すモデルです。

このフレームワークにおける主要なチーム形態は、ストリームアラインドチームです。 ストリームアラインドチームとは、ひとつのビジネス機能のソフトウェアを担当するビジネス機能中心のチームです。 チームの寿命は長く、自分たちはビジネス機能を強化するソフトウェアプロダクトを提供すると考えています。

各ストリームアラインドチームは、フルスタックであり、フルライフサイクル（フロントエンド、バックエンド、データベース、ビジネス分析、機能の優先順位付け、UX、テスト、デプロイ、モニタリングといった、ソフトウェア開発全般）を担当します。 ストリームアラインドチームはアウトカム指向であり、 アクティビティ指向のチームのようにビジネス分析、テスト、データベースなどの機能にフォーカスするのではなく、ビジネスの結果にフォーカスします。 規模は大きすぎてはいけません。理想的なのは2枚のピザチームです。 大きな組織にはそのようなチームがたくさんあります。 各チームは異なるビジネス機能をサポートしていますが、 すべてに共通するニーズ（データストレージ、ネットワーク通信、オビザーバビリティなど）もあります。

このような小さなチームは認知的負荷を軽減する方法を求めています。 データストレージの問題よりも、ビジネスニーズのサポートに集中したいからです。 そのために重要となるのは、チームがフォーカスしていない問題を扱うプラットフォームを構築することです。 多くのチームでは、広く利用されているサードパーティのプラットフォームになるでしょう。 たとえば、データベースバックエンドのウェブアプリケーションにRuby on Railsを使うようなことです。 しかし、あらゆるプロダクトから利用できる単一のプラットフォームはありません。 複数のプラットフォームを見つけて、それらを統合する必要があります。 また、大きな組織では社内サービスにアクセスしたり、会社のルールに従ったりする必要もあります。

このような問題は社内にプラットフォームを構築することで解決できます。 そうすれば、サードパーティのサービス、ほぼ完璧に近いサービス、社内サービスなどを統合できます。 チームトポロジーでは、こうしたプラットフォームを構築するチームを（何のひねりもないが、わかりやすく）プラットフォームチームと呼んでいます。

小さな組織であれば、プラットフォームチームはひとつでいいでしょう。 プラットフォームチームは外部から提供されたプロダクトの上に薄いレイヤーを作ります。 しかし、大きなプラットフォームでは、2枚のピザよりも多くの人が必要になるでしょう。 そこで著者たちは、複数のプラットフォームチームをまとめるプラットフォームグルーピングを説明する方向に動いています。

プラットフォームの重要な特徴は、 基本的にセルフサービスで使用できるように設計されていることです。 ストリームアラインドチームは、 プラットフォームチームと細かく調整することなくプラットフォームを使用して、 自分たちのプロダクトを担当します。 チームトポロジーのフレームワークでは、 こうしたインタラクションはX-as-a-Serviceモードと呼ばれています。 プラットフォームがストリームアラインドチームに対するサービスとして振る舞うのです。

しかし、プラットフォームチームも顧客のニーズを深く理解して、自分たちのサービスをプロダクトとして構築する必要があります。 そのためには、別のインタラクションモードを使用する必要があります。 コラボレーションモードです。 コラボレーションモードとは、より強力なパートナーシップを結ぶインタラクションの形式です。 プラットフォームがX-as-a-Serviceモードに移行するまでの一時的なアプローチです。

今のところ、このモデルは特に新しいものではありません。 ビジネスアラインドチームと技術サポートチームを分けるというアプローチは、 エンタープライズソフトウェアと同じくらい昔からあるものです。 近年、多くの著者が、 ビジネス機能チームはフルスタックであり、 フルライフサイクルを担当すべきということを述べています。 私が考えるチームトポロジーの素晴らしいインサイトは、ある問題にフォーカスしているところです。 その問題とは、フルスタックでフルライフサイクルのビジネスアラインドチームは過剰な認知的負荷に直面することが多く、小規模で反応性の高いチームに対する要望の足かせになっているという問題です。 プラットフォームの主な利点は、この認知的負荷を軽減することです。

このインサイトは深い意味を持ちます。 まず、プラットフォームチームのプラットフォームに対する考え方が変わります。 クライアントチームの認知的負荷を軽減することで、 標準化やコスト削減を主な目的としたプラットフォームの設計決定やプロダクトロードマップが変わります。 このインサイトはプラットフォーム以外にも当てはまります。 このインサイトによって、チームトポロジーはあと2種類のチームを特定し、モデルをさらに発展させました。

いくつかの機能には、 多くのストリームアラインドチームの重要なトピックについて、 膨大な時間と労力を割くことができる専門家が必要です。 たとえば、セキュリティの専門家は、 ストリームアラインドチームのメンバーよりも、 セキュリティの問題の調査やコミュニティとの交流に多くの時間を使うでしょう。 こうした人たちはイネイブリングチームになります。 他のチームで関連するスキルを高め、そのチームが独立性を維持し、サービスの所有と進化がうまくできるようにするという役割です。 イネイブリングチームを実現するには、最後のインタラクションモードを使います。 ファシリテーションモードにはコーチングの役割が含まれます。 イネイブリングチームは標準に準拠していることを確認するために存在しているのではなく、 ストリームアラインドチームが自律的になるように、教育・指導するために存在しているのです。

ストリームアラインドチームは顧客に対する価値のすべての流れを担当しますが、 専門のグループが必要なほど難しい作業が発生することがあります。 最後のチームにつながります。 コンプリケイテッド・サブシステムチームです。 このチームの目的は、 複雑なサブシステムを使用するストリームアラインドチームの認知的負荷を軽減することです。 サブシステムのクライアントがひとつだけであっても、 コンプリケイテッド・サブシステムチームを作ることは有用です。 コンプリケイテッド・サブシステムチームのクライアントとのインタラクションはX-as-a-Serviceモードですが、短期間はコラボレーションモードを使用する必要があります。

図：チームトポロジーには、チームとその関係を示すグラフィカルな記号が含まれています。上記の図は現在の標準のものであり、書籍で使用されているものとは異なります。最近の記事では、これらの図の使用方法について詳しく説明されています。

チームトポロジーは、コンウェイの法則の影響を明確に認識して設計されています。 チームトポロジーが奨励するチーム組織は、 人間の組織とソフトウェアの組織の相互作用を考慮に入れています。 チームトポロジーの提唱者は、 チーム構造がソフトウェアアーキテクチャの将来の開発に影響を与え、 ビジネスニーズに合わせた、反応性のある、分離されたコンポーネントを生み出すと考えています。

George Boxが「すべてはモデルは間違っているが、なかには役に立つものもある」と言っています。 つまり、チームトポロジーは間違っています。 複雑な組織を4種類のチームと3種類のインタラクションに単純に分割することはできません。 しかし、このような制約があるからこそ、このモデルは役に立つのです。 チームトポロジーは、組織を効率的に運営していくためのツールです。 ストリームアラインドチームの認知的負荷を軽減し、流れを最大化できるようにするのです。

謝辞

Andrew Thal、Andy Birds、Chris Ford、Deepak Paramasivam、Heiko Gerin、Kief Morris、Matteo Vaccari、Matthew Foster、Pavlo Kerestey、Peter Gillard-Moss、Prashanth Ramakrishnan、Sandeep Jagtap たちと草稿について社内メーリングリストで議論し、有益なフィードバックをもらいました。

Matthew Skelton と Manuel Pais は、書籍以降の考え方を共有してくれるなど、詳細なコメントを提供してくれました。

さらに詳しく知るために

チームトポロジーのフレームワークについて最も詳しいのは、2019年に出版された同名の書籍です。 著者たちはチームトポロジーのウェブサイトも運営しており、 教育およびトレーニングのサービスを提供しています。 チームインタラクションモデリングに関する最近の記事は、 チームトポロジーの（メタ）モデルを使用して、 組織のモデルを構築・進化させる入門的な内容になっています[1]。

チームトポロジーの多くは、認知的負荷の考えにもとづいています。 著者たちは、TechBeaconで認知的負荷について調査しました。 Jo Pearceは、ソフトウェア開発における認知的負荷について詳しく説明しています。

チームトポロジーのモデルは、 私がこのサイトで公開しているソフトウェアチーム組織に関する考えと共通する部分が多くあります。 team organizationタグから読むことができます。

脚注

[1] 私のモデリング用語で厳密に言うとすれば、チームトポロジーはメタモデルとして機能していると言えるでしょう。私がチームトポロジーを使って、航空会社のソフトウェア開発組織のモデルを構築したとすると、チームトポロジーの用語に従って分類された航空会社のチームのモデルが示されます。その場合、チームトポロジーのモデルは、私の航空会社のモデルのメタモデルであると言えます。