Spotifyモデルとは: Squad、Tribe、Chapter、Guildを解説

Spotifyモデルは、Squad(スクワッド)と呼ばれる小規模で自律的なプロダクトチームを中心に構築された、アジャイルをスケールさせるための組織構造です。Spotifyは2012年に2本の影響力のあるエンジニアリング文化に関する論文を発表し、このモデルは音楽ストリーミングの世界をはるかに超えて、官僚主義に縛られずに急成長したい銀行、小売業者、ソフトウェア企業へとまたたく間に広がりました。

先に断っておくと、Spotify自身は、当初説明されていた形でこのモデルをもはや運用していません。同社はこのモデルを超えて進化しました。だからといってこのモデルを切り捨てる理由にはなりませんが、そのまま丸ごと真似すべき手本としてではなく、アイデアの源として扱うべき理由にはなります。

Spotifyモデルとは

Spotifyモデルは、大規模なエンジニアリング組織全体にアジャイル手法をスケールさせるためのアプローチです。チームを機能(フロントエンド、バックエンド、QA)ごとに編成するのではなく、ミッションごとに編成します。小規模なクロスファンクショナルなSquadがプロダクトの一部をエンドツーエンドで所有し、他のチームを待つことなくリリースできます。

このモデルは4つの構造単位で定義されます。

このモデルのその後の説明には、さらに2つの概念が登場します。

• Trio: Tribeの成果に対する説明責任を共有する、Tribe Lead、Product Lead、Design Leadの3人組。
• Alliance: Tribe同士の作業が密接に結びついている場合の、Tribe間の調整レイヤー。

この考え方全体の根底にあるのは、**自律性(autonomy)と整合性(alignment)**の間の緊張関係です。Squadには、素早い意思決定ができるだけの自由が必要です。しかし、すべてのSquadが好き勝手にやってしまえば、プロダクトはバラバラになります。ChapterとGuildは、命令統制型の階層を新たに加えることなく、全体の一貫性を保つための結合組織の役割を果たします。

重要なポイント

• Spotifyのオリジナルの文化論文(Henrik Kniberg氏とAnders Ivarsson氏、2012年)は、このモデルを固定的なプロセスではなく「考え方の一つ」と説明しており、今なお進化し続けていることを明確に述べていました。
• 当時SpotifyのシニアアジャイルコーチだったJoakim Sunden氏は、2019年のブログ投稿で、同社がオリジナルの説明をはるかに超えて進化したことを認めています(出典: blog.crisp.se、2019年)。
• McKinseyが2022年に1,000のソフトウェア組織を対象に実施した調査によると、クロスファンクショナルでミッションに沿ったチーム構造を採用している企業は、機能別のサイロ構造を採用している企業に比べて、市場投入までの時間が速いと報告する可能性が1.5倍高いことが分かりました(出典: McKinsey Digital、2022年)。

Spotifyモデルとの主な違い: SAFe

どちらも同じ根本的な課題、つまり大規模なエンジニアリング組織をどうすれば素早く動かし続けられるかに取り組んでいます。しかし、その答え方は異なります。

SAFe(スケールドアジャイルフレームワーク)は、詳細で規範的な階層(チーム、プログラム、ソリューション、ポートフォリオ)を提供します。定義された役割(Release Train Engineer、プロダクトマネジメント)、定義された儀式(PIプランニング、システムデモ)、そして構造化されたリリースのリズムがあります。

一方、Spotifyモデルは規範的ではなく、記述的です。「私たちにとってはこの単位がうまくいった、その背景にある考え方はこうだ」と示すだけで、儀式やリズムは自分たちで考え出す必要があります。

規制対応、大規模なハードウェアプログラム、外部ベンダーとの緊密な連携が必要な企業では、SAFeの構造がその負荷に見合う価値を持つことが多くあります。一方、Squadをスタートアップのように機敏に動かしたいプロダクト主導の企業は、より軽量なSpotifyのアプローチや、ハイブリッドな形を好む傾向があります。

Spotifyモデルのメリット

開発の高速化。 Squadはプロダクト領域のフルスタックを所有しているため、継続的にリリースできます。「開発チーム」「QAチーム」「運用チーム」の間での引き継ぎは発生しません。その3つはすべてSquadの中に含まれています。これはScrumとはの背景にある考え方と同じものを、より大きなスケールで適用したものです。

調整コストの削減。 Squadが独立してデプロイできるのであれば、他の7つのチームとリリースの時期を調整する必要はありません。このモデルはコンウェイの法則を意図的に活用しています。システムアーキテクチャがチーム構造を反映するため、チーム同士は疎結合を保てます。

