チームが全行程を所有する：ストリームアラインドチームとデリバリー
こんな状況を想像してみてください。あなたのチームがEコマースアプリの検索機能に新しいフィルターを追加したいとします。デザインは完成し、コードも書き終え、ローカルではテストもパスしています。しかし、リリースできません。デプロイには別のチームが必要です。インフラは別のチームが管理しています。データベースの変更はさらに別の担当者です。そしてリリーススケジュールは、週に一度しか集まらないグループが管理しています。
これが多くのエンジニアリングチームの現実です。単一の機能をリリースする作業には、複数のチーム間での引き継ぎが伴います。引き継ぎのたびに待ち時間、コンテキストスイッチ、調整のオーバーヘッドが発生します。構築に3日かかった機能が、ユーザーに届くまでに2週間かかることもあります。
もっと良い方法があります。それは「ストリームアラインドチーム」と呼ばれ、Team Topologiesモデルにおける基本パターンです。
ストリームアラインドチームの条件
ストリームアラインドチームは、アイデアからユーザーに至るまでの完全な価値ストリームを所有します。このチームは、機能のリリース、バグ修正、本番環境へのデプロイにおいて、他のチームに依存しません。コミットから実際の利用開始まで、変更を加えるために必要なすべてをチーム内で完結させます。
Eコマースアプリケーションで検索を担当するチームを考えてみましょう。このチームには、インデックスとクエリを扱うバックエンド開発者、検索結果ページを構築するフロントエンド開発者、検索シナリオをテストするQAエンジニア、そして本番環境へのデプロイを管理する担当者が含まれます。このチームが新しいフィルターを追加したい場合、すべてを自分たちで行います。変更の設計、コード作成、テスト、デプロイまで。他のチームの作業が終わるのを待つ必要はありません。
以下は、2つのデリバリーパスの比較図です。
これが、自分たちの価値ストリームを持つことの意味です。価値ストリームとは、アイデアをユーザーが実際に使える価値に変える一連のステップです。CI/CDの観点では、価値ストリームはコードコミットからビルド、テスト、デプロイ、そして機能がユーザーに公開されるまでのすべてをカバーします。ストリームアラインドチームは、これらのすべての段階を所有します。
これがCI/CDをどう変えるか
チームが価値ストリームを所有すると、CI/CDパイプラインは根本的に変わります。チームは自分たちのニーズに合わせてパイプラインを設計します。統合テストをいつ実行するか、どのデプロイ戦略が自分たちの機能に適しているか、いつロールバックするかを決定します。他のチームとリリーススケジュールを調整する必要はありません。
このパターンは、所有権の考え方を変えます。従来のセットアップでは、チームAが機能を構築し、チームBがデプロイを担当し、チームCがインフラを管理するという分離がよく見られます。何か問題が発生するたびに、チームAはチームBまたはチームCを待つことになります。ストリームアラインドチームでは、所有権はエンドツーエンドです。機能を構築したチームが、本番環境でもそれを運用します。
パイプライン設計への実際的な影響は大きいです。すべてのチームが通過しなければならない巨大なパイプラインが1つある代わりに、各チームが独自のパイプラインを持つことができます。バックエンドチームは、重い統合テストを含むパイプラインを持つかもしれません。フロントエンドチームは、ビジュアルリグレッションテストに焦点を当てるかもしれません。各パイプラインは独立して、チーム自身のペースで実行されます。
コミュニケーションのボトルネックが消える
ストリームアラインドチームの最大の利点の1つは、コミュニケーションのボトルネックが減ることです。ステージング環境にデプロイするためだけに調整ミーティングを開く必要はありません。リリース枠を待つこともありません。他のチームと合意した境界内で、自分たちの速度で進めます。
あなたのチームが最後に本番環境で問題を抱えたときのことを思い出してください。もしストリームアラインドチームだったなら、コードとデプロイを自分たちで所有しているので、すぐに修正できたはずです。チケットを発行したり、インフラチームがアクセス権を付与するのを待ったり、コードベースを知らない別のチームに問題を説明したりする必要はありませんでした。
すべてのチームがストリームアラインドになれるわけではない
ストリームアラインドチームは一夜にして現れるものではありません。小規模な組織では、1つのチームがアプリケーション全体を担当するかもしれません。大規模な組織では、1つのチームが検索、レコメンデーション、支払いなどの単一のプロダクト領域を担当するかもしれません。重要なのは、各チームが自分たちが何を所有し、何が他のチームに属するかについて明確な境界を持っていることです。
このパターンは、チームが孤立して作業することを意味するわけでもありません。ストリームアラインドチームは、連携するためのツール、環境、インフラを依然として必要とします。彼らには、その上に構築するためのプラットフォームが必要です。ここで、他のチームパターン、例えばプラットフォームチームが登場します。プラットフォームチームは、ストリームアラインドチームがすべてをゼロから構築することなく迅速に動けるように、基盤を提供します。
ストリームアラインドチームへの移行のための実践的チェックリスト
チームをこのモデルに移行させたい場合、以下が実践的なチェックリストです。
- 現在の価値ストリームをマッピングする。 アイデアから本番環境に至るまでのすべてのステップを書き出します。各ステップに関与するチームをメモします。引き継ぎの回数を数えます。
- 1つの境界のある領域を特定する。 明確な境界を持つ機能またはサービスを選びます。検索、支払い、通知、ユーザープロファイルなどです。システム全体ではなく、1つの領域から始めます。
- チームにエンドツーエンドの所有権を与える。 その領域のコード、テスト、デプロイ、本番監視をチームに任せます。この範囲では、他のチームへの依存関係を排除します。
- チームに独自のパイプラインを設計させる。 会社全体のパイプラインテンプレートを強制しないでください。テスト戦略、デプロイ頻度、ロールバックアプローチをチームに選択させます。
- ゲートではなくプラットフォームを提供する。 チームが使用できる共有インフラとツールを構築しますが、承認を待ったり、リリース枠に並んだりする必要はありません。
- 明確な境界を設定する。 このチームが何を所有し、他のチームが何を所有するかを定義します。チーム間のインターフェースを文書化します。あるチームの責任がどこで終わり、別のチームの責任がどこから始まるかを全員が理解していることを確認します。
本当のポイント
ストリームアラインドチームは、デリバリー体験を「待って調整する」ことから「動いてリリースする」ことへと変えます。チームが価値ストリームを所有すると、引き継ぎの摩擦がなくなります。CI/CDパイプラインは、チームが従うプロセスではなく、チームが制御するツールになります。チームは本番環境の問題に即座に対応し、自分たちのペースで機能をリリースし、組織的な依存関係を乗り越える代わりに価値の構築に集中できます。
小さく始めてください。1つの境界のある領域を選び、チームに完全な所有権を与え、デリバリースピードがどう変わるかを見てみてください。許可を待つことと全行程を所有することの違いは、ほとんどのチームが予想するよりもはるかに大きいです。