Web系企業/事業会社への最高の反面教師: "Spotify's Failed #SquadGoals"を読んで
はじめに
以前Scrum@Scaleについて@tyantya41717651さん、@zakky_devさんとディスカッションしましたが、先日お二人と、大規模アジャイルフレームワークであるSpotifyモデルと先日公開された失敗記事(「Spotifyは "Spotifyモデル "を使っていない(Spotify's Failed #SquadGoals)」)についてディスカッションしたのでブログにまとめました。*1
Spotifyモデルと取り上げた理由
今回Spotifyモデルの詳しい解説をしませんので、知りたい方は以下の記事を参照していただければ幸いです。
ただし、今回Spotifyモデルを初めて読んだ3人が驚いたのは、「スクワッド」や「ギルド」というキラキラの衣装を取り払うと、驚くべきほどのオーソドックスなマトリクス型組織が浮かび上がることです。日の下に新しきものなし。ただし、これが「スクラム」や「アジャイルマニフェスト」など使い古されたワードに退屈していた方には新鮮に映ったことも同時に想像ができます。
そして、2012年時点でSpotify社自体がSpotifyモデルを既に利用していなかったことも有名です。
にも関わらず今回なぜSpotifyモデルを取り上げたかというと、自分たちが観察するところ、とりわけWeb系企業/事業会社で無自覚にSpotifyモデルと同じような形で組織運営をしている所が多いからです。
つまり、Spotifyモデルとその失敗をおさらいすることは、今でもWeb系企業/事業会社でアジャイル組織運営をされている方の悩みに直結するものが多いと思い、何かの参考になればとブログにまとめました。
モデルの失敗ではなく、ヒトの失敗
まずはじめに、とても重要なポイントは、"Spotify"の失敗とは「Spotifyモデル」の失敗ではなく、Spotify社の中のヒトがSpotifyモデルにうまく適用できなかった、あるいは、ヒトに適さないモデルを適用しようとした、ということが失敗の要因であるということです。*2
Spotifyモデルに限らず、Scrum@ScaleであれLeSSであれSAFeであれ、私たちは問題解決をフレームワークや組織構造に求めがちなところがありますが、実際にフレームワークや組織構造を機能させて問題を解決するのは、あくまで運用するヒトの地道な努力であることを忘れてはなりません。*3
扱える以上の自由や権限を与えた悲劇
さて、前項でSpotify社の中のヒトがSpotifyモデルにうまく適用できなかった、と書きましたが、実際に何が起こったかを一言にまとめると、
「扱える以上の自由や権限を与えた悲劇」
と表現できます。
上記により、Spotifyには様々な悲劇が襲いました。
1. チームへの過剰な権限付与による、サイロ化の加速
2. 自由なプロセスや能力不足による、分隊間協力の困難化
3. 全員での意思決定を追求したことによる、意思決定コストの増大
1. チームへの過剰な権限付与による、サイロ化の加速
Spotifyモデルでの開発チームの単位は分隊(Squads≒スクラムチームみたいなもの)という。分隊とはクロスファンクショナルチームであり、自己組織化されており、それぞれ長期的なミッションを持ち、長い時間プロダクトの一部分を担当するチームのことである。
彼ら自身で自分たちの働き方を決めている。あるチームはスクラムのスプリントを使い、あるチームはカンバンをつかい、あるチームはいろんなアプローチを使っている。
(Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む)
さらに、各分隊毎に「座席やラウンジ、分隊で使える「相談」部屋といったすばらしい職場環境を与えられている。ほとんど全ての壁はホワイトボードとして使える」という充実ぶりだったと言います。
エンジニアだったらうらやましくなる環境ではないでしょうか!?
......しかし、ここからは前職での経験から、まさにこのように各分隊毎に長期的なミッション、働き方を自由に決める権限、そして豊かな職場環境を与えたことが分隊のメンバーの「自分のチームが全てという意識」を加速させたのではと想像します。
さらに紹介記事では、分隊間の依存関係を解決するイベントや、スキルをシェアする支部やギルドの紹介があるのですが、「会社のミッション」の共有についての記述がありません。
会社のミッションの共有が薄いまま、分隊へ長期的なミッションと協力な権限を与える中で、各分隊はまるで一つのスタートアップ企業のように機能していきました。
そして......組織はサイロ化に向かったのです。
2. 分隊のプロセスの自由さや能力不足による、分隊間協力の困難化
1では、分隊への過剰な権限付与が分隊の部分最適を進ませたのではないかと述べてきましたが、分隊間は協力したくてもできないという事情がありました。前項で「分隊は働き方を自由に決められる」と書きましたが、ここが悪い方向に作用したのです。
Spotifyは、チーム（スクワッド）の横断的なコラボレーションのための共通のプロセスを定義していませんでした。すべてのチームに独自の働き方を認めることは、各チーム同士がコラボレーションを行う際にそれぞれ異なる関わり方が必要になることを意味していました。組織全体の生産性が低下していました。
(Spotifyは "Spotifyモデル "を使っていない)
つまり、各分隊毎に自由なプロセスを定義していったので、お互いにどう協力していいかわからなかったのです。それは全く異なる技術スタックのコンポーネントを連携をさせるような困難さに例えられます。
......共通APIがあればいいじゃないかって？
もちろんそうなのですが、共通APIにあたる「プロセスの問題を効果的に議論するための共通言語」について人々は「それらを解決するための教育、パフォーマンスを評価するための経験を欠いていました」ことがさらに悲劇を加速させました。
コラボレーションは知識と実践を必要とするスキルです。マネジャーは、メンバーがアジャイルプラクティスを良く理解していると思い込んではいけません
(Spotifyは "Spotifyモデル "を使っていない)
ここで自分は、アジャイルの原則についての基礎的な教育の重要性(守破離)や、能力の低い人ほど自らの能力について高い評価を下すという「ダニング＝クルーガー効果」*4を思い出していました。
もちろん、Spotify社のメンバーをディスりたいわけではなく、とても優秀とだ思われるSpotifyのメンバーでさえそうなのです。
独自のコンセプトを試す前に、最初は「守破離」の「守」を徹底的にやるしかないのではないかということを最近は考えています。
3. 全員での意思決定を追求したことによる、意思決定コストの増大
1,2でSpotifyが、自由なコンセプトの分隊がサイロ化した経緯とその感想について語ってきましたが、さらに3では、リーダー不在のまま意思決定権をメンバーに移譲したことによる悲劇について記載します。
分隊には公式に指定されたリーダーががいるわけではない。しかし、プロダクトオーナーは1名いる。プロダクトオーナーはチームによって完了されていく作業の優先順位づけに責任をもっているが、チームがどのように作業するかまでは関与しない。
(Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む)
分隊にはリーダーがいないので、実質はプロダクトオーナーの権限が優先されると思いきや、プロダクトオーナーは「チーム内で意見の相違が生じた」場合、「全てのエンジニア」と交渉し、「エンジニアが合意に達することができなかった」場合、「チームにいるエンジニアの専門分野の数だけ、エンジニアマネージャー（チャプターリード）にエスカレーションする必要」という途轍もない面倒なプロセスを踏まなければなりませんでした。
これもまた「扱える以上の自由や権限を与えた悲劇」の一つ、つまりメンバーの意思決定や合意能力が低い状態で、最終的な意思決定の責任者が不在なまま、メンバーに意思決定権を移譲したために発生した悲劇と考えられます。
まとめ
今回Spotifyモデルとその失敗を読んで強く思ったのは、どんなに良さそうなフレームワークやモデルは組織や人などのコンテキストに応じて適用すべきだ、ということです。
とはいえ、これからも、自律心が高く、権限に与えないと退職してしまうメンバーが多いWeb系企業/事業会社がSpotifyモデルを意図せずに採用する場合が多いと思います。
その際に起こりがちな落とし穴を、ここまで露骨に誠実に描いてくれたJeremiah Leeに本当に感謝です。
他にも様々な学びが満載なので、もし良ければ元のブログの方にも是非あたってみてください!!
今回長くなってしまいましたが、最後までお読みいただき、ありがとうございます!!
*1:前回のScrum@Scaleの記事についてはこちらを参照norihiko-saito-1219.hatenablog.com
*2:問題を安易に組織構造で解決しようとする危険性については、沼上 幹の『組織デザイン』を参照 www.amazon.co.jp
*3:ただし、他の大規模アジャイルフレームワークに比べてSpotifyモデルは適用体験が少ないため、脆弱なフレームワークという感覚があります。例えばLeSSではチーム毎にPOがいることが局所最適化に繋がる危険性が指摘されています scrummaster.jp
*5: 権限移譲については、Management3.0の7つのレベルのデリゲーションやリチャード・ハックマンの権限マトリクスなどが参考になりますwww.ryuzee.comhttps://www.infoq.com/jp/articles/what-are-self-organising-teams/
