チームトポロジー

大企業のソフトウェア資産など、大規模なソフトウェア開発には多くの人員が必要になります。多くの人員がいる場合は、効果的なチームに分割する方法を考えなければなりません。 ビジネスケイパビリティ中心のチームを編成することで、ソフトウェア開発は顧客のニーズに迅速に対応できますが、必要なスキルの範囲が広いため、そのようなチームはしばしば圧倒されてしまいます。マシュー・スケルトンとマヌエル・パイスによって開発されたチームトポロジーは、ソフトウェア開発チームの組織を記述するためのモデルです。これは、4つの形式のチームと3つのモードのチームインタラクションを定義しています。このモデルは、ビジネスケイパビリティ中心のチームが価値のあるソフトウェアを安定して提供するというタスクにおいて成功できるように、健全なインタラクションを促進します。

このフレームワークにおける主要なチームの種類は、ストリームアラインドチームです。これは、単一のビジネスケイパビリティのソフトウェアを担当するビジネスケイパビリティ中心のチームです。これらは長期にわたるチームであり、ビジネスケイパビリティを強化するためのソフトウェア製品を提供するものとして、自分たちの取り組みを考えています。

各ストリームアラインドチームは、フルスタックかつフルライフサイクルであり、フロントエンド、バックエンド、データベース、ビジネス分析、機能の優先順位付け、UX、テスト、デプロイ、監視など、ソフトウェア開発のすべてを担当します。彼らは、ビジネス分析、テスト、データベースなどの機能に焦点を当てたアクティビティ指向チームではなく、ビジネス成果に焦点を当てた成果指向です。しかし、彼らはまた、大きすぎてはいけません。理想的には、それぞれが2枚のピザで賄えるチームです。大規模な組織には、そのようなチームが多数存在します。サポートするビジネスケイパビリティは異なりますが、データストレージ、ネットワーク通信、可観測性など、共通のニーズがあります。

このような小規模なチームでは、認知負荷を軽減する方法が必要になります。そのため、彼らは（たとえば）データストレージの問題ではなく、ビジネスニーズのサポートに集中できます。これを行う上で重要な部分は、これらの非中心的な懸念に対処するプラットフォーム上に構築することです。多くのチームにとって、プラットフォームは、データベースに裏付けられたWebアプリケーション用のRuby on Railsなど、広く利用可能なサードパーティ製のプラットフォームになる可能性があります。しかし、多くの製品では、使用する既製のプラットフォームは1つではなく、チームは複数のプラットフォームを見つけて統合する必要があります。大規模な組織では、さまざまな内部サービスにアクセスし、企業標準に従う必要があります。

この問題は、組織向けの内部プラットフォームを構築することで対処できます。このようなプラットフォームは、サードパーティサービス、ほぼ完全なプラットフォーム、および内部サービスの統合を行うことができます。チームトポロジーは、これを構築するチームを（想像力に欠けますが賢明にも）プラットフォームチームとして分類します。

小規模な組織は、外部から提供された一連の製品の上に薄いレイヤーを作成する単一のプラットフォームチームと連携できます。ただし、大規模なプラットフォームには、2枚のピザで賄えるよりも多くの人員が必要になります。したがって、著者は多くのプラットフォームチームのプラットフォームグループについて説明するように移行しています。

プラットフォームの重要な特徴は、主にセルフサービス方式で使用できるように設計されていることです。ストリームアラインドチームは依然として製品の運用を担当しており、プラットフォームチームとの elaborate なコラボレーションを期待することなく、プラットフォームの使用を指示します。チームトポロジーフレームワークでは、このインタラクションモードはX-as-a-Serviceモードと呼ばれ、プラットフォームはストリームアラインドチームへのサービスとして機能します。

