Spotifyモデルを導入した組織で働いて感じたこと

アジャイルをスケーリングする方法の１つに、Spotifyモデルというものがあります。音楽ストリーミングサービスのSpotifyで導入されている組織モデルということから、この名前がついています。アジャイルのカンファレンスなどでも、Spotifyモデルを導入している企業の発表を聞くことがあります。

ただこのSpotifyモデルにはデメリットもあることが指摘されており（あらゆるものにデメリットはありますが）、特に最近 Spotify's Failed #SquadGoals （日本語訳：Spotifyは "Spotifyモデル "を使っていない）という記事が話題になっています。

私自身もSpotifyモデルを導入したITシステム部門で働いた経験があります。その組織では上の記事で指摘された問題点の一部について改善策を適用し、ある面では上手くいきましたが、問題点も残りました。

今回はこの経験に基づいて問題点を考察し、Spotifyモデルに対する私の考え方をまとめてみます。

いきなり結論
Spotifyモデルとはなにか
私が在籍したSpotifyモデル組織
"Spotifyは Spotifyモデルを使っていない" で指摘された問題点
Spotifyモデル組織での経験と問題点の考察
まとめ
関連書籍

いきなり結論

少し長くなるので、結論を先に記載します。

Spotifyモデルを一言で表すと、"かなりプロジェクト型に近いマトリクス型組織"。目新しい何かではなく、複雑に考えすぎないほうが良い。
プロジェクト型組織に近いため、メリット・デメリットともに従来のプロジェクト型組織に対する評価とよく似ている。私が考える一番のデメリットはチームがサイロ化しやすい点。
Spotifyモデルを導入する場合、組織内で情報・知識・意識を共有することを、マネージャーもメンバーも常に心がける必要がある。プロジェクト型組織に近いモデルの性質上、最初にこのような仕組みを構築しても徐々に形骸化しやすい。
モデル、体制、組織構成だけでできることは限られる。それらを構成するメンバーのマインドセットや文化と合わせて作り上げる必要がある。

Spotifyモデルとはなにか

Spotifyモデルの説明は既に多くの記事あるので割愛します。以下を参照してください。

Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む（Spotifyモデル）leantrenches.wordpress.com

私が在籍したSpotifyモデル組織

私が在籍したある企業のITシステム部門にはSpotifyモデルが導入されていました。体制の概要は以下の通りです。

ITシステム部門のメンバー構成は日本に100人程度、中国に200人程度。
サポートする社内のビジネスエリア（人事、財務、購買など）ごとにTribeを構成。
ビジネスエリア内を更に細分化し、その細分化したエリアをSquadが担当。
細分化したエリアに複数システムがある場合、1つのSquadで複数システムを担当。
1つのTribeには3~5個程度のSquadが存在。
Squadの所属メンバーは7~9人程度。
Squadのメンバー構成は日本メンバーと中国メンバーが半々程度。

"Spotifyは Spotifyモデルを使っていない" で指摘された問題点

詳細は元記事を読んで頂くのが良いですが、以下4点の課題が指摘されています。

マトリクス経営は間違った問題を解決した
チームの自律性を重視しすぎた
チーム同士は協力し合えると思い込んでいた
モデルは神話化し、変わることができなくなった

Spotifyモデル組織での経験と問題点の考察

在籍したSpotifyモデル組織での経験をもとに、指摘された問題点について私の考えを述べます。

1. マトリクス経営は間違った問題を解決した

エンジニアリングマネージャー（チャプターリード）は、管理対象者のキャリア開発以上の責任をほとんど持ちませんでした。その場合でも、対人スキルの開発を支援する能力は限定的でした。エンジニアリングマネージャーは、チーム（スクワッド）内の日々の状況に十分に関与することが出来ず、このためチーム内の他の人々を十分に管理したり、チーム内の対立に対処するための独自の行動を取ることが出来ませんでした。

この点は私自身も同様に感じました。Chapter Leaderの権限や作業は非常に小さく、あからさまに言うとあまりやることがなく感じられます。

この問題点について、在籍していた組織では「Chapterをなくす」という解決策を取りました。つまりエンジニアもビジネスアナリストも含め、横の繋がりであるチャプターを組織図上からなくし、Tribe-Squadという単純な組織にしました。

