スケーリングにおけるチーム構造の変遷

みなさんこんにちは。@ryuzeeです。

アジャイルを活用したプロダクト開発では、初期は1つの小規模なチームからスタートすることが一般的です。この段階では迅速な仮説検証や市場適応が求められるため、ユーザーからのフィードバックを反映しやすい少人数の柔軟なチーム構成が理想的です（逆に言うと、仮説検証段階でチーム規模を大きくしてしまうと、何か仕事をしなければいけないと考えて、使わない機能を開発したり、余計な標準化などに時間を費やしたりしてしまう可能性があります）。

しかし、プロダクトが成長し、市場での成功の兆しが見えてくると、より多くの機能の開発や技術的な対応が必要になり、チーム規模の拡大（スケーリング）が必要になるのが一般的です。このような状況では、単に人数を増やすだけでなく、チームをいかに効果的に分割し、チーム間のスムーズな協力体制を構築するかが成功の鍵となります。

チーム人数の増加とチーム分割：スケーリングフレームワークの活用

人数が増えると、特に10人を超えたあたりから、チーム内での意思決定やコミュニケーションの効率が低下し、全体の動きが鈍くなります。 Amazonの「2ピザルール」に象徴されるように、少人数で機動力を保てるチームが開発を効果的に行うには望ましいのです。よって、プロダクトが成長し、チーム人数が増加するタイミングで、チームの分割を検討することになります。つまり、チームはいきなり数が増えるのではなく、プロダクトの成長にあわせて徐々にその数が増えていきます。 1チームでスクラムを利用しているのであれば、最初はプロダクトオーナーが1人、スクラムマスターが1人、開発者が4～5人で合計6～7人だったところから、開発者が徐々に増えて10人になり、場合によってはさらに人が増えます。このとき、徐々にチームがオーバーヘッドを感じるようになるため、このチームを2つに分割します。分割後のそれぞれのチームには、また人が増えていき、その数が10人を越えたときにさらにチームを分割するといった具合です。

この緩やかなスケーリングのときに役立つのが、LeSS（Large-Scale Scrum）、Nexus などのスケーリングフレームワークやScrum of Scrums（スクラムオブスクラム） のようなプラクティスです。これらのフレームワークやプラクティスでは、複数のチームで1つのプロダクトを扱います。プロダクトオーナーは1人で、共通のプロダクトバックログを使います。通常のスクラムに加えて、チームをまたいだ計画や調整を行うイベントが追加され、チームが協力して1つのプロダクトに取り組めるようになっています。また、NexusではNexus統合チームによって複数チームの結合を支援することで、スプリントごとに確実に結合したインクリメントを届けられるようになっています。このようにして、チーム数が増加しても一貫性を保ちながら、開発効率を維持することが可能となります。

スケーリングによる難易度の増加

とはいえ、LeSSやNexusのようなスケーリングフレームワークを使用して1つのプロダクトバックログを共有するチーム数を増やし続けると複雑さが増します。プロダクトバックログが全体的に肥大化すると、優先順位の調整や依存関係の管理が難しくなります。また、多くのチームをまたいだ調整が必要になるため、調整に時間がかかり、開発に使える時間が減ります。さらに、プロダクトが巨大になると認知負荷が増えるため、開発自体の効率も低下します。そもそもプロダクトオーナー自体の作業負荷もとても大きくなります。 LeSSでもNexusでも8～9チームをまたぐ大規模な状況を想定してはいますが、難易度は高いと言わざるを得ません。

そこでチームが増加していく過程で別のアプローチを検討することになります。

プロダクトの明確化に伴う領域分割と独立チームの形成

スケーリングするのはプロダクトが成長しているときです。
初期の仮説検証が終わり、ある程度プロダクトの全体像がかたまってくると、プロダクトに含まれる機能群が徐々に明確になってきます（ペルソナなども明確になります）。
その結果、プロダクトが複数の領域から構成されていることが理解できるようになります。
この段階に達すると、機能や技術領域ごとにチームを独立させることが有効となります。
たとえば、コア機能、課金、認証、API、管理系機能など、異なる機能領域ごとにチームを編成し、各チームがそれぞれの領域に特化して作業を進めることで、認知負荷を下げるとともに、依存関係の管理の手間や結合のコストを減らすことができます。

