Spotify’s Failed #SquadGoalsを和訳してみました。

Spotifyは "Spotifyモデル "を使っていない。そして、あなたもそうすべきです。

スタートアップカルチャーの魅力の中でも、小規模なチームのスピードとアジリティに勝るものはありません。が、企業が成長していく中でこの感覚を維持することは困難です。2012年、Spotifyは新しい働き方を発表し、スピードとアジリティを理解したことを示唆しました。私が2017年にストックホルム本社のプロダクトマネジメント職の面接を受けたとき、Spotify Modelを実際に目の当たりにして興奮しました。しかし、最初の面接の前に採用担当者の言葉に私は驚きました。

彼女は私に、Spotifyがアジャイルなユートピアになることを期待しないようにと注意を促したのです。私が入社したのは、Spotifyが1年半の間に3倍の3,000人の規模になった後でした。私は、有名なスクワッドモデルが単なる野心的な取り組みに過ぎず、フルに実装されたものではないことを知りました。私は、会社のリーダーが徐々にトラディショナルな管理体制に移行していく中で、組織が混乱していくのを目の当たりにしました。

同僚に、なぜコンテンツの現実に合わせて削除されなかったり更新されなかったのかと尋ねたときも、良い答えは返ってきませんでした。多くの人は皮肉にも、その投稿はリクルートに最適だと思っていました。私はもうSpotifyでは働いていないので、歴史を正しく伝えるために私の経験を共有しています。SpotifyのスクワッドモデルはSpotifyを失敗させました。あなたの会社も失敗するでしょう。

しかし、私の言葉を鵜呑みにする必要はありません
Spotify Modelホワイトペーパーの共著者や、Spotifyで働いていた複数のアジャイルコーチは、何年も前から（Spotify Modelを）コピーないよう言い続けてきました。

しかし残念ながら、人々が「信じたい」と思うアイデアは速く広く伝わる一方で、真実は伝わらないものなのです。"それ（Spotify Model）を書いた時点ですでに、私たちはSpotify Modelを採用していませんでした。それは単なる野心の一部であり、その近似に過ぎませんでした。人々は実在しないものをコピーするのに苦労してたことになります"
-Joakim Sundén, Spotify 2011-20174年アジャイルコーチ

私たちがやっていることを見て、それがコピー可能で実践可能なフレームワークだと思っている人を見ると、私は心配になります。...私たちは今、自分たちにも問題があることを必死で訴えようとしています。すべてが『ピカピカで、すべてがうまく機能していて、すべてのチームが超絶に素晴らしい』というわけではありません。
-Andres Ivarsson、Spotify：ホワイトペーパーの共著者

Spotify Modelの要約
30分以内にオリジナルのホワイトペーパー（日本語版はこちら）読んでみることもできますし、慣れてきたら飛ばし読みすることももできます。

ここでは簡単にまとめてみましょう。Spotifyには、その方がかっこよく聞こえるから（冗談ではなく）という理由で、「スクワッド（Squad＝分隊）」と呼ばれるチームがありました。チームのグループは、「トライブ（Tribe＝部隊）」と呼ばれる部署に編成されていました。各チームは自律的なミニスタートアップであることが意図されており、プロダクトマネージャーが各フィーチャーごとのミニCEOを務めていました。各チームには、さまざまな専門分野を持つデザイナーとソフトウェアエンジニアがいました。その構成は、各チームが、他のチームに頼らずとも、成功のために必要とするすべてのスキルを自チームが持つことを意図していました。

プロダクトマネージャーは伝統的なマネジメント構造を持っていました。チームのプロダクトマネージャーは、その部署のプロダクトディレクター（トライブリード）の配下にありました。デザイナーについても同様です。しかし、ソフトウェアエンジニアは、そのチーム構造の外で管理されていました。

「チャプターリード 」は、部門間横断で特定の種類のソフトウェア開発技術に特化したソフトウェアエンジニアを管理していました。例えば、部門内のすべてのチームでバックエンドAPIを担当するソフトウェアエンジニアは、すべて1人のマネージャーの配下であり、部門内のAndroidモバイルエンジニアはすべて別のマネージャーの配下となります。その意図は、部門内のチーム間でエンジニアを移動させ、マネージャーを変更することなくビジネス要件を満たすことができるようにすることでした。

うまくいかなかった理由

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

1. マトリクス経営は間違った問題を解決した
「フルスタック」のアジャイルチームはうまくいったが、ソフトウェアエンジニアのマトリクス型マネジメントは、解決した以上に多くの問題をもたらしました。

