フレームワーク活用ガイドひとことで言うと#
組織を**Squad（小チーム）・Tribe（部族）・Chapter（専門職の縦軸）・Guild（興味コミュニティ）**の4要素で編成し、自律性とアラインメントを両立させるフレームワーク。音楽ストリーミング企業Spotifyの開発組織を参考に、Henrik KnibergとAnders Ivarssonが2012年に整理した。
押さえておきたい用語#
- Squad（スクワッド）
- プロダクトの特定ミッションを担う6〜12人の小チーム。開発・デザイン・QAなど職種混成で、1つのスクラムチームに近い存在を指す。
- Tribe（トライブ）
- 関連するSquadをまとめた40〜150人規模のグループ。ダンバー数（人が密な関係を維持できる上限）を意識したサイズ設計である。
- Chapter（チャプター）
- 同じTribe内で同一職種のメンバーを縦に束ねるグループのこと。スキル育成や技術標準の策定をここで行う。
- Alignment（アラインメント）
- 組織全体の方向性の一致。Squadの自律性を最大化しつつも、全体の戦略とズレないようにする仕組みを指す。
- Guild（ギルド）
- Tribeを横断して、共通の関心テーマで集まる任意参加のコミュニティ。技術勉強会やベストプラクティス共有の場として機能する。
Spotifyモデルの全体像#
こんな悩みに効く#
- 組織が大きくなるにつれ、チーム間の調整コストが膨らんで開発速度が落ちている
- 機能別組織（開発部・デザイン部）だと、プロダクトへの当事者意識が薄れている
- エンジニア同士の技術交流が部署の壁で遮断され、スキルのサイロ化が進んでいる
基本の使い方#
まず、プロダクト全体を「ユーザー体験の単位」で切り分ける。検索・レコメンド・決済・オンボーディングなど、それぞれが独立して価値を届けられる粒度が目安。
- 1つのSquadが1つの明確なミッションを持てるサイズにする
- 「このSquadの成功指標は何か？」を言語化できなければ粒度が大きすぎる
各ミッションに対して、職種混成の6〜12人チームを組む。開発・デザイン・QA・プロダクトオーナーが1チームにそろう状態が理想。
- 「何を作るか」「どう作るか」の両方をSquad内で決められるようにする
- 外部承認なしにリリースできる権限を持たせる
- Squad同士の依存関係は最小限に設計する
関連性の高いSquadを束ねて40〜150人のTribeにまとめる。Tribeリーダーがアラインメントの調整役を担う。
- Tribeのサイズがダンバー数（約150人）を超えたら分割を検討する
- 定期的なTribe全体会（デモ・振り返り）でSquad間の情報格差を埋める
Squadだけだと職種ごとの知見が閉じてしまう。Chapterは同一Tribe内の同職種メンバーで技術標準やスキル育成を行い、Guildは興味ベースでTribeを超えた交流を促す。
- Chapterリーダーはピープルマネジメントの責任を持つ（評価・1on1など）
- Guildは任意参加。強制すると形骸化する
具体例#
従業員120人のフードデリバリースタートアップ。創業4年目にして、新機能のリリースサイクルが月1回から2か月に1回まで鈍化していた。原因は、開発部30人・デザイン部8人・QA部5人という機能別組織のまま拡大したため、チーム間の仕様調整会議が週12時間にも膨れ上がっていたこと。
Spotifyモデルを参考に、プロダクトを「注文体験」「配達マッチング」「レストラン管理」「決済・売上」の4ミッションに分解。それぞれに開発・デザイン・QAを配置した8〜10人のSquadを編成した。
導入6か月後、リリースサイクルは2週間に1回に短縮。調整会議は週3時間まで減った。Squadメンバーの当事者意識スコア（社内サーベイ）は5段階中3.1 → 4.4に改善している。
従業員250人のHR Tech企業。5つのプロダクトラインを持ち、各プロダクトチームはすでにSquad的な構成で動いていた。しかし、チームごとにコーディング規約もテスト方針もバラバラで、あるSquadのコードレビュー通過率が45%、別のSquadでは**88%**と品質格差が深刻だった。
そこでフロントエンド・バックエンド・SRE・デザインの4つのChapterを設置。Chapter内で隔週の技術共有会を実施し、共通のコーディングガイドラインとレビュー基準を策定した。
| 指標 | 導入前 | 導入8か月後 |
|---|---|---|
| コードレビュー通過率（全社平均） | 62% | 81% |
| 本番障害件数（月平均） | 4.2件 | 1.8件 |
| 技術負債対応に充てる時間割合 | 8% | 22% |
Chapterリーダーが評価面談も担うようにしたことで、「誰に相談すればいいかわからない」という不満がエンゲージメント調査から消えた。
従業員1,800人の地方銀行。経営層の号令でDX推進室を立ち上げたものの、推進室12人だけが奮闘し、現場の営業店舗や事務センターとの温度差が問題になっていた。
全社から希望者を募り、「データ活用Guild」「UI/UX Guild」「業務自動化Guild」の3つを発足。各Guildに推進室メンバーが2〜3人入り、残りは営業・融資・総務など現場部門から参加した。月1回のGuild会で小さなプロトタイプを作り、3か月ごとに全社発表会を開催。
初年度の成果として、業務自動化Guildから生まれたRPAが融資審査の書類確認を自動化し、処理時間を1件あたり40分 → 12分に短縮。Guild参加者は発足時の34人から1年後に97人へ拡大し、「DXは推進室だけのもの」という空気が薄れていった。現場発のアイデアが組織を変える、その最初の一歩になった。
やりがちな失敗パターン#
- 形だけSquadを作り、権限を渡さない — 名称をSquadに変えても、意思決定に上長の承認が必要なままでは何も変わらない。「リリース判断をSquad内で完結できるか」が試金石になる
- Chapterを軽視してスキルがサイロ化する — Squadの自律性ばかり強調すると、チームごとに技術スタックや品質基準がバラバラになる。Chapterリーダーにピープルマネジメントの権限と時間を確保すること
- Squadのミッションが曖昧で依存関係だらけ — 「決済もやるし通知もやる」のような広すぎるミッションだと、他Squadとの調整コストが結局増える。1つのSquadが独立してデリバリーできる粒度まで分解する
企業での実践例 — Spotify#
Spotifyモデルは2012年、同社のアジャイルコーチであるHenrik KnibergとAnders Ivarssonがホワイトペーパー「Scaling Agile @ Spotify」として公開したことで広く知られるようになった。当時のSpotifyは従業員約250名で、スクラムをベースにした開発体制を敷いていたが、チーム数の増加に伴い「スクラムの儀式（セレモニー）に縛られて自律性が下がる」問題に直面していた。そこでスクラムの枠組みを緩め、Squad単位でプロセスを自由に選べる設計に移行した。
ただし、Spotify自身がこのモデルの運用で課題にも直面している点は押さえておく必要がある。Kniberg自身が後に「あのホワイトペーパーは2012年時点のスナップショットであり、Spotifyは常に組織を進化させ続けている」と明言している。実際にSpotify社内では、Chapterリーダーの役割が曖昧になりピープルマネジメントが手薄になった時期や、Squad間の依存関係が想定以上に複雑化してTribeレベルの調整コストが増大した時期があった。2020年頃にはSquad/Tribe構造を残しつつも、より明確なプロダクト領域の定義とエンジニアリングマネージャーの権限強化を行っている。「Spotifyモデル」をそのまま模倣するのではなく、自社の文脈で継続的に改変していくことの重要性を、Spotify自身の歴史が示している。
まとめ#
Spotifyモデルは、Squadでミッション単位の自律性を確保しつつ、ChapterとGuildの横串で知見の断絶を防ぐ組織設計パターン。そのまま模倣するのではなく、自社の規模・文化・プロダクト特性に合わせてカスタマイズすることが前提になる。導入の鍵は「名前を変える」ことではなく「権限を委譲する」こと。まずは1つのTribe規模で小さく試し、うまくいった仕組みを横展開するのが現実的な進め方になる。