それぞれの機能領域は基本的に疎結合になるように構築するのが一般的です（つまりこのタイミングでモノリシックアプリケーションの分割が始まります）。
そうすることで、お互いの機能領域は別プロダクトのように扱うことができます。

別プロダクトとして扱うということは、それぞれ独立したプロダクトオーナー、プロダクトバックログを持つことになります。チーム間の調整は、機能領域間のインターフェイスが中心になり、作業やデプロイ自体は独立して進められるようになります。
これらの結果、チームは自律性が高い状態になります。さらにいえば、分割後のチームは分割前と同じ開発プロセスを利用する必要すらないかもしれません。もともとのチームがスクラムを使って開発していたとしても、新しいチームではカンバンを使うとか、場合によっては計画駆動型のプロセスにするといった判断もできます。

一方でこの形に分けた場合の問題もあります。
それは機能領域ごとに仕事の重要性や量、ピーク性が異なる可能性があることです。
例えば、機能領域Aの3番めのプロダクトバックログアイテムは、機能領域Bの1番めのプロダクトバックログアイテムより重要性が高いかもしれません。
もしくは、ある時点で特定の機能領域はもう作業の必要がないくらい安定するかもしれません。
このような場合は、さらにチーム構成を見直す必要があります（担当領域を変えたり、複数のチームを統合したり、複数チームによるスクラムに戻したりすることもあります）。

チームトポロジーによるチームの形成

前項では機能領域の切り出しによる独立チームについて説明しましたが、チーム形成の観点はそれだけではありません。ここで使えるのが書籍『チームトポロジー』で解説しているアプローチです。チームトポロジーでは、4つのチームタイプと3つのインタラクションモードを定義しています。ここではチームタイプについて説明します（チームトポロジーの概要を簡単に知りたい場合は、こちらのスライドを参照してください）。

ストリームアラインドチーム

最終的なユーザーに直接価値を提供するチームで、プロダクトの成長に応じてその数を増やしていきます。いちばん中心となるチームタイプです。

コンプリケイティッドサブシステムチーム

複雑な技術や特化した専門知識が必要な領域（例：AIとか高度なアルゴリズムなど）を扱う専任チームです。他のチームが依存するサブシステムやコンポーネントを管理することで、各チームがその専門性に頼り、負担を軽減できます。

プラットフォームチーム

インフラや共通ツール、リリースパイプラインなどを提供するチームで、全体の基盤を整備します。各チームが共通の基盤に依存し、独自の環境を整える負担を軽減します。他のチームはプラットフォームチームが提供するものをサービスとして利用します。

イネイブリングチーム

技術的な支援や新しいプロセスの導入をサポートするために、短期間の支援を提供するチームです。例えばテスト駆動開発やDevOps、UXの専門知識などを提供し、他のチームがその分野のスキルを習得し、チーム外に頼らずに自分たちで作業を進められるよう支援します。

ストリームアラインドチームとコンプリケイティッドサブシステムチームは、機能領域によって分割したチームですが、これに加えて全体の開発を支えるプラットフォームチームとイネイブリングチームを必要に応じて準備します。スケーリングすればするほど、同じことを別々のチームで何度も行ったり調査したりするのはムダなので、プラットフォームチームとイネイブリングチームのチームの有効性が大きくなります。 SREもイネイブリングチームと考えることができます。

チーム編成の動的な組み換え

「チームは安定していたほうがよい」というのは昔から言われている話ですし、1チームで事足りる開発をしている場合はそれは当てはまります。チームを新しく作るとどうしてもパフォーマンスを発揮するまでに時間がかかる（税金がかかる）ので、意味もなくチームを切った貼ったするのは考え物です。しかし前述の文脈のとおり、プロダクトが成長段階にある場合は、その変化に対応するためにもチームの動的な組み換えが必要になるのが現実です。

ここでは書籍『Dynamic Reteaming』で定義されている5つのチーム形成パターンについて紹介します。

