「Spotifyは最早Spotifyモデルを使っていない」「Spotifyモデルは失敗だった」というのは一定の定説として流布しています（ 参考文献2、参考文献3）。Spotifyモデルがうまくいかなかった原因として、一般的には、チームの強すぎる自律性による組織全体の生産性低下、マトリクス型組織によるマネジメント不全などが挙げられます。

ここで、Spotifyモデルでは公式な組織としてスクワッドやチャプターがありますが、Spotifyモデル内でもより形式ばらない非公式な組織として存在する、ギルドについてはどうでしょうか。チャプターと異なりマトリクス組織の公式な枠組みからは外れていますし、参考文献においても特に失敗の原因として挙げられることはないように思います。

画像出典：Henrik and Anders (2012)

Spotifyのホワイトペーパーでは、ギルドについては以下のように触れられてます。

• スクワッドの自律性を犠牲にせず、会社をつなげ、スケールメリットを与えるもの
• 関心に基づくコミュニティであり、知識、ツール、コード、慣習などを共有したいと考えている人々のグループ

Spotifyモデルを解説した書籍「ユニコーン企業のひみつ」(Jonathan (2021)) では以下のように触れられています。

• 「同じ専門分野に興味のあるメンバーからなるグループで、組織を横断して形成される」（p.65）
• 「ギルドの役割としてさらに重要な点は、ギルドがメンバーに学習と成長への道のりを与えていること」（p.66）

「エンジニアリングマネージャーのしごと」(James (2022)) では以下のように触れられています。

• 「ギルドはサイロを防ぐ簡単で強力な方法」(p.256)
• ギルドを作るのが良い選択肢になるのは、チームが車輪の再発明をしている時、チームの技術選択が組織全体から見て乖離し始めている時、設計・互換性・速度などの観点からコードのマージ時に予想外のことが起こっている時、エンジニアが自身の仕事と他のチームの仕事とがつながっていないと感じている時（p.257）

複数のプロダクトを複数のチームで、またはひとつのプロダクトを複数のチームで開発している場合は、チームを横断したつながりを意図して作らなければ、容易にチームがサイロ化します。これは、車輪の再発明が行われる、知識の共有がなされない、など組織のスケールメリットを十分に活かせていない状態です。

チームを横断して同じ分野に興味を持つメンバーが集まり情報を交換することは、スケールメリットを得る機会を提供し、またメンバーの成長の機会も提供します。これがギルドを作ることの意義であり、今もって有効であると考えます。Spotifyモデル自体は失敗したのかもしれませんが、Spotifyモデルに内包されていたギルドという考え方には今も価値がありそうです。

References

1. Henrik Kniberg, Anders Ivarsson, (2012), “Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds”
2. Jeremiah Lee, (2020), “Failed #SquadGoals Spotify doesn’t use “the Spotify model” and neither should you.”, retrieved from https://www.jeremiahlee.com/posts/failed-squad-goals/ （最終アクセス日：2025年10月29日）
3. mtx2s, (2025), “チームの自律性を重んじるだけでは組織がうまく回らない / 「Spotify’s Failed #SquadGoals」を読み解く”, retrieved from https://mtx2s.hatenablog.com/entry/2025/10/02/201310 （最終アクセス日：2025年10月29日）
4. Jonathan Rasmusson, (2021), “ユニコーン企業のひみつ Spotifyで学んだソフトウェアづくりと働き方”, オライリー・ジャパン
5. James Stanier, (2022), エンジニアリングマネージャーのしごと チームが必要とするマネージャーになる方法, オライリー・ジャパン