チーム トポロジ

• 適切なチームが配置されているか
• 担当チームのいない分野に対する能力の欠落があるか
• チームの自律性と他のチームからのサポートの間で、必要なバランスが取れているか

開発および運用のリーダーは、チーム トポロジのレンズを通して組織を見ることで、適切なチームが配置されているかどうかを的確に把握できます。チームのバリエーションの数を 4 つの基本チーム トポロジにまで減らして、経営幹部と実際のチーム メンバーの両方が容易に理解できるようにすることをお勧めします。

• ストリーム基準のチーム
• プラットフォーム チーム
• 複雑サブシステム チーム
• イネーブリング チーム

これらのチーム タイプは、企業の規模と成熟度に応じて異なる形態を取ることにご注意ください。実際には、複数のタイプのチームを組み合わせたりチームを別のタイプに転換させたりすることが、多くの場合で最良のアプローチとなります。

ストリーム基準のチームは、影響力のある 1 つの作業ストリームに集中します。これは、単一の製品またはサービス、単一の機能セット、単一のユーザー ジャーニー、または単一のユーザー ペルソナです。チームは、作業の一部を実行するために他のチームにハンドオフすることなく、顧客またはユーザーの価値を可能な限り迅速かつ安全に単独で構築して提供できます。

ストリーム基準のチームはデリバリーの全範囲に取り組むため、必然的に顧客に近づき、通常はすでにアジャイルの形態を取っています。このチームは、本番環境でソフトウェアを保守しながら、開発サイクルに顧客からのフィードバックを取り入れます。

多くのソフトウェア企業ではストリーム基準のチームが一般的ですが、その他の組織ではデリバリー ストリームではなく、部門別に編成されたチーム構造 (つまり、エンジニアリング、設計、QA ごとに個別のチームを持つ) がよく見られます。

ストリーム基準のチームは組織で最も一般的なチーム タイプであるため、他のチームの役割はストリーム基準のチームに対する比較で定義されます。ストリーム基準のチームは、サポート チーム (複雑サブシステム、イネーブリング、プラットフォームの各チーム) に定期的に連絡して、製品とサービスのデリバリー速度と品質を継続的に改善する必要があります。

プラットフォーム チームは、ストリーム基準のチームが実質的な自律性を持って作業を遂行できるようにする役割を担います。ストリーム基準のチームは本番環境でアプリケーションを構築、実行、修正するための完全な所有権を保持しますが、ストリーム基準のチームが使用できる内部サービスはプラットフォーム チームから提供されます。

プラットフォーム チームは、オーバーヘッドをほとんど伴わずに、多数のストリーム基準のチームが使用する機能を作成します。プラットフォーム チームは製品を最適化することで、ストリーム基準のチームのリソースと認知的負荷を最小限に抑えます。プラットフォーム チームはさまざまなユーザー エクスペリエンスまたは製品全体で一貫したエクスペリエンスを作成できるため、エンド ユーザーにとっても恩恵があります。

アトラシアンでは、プラットフォーム チームが当社のすべての製品 (ID 管理など) で使用されるサービスを構築して、ストリーム基準のチーム向けにドキュメント、サポート、コンサルティングを提供することが求められています。

複雑サブシステム チームは、特定のスキルと知識に依存するシステムの一部を構築して保守する責任を担います。ほとんどのチーム メンバーは、サブシステムを理解して変更を加えるうえで、特定の知識分野の専門家でなければなりません。

このチームの目標は、サブシステムを含む、またはサブシステムを使用するシステムで作業するストリーム基準のチームの負荷を軽減することです。複雑サブシステム チームの専門知識と能力を借りることで、ストリーム基準のチームは日常業務としては複雑すぎる分野で相応の能力を構築する必要がなくなります。このチームのチーム メンバーは、特定のマイクロサービス (つまり請求サービス)、アルゴリズム、さらには人工知能に関する専門知識を持っている場合があります。

よくある落とし穴は、サブシステムを使用するすべてのストリーム基準のチームに専門家を組み入れることです。これは効率的であるようで結局は費用対効果が低く、ストリーム基準のチームにとっては対応範囲外になります。

ストリーム基準のチームは常にプレッシャーの中で、迅速にデリバリーを遂行したり変化に対応したりしなければならず、新しいスキルを研究、学習、実践する時間を確保するのが困難になっています。

特定の技術 (または製品) 分野の専門家で構成されるイネーブリング チームが、この能力ギャップを埋めるのに貢献します。これらのチームは、ツール スタックに影響を与えるツール、フレームワーク、エコシステムの選択について、情報に基づいた提案を行えるように、研究と実験に重点を置いています。

これによって、ストリーム基準のチームは主要目標に向けた時間を減らすことなく、能力を獲得して進化させる余裕が生まれます。イネーブリング チームは、ソリューションではなく問題に焦点を当てて能力を成長させることによって、ストリーム基準のチームの自律性を高めることを目指しています。

イネーブリング チームがその役割をうまく果たせば、そのサポートを受けているチームは数週間程度で自律するはずです。イネーブリング チームは、永続的な依存関係を与えてはいけません。