SpotifyのSquadチームモデルは失敗だった
(jeremiahlee.com)<p>「Spotify自身も『the Spotify model』を使っていない。あなたも使わないでください。」<br />
2012年に有名になったSpotifyの「Scaling Agile」ホワイトペーパーは、彼らの希望を示したものにすぎず、完全には実装されなかった。<br />
ホワイトペーパーは現実とは異なっていたが、採用には役立ったためそのまま残され、筆者は退職後にこれを正すため記録を残した。<br />
そのモデルの何が間違っていたのか、Spotifyの失敗から何を学べるのか、そして代わりに推奨するモデルについて詳しく書かれた記事。<br />
<br />
このホワイトペーパーの共同著者やSpotifyのアジャイルコーチたちは、以前から社外の人にこれを真似しないよう話していたことがある。<br />
「私たちがホワイトペーパーを書いた時点でも、私たちはそれをやっていなかった。部分的な野心と推測にすぎなかった。人々は実際には存在しないものを苦労して追いかけていた」<br />
<br />
なぜうまく機能しなかったのか？<br />
<br />
1. マトリクス管理は間違った問題を解決していた<br />
<br />
フルスタックのアジャイルチームはうまく機能する。だが、マトリクス型の管理はさらに多くの問題を生み出した。<br />
→ Spotifyのチームは長く続く構造だったため、別チームへ移る際にマネージャーを変更しなくてよいという利点はごく限定的だった<br />
→ エンジニアリングマネージャーはキャリア開発レベルの責任しか持たず、対人スキルなどを身につける支援はできなかった<br />
→ 各チームのエンジニアを統括する単一のマネージャーがいなかった。mini-CEOの役割を担っていたプロダクトマネージャーに対して、mini-CTOのような役割を果たす人がいなかった。つまり、技術チームへの支援に責任を持ったり、優先順位を交渉したりする人がいなかった。技術チーム内で意見の不一致が起きると、プロダクトマネージャーがすべてのエンジニアと交渉しなければならなかった。そこで解決しなければ、少なくとも3人以上いるバックエンド／Web／モバイルのエンジニアリングマネージャーと交渉するか、部門のエンジニアリング責任者へエスカレーションすることになった。<br />
<br />
[ Spotifyの失敗から学ぶこと ]<br />
→ プロダクト・デザイン・技術チームでは一般にエンジニアの人数が多いため、エンジニア全体を担当するマネージャーが必要であり、チーム内の意見衝突時にエスカレーションする経路が生まれる<br />
→ プロダクトマネージャーには、技術について議論できる対等なピア（CEOとCTOのような関係）が必要である。 <br />
<br />
2. チームの自律性に依存していた<br />
<br />
会社が小さいうちは、各チームが幅広い仕事を担い、主導権を持つチームがしばしば入れ替わる。 <br />
会社が大きくなると、各チームに重複していた機能は効率化のために新しいチームへ統合される。 <br />
チーム数が増えると主導権が変わる機会は減り、自分たちが解決すべき問題について長期的に考えられるようになる。<br />
<br />
→ Spotifyはチーム間コラボレーションに関する共通プロセスを定義しなかった。各チームがそれぞれ独自の方法で参加したため、組織全体の生産性が低下した。<br />
→ 「Spotifyモデル」は、会社がはるかに小さかった頃に整理されたものだった。本来はその後に続く整理が必要だったが、できなかった。自律性までしか語られず、チーム間コラボレーションの部分は完成しなかった。<br />
<br />
[ Spotifyの失敗から学ぶこと ]<br />
→ 自律性にはアラインメントが必要である。会社の優先順位は経営陣によって定められるべきだ。自律性とは、チームがやりたいことを勝手にやることではない。<br />
→ チーム間コラボレーションのプロセスは必須である。自律性とは、各チームがすべての問題を単独で解決するよう放置することではない。<br />
→ 成功をどう評価するかも経営陣が定めておく必要があり、そうして初めてチーム間コラボレーションの優先順位を決める際に調整できる。 <br />
→ 自律性には責任が伴う。Product Managementは製品価値に責任を負うべきである。各チームには、追加される部分を「完了」させる責任がある。成熟したチームは、ビジネス価値、リスク、学習、そして次のステップに向けた最適な動きを示すことで、自らの独立性を正当化しなければならない。<br />
<br />
「Spotifyでたった一つだけ直したいことを選ぶなら、自律性を強調しすぎるべきではなかったということだ。」 - Spotifyの元アジャイルコーチ、Joakim Sunden<br />
<br />
3. コラボレーションは前提とされた能力にすぎなかった<br />
<br />
Spotifyは各チームが作業方法をコントロールできるようにしていたが、多くの人はアジャイルについて基本的な理解を持っていなかった。 <br />
その結果、各チームはアウトプットを改善するために、プロセス改善を繰り返しながら最適な組み合わせを探す努力をしなければならなかった。 <br />
プロセスの問題や解決方法、成果評価を効率的に行うための共通言語がなかった。実際にはアジャイルですらなく、単なる「Not-Waterfall」だった。<br />
<br />
Spotifyには、各チームに対してプロセス改善を教え提案する「アジャイルコーチ」がいた。意図はよかったが、すべてのチームを支援するにはコーチの数が足りなかった。 <br />
各コーチがチームに割ける時間は、各チームがプロジェクトを完了し成果を評価するところまで支援するには不十分だった。そのため、彼らは何にも責任を負わなかった。<br />
<br />
[ Spotifyの失敗から学ぶこと ]<br />
→ コラボレーションは知識と練習を必要とするスキルである。マネージャーは、人々が既存のアジャイルプラクティスを理解していると想定してはならない。<br />
→ 会社が十分に大きくなれば、各チームにはチーム内で計画を立て、チーム間コラボレーションを可能にするためのサポート組織が必要になる。Program Managementがプランニングプロセスに責任を持つべきである。専任のProgram Managerは、Product ManagerとEngineering Managerがそれぞれの役割を果たしつつ協力するのと同じように、チームが機能するようにしなければならない。 <br />
<br />
4. 神話は変更しにくい<br />
<br />
Agile Scrumがバーンダウンやスプリントといった用語を提示したのは、新しい概念を紹介するにあたって名前が必要だったからだ。 <br />
SpotifyはMissions、Tribe、Squads、Chapter Leadのような新しい言葉を導入したが、これは「何か特別な語を選ばなければならないものを作ったという幻想」を植え付けた。 <br />
<br />
こうした不要な同義語を取り除けば、Spotifyモデルは自律性が多すぎ、管理構造が弱い「Cross-Functional Team」の集まりにすぎない。 <br />
もしSpotifyがこのモデルのアイデアを元の名称で呼んでいたなら、モデルが失敗したとき、それを文化的アイデンティティの変更とは考えず、よりうまく機能する内部プロセスを探すことだと評価できたかもしれない。<br />
<br />
[ Spotifyの失敗から学ぶこと ]<br />
→ ほとんどのビジネスは、維持できるイノベーション領域がいくつかに限られる。内部プロセスのイノベーションが市場で会社を差別化することはほとんどない。過去を研究すれば、ビジネスはイノベーションにより適した領域を見つけられる。<br />
→ 理解の最適化を図ること。組織の生産性を維持するために、構成員が学ばなければならないすべての新しい事柄の価値を評価すべきである。</p><p>*** 代わりにこうしてください。（もちろん近道はありません。）<br />
<br />
Spotifyモデルを探した理由は、おそらく自分たちのチーム構造を作るためでしょう。そこで立ち止まらず、さらに調べてください。<br />
Spotifyよりも長い時間をかけた検証に耐えてきた企業が、より多くの文章を残しています。<br />
<br />
2012年のSpotifyは、大規模組織の中で小規模チームのスピードと俊敏性を維持する方法を見つけられませんでした。<br />
彼らはこの原初的なモデルを超えて、よりよい答えを見つけるために外部へ目を向けました。あなたもそうすべきです。 <br />
<br />
別の働き方についての筆者のおすすめ<br />
<br />
- プロダクト・開発・デザイン組織に200人以上いますか？ 私がFitbitにいたときは「Scaled Agile Framework」がうまく合いました。<br />
- 200人以下なら「Shape Up By Basecamp」をおすすめします。私の次のスタートアップではこの構造を採用するつもりです。<br />
- 「Essential Scrum」と「Team Topologies」を読んでみてください。</p>
4件のコメント