しかし、プラットフォームチームは、顧客のニーズを深く理解した上で、自社のサービスを製品として構築する必要があります。これには多くの場合、サービスを構築している間、別のインタラクションモードであるコラボレーションモードのいずれかを使用する必要があります。コラボレーションモードは、より intensive なパートナーシップ形式のインタラクションであり、プラットフォームがx-as-a-serviceモードに移行するのに十分成熟するまでの temporarily なアプローチと見なす必要があります。

これまでのところ、このモデルは特に独創的なものを表していません。組織をビジネスアラインドチームとテクノロジーサポートチームに分割することは、エンタープライズソフトウェアと同じくらい古いアプローチです。近年、多くの著者が、これらのビジネスケイパビリティチームにフルスタックとフルライフサイクルの責任を負わせる重要性を表明しています。私にとって、チームトポロジーの明るい洞察は、フルスタックでフルライフサイクルのビジネスアラインドチームを持つということは、多くの場合、過度の認知負荷に直面することを意味し、これは小規模で対応性の高いチームへの要望に反するという問題に焦点を当てています。プラットフォームの主な利点は、それがこの認知負荷を軽減することです。

この洞察は、 profound な意味合いを持っています。まず、プラットフォームチームがプラットフォームについてどのように考えるべきかが変わります。クライアントチームの認知負荷を軽減すると、主に標準化またはコスト削減を目的としたプラットフォームとは異なる設計上の決定と製品ロードマップが導き出されます。プラットフォーム以外にも、この洞察により、チームトポロジーはさらに2種類のチームを特定することにより、モデルをさらに発展させています。

一部のケイパビリティには、多くのストリームアラインドチームにとって重要なトピックを習得するために、かなりの時間とエネルギーを費やすことができるスペシャリストが必要です。セキュリティスペシャリストは、ストリームアラインドチームのメンバーとして可能であるよりも多くの時間をセキュリティ問題の調査とより広範なセキュリティコミュニティとのインタラクションに費やす場合があります。そのような人々はイネーブリングチームに集まります。その役割は、他のチーム内で関連するスキルを伸ばすことであり、それらのチームは独立性を維持し、サービスをより適切に所有および進化させることができます。これを達成するために、イネーブリングチームは主にチームトポロジーの3番目で最後のインタラクションモードを使用します。促進モードにはコーチングの役割が含まれます。イネーブリングチームは標準を作成および確実に準拠するためではなく、同僚を教育およびコーチングして、ストリームアラインドチームの自律性を高めるために存在します。

ストリームアラインドチームは、顧客にとっての価値の流れ全体を担当しますが、ストリームアラインドチームの作業の側面で、 dedicated なグループがそれに焦点を当てる必要があるほど要求が厳しい場合があります。これにより、4番目で最後のタイプのチームである複雑なサブシステムチームが生じます。複雑なサブシステムチームの目標は、その複雑なサブシステムを使用するストリームアラインドチームの認知負荷を軽減することです。そのサブシステムのクライアントチームが1つしかない場合でも、それは worthwhile な分割です。ほとんどの複雑なサブシステムチームは、x-as-a-serviceモードを使用してクライアントと対話しようとしますが、短期間はコラボレーションモードを使用する必要があります。

チームトポロジーは、コンウェイの法則の影響を明確に認識して設計されています。それが奨励するチーム編成は、人間とソフトウェアの組織の相互作用を考慮しています。チームトポロジーの支持者は、そのチーム構造がソフトウェアアーキテクチャの将来の開発を、ビジネスニーズに合致した responsive で疎結合されたコンポーネントに形作ると考えています。

ジョージ・ボックスは、「すべてのモデルは間違っている、いくつかは役に立つ」と巧みに述べました。したがって、チームトポロジーは間違っています。複雑な組織は、4種類のチームと3種類のインタラクションに単純に分割することはできません。しかし、このような制約こそがモデルを役立つものにしています。チームトポロジーは、人々が組織をより効果的な運用方法に進化させることを促進するツールであり、ストリームアラインドチームが認知負荷を軽減することでフローを最大化できるようにするものです。