Spotifyの組織モデルは真似すべき？

Martin Fowlerのサイトを見ていたら、さらっと「広く知られているSpotifyモデル」なんて言葉が出てきて、初耳だったので色々と調べてみた。

How to manage a program in a product-mode organization

It now employs around 200 people in its product division and the organizational structure is similar to the widely publicized Spotify model with squads and tribes aligned to the underlying modularized product architecture.

Martin Fowlerのサイトは架空の会社を例に出しているが、この会社が使っているのがSpotifyモデル。

Spotify - Wikipedia

An article was written in the scholarly journal IEEE Software in February 2019 outlining Spotify's strategy to assist its engineers in software development across geographically disparate offices and teams. The organizational framework supporting Spotify's software development is extensive, grouping their employees first into "tribes", which are composed of between 30 and 200 engineers each, with a clear mission, set of principles and a senior leader.

Wikipediaによると、Spotifyの組織モデルはIEEEのジャーナルにも掲載されていて、missionとprinciple、そしてsenior leaderによって率いられる30〜200人のtribe（部族）を構成する。

Within each tribe are smaller groups called squads and chapters: squads are meant to feel like mini start-ups facilitating creativity by including cross-functional roles, whereas chapters share the same manager and are meant to be focused on personal growth and skills development by discussing shared challenges.

tribeの下にはsquadとchapterがある。squadはcross-functionalとすることで小さなスタートアップのように創造性を発揮することを意図している。一方でchapterは同じマネージャの下で、チャレンジを共有することで個人的な成長やスキル開発を意図している。

Bridging these groups is a concept called a "guild", which is made up of employees with similar skills and interests, hoping to share their coding experiences and knowledge. Guilds are different from the other groups in that they are voluntary and not restricted to each geographical office whereas the others are physically separate.

さらにguildという概念もある。これは同様のスキルや興味を持つ従業員がコーディングの経験や知識を共有するために構成される。squadやchapterが物理的に別々なのに対し、guildは地域的にどこにいるかに制限されない。

How to Build Your Own “Spotify Model”

Another two years have passed and the company now has 15 million customers. The engineering team has tripled in size to 300 people. A challenge that has been top of mind for a while now is, “With 30 teams, how do we make sure we build a castle that makes sense to the customer, instead of a pile of 30 bricks that nobody likes?”

アジャイル組織のコンサルティングをしているThe ReadyはSpotifyの組織を長年、ウォッチしている。Spotifyの課題は「30のチームが、誰も望まないレンガの山を気づくのではなく、顧客にとって意味のある城を気づくにはどうすればいいか」ということだった。エンジニアが300人になった2013年にtribe、squad、chapter、guildという組織体制に着手した。

Some recent examples: implementing SOX compliance to enable the IPO, keeping up with new privacy laws and moving all infrastructure into the Google Cloud. Also, the lack of focus on architecture and technical standards has made it challenging to scale the platform to support its growing user base.

2018年にはIPOに向け、SOXアライアンスに適合させ、新しいプライバシー法に対応、そしてGoogle Cloudにすべてのインフラを移行した。アーキテクチャーや技術標準の中央管理が書けている中、ユーザ規模が成長に合わせてプラットフォームのスケーリングをするのはチャレンジングだった。

Implementing these initiatives top-down wouldn’t work in Spotify’s culture. A team can simply say “I don’t want to do it” and would need to be seduced to give these priority.

現在のSpotifyでは、トップダウンでは動かない。チームは、自分のやりたくないことはやらない。もしやらせるなら、それなりのプライオリティを示さなければいけない。

AppleやGoogleがモバイルOSという優位性を持っているにも関わらず、何も持っていないSpotifyが躍進を続ける秘密は、その組織論にあるのだと思う人もいるかもしれない。The ReadyのJurriaan Kamerは「時間が立たないとSpotifyの組織がうまくいくかどうかわからない」と言い、Spotifyの組織モデルをそのまま適用するのではなく、組織ごとの特性に合わせるべきだと言っている。