Competing with Unicorns: How the World’s Best Companies Ship Software and Work Differently
The Agile Samuraiの作者であり Spotify において Agile Coach と Engineer を努めたJonathan Rasmussonによる本．本書は Unicorn もしくは Tech company がどのようにチームをつくり，組織をスケールさせ，文化を作っているのかについて書いている．タイトルに Unicorn とあり複数の企業を扱ってるように見えるが，基本的には作者の Spotify における体験が基になっており Spotify の話が中心になっている．
なぜ Microservices か?では Microservices の最終ゴールは組織にあると書いた．これは共通の見解（のはず）である一方で，Microservices においてどのような組織構造・チーム構成を作っていくのが良いのかについて具体的な例を基に書かれたものはあまり見たことがない．自分は組織作りにまで関われているわけではないし，専門でもないが，これまでいくかの記事，発表を見てきた中でも Spotify はこれを非常にうまくやっているように感じていた．
Spotify がどのようなチームや組織を作っているかについてはScaling Agile @ Spotifyという 2012 年に公開されたブログが一番有名であると思う．そこではメインのコンセプトである Squad や Tribe，Guild という概念が紹介されている．また 2019 年にはその組織やエンジニアリング文化について紹介する 20 分の動画も公開されており（Spotify Engineering Culture part1・part2）2012 年からのアップデートがわかる．もう一つ自分が感銘を受けたのがBreaking Hierarchy - How Spotify Enables Engineer Decision Makingという QCon New York 2019 の発表で，そこではいかに組織のヒエラルキーをぶっ壊してエンジニアやチームに意思決定を促しているかについて紹介されている．
Competing with Unicorn はこれらをより詳細にまとめた本になる．Squad や Tribe による組織構造や，各 Squad の Autonomous（自律性）を保ちつつ Company bets による Alignment の方法，Productivity への投資やこのような組織における Leadership のあり方などについて詳しく解説されている．
Squad and Tribe
Spotify のような Unicorn ではいかに組織を拡大していくかが大きな課題になる．スケールしつつも Startup のような俊敏さを失わないようにするのはとても難しい．Spotify はこの課題を解決するために Squad，Tribe，Chapter，Guild という組織構造を取り入れている．
まず一番基礎となる単位が Squad である．Squad は 8 人以下のメンバーで構成され，Mission vs. Project で詳しく紹介するようにそれぞれに Mission が与えられ Mini-startup のように動けるように設計されている．Squad は自己組織化されており，何をどのようにつくるかという意思決定や，開発からリリース，運用までなるべく自分たちで完結できるようになっている．Squad が最も重要な単位でありその他の Tribe や Chapter はこれを補助するためだけに存在してる（この辺はTeam topologiesの Team first thinking と同じ）．Squad は CV とかにも書かれているし結構一般的に使われているっぽい．
同様の Mission をもった Squad をまとめたのが Tribe である．例えば，App Integration Squad（Facebook などのアプリケーションとの連携を行なう）や Home Consumer Electronics Squad（家電との連携を行なう）などをまとめて Partner and Platform Eeperience Tribe を構成する．Tribe はDunbar’s Numberを基に 40 人から 150 人で構成され，Squad と同様に Mission を持つ．Tribe の利点は同様の課題を持った Squad をまとめることでアイディアやコードなどを共有しやすくなることにある．自律性を保つために Squad は協力はし合うが依存は少なくしている，Tribe 間は更に依存はなくしている．
Tribe 内部において特定の技術領域などでまとまったのが Chapter である．例えば QA Chapter や Web Engineer Chapter などがある．それぞれの Chapter には Chapter lead がおり採用から給与の決定，キャリアの開発などを担う．Chapter の利点はコミュニケーションを形成して最新の技術やよりよいプラクティスなどをやり取りできるようになる部分である．
Chapter を複数 Tribe 間にまで拡大したのが Guild である．例えば iOS Guild などがある．Chapter と Guild の違いは Guild が基本的には任意のコミュニティであることである．iOS Guild に入るのに iOS 開発者である必要はないし Guild の集まりに毎回必ず出席する必要もない．
以上が基本的な Spotify の組織構造である（組織変更の仕方もとても興味深かった．一般的にはマネージャーなどが裏で話し合って決められるものだがたまに Squad の一覧をオフィスに張り出して後は自分たちで決めさせるということもやるらしい）．
Mission vs. Project
Spotify ではトップダウン的に Project が落とされていくのではなく，各 Squad には Mission が与えられている．Project を避ける理由としては以下を挙げている．
- 短命であること：始まりがあり，終わりがある．終わったらそこで止まってしまう．プロダクト開発では最初のバージョンのリリースは終わりではなくて始まりなのに止まってしまう
- フィードバックの機会がないこと：プロダクト開発とはフィードバックループを回すことこそに意味があるがそれができない
- 厳格すぎること：リソースとやるべきことは予め決められており別のことを挑戦する余地がまったくない
- 考えなくなること：時間や予算という制約によって直感や学びを使うことができなくなる
では Mission とは何かというと，Mission とはハイレベルの達成するべきゴールであり，会社の究極的な目的を達成するために Squad が向かうべき方向性を示すものである．例えば Spotify における Mission には「Make disvoerying new music easy」（新しい音楽の発見を容易にする）だったり「Make listening ot music in the car the best experiece ever」（車内の音楽体験を最高のものにする）というものがある．Mission により各チームを Engage させ（チームに脳を使わせる），目的を与え，長期でものを考えることにより Ownership をもたせることができるようになる．
これらの Mission を達成するために各 Squad は自分たちでやるべきことやその優先度，その方法を自分たちで決定していく．より具体的には各 Squad には Product Manager がいる．Product manager は社全体と Squad を繋ぎ，Squad の方向性を定め，チームとともに戦略やロードマップ，機能定義などを行なう（Product manager は元エンジニアが多くとても Technical である．また強い Leadership と交渉力などが求められる）．
Autonomous vs. Alignment
Spotify の組織で最も重視されているのは Squad の Autonomous（自律性）だと思う．与えられた Mission に対していかに各 Squad が自律して動けるようにするかで組織や仕組みが作られている．Microservices アーキテクチャもそれを達成するための 1 つの方法でしかない（Squad 間のアーキテクチャ的な依存を減らし独立してリリースが行えるようにすることを目的にしている）．
Autonomous（自律性）が重視されている一方で Spotify という会社全体としての Mission と戦略への Aligment も行われている（この原則を「Be autonomous, but don't suboptimize」と言っている）．Autonomous と Alignment は同時には満たせないように思えるが以下の図はそれがどのような状態かをうまく説明している．
まず左下は Alignment もなく Autonomy もない状態である．これは完全に Micromanagement の文化でありハイレベルのゴールはなくただ言われたことをやれという状態．左上の状態は Aligment は高いが Autonomy がない状態である．これはリーダーのコミュニケーション力が高く組織として向かうべき状態や問題が共有されてる．しかしリーダーはそれをどのように解決するべきかまで指示してしまっており自由度がない状態．右下は Alignment はないが Autonomy がある状態である．これはカオスでリーダーは無意味で単純に皆が好き勝手やっている状態... 右上は Alignment と Autonomy がある状態である．これはリーダーは組織として向かうべき状態と解くべき問題を共有できており，かつそれをどのように解決するかを各チームに移譲している状態．Spotify が目指しているのはこの状態である．
具体的に全社的なプロジェクトを回すためには Company bets という仕組みを使っている．Company bets はある Q に会社として達成するべき問題を優先度順で提示するものである．例えば筆者が経験したものとして以下の例が挙げられていた．
- Sony Playstation
- Google Chromecast
- Japan Kaunch
- GDPR
- Prepare for IPO
上の例では Playstation 上で Spotify を使えるようにすることが最も重要なことであり，それに関わる Squads はそれに注力する．もしそこに関連がなければ次の Google Chromecast に注力する..．各 Squad は基本的に自分たちの Mission と Roadmap を持っているが Company bet が提示されたら優先度順に自分たちの Squad に関わるものかを精査して関わるならそれを中心に動く．もしどれにも関わりがなさそうであれば基本的に自分たちの roadmap に従って動くことになっている．以下の図がわかりやすい．全社の 30%くらいが Company bets に動いているらしい．
Company bets の提示の方法としては DIBB というフレームワークを使っている．DIBB は Data，Insight，Belief，Bet の頭文字をとったものである．Data は数字による現状の状態（事実），Insight はそこから得られる学びや結論，Belief はそこから導き出される仮説，そして Bet はそれに基づくやるべきことを示す．以下は１つの例．Spotify はこれを意思決定と議論に使っている．
面白かったのは一番最初の Company bets を始めたときに 65 くらいの Bets が出てきたという話... これは自分も昔大量の Backlog を提示していたことがあるので分かる...と思って読んでいた．No と言うのが Lead の仕事であり，やるべきことを絞り本当に集中するべきことを提示しないといけない．
Conclusion
他にも開発者の Productivity を改善することに注力する Squad がいることや，Feature flag と Release train によるリリースの方法，Data に基づく意思決定の方法，文化の重要性とその育て方などが語られており面白かった．他にも Spotify のこの文化がスウェーデン人（Spotify はスウェーデン発）的なコンセンサスのとり方やボトムアップの精神などからきているという話はかなり興味深かった．
とても学びがあったが以下は意識しておきたい．
So take these models and ideas. Use them as inspiration for how others are working. But remember to adapt, embrace, and make them your own. While the underlying principles will always hold, implementing them at your place of work will require you to tweak and adapt.