チームモデルがデリバリーの妨げになるとき
3つのチームがそれぞれ機能を開発している。各チームが独自にパイプラインを構築し、それぞれの環境を管理し、それぞれの方法でデプロイしている。そして今、すべてのチームミーティングで同じ問題が表面化し始めている。デプロイに時間がかかりすぎる、インフラのオーナーが誰かわからない、リリースのたびに調整が地獄絵図になる——。
これこそ、多くのエンジニアリングリーダーが「完璧なチームモデル」を探し始める瞬間だ。彼らはストリームアラインドチーム、プラットフォームチーム、イネーブリングチームについて読み漁る。SpotifyやNetflixがやったことを真似しようとする。しかし厳しい現実は、チームモデルはメニューから選ぶものではないということだ。チームモデルは、組織が今まさに感じている特定のプレッシャーへの応答なのだ。
痛みのあるところから始めよ
チーム構造を決める前に、実際に何がボトルネックになっているのかを見極めよう。5〜10人の小規模チームでは、問題はたいていチームの境界ではない。すでに全員が何でもやっている。一人のエンジニアがコードを書き、サーバーを管理し、パイプラインを構築する。ここでの本当の痛みはバスファクターだ。その一人が病気で休めば、誰もデプロイできなくなる。
この規模では、形式的なチームモデルは答えにならない。必要なのはドキュメントと共有されたプラクティスだ。誰でもデプロイを実行できるようにする。手順を書き出す。失敗し続ける部分を自動化する。たった8人しかいないのにプラットフォームチームを作ってはいけない。単にハンドオフが増えるだけだ。
プレッシャーが変わるのは、チームが3〜4つのフィーチャーチームに成長したときだ。今度は痛みの質が変わる。各チームがゼロから独自のパイプラインを構築する。各チームが環境の扱い方を再発明する。共有された標準がなく、その不整合が時間を浪費し始める。この時点でプラットフォームチームが意味を持ち始める。ただし、大規模なチームである必要はない。標準的なパイプラインを提供することを仕事とする1〜2人から始めよう。スケールする前に、まず価値を証明させるのだ。
プロダクトの成熟度がすべてを変える
プロトタイプを構築するチームと、何千ものユーザーがいるサービスを運用するチームでは、まったく異なる制約に直面する。初期段階のプロダクトにはスピードと柔軟性が必要だ。方向転換を素早く行える必要がある。硬直したチーム構造はそれを遅らせるだけだ。俊敏に動ける小さなクロスファンクショナルチームは、完璧に組織化されているが反応できないチームよりも価値がある。
プロダクトが本番環境に入り、実際のユーザーが依存するようになると、優先順位が変わる。信頼性が重要になる。安定したプラットフォームが必要だ。プロダクションの障害に気を取られずに品質に集中できるチームが必要になる。これこそ、ストリームアラインドチームが信頼できるプラットフォームチームを必要とする瞬間だ。同時に、イネーブリングチームが価値を発揮するときでもある。テストプラクティス、デプロイパターン、モニタリング設定の改善を他のチームを支援するチームだ。
アプリケーションの種類がモデルを形作る
まだ管理可能なモノリシックアプリケーションは、単一のストリームアラインドチームで扱える。しかしモノリスが成長し、より多くのチームが同じコードベースに触れるようになると、古典的な問題が発生する。ある部分の変更が別の部分を壊す。すべてを一緒にリリースしなければならないため、デプロイが遅くなる。
よくある本能はモノリスをマイクロサービスに分割することだ。しかしそれが常に正しい第一歩とは限らない。コードを分割する前に、既存のチームがより良いテストを書き、デプロイプラクティスを改善するのを支援するイネーブリングチームの結成を検討しよう。モノリス内部でのより良いエンジニアリング規律が、時期尚早なマイクロサービス移行よりも多くの時間を稼いでくれることがある。
すでにマイクロサービスを運用しているなら、チームモデルはおそらくより分散型になる。各ストリームアラインドチームが1つ以上のサービスを所有する。しかし課題は一貫性に移る。チームの自律性を殺さずに、どうやってサービス間の整合性を保つか？ここでプラットフォームチームが不可欠になる。各チームが強制されることなく採用できる標準を提供するのだ。優れたプラットフォームは、正しいことを簡単なことにする。
チームモデルは永続的ではない
最大の過ちは、チーム構造を一度決めたら終わりと考えることだ。組織は変化する。プロダクトは進化する。チームは新しいスキルを学ぶ。昨年うまくいったモデルが、今年はボトルネックになっているかもしれない。
ストリームアラインドチームが、他のチームが依存し始める機能を構築した結果、自然にプラットフォームチームに進化することもある。あるチームのテスト改善を支援したイネーブリングチームが、組織全体にサービスを提供するプラットフォームチームに成長することもある。これらの移行は健全だ。組織が実際のニーズに適応している証拠だからだ。
重要なのは定期的な評価だ。自問しよう。現在のチームモデルはデリバリーを促進しているか、それとも妨げているか？チームが常に互いを待っているなら、同じコミュニケーションのボトルネックが毎スプリント現れるなら、デプロイにあまりにも多くの承認とハンドオフが必要なら、調整の時だ。
実践的なチェックリスト
以下のクイック評価を使って、チームモデルに調整が必要かどうかを判断しよう。
- デプロイが別のチームを待つことでブロックされていないか？ 所有権を明確にするか、プラットフォームチームが必要かもしれない。
- すべてのチームがゼロから独自のパイプラインを構築していないか？ 小さなプラットフォームチームが全員の時間を節約できる。
- チーム間の摩擦が原因でモノリスを分割しようとしていないか？ まずイネーブリングチームを試し、モノリス内部のプラクティスを改善しよう。
- プラットフォームチームがフィーチャーチームよりも速く成長していないか？ それはプラットフォームが間違った問題を解決している兆候かもしれない。
唯一のルール
正しいチームモデルなど存在しない。あるのは、現在のコンテキストに適合するモデルだけだ。目標は教科書の図に合わせることではない。目標はデリバリーから摩擦を取り除くことだ。チーム構造がデプロイをより速く、より安全に、より予測可能にしているなら、それは機能している。もし調整のオーバーヘッドと待ち時間を増やしているなら、変えよう。
チームモデルをデプロイパイプラインと同じように評価しよう。痛みがあれば、直すのだ。