ボトルネックを生まない3つのチーム連携パターン

プラットフォームチームが素晴らしいCI/CDパイプラインを構築したとします。ストリームアラインドチームがそれを使いたい。しかし、デプロイを実行するだけで済むはずが、彼らはプラットフォームチームに質問を繰り返します。気づけばプラットフォームチームはすべてのリリースに引きずり込まれ、誰も本来の仕事ができなくなっています。

これは、チームタイプを知っているだけでは不十分な瞬間です。チームがどのように相互作用するかも理解する必要があります。Team Topologiesは、チームが新しい依存関係を作ったり互いの速度を落としたりせずに協力するための3つのインタラクションパターンを定義しています。各パターンは異なる状況に適しており、どれを使うべきか、そしていつ切り替えるべきかを知ることが、スムーズなデリバリーと絶え間ない調整コストの差を生みます。

コラボレーション：不確かな問題に一緒に取り組む

コラボレーションは、2つのチームが定義された期間、密接に協力するときに発生します。コミュニケーションチャネルを共有し、頻繁に同期し、同じスペースで作業することもよくあります。このパターンは、問題がまだ十分に理解されておらず、両方のチームの専門知識が必要な場合に有効です。

ストリームアラインドチームが、複雑サブシステムチームが管理するサブシステムに変更を必要とする機能を追加したいとします。どちらのチームも単独では解決できません。ストリームアラインドチームは機能要件を知っています。複雑サブシステムチームは内部アーキテクチャを知っています。彼らは協力して適切な設計を見つけ、結合コードを書き、何も壊れないことを確認する必要があります。

コラボレーションは強力ですが、コストがかかります。両方のチームの注意力を消費し、一時的な依存関係を生み出します。だからこそ、コラボレーションは永遠に続くべきではありません。問題が解決され、パターンが明確になったら、より軽いインタラクションに移行する必要があります。コラボレーションが長引くと、チームは互いに依存し合い、自分たちの価値ストリームから注意がそれます。

問うべき重要な質問：深い共同作業はまだ必要か？それとも、学んだことを文書化して次に進むべきか？

X-as-a-Service：手取り足取り教えずに機能を提供する

X-as-a-Serviceパターンでは、あるチームが、他のチームが実装の詳細を知らなくても利用できる機能を提供します。提供側のチームはインターフェース、可用性、品質を所有します。消費側のチームは、APIを呼び出したり、事前構築されたパイプラインを実行したりするように、単にそれを使用します。

これは、プラットフォームチームとストリームアラインドチームの間の自然なインタラクションです。プラットフォームチームは、環境、CI/CDパイプライン、監視ツールなどをサービスとして提供します。ストリームアラインドチームは、パイプラインがどのように構築・保守されているかを理解する必要はありません。ただ使うだけです。

このパターンの成功は、安定した明確なインターフェースにかかっています。サービスが頻繁に変更されたり、ドキュメントが不完全だったりすると、消費側のチームは不満を感じます。彼らは独自のソリューションを作り始めます。それではプラットフォームチームを持つ意味がありません。

X-as-a-Serviceはコミュニケーションのオーバーヘッドを減らし、各チームが自分のペースで動けるようにします。しかし、これは提供側のチームがインターフェースを製品として扱い、後付けのものとして扱わない場合にのみ機能します。

ファシリテーション：チームが自立できるように教える

ファシリテーションは、あるチームが別のチームの特定の能力向上を支援するが、作業を引き継がないパターンです。これはイネーブリングチームの核となるパターンです。

イネーブリングチームは、ストリームアラインドチームのために作業を行うために来るのではありません。彼らは教え、コーチし、例やガイドを提供するために来ます。例えば、アプリケーションセキュリティを専門とするイネーブリングチームは、ストリームアラインドチームが安全なコードの書き方、シークレットの管理方法、セキュリティスキャンをパイプラインに統合する方法を理解するのを支援できます。ストリームアラインドチームが自分でできるようになると、イネーブリングチームは一歩下がり、支援が必要な別のチームに移動します。

ファシリテーションはコラボレーションとは異なります。イネーブリングチームは製品を構築しないからです。X-as-a-Serviceとも異なります。イネーブリングチームは恒久的なサービスを提供しないからです。ファシリテーションの目標は、他のチームを自立させることです。

ここでの落とし穴は、ファシリテーションが終わらないことです。イネーブリングチームが一つのチームに長く留まりすぎると、恒久的なベビーシッターになります。チームは彼らなしでは決して運用することを学びません。

3つのパターンは並行して実行できる

これらの3つのパターンは排他的ではありません。健全な組織では、これらすべてが同時に実行されています。ストリームアラインドチームは、X-as-a-Serviceを通じてプラットフォームチームのサービスを利用し、複雑な機能については複雑サブシステムチームとコラボレーションし、テストプラクティスについてはイネーブリングチームからファシリテーションを受けるかもしれません。

重要なのは、どのパターンがアクティブで、いつ切り替えるべきかを認識することです。明確な理由なく続くコラボレーションは新しい依存関係を生み出します。不安定なインターフェースを持つX-as-a-Serviceは信頼を破壊します。決して終わらないファシリテーションは、チームが自立するのを妨げます。

インタラクションパターンを選択するための実践的チェックリスト

チーム間の新しいインタラクションを設定する前に、このクイックチェックを実行してください：

次のフローチャートは、チェックリストの主要な決定ポイントをまとめたものです：

flowchart TD A[新しいチーム連携が必要] --> B{問題はよく理解されているか？} B -- いいえ --> C[コラボレーション] C --> D[終了日を設定] B -- はい --> E{手取り足取り教えずに機能を提供できるか？} E -- はい --> F[X-as-a-Service] F --> G[インターフェースを製品として扱う] E -- いいえ --> H[ファシリテーション] H --> I[イネーブリングチームの出口計画を立てる]
  • 問題が不明確で、共同での発見が必要か？ → コラボレーションを使うが、終了日を設定すること。
  • あるチームが他のチームに必要な安定した機能を持っているか？ → X-as-a-Serviceを使い、インターフェースを製品として扱うこと。
  • チームが新しいスキルを学ぶ必要があるか？ → ファシリテーションを使い、イネーブリングチームの出口を計画すること。
  • コラボレーションが予想より長く続いているか？ → そのパターンが必要性ではなく習慣になっていないか問いかけること。
  • X-as-a-Serviceのインターフェースが不満を引き起こしているか？ → 新しい機能を追加する前に、インターフェースかドキュメントを修正すること。
  • 数ヶ月経ってもイネーブリングチームがまだ必要か？ → チームが学んでいない可能性がある。別のアプローチに切り替えること。

まとめ

インタラクションパターンは単なる理論ではありません。どれだけの調整が健全で、どれだけが無駄かを判断するための実践的なツールです。コラボレーションは難しい問題を解決しますが、一時的であるべきです。X-as-a-Serviceはデリバリーを加速しますが、安定したインターフェースが必要です。ファシリテーションは能力を構築しますが、出口計画が必要です。

うまくデリバリーできるチームとは、すべてにおいてコラボレーションするチームではありません。いつ協力し、いつサービスを提供し、いつ教えて一歩下がるべきかを知っているチームです。