"ユニコーン企業のひみつ"を読んで
はじめに
"ユニコーン企業のひみつ" という本を読みました。
この本は、僕がブログなどでも何度か触れているSpotifyで用いられている組織体系についての話が扱われている本です。
SpotifyでAgile Coachを務めたJonathan Rasmussonによる本です。
原書のCompeting with Unicornsという本があるのですが、つまみ読みしている程度だったので、個人的に良いタイミングで翻訳本が出てくれました。感謝です。
原書
早速この本を読んでみて、色々と思うところがあったので久しぶりのNoteを書きました。
ここでは本の中でいくつかの気になる内容について触れていますが、決して網羅的な内容になっている訳ではないので、もしもこのブログを読んで興味を持つような箇所がありましたら、是非ユニコーン企業のひみつを読んでみて下さい！非常に読みやすい本だと思います。
Spotifyに関する資料について
この本でも、あとがきの"There is no Spotify model"のところで触れられていますが、
Spotifyの開発組織に関する公式の文書と言えば、
2012年に公開された
Scaling Agile@Spotify
と、
2019年に公開された(2014年次の資料)
や、QConで発表された
位で、他は諸説色々な噂話みたいな感じになってしまいましたが、本書は実態について信頼できる、新たな公式資料という感じです。
ただ、結局ここで触れられている組織体系もある程度昔のものですし、このやり方を推奨しているわけでもないので、結局はこれを参考しつつ、自分たちのスタイルを作るべきというのは変わらないです。
ミッションとプロジェクト / プロジェクト駆動とプロダクト駆動
本書では、Squadはトップダウン的に落ちてきたプロジェクトをハンドリングするのではなく、各Squadでミッションを定義し、その実現に向かって主体的に動いていくものと書かれています。
プロジェクトの問題点として、下記の点があげられていました。
1.期間があまりにも短い
-> 本来、リリースは終わりではなく、始まりであるはずなのに、プロジェクトにすることによって、リリースが一つの終わりのようになってしまう点。プロジェクトには多くの場合反復的な改善が含まれない点。
2.フィードバックの機会がない
-> 上記と似ているが、反復を想定しているものではない為、リリースまでの期間が長くなればなるほどフィードバックを受けるタイミングが遅くなる点。
3.プロジェクトはあまりにも融通がきかない / プロジェクトは力を奪う
-> ゴールに向かって突き進むものになる。途中で、そのものの価値や存在に疑念を抱いたとしても引き返すことが非常に難しい点。
4.プロジェクトは間違ったことにフォーカスしうる
-> プロジェクトは納期や予算にフォーカスする。それよりも仕事そのものや、インパクトを重視するべきだ、という主張。
それに対してミッションは、抽象度が高めの目標であり、
- チームの仕事の方向づけ
- 目的の共有
- 長期的な視野
をチームに与え、かつ、その達成の方法はチームに委ねられるものであるとあります。
実際にSpotifyのSquadが掲げるミッションの例として、
- 新しい音楽を簡単に見つけられるようにする
- リビングルームを制する
- 朝の通勤のお供になる
などがあったと書かれています。
Squadはこのミッションを達成する為のHowを考え、自律して、自走していくということです。そして、そのHowの部分はSquadに委ねられているということです。
多くの人が顧客/プロダクトドリブンでミッションベースでやっていくことのメリットは感じる一方で、そういうタスクばかりではない、とも思う方もいると思います。そこでカンパニーベットという概念が登場します。
カンパニーベット
ミッション駆動は素晴らしいが、全社的な取り組みや大きな物事を成し遂げたい時には、足並みを揃えるのが非常に難しいです。カンパニーベットは会社が取り組むべき重要事項を終わらせたい順に並べたリストです。本では、全社リソースの30%は常にカンパニーベットに取り組んでいる状態にしておく。と書かれています。この割合自体は会社のフェーズや状況に応じて調整すれば良い、ということだと思います。
ある一時期のSpotifyのカンパニーベットの例としてはこんな感じだったそうです。(例を載せてくれるのまじでありがたい。)
- Sony Playstation <-これに貢献できる人はこれやる
- Google Chromecast <- そうでなければこれ
- 日本上陸
- GDPR
- 上場準備
なので、上の図の様にSquad、あるいはSquadの各メンバーは、リソースの30%を上記のCompany Betに注ぎます。もちろん内容によって、貢献できるもの、貢献できないものがあるので、Company Betがはまらないメンバーがいれば、引き続きミッションの達成に注力します。
カンパニーベットは当然複数のSquadを跨ったプロジェクトになることも多いので、コミュニケーションの連携や定期的な状況の確認などが大切になります。
そこで、Road Managerと呼ばれるカンパニーベットのExecutionを責務とする専任のマネージャがいるとのこと。さらっと書いてあったが、
GoogleやFacebookではこの役割の人をプロダクトマネージャと呼ぶ
の一文が結構気になっています。
カンパニーベットとミッション駆動の2つをうまく組み合わせて、戦略とプランニングを同時に進めていきます。
そして、本では、あくまで時間の使い方の決定権はSquadに委ねる、ということが書いてある。今回の記事では触れていないが(もしよかったらこちらの記事をみてください！)、Squadの一番の目的はAutonomyなので、そのAutonomyは例えカンパニーベットがあっても揺らぐことはない、ということを念押ししている。とはいえ、カンパニーベットはその特性から期限や見積もりが要求されるものも多い。実際に上記のSony Playstationとの連携のプロジェクトではそのような事態があり、経営陣とSquadでの議論とストーリーが簡潔に書かれています。
誰と仕事するのか、誰の為の機能なのか
Spotify, Amazon, Google, Facebookとあるが、基本的にはtoCに向いているプロダクトが中心だと感じています。もちろんtoBが絡んでくる開発プロジェクト自体も多く存在し、本書でも、Sonyとの連携時の経営陣とSquad内でのやりとりについて触れられていますが、正直このケーススタディはもっとほしかったと率直に感じました笑
ここで書かれているストーリーは、SquadのAutonomyを表現する一例として書かれているように感じましたが、ここで書かれている話は、結果的にうまくいったケースの1例なので、ケーススタディとして扱うには正直難しいと感じました。実際にはすごく多くの数の、悩ましい問題があるはずです。
一方で、SquadのAutonomyを会社として、組織として尊重していくとはこういうことだよということを伝えたいんだなと感じました。
考えていること
これは会社の事業やプロダクトの特性や、組織、フェーズにもよりますが、
1.カンパニーベットというと少し大袈裟な気もするが、やっておきたいと思っていることがそれなりにある。(これは以下に減らせるか、正しく順序をつけられるか、という話かもしれない)
2.か、外部のステークホルダーがプロダクトの特性上多く、スケジュールや進捗が必要になるベット※の割合や数が多い(一方で、カンパニーベットは大きなカンパニーベットを同時にやることをなるべく避ける、と書いてあり、たしかにミッション駆動とカンパニーベットとのバランスの取り方だとそうなるのはわかるが、、となっている)
※みたいなベットがSquadの中で自然と決断され、やっていることであれば良いのか、どうなんだろう、ということを考えている。
toB向けのSaaSを展開している企業で、クロスファンクショナルチームに取り組んでいる会社とかの事例とかがあれば、是非お話したり、議論したりしてみたいです！
この記事が気に入ったらサポートをしてみませんか？