• Spotifyのチームは比較的長く存続していました。が、他のチームに移ったときにマネージャーを変えなくてもよいというメリットは限定的でした。
• このモデルでは、エンジニアリングマネージャー（チャプターリード）は、管理対象者のキャリア開発以上の責任をほとんど持ちませんでした。その場合でも、対人スキルの開発を支援する能力は限定的でした。エンジニアリングマネージャーは、チーム（スクワッド）内の日々の状況に十分に関与することが出来ず、このためチーム内の他の人々を十分に管理したり、チーム内の対立に対処するための独自の行動を取ることが出来ませんでした。
• チーム（スクワッド）内のエンジニアに責任を持つエンジニアリングマネージャーが一人もいなかったため、プロダクトマネージャーには自分のカウンターパートとなる相手、つまりミニCTO（ミニCEO）の役割を担う人がいませんでした。また、エンジニアリングチームのデリバリー責任者や、その責任者のカウンターとして仕事の優先順位を交渉できる担当者もいませんでした。
• エンジニアリングチーム内で意見の相違が生じた場合、プロダクトマネージャーはチーム内のすべてのエンジニアと交渉する必要がありました。エンジニアが合意に達することができなかった場合、プロダクトマネージャーは、チームにいるエンジニアの専門分野の数だけ、エンジニアマネージャー（チャプターリード）にエスカレーションする必要がありました。バックエンド、ウェブアプリ、モバイルアプリのエンジニアがいるチームには、少なくとも3人のエンジニアリングマネージャーがおり、彼らを巻き込む必要があります。これらのエンジニアリングマネージャーがコンセンサスに達することができない場合、1つのチームの問題は、部門のエンジニアリングディレクターにエスカレーションする必要がありました。

チャプターリード”は個人としての成長を支援するサーバントリーダーです。彼らはどのチームとも一緒に働くことはありません。すべてのチームには直属の上司がいるのですが、上司たちはデリバリーに対する説明責任を一切持っていません。彼らはその責任を取ることはないのです。プロダクトオーナーがチームのマネージャーであることは明白です。

-Spotifyのアジャイルコーチ、Joakim Sundén氏

Spotifyの失敗から学ぶ：

• プロダクトの設計・エンジニアリングチーム（スクワッド）には、通常、デザイナーやプロダクトマネージャーよりも多くのエンジニアが所属しています。チーム内のエンジニアのためのエンジニアリングマネージャーを一人置くことで、チーム内の対立に対する説明責任のあるエスカレーションパスができます。
• プロダクトマネージャーには、自分のカウンターパートとなるエンジニアリングマネージャーが必要なのです。プロダクトマネージャーは、作業の優先順位付けについて説明責任を持つべきであり、エンジニアリングマネージャーは、エンジニアの実行について説明責任を負うべきです。これには、プロダクトマネージャーとの間でスピードと品質のトレードオフを交渉できることも含まれます。

2. チームの自律性を重視しすぎた
企業が小規模な場合、チームは成果を出すために様々な仕事をしなければならず、頻繁にイニシアチブをシフトしなければなりません。企業がスタートアップからスケールアップへと成長していくと、チーム間で重複していた機能は、重複を減らして組織の効率化を図るための専用チームへと移行していきます。チームの数が増えると、チームがイニシアチブをシフトする必要性は頻度が減少します。

これらの変化はいずれも、チームが解決すべき問題について、より深く長期的に考えることを可能にします。しかし、反復作業の高速化が保証されるわけではありません。チームが責任範囲が小さくフォーカスしていくたびに、新たなチーム間の依存関係が生まれてくるのです。

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

SpotifyModelは、Spotifyがもっと小さな会社だった頃に文書化されました。Anders Ivarsson氏によると、このモデルは複数のパートで構成されることになっていたと言います。自律性は最初のバージョンに入りましたが、アラインメントとアカウンタビリティに関する部分は完成しませんでした。

Spotifyの失敗から学ぶ：

• 自律性にはアライメントが必要です。会社の優先順位はリーダーによって定義されなければなりません。自律性とは、チームがやりたいことを何でもできるという意味ではありません。
• チーム間のコラボレーションのためのプロセスを定義する必要があります。自律性とは、すべての問題の自己組織化をチームに任せることを意味するものではありません。
• チーム間の依存関係の優先順位付けを効果的に交渉できるように、成功をどのように評価するかをリーダーが定義しなければなりません。
• 自律性には説明責任が必要です。プロダクトマネジメントは価値に対して説明責任があります。チームには「完了した」インクリメントを提供するための説明責任があります。成熟したチームは、ビジネス価値、リスク、学習、そして最適な次のアクションをすべて明確化する能力をもったとき、初めてその独立性を正当化に主張することができるのです。

"私が別の方法でやるとしたら、自律性は重視しすぎるべきではないと言うでしょう。"

"（自律性を重視しすぎれば）新しいチームができるたびに、彼らは仕事のやり方を再発明しなければならなくなります。もしかしたら、もしかしたらですよ、私たちは「最低限の実行可能なアジリティ」を持つべきかもしれません。そこから始めるのです。そこからオプトアウトするのは自由ですが、人々は常にそこにオプトインしなければならないわけではありません。"