ワンバイワンパターン

メンバーが一人ずつチームに加わったり抜けたりするパターンです。主に個々の成長やキャリアの変化に伴う異動が原因で、チームは大きな変化を避けながらも、新たなスキルや視点が加わることで少しずつ進化していきます。小規模な変化であるため、チームの安定性が保たれやすい特徴があります。

グロウアンドスプリットパターン

チームが大きくなりすぎた場合、効率的な働き方を維持するために分割されるパターンです。成長に伴いサブチームが形成され、それぞれが異なるタスクやプロジェクトを担うことがあります。分割によりチームのフォーカスが明確になり、成果の向上が期待されますが、新しい関係構築が求められる点で調整が必要です。

アイソレーションパターン

特定の課題に集中するため、メンバーが一時的にチームから外れて独立したグループを形成するパターンです。複雑な問題解決や、新しいプロジェクトに専念する際に使われ、他のチームからの影響を受けにくくすることで集中力を高めます。成功すれば成果が大きいものの、孤立感を生じる可能性もあります。

マージパターン

二つ以上のチームを統合し、新しいチームとして再編成するパターンです。異なる専門知識やバックグラウンドを持つメンバーが融合し、新たなシナジーを生み出すことを目的とします。統合後はチームビルディングが必要で、衝突や調整が発生しやすいものの、新しい価値が生まれる可能性が高まります。

スイッチングパターン

チームメンバーが別のチームに異動することで、知識や経験を他のチームに共有するパターンです。新たな視点がもたらされ、チーム間の連携が強化されることが期待されますが、適応に時間がかかる場合もあります。組織内の知識の流動性を高め、全体の成長に寄与します。

この5つのパターンは、ここまで説明してきたスケーリングによるチーム構成の変化と合致していることがわかると思います。

まとめ

今回はプロダクト開発におけるチーム構造の変遷の考え方について説明しました。冒頭で説明したとおり、プロダクト開発において仮説検証が終わっていない段階で思い込みで大量の「要件」を用意し、それを実現するためにたくさんのチームを作るのは良い選択ではありません。プロダクトの成長にあわせて動的にチームを増やしたり組み替えたりしていくことを前提にして考えるとよいでしょう。

ここまでの内容を踏まえて、チームの構造変化の典型的なシナリオを以下に記載します。

仮説検証の初期は数名のメンバーから始めます。この時点ではスクラムではありません（3人でスクラムをしても仕方ない）
仮説検証の過程では、ワンバイワンパターンで1人づつ開発者を増やします。人数が増えると構造が必要なためスクラムなどを活用します。この時点でのチームはストリームアラインドチームです
仮説検証が進み、プロダクトの可能性の見極めができて、さらにチームに人が増えた時点で、グロウアンドスプリットパターンでチームを分割します。分割したチームはストリームアラインドチームが基本です。スクラムの場合はフレームワークやプラクティスを活用して、スケーリングに対応します
またプロダクトの一部の複雑な機能開発（AIなど）を行う場合に、アイソレーションパターンで独立したチームを作り、専門性を発揮しつつ集中して取り組むようにします。ここでできるチームはコンプリケイティッドサブシステムチームです
さらにチームが増えるとスクラムのスケーリングの難易度は跳ね上がります。またプロダクトの機能領域が明確になってきているので、それを踏まえてプロダクトの分割が可能です。なるべくお互いが疎結合になるように少しづつ進めます（つまりモノリシックを分解します）。これによってチームの認知負荷は軽減されます
また、多くのチームが共通して利用するようなものは、プラットフォームチームを作り、それを各チームにサービスとして提供するようにします。これによって多くのチームが似たようなことに時間を使うのを避けられます。さらに各チームが効果的に開発できるようにスキルトランスファーを行うイネイブリングチームを作ります
このようにしてチームを構成しているなかで、新しい領域に取り組むために、マージパターンを使って小さなチームを統合することもあります。
この流れとは別にメンバーの知識の共有や新たなスキルの獲得、モチベーションの向上などのために、スイッチングパターンを使ってメンバーの交換を行います

それでは。