機能別サイロを作らないスキルの成長。 Chapterは、完全に自律したチームが生み出す本当の問題を解決します。エンジニアが自分のSquadの中に閉じこもり、職能コミュニティとのつながりを失ってしまうという問題です。5つのSquadにまたがる5人のiOSエンジニアからなるChapterは定期的に集まり、プラクティスを共有し、集団としての技術水準の底上げを図り、Chapter Leadに技術品質に対する明確な説明責任を与えます。

当事者意識のある文化。 Squadがフロントエンドからデータベース、オンコール対応までユーザージャーニー全体を所有すると、チームは自分たちの意思決定の結果を実感できます。この当事者意識は、チケットベースの引き継ぎ構造では生まれない形で行動を変えます。

Guildが知識移転を加速する。 Guildは本質的に実践コミュニティです。公式な権限は持ちませんが、トップダウンのメモよりもずっと速く、良いアイデアを社内に広めます。アクセシビリティ、オブザーバビリティ、データエンジニアリングといったテーマごとにGuildを持つことができます。

限界と批判

このモデルには、よく文書化された失敗パターンがあり、チームの再編を始める前に目を通しておくべきです。

Spotify自身がすでに先へ進んでいる。 オリジナルの2012年の論文は、Spotifyがおよそ30~40のSquadを抱えていた頃に書かれたものです。2019年までに同社は数百人規模のエンジニアを抱えるようになり、それらの論文で説明されていたモデルはもはや自分たちの働き方に合っていないことを認めています。最も誠実な捉え方は、これらの論文はある一時点のスナップショットを記録したものであって、永遠の組織的真理ではない、というものです。

「Spotifyモデル」がカーゴカルトと化した。 多くの企業が、Spotifyでそれを機能させた文化的条件を伴わないまま、用語(Squad、Tribe、Chapter、Guild)だけをコピーしました。チームの呼び方を変えても、意思決定の方法そのものは変わりません。

Chapter Leadは扱いにくい二重の責任を負う。 Chapter Leadは、人事管理者(評価、採用)であると同時に、Squad内の個人貢献者でもあります。これはうまく務めるのが難しい役割です。担当者次第で、Chapterの機能は形骸化することもあれば、逆に肥大化することもあります。

依存関係は消えない。 このモデルは、Squadが独立して動けることを前提としています。しかし実際のプロダクトでは、Squad同士がプラットフォームや共有サービス、データを共有しています。TribeやAllianceがこれを処理することになっていますが、モデルはその方法を十分に規定していません。多くの組織は、結局逃れようとしていた統合会議を、新しい名前をつけただけで作り直すことになります。

Tribeの概念をスケールさせるのが難しい。 Tribeは40~80人規模であれば一貫性を保てます。それを超えると、Tribeをまとめている共有の文化や非公式なコミュニケーションが崩れ始めます。しかし、いつTribeを分割すべきか、分割をどう扱うべきかについて、モデルは明確な指針を与えてくれません。

すべての企業文化に適しているわけではない。 高いレベルのSquadの自律性を機能させるには、意思決定を自ら担いたいと考えるエンジニア、深い階層構造なしに動けるプロダクトマネージャー、そしてコントロールを手放すことに抵抗のないマネージャーが必要です。強い命令統制型の文化を持つ組織では、リーダーシップの大幅な変化を伴わない限り、このモデルはむしろ不安定さを生み出します。

Spotifyモデルの適用方法

このモデルを導入するのであれば、あくまで出発点として扱い、大幅にカスタマイズすることを前提にしましょう。以下は実践的な手順です。

ステップ1: プロダクトをSquadサイズのミッションに分解する

まず、エンジニアリング組織が担っているユーザージャーニーやプロダクト領域から始めます。Squadは、決済体験、通知システム、データパイプラインといった、意味のあるまとまりをエンドツーエンドで所有すべきです。そのSquadが何を所有しているのかを一言で言えないなら、規模やスコープの設定が適切ではありません。

既存の機能別チーム構造をそのまま反映したSquadを作ってしまう罠には注意してください。「バックエンドSquad」ではこのモデルの目的が損なわれてしまいます。「UIから決済処理まですべてを所有する決済Squad」の方が、このモデルの意図に近いものです。

ステップ2: Squadが増える前にTribeを定義する

グループ分けが恣意的になってしまうほどSquadが増える前に、早い段階でSquadをTribeにまとめましょう。Tribeは、グロース、コアプロダクト、プラットフォーム、データといった、一貫したドメインを持つべきです。この段階でTrio(Tribe Lead、Product Lead、Design Lead)を任命しておきます。