"いつこのプロセスを採用し始めるのかって？おそらく手遅れになったときです。"

—Joakim Sundén, agile coach at Spotify

"ヘンリック・クナイバーグ氏は、大規模な取り組みが苦手な私たちが、今でも大規模な取り組みが苦手であることを話してくれました。"

"働き方に一貫性がないと、人が動きにくくなります。逆に、人が動きにくいということは、働き方に一貫性がない可能性が高いということです。こういった流れは、もはや同じ会社で働いているとは言えないほどにまで強化されていきます。そうなると、このようなおかしなサブカルチャーのために働くことになります。"
-Spotifyのアジャイルコーチ、Jason Yip氏 2015年執筆時

3. チーム同士は協力し合えると思い込んでいた
Spotifyはチームに仕事のやり方を自分達でコントロールできるようにしましたが、多くの人はアジャイルプラクティスの基本的な理解を持っていませんでした。その結果、チームはデリバリーを改善するのに役立つ組み合わせを見つけようとして、プロセスの微調整を繰り返していきました。人々は、プロセスの問題を効果的に議論するための共通言語、それらを解決するための教育、パフォーマンスを評価するための経験を欠いていました。それはまったくアジャイルとは言えないものでした。ウォーターフォールではない、というだけでした。

「アジャイルコーチ」とは、Spotifyがプロセスの改善を教えたり提案したりするためにチームを提供する内部コンサルタントのことでした。善意ではありましたが、すべてのチームを支援するのに十分な数のコーチはいませんでした。コーチがチームと関わる期間は、チームのパフォーマンスを評価するのに十分とは言えませんでした。さらに言えば、彼らは何の説明責任も負っていませんでした。

能力の無い管理はカオスなのです。

—L. David Marquet, Turn the Ship Around!

Spotifyの失敗から学ぶ：

• コラボレーションは知識と実践を必要とするスキルです。マネジャーは、メンバーがアジャイルプラクティスを良く理解していると思い込んではいけません。
• 会社が十分な規模になると、チーム内の計画を促進し、チーム間の協力体制を構築するために、チームには専任のサポートが必要になります。プログラムマネージャーは、計画プロセスに責任を持つことができます。専任のプログラムマネージャーは、専任のプロダクトマネージャーやエンジニアリングマネージャーがそれぞれの能力を活かして行うのと同じような方法でチームを活性化させます。

4. モデルは神話化し、変わることができなくなった
スクラムがバーンダウンやスプリントのような言葉に新しい意味を導入したのは、新しい名前を必要とする新しい概念を導入したからです。Spotifyは、その働き方を説明するために、ミッション、トライブ、スクワッド、ギルド、チャプターリードという語彙を導入しました。それは、そのような特殊な言葉の選択を学ぶのにふさわしい、新しい価値のあるものを創造したかのような錯覚を与えました。しかし、アイデアから不必要な同義語を取り除けば、Spotify Modelは、自律性が高すぎる一方でプアな管理体制を持つクロスファンクショナルなチームの集合体であることがわかります。騙されてはいけません。

Spotifyがこれらのアイデアを元の名前で呼んでいれば、うまく機能する内部プロセスを見つけるためだけの文化的アイデンティティの変更に直面するのではなく、失敗したときにそれをもっと公平に評価することができたかもしれません。

Spotifyの失敗から学ぶ：

• ほとんどの企業にとって、イノベーションを維持できるのはいくつかの領域に限られています。社内プロセスは、市場において企業を差別化する最大のイノベーション領域はではありません。過去を学ぶことで、企業はイノベーションのためのより良い領域を選択することができるようになります。
• 学習のために最適化しましょう。組織の中で生産性を高めるために誰かが新たに学ばなければならないことはすべて、その価値を評価する必要があります。
• ビジネスユニット、部門、チーム、マネージャーは、Spotifyの失敗した方法論に固執してはいけません。彼らはSptifyのモノマネよりも効果的に組織構造の役割と責任を伝えることができるのです。

その代わりにこうしよう(冗談です。迅速な解決策はありません)
あなたがSpotify Modelを見つけたのは、自分のチームをどのように構成するかをいつも考えていたからでしょう。でもここで止まってはいけません。学習を続けてください。長い間試練に耐えてきた企業のリーダーたちは、Spotifyのブログよりもはるかに多くのことを書いています。人間は、人間が存在している限り、どうやって一緒に働くかを考えてきました。工業化時代と情報化時代は制約の一部を変えましたが、組織論を研究している学者たちは、人間が集団で成功するために必要なものについて、時代を超えた真実を発見しています。

結局のところ、2012年のSpotifyは、大規模な組織の中で小さなチームのスピードとアジリティを維持する方法を理解してはいなかったのです。同社は、その名を冠したモデルを超えて進化し、より良い答えを見つけるために自分自身の外に目を向けました。

あなたもそうすべきです。