スマートキャンプでエンジニアをしている瀧川です。
今回、4/26に発売になりました『ユニコーン企業のひみつ ―Spotify で学んだソフトウェアづくりと働き方』を、翻訳者様のご厚意で献本いただいたのでそちらのレビューを書かせていただこうと思います！
(翻訳いただいた島田様、角谷様ありがとうございます🙏)
🦄 テック企業のみなさま、テックブログの記事の候補に一冊いかがでしょうか!!!q 🙏 » 🦄 書籍『ユニコーン企業のひみつ』を貴社テックブログでレビューしていただける企業さまを募集します https://t.co/TdfL58TwpS
— Kakutani Shintaro (@kakutani) 2021年4月7日
今回の企画に手を挙げさせていただいた背景として、ちょうどここ最近組織のスケーラビリティに課題を感じ、マネジメントに関心を持っていたことがあります。
私は自分自身が俗に言うフルスタックエンジニアとして最前線でなんでもアウトプットし、その背中を見せることでメンバーも活性化し組織としても成長するとずっと考えてきました(昔ながらの職人みたいですね)。
しかし最近になってそれが逆に組織のスケールを阻害しているのでは？もっと俯瞰したときに良い方法があるのでは？と考えるようになりました。
そんなときに件のTweetを拝見し、それに対する一つのヒントとして、大きな成功を収めたSpotifyモデルは参考になるのではと思い反射的に手を挙げていました。
そういった背景の人間が読んで感じた、本書に書いていないこと、すなわち自分たちで考える必要があることについてツラツラと書かせていただこうと思います。
様々な感想や考察を生む良書だと思いますので、すでに興味を持たれている方は、まずご自身でも手に取っていただき、読了後に再度本記事を見るとより楽しめるかなと思います！
どんな本なのか
名著と名高い『アジャイルサムライ−達人開発者への道−』を執筆されたJonathan Rasmussonが、自身が(元)ユニコーン企業であるSpotifyでアジャイルコーチ・エンジニアをする中で経験した、スタートアップの良さを失うことなく組織をスケールするノウハウ(俗に言うSpotifyモデル)についてまとめている著書となっています。
Spotifyモデルとは、スクワッド、トライブ、チャプター、ギルドといった組織体系や全社で進むべき道を示すカンパニーベットといった要素を定義しそれらが協調しあうことで、自己組織化・スケーラビリティが獲得されるといったモデルになっており、それらを実現するためのヒントが作者の経験則など元にまとめられています。
用語
- スクワッド
- 共通のミッションを負った職能横断の少人数チーム
- トライブ
- スクワッドをドメインでまとめたグループ
- チャプター
- トライブ内の同じ専門性を持ったメンバーのグループ
- ギルド
- 同じ専門分野に興味のあるメンバーのグループ（トライブ内などの制限なし）
- カンパニーベット
- 会社が取り組みたい重要事項を優先度順に並べたもの
書いていないこと
書いてある内容についてはたくさんのブログなどで取り上げられているかと思うので、本記事では自身を取り巻く環境と照らし合わせたときに疑問に思ったことや、考えたことを書いていこうと思います。
本書内で取り上げられている言葉の定義についても、本記事では詳しく説明しないので、本を手にとっていただくか、Spotifyモデルについて調べていただければと思います。
スクワッドのミッションはどのように決定するか
スクワッドは必ずミッションを負い、そのミッションに到達する手段について裁量を与えることが大切だと挙げられていました。
ではスクワッドのミッションとはどのように決定するのでしょうか？
本書では経営リーダーが決めると書かれていました。
一方で経営リーダーが決める指標として、カンパニーベットもあります。
この2つのレベルの指標をどのように決めるべきなのかに難しさを感じました。
またスクワッドのミッションはカンパニーベットより優先されるものだとされており、その点でもどちらに何を据えるか難しいですね。
私見ですが、カンパニーベットとスクワッドのミッションはタイムスパンと粒度が違うのかなと感じました。
一般的には、会社でやりたいことは長期かつ粗い内容、一方でチームのミッションは短期かつ細かい内容になることが多いかと思います。
しかし本書の例などを見ると、どちらかというとカンパニーベットが短期で具体的な内容で決められている印象を受け、これはスクワッドのミッションはカンパニーベットより優先されるという原則を考えるとある程度納得感があるように感じました。
このあたりは非常に重要なテーマで、自社でもいつもモヤモヤしているところなので、引き続き調べてみようと思っています。
余談ですが本書で取り上げられていたロードマネージャーというロールが重要そうだと感じています。
データサイエンティストがスクワッドで活躍する方法
本書の一つのテーマとしてデータサイエンティストの重要性についても書かれており、スクワッドがデータからインサイトを得て意思決定するために、スクワッド内にデータサイエンティストを持つのが良いとされていました。
私を取り巻く環境に目を向けてみると、私が所属するチームは、PdM、プランナー、デザイナー、エンジニアといった職能の違うメンバーが集まった、まさにスクワッドと呼べるものになっており、日頃から施策立案から実装、リリースまでを協力しながら進めています。
そこで私が感じているのが データの定点観測・仮説検証・施策の効果測定 のやりきれていない感です。
チームがミッションを負い、精度高く試行錯誤(イテレーション)するためには、ミッション達成の定義やスピーディなデータ分析を可能にする基盤が必要だと感じています。
ではなぜ必要性を感じているのに、実際私のチームにはデータサイエンティストがチーム内にいないのか。
一概に理由は挙げられないのですが、一つの要素として、データ分析のコストの見積もりにくさがあるのではと考えています。
例えば施策を立てるためにデータ分析をする場合、一つのデータを出して施策が決定することはなく、何度もPdMやプランナーと話しつつデータを出すことを繰り返すと思います。
その繰り返しにどれくらい時間がかかるかわからない、分析した結果なにも得られないかもしれない、そういった不確実性が安定した開発フローを阻害するイメージがあります。
その壁を破りデータサイエンティストが活躍するチームはどうすればできるか。
一つは活躍を信じてBetすること、もう一つはデータ分析基盤のイニシャルコストをしっかりとかけることだと感じています。
例えば一歩踏み込んだデータ分析基盤の工夫だと、分析する際に頻出するドメインロジックをすぐに分析に組み込めるようにしたり、新機能開発時に効果測定用のログを漏れなく埋め込むフローを整備するなどがあるかなと思います。
そういったコストをかけることで分析スピードが上がり、現状の開発フローに組み込めるようになるのではと考えています。
余談ですが、実際の取り組みとして近々でLookerの導入を進めており、それを足がかりに理想的な状態を目指しています。
スクワッド間での人の異動をどのように実現するか
トライブ内(スクワッド間)での異動は積極的にすべきだとSpotifyでは考えられていたと言及されていました。
これについても納得感があり、私もミッション達成のために必要なリソースがあれば柔軟にアサインできるべきで、メンバーとしても極力ミッションに共感できるチームに移るのがいいのではと考えています。
ただこれについても実現のためには課題があると思います。
現実的に一番大きい問題は異動時のオーバーヘッドかなと考えています。
実際に弊社でも直近で定期的なチームのメンバー入れ替えにチャレンジしていますが、そこで課題として挙がるのが異動時にそのチームの開発フローに合わせるのにコストがかかるということでした。
例えばリリースまでにどういったチェックが必要か、タスクの詳細をだれとどのように詰めていく必要があるかなどがチーム毎文化として存在するため、それを理解し合わせるのにコストがかかっていました。
(前提として弊社はどのチームもスクラムをベースとしているのですが、定常的な振り返りで改善した結果チームの文化はズレていきます)
そういった状況でどのようにオーバーヘッドを抑えていくか。
ここは現在試行錯誤中ですが、本書に書かれていたチャプターに相当する枠組みと、トライブのリーダーでの振り返りが効くのではないかと考えています。
前者については弊社の現状だと、エンジニアが横軸で参加するイベントをいくつか実施しており、隔週でタスクや取り組みを共有する会、雑談会、ペアプロ会、勉強会などを通じてズレを補正するような動きをはじめています。
後者については訳者のあとがきでもSpotifyモデルの変化として取り上げられていた「TPD Trio」が近いかなと思いますが、リーダー同士で定常的に状況や環境の変化を共有し、お互いに真似できるところを探すことでメンバーの負荷が低くなるフローを模索しています。
ここについては人の入れ替わる間隔など含めて課題が多いので、向き合っていく必要があると感じています。
どうやって企業文化をアップデートしていけばよいか
Spotifyモデルは2012年にアウトプットされたもので、訳者のあとがきで現在はアップデートされ新たな構成要素も存在することが書かれていました。
やはり組織の形態や企業文化には正解やゴールがなく、様々な状況に応じてアップデートしていく必要性があることに納得感がありました。
ただ、どういったプロセスを経てアップデートしていくのか、これは非常に難しいと感じました。
チームの改善であれば当事者で定常的な振り返りなどを通して、大事にすべきものと変えていくものを見極めていくことができますが、企業文化についてはどうでしょうか。
課題も抽象的になると思いますし、解決のためのアクション起こすとしても関連する人や組織が多くなる分、大きなリスクを負う必要が出てくるでしょうし一筋縄ではいかないですよね。
やはりそこを乗り越えてアップデートしていくためには、経営リーダーとしては会社としてのミッションを示す、メンバーとしては密にリーダー層とコミュニケーションを取るといった、本書でも随所に書かれていたことが最低限必要で、そこから少しずつ堅実に改善を進めるしかないのではないかなと感じています。
終わりに
今回献本いただいた『ユニコーン企業のひみつ ―Spotify で学んだソフトウェアづくりと働き方』を読ませていただき、自社の取り組みや自分の思いも含めてレビューを書かせていただきました。
著者のSpotifyでの経験を元に、スクワッド、トライブ、カンパニーベットといったキーワードを中心として、自己組織化しスケールする組織の一例を示す良書だと感じました。
余談ですが著書の中で「反直感的ベット」という言葉が出てきますが、最近プロダクトに携わる中で少しその考え方が抜けていた気がして、改めてテック企業で働くことの意義を考えさせられました。
本記事を読んで少しでも興味が湧いた方は、ぜひご自身でも手にとって読んでいただければと思います！