結果として、複数のマネージャーから取得していた承認処理が不要になる、マネージャーは各メンバーが何をしているか把握しやすい、責任者が明確になるなどの効果がありました。但し、私の考えではこれは単なる「プロジェクトの終りが見えないプロジェクト型組織」です。この解決策では、メリット・デメリットとも、プロジェクト型組織の特徴が色濃く出てくると感じます。デメリットについてはSquadのサイロ化を強く感じました（問題点2で記載）。

2. チームの自律性を重視しすぎた

Spotifyは、チーム（スクワッド）の横断的なコラボレーションのための共通のプロセスを定義していませんでした。すべてのチームに独自の働き方を認めることは、各チーム同士がコラボレーションを行う際にそれぞれ異なる関わり方が必要になることを意味していました。組織全体の生産性が低下していました。

ここで書かれているほどはSquadごとに働き方の自由裁量はありませんでしたが、やはり隣のSquadが何をどのようにすすめているか、導入前より分かりにくくなりました。別Tribeの話となると、まるで別部門や別会社のことのように、状況が分かりません。複数のSquadが関与する大きなプロジェクトなどでは、各Squadの情報連携が実施されましたが、普段の作業プロセスにおける改善や技術的挑戦など把握するのが難しくなりました。

加えて、あるビジネスエリアで大きなプロジェクトが発生した場合（例えば購買エリアでパッケージソフトを導入するなど）、ビジネスエリアを超えて人員をサポートさせるということも難しくなりました。各ビジネスエリアごとにTribe/Squad固有のバックログを抱えているため、システム部門全体として最も優先度の高いプロジェクトがあったとしても、メンバーをそのプロジェクトに割り振ることが難しいです。

プロジェクトに単純にメンバーを追加することの効果、是非はあるとしても、システム部門全体として優先度の高いものから開発できているのか疑わしく感じます。部分最適化が進んでしまう可能性があります。

3. チーム同士は協力し合えると思い込んでいた

コラボレーションは知識と実践を必要とするスキルです。マネジャーは、メンバーがアジャイルプラクティスを良く理解していると思い込んではいけません。

SquadやTribeがサイロ化することを防ぐためには、各メンバーが情報・知識・意識を共有することが必要です。私達もGuildやランチセッションなどで情報・知識・意識を共有する試みを続けました。しかし上記でも指摘されているように、アジャイルについての理解、技術的な知識や仕事への思いは人それぞれで、Guildなどの仕組みさえ作ればすべて上手くいく訳ではありませんでした。

一方でマネージャーにも、1. 情報・知識・意識を共有し、2. Squadへできるだけ権限移譲をすすめるという、２つの姿勢が必要です。残念ながらマネージャーの中には、自分しか知らない情報を持つことを力の源と考える方もいたように思います（意識/無意識にかかわらず）。このような姿勢はサイロ化を促進してしまう要因となります。1の共有がないまま、2の権限移譲をすすめることは、誤った判断を招く可能性を高めることになります。

4. モデルは神話化し、変わることができなくなった

ビジネスユニット、部門、チーム、マネージャーは、Spotifyの失敗した方法論に固執してはいけません。彼らはSptifyのモノマネよりも効果的に組織構造の役割と責任を伝えることができるのです。

私が在籍した組織では、Spotifyモデルそのものにはあまり囚われず、改善の土台として扱っていたように感じます。それはChapterを廃止した点からも伺えます。それでも一度構築されたTribe-Squad体制から完全に自由になることは難しいです。

例えば、先進的な技術を活用したプロジェクトを実施するため、高スキルなエンジニアを集めたプロジェクトチームを結成することになりました。1 Squadとしてそのようなエンジニアを集めたチームはないため、複数のSquadからエンジニアを集めてプロジェクトチームとしました。その際でも、体制図上は既存のTribe-Squadがそのまま存在し、このプロジェクトチームはSquadとなりませんでした。

これはモデル自体を有名無実化していくやり方ともいえます。ある意味日本的な対応かもしれません。

まとめ

アジャイルをスケーリングする場合、小規模なチームだからこそ手に入れられた信頼関係と共通の目的意識に基づく適応力向上を、どのように拡大するかがポイントだと考えています。その観点からSpotifyモデルを検討すると、最初に小規模チームを複数構築する点は優れていますが、それらを結合して大きな組織としてのメリットを活かす点には改善の余地が多いと感じます。

この改善点に対する簡単な解決策はありません。ただ私の考えとしては、組織構造やシステム設計自体にこれ以上できることはそれほどなく、その中にいるヒトのマインドセットや価値観（例えば心理的安全性や帰属意識など）がパフォーマンスを左右する要因となると考えています。