Spotify Modelは、2012年に音楽ストリーミング大手Spotifyが『Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds』で発表した、従来の*アジャイルを拡張した開発プロセスのことです。
現在私が所属するエンジニアリング組織でもSpotify Modelに近い組織構成・開発プロセスを採用しています。
本記事ではSpotify Modelの概要と、スタートアップ企業の開発組織がスケールアップを図る際に利用する場合のヒントや注意点を紹介します。PMFの達成後にプロダクトや開発組織の成長をさらに加速させたい方や、VCが投資先を支援する際の参考になれば幸いです。
*アジャイル：小さな単位で設計・開発・テスト・リリースなどのサイクルを素早く回し、変化に対応しながら価値を提供する開発手法
Spotify Modelの誕生
Spotify ModelはSpotifyの開発組織が、3年間で30人から250人へと急激に拡大する過程で誕生しました。
当時の組織は1つの拠点ではなく、ストックホルムやニューヨークなど3都市にまたがる30以上のチームを抱え、従来の*スクラムでは対応しきれない課題に直面していました。そこで生まれたのが、Squad（スクワッド）、Tribe（トライブ）、Chapter（チャプター）、Guild（ギルド）という独自の構造を持つSpotify Modelです。
*スクラム：アジャイルの一種で、1〜4週間などの短いスプリントを繰り返しながら、役割を分担しチームワークを重視する開発手法
Scaling Agile @ Spotify より引用
Squad（スクワッド）
主な特徴：
- スクラムチームに近い概念で、ミニスタートアップのように自律的に開発を行う
- 特定のサービスや機能（例：レコメンド機能、支払いシステム）の設計から運用までを一貫して担当する
- Squadごとに開発プロセス（例：スクラム、カンバン）は自分たちで選択・改善できる
- プロダクトオーナー(PO)がバックログ優先度を決めるが、チームの働き方には干渉しない
Squadは、プロダクトを開発する組織の基本単位です。特定の領域においてオーナーシップを持ち、開発を進めていくためその領域におけるエキスパートになることができます。必要最小限の機能を早くリリースし、メトリクスやA/Bテストで検証する「Think it, build it, ship it, tweak it（考えて、開発して、リリースして、微調整しよう）」をモットーに開発を進めていきます。
Tribe（トライブ）
主な特徴：
- 関連する複数のスクワッドを束ねた単位（例：音楽プレーヤー系、バックエンド基盤）
- メンバー数はダンバー数（約100人）を意識し巨大化させない
- 定期的に集まる機会を作り、ソフトウェアのデモを行ったり学びなどを共有する
各Squadは自己組織化されたチームですが、もし互いに全くコミュニケーションを取らないようでは、企業組織としての機能が損なわれます。そこで導入されているのが、下記の2つの構造です。
Chapter（チャプター）
主な特徴：
- 同じTribe内で同じ職能・専門領域をもつ人々の集まり（例: フロントエンド開発担当、バックエンド開発担当）
- 技術的専門性を維持し、知識共有を促進する
Guild（ギルド）
主な特徴：
- Tribeを横断して、興味関心が同じ人々が集まる好奇心を持ったコミュニティ
- 勉強会等の実施によって、スキルや知見の共有
スタートアップ企業のスケールアップに活用するメリット
ここまで紹介したSpotify Modelを、PMFを達成したスタートアップがさらにスケールアップしていく際に活用すると、どのようなメリットがあるのでしょうか。私が考えるポイントを以下に挙げます。
- 組織のスケーラビリティ強化
- 技術的優位性の強化
プロダクトの成長に合わせて開発組織を拡大する際、自己組織化された小チーム（Squad）がミニスタートアップのように動ける仕組みはとても有効です。
ソフトウェア開発では、ユーザーに素早く価値を届けてフィードバック（以下、FB）をもらうことが重要です。そのために、各Squadが独立して意思決定を行い、開発→リリース→FB→修正のサイクルを高速で回せる体制は大きな強みになります。
ユーザーに提供して実際に使ってもらわない限り、そのプロダクト（機能）が本当に価値を持つかどうかはわかりません。であれば、最短期間でリリースし、失敗や課題を素早く洗い出して再度修正・改善したほうが合理的であると私は考えています。
実際に私の所属する開発組織では、プロダクトオーナー・デザイナー・エンジニアで議論したユーザー体験の仮説を検証するために、まずは最小最短で機能をリリースすることを重視しています。
その際にあらかじめユーザーに期待するFBも考えておき、そのFB内容を後続のタスクとして取り組むことで、継続的にユーザに価値を提供する仕組みを作っています。
SquadやTribeに加えてChapterやGuildを活用し、他チームと技術的な知見を共有することによって、組織全体のスキル向上や特定領域での専門性を強化することができます。実際にSpotifyでは、ウェブ開発やテストのChapterがSquad間でベストプラクティスを広め、100以上のサービスを高品質に保ったそうです。
注意点
実際にSpotify Modelに近い形で開発を行った経験から、いくつかの注意点を挙げます。
- 他の領域のドメイン知識の欠如
- 組織の規模によっては逆効果
- Squad同士の依存がある場合は非効率になる
特定の領域に専念してエキスパートになることは強みではありますが、逆に言えば他の領域にはほとんど触れる機会がないともいえます。そのため、担当領域が変わった場合には、キャッチアップに時間がかかるかもしれません。
→組織内で知識が偏りやすくなるリスク
Spotify Modelが示された当時、Spotifyの開発組織は約250名規模でした。比較的小規模の開発組織では、ここまで複雑なモデルを導入する必要がないケースも多いと考えられます。
例えば開発組織が10人で構成されている場合、多くても3チームの構成になるでしょう。その組織において担当領域を細かく絞ると、かえってコミュニケーションコストが増え、自己組織化の良さが生きなくなる可能性があります。
他のSquadと強く依存する場合、開発スピードが低下する可能性があります。
例えば、EC系のサービスで決済機能Squadと注文管理Squadを分けた場合、それぞれが別々に開発を進めると、決済処理や注文ステータスの管理を連携するために多くのミーティングや仕様調整が必要になります。結果的にリリースが遅れ、Squad間のやり取りが増えてしまうリスクがあります。
Scaling Agile @ Spotify より引用
解決策の例
1の解決策としては、ドキュメント化することが挙げられます。具体的には、意思決定の背景や複雑なドメイン知識が必要になる場合には、それらをドキュメントとして残して、組織内から参照できるようにするということです。
2に関しては、小規模組織では、まずシンプルなチーム構成で開発を進め、必要に応じて段階的にSpotify Modelの要素を取り入れていくほうが現実的かもしれません。
3に関しては、依存が発生しないようなSquad構成にする必要があります。例の場合だと商品購入Squadのように決済と注文管理を一貫して開発する組織体制にすることが有効です。
まとめ
本記事ではSpotifyの開発組織が実際に行なっていたSpotify Modelを紹介しました。この組織構成・開発プロセスはあくまで一例であり、実際にはプロダクトの性質やチームの規模などを踏まえて、適宜カスタマイズすることが重要です。PMF後のスタートアップやVCが投資先を支援する際に、このモデルのエッセンスが参考になれば幸いです。
参考文献
Henrik Kniberg Spotify Engineering Culture - Part 1 (aka the "Spotify Model")
Henrik Kniberg Spotify Engineering Culture - Part 2 (aka the "Spotify Model")