Tribeは100人未満を目安にしましょう。それを超えると、Tribeをまとめる非公式な信頼関係のネットワークが自然には形成されなくなります。

ステップ3: 各職能ごとにChapterを立ち上げる

Squadをまたいで存在する技術的な職能、フロントエンド、バックエンド、モバイル、データ、QAなどを特定します。それぞれについて、技術力が高く、人事管理者としても信頼される人物をChapter Leadに任命します。コーディング規約、面接プロセス、オンボーディング、技術的な方向性など、そのChapterが何に責任を持つのかを定義しましょう。

Chapterを大きくしすぎないようにしましょう。5~15人程度なら管理しやすい規模です。30人のエンジニアからなるChapterは、もはやコミュニティではなく、一つの部門です。

ステップ4: Guildは指示ではなく自然発生的に立ち上げる

Guildは、人々が自発的に組織したいと思うほど関心を持って初めて機能します。すでにあるテーマ(オブザーバビリティ、アクセシビリティ、テストの実践など)の伝道者となっているエンジニアを見つけ、月に一度のフォーラムを運営してもらうことで、いくつかのGuildの種をまくことができます。

Guildへの参加を義務化したり、Guildへの参加を評価項目に組み込んだりしないでください。それはGuildを有用なものにしている非公式な性質を殺してしまいます。

ステップ5: 整合性を保つための仕組みを明示的に定義する

これは多くのチームが飛ばしてしまうステップであり、Spotifyモデルの導入がうまくいかなくなる原因の多くはここにあります。整合性を伴わない自律性は、17のチームがそれぞれ別々の認証システムを作ってしまうという結果を生みます。

次のことを文書化しておきましょう。Squad間の依存関係はどうやって伝達するのか。技術選定はどう統治されるのか。プラットフォームの機能を共有サービスにするのか、それとも各Squadが独自に作るのか、誰が決めるのか。これらの答えは、Spotifyモデル自体からは出てきません。自分たちで定義する必要があります。

ステップ6: 構造そのものについても振り返りを行う

半年ごとに、TrioとChapter Leadに問いかけましょう。Squadの構造は今も適切か。2つのSquadが互いに依存し合いすぎて統合すべき状態になっていないか。Tribeが大きくなりすぎていないか。こうした構造そのものに関する振り返りは、Squad内で行うスプリントの振り返りと同じくらい重要です。

Spotifyモデルの事例

2012年の論文発表後、このモデルは業界を超えて広がりました。以下は、さまざまな組織がこのモデルをどう適応させたかを示す、文書化された事例です。

ING銀行の事例は、おそらく最もよく引用される大企業での導入事例です。彼らの重要な適応は、コンプライアンスのChapterを後付けの存在としてではなく、一級の構成要素として扱ったことであり、これはあらゆる規制業界にとって示唆に富む教訓です。

ベストプラクティス

Spotifyモデルの導入が成功する企業と、カーゴカルト的な実装に終わる企業を分けるいくつかの原則を紹介します。

Squadの境界をアーキテクチャに合わせましょう。 Squadが独立してデプロイできるようにしたいなら、システムは疎結合である必要があります。組織設計と技術アーキテクチャは連動して進めなければなりません。だからこそ、アジャイルの儀式やエクストリームプログラミングの実践を採用しているチームは、このモデルを導入しやすいのです。彼らの技術的な習慣は、もともと疎結合を志向しているからです。

呼び方だけ変えて、仕組みを変えないのはやめましょう。 チームを「Squad」、部門を「Tribe」と呼ぶだけでは、それ自体は何も変わりません。意味のある変化は、意思決定の方法、作業の優先順位付けの方法、Squad間の対立の解決方法にこそあります。

Chapter Leadへの投資を惜しまないようにしましょう。 Chapter Leadの役割は見た目以上に難しいものです。優れたChapter Leadは、自分のChapter全体の技術品質の底上げに積極的に取り組み、効果的な1on1を行い、個人貢献者としての信頼も保ち続けます。この役割への投資を怠ることは、このモデルが崩れていく最もよくある原因の一つです。

Guildを過度に制度化しないようにしましょう。 Guildの会議が義務になったり、Guildの成果物がレビューの関門になったりしてしまうと、実践コミュニティを委員会に変えてしまったことになります。軽量なままにしておきましょう。

必要な部分だけを選んで取り入れましょう。 すべての用語をそのまま採用する必要はありません。SquadとTribeは運用するけれど、規模が小さすぎるという理由でGuildは省略している組織もあります。Chapterを運用しつつ、それを「プラクティスエリア」と呼んでいる組織もあります。重要なのはラベルよりも概念そのものです。

2012年の論文を、今も通用する文書として扱わないようにしましょう。 それらは、ある特定の時点における、急成長中の一企業のスナップショットです。読んで、その背後にある考え方を取り出し、自分たちの組織に合ったバージョンを作りましょう。

Squad間の開発リズムを比較検討しているなら、ScrumのスプリントのリズムとKanbanの継続的なフローモデルは、どちらもSpotifyモデルを採用している組織のSquad内で使われています。Squadによっては、スプリント計画の規律とKanbanのWIP制限を組み合わせたハイブリッドであるScrumbanを運用しているところもあります。個々のSquadがどちらを運用すべきかを決める前に、ScrumとKanbanの違いというトレードオフを理解しておく価値があります。

よくある質問

SpotifyモデルはSAFeと同じものですか?

いいえ、違います。SAFeは、定義された役割、儀式、リリース構造を持つ規範的なフレームワークです。Spotifyモデルは記述的な組織設計であり、単位(Squad、Tribe、Chapter、Guild)と哲学(自律性と整合性)を示すものの、儀式やリズム、ガバナンスは各組織に委ねられています。企業によっては両者の要素を組み合わせ、Spotifyモデルの単位構造を使いながら、Squad間の依存関係を管理するために明示的なSAFe流のPIプランニングを取り入れることもあります。

Spotifyモデルは非IT企業でも機能しますか?

このモデルはソフトウェアエンジニアリングのために設計されたものであり、その前提(継続的デリバリー、技術スタックの所有、Guildベースの知識共有)は自然にITチームに適合します。非IT企業もこのモデルを取り入れていますが、通常はSquadの定義を大幅に調整する必要があります。マーケティングSquadや運用Squadは、自らのデプロイパイプラインを管理するエンジニアリングSquadと同じようなエンドツーエンドの所有モデルを持ちません。自律性、整合性、実践コミュニティといった原則は転用できますが、具体的な仕組みはそのままでは通用しないことが多いです。

Spotifyモデルの恩恵を受けるには、企業はどのくらいの規模である必要がありますか?

このモデルは、規模が大きくなるにつれて生じる調整上の課題を解決するために設計されました。おおよそ50~80人のエンジニアより少ない規模であれば、単一のフラットなアジャイルチーム構造、あるいはTribeやChapterを持たないシンプルなSquad構成で十分な場合がほとんどです。TribeやGuildがその負荷に見合う価値を発揮し始めるのは、非公式なコミュニケーションだけではもはや調整しきれないほどSquadの数が増えてからです。

Spotifyモデルの導入に失敗した企業では、何がうまくいかなかったのですか?

最もよくある失敗パターンは、意思決定の構造を変えないまま用語だけを導入してしまうことです。Squadの自律性が機能するためには、Squadがすべてを階層構造に回すことなく、技術、アーキテクチャ、優先順位に関する意思決定を実際に行える必要があります。「Squad」がデプロイのために依然として6段階の承認を必要とするなら、それはどんな意味においても自律的とは言えません。2番目によくある失敗は、Chapter Leadの役割への投資不足で、これによりSquad間で技術基準がばらつき、品質が乱れていきます。

SpotifyモデルとScrumを組み合わせることはできますか?

はい、できますし、多くの組織がそうしています。Spotifyモデルはチーム構造と組織単位を定義するものであり、ScrumはSquad内の開発リズムと儀式を定義するものです。あるSquadが2週間のスプリントを回し、振り返りを行い、バックログを精査しながら、同時にあるTribeに所属し、あるChapterを持ち、いくつかのGuildに参加することもできます。両者は異なるレベルで機能しており、直接的には競合しません。

---

Spotifyモデルは、大規模な自律的でミッション駆動型のチームについて語るための語彙をソフトウェア業界に与えました。Spotify自身がオリジナルの設計を超えて進化したとしても、プロダクト領域をエンドツーエンドで所有するSquad、職能の一貫性を保つChapter、非公式に知識を広めるGuildといった概念は、一つのスウェーデンのスタートアップをはるかに超えて、有用であることが証明されています。これらを絶対的な法則としてではなく、物事を見るためのレンズとして活用すれば、カーゴカルトの罠にはまることなく、その価値の大半を得られるはずです。

関連記事

• アジャイル手法とは
• Scrumとは
• スケールドアジャイルフレームワーク(SAFe)
• ScrumとKanbanの違い
• アジャイルの儀式
• Scrumban
• Kanbanとは
• エクストリームプログラミング