「ユニコーン企業のひみつ」と「Spotify’s Failed」の勉強会をしました
こんにちは、atama plusの松村です。
普段はスクラムマスターとして開発チームの活動支援を行っています。
基本的にはチームと一緒に活動することが多いのですが、チームの情報を共有するためにスクラムマスター同士で集まることも多々あります。
その中で、チームの活動を支援する上で必要となる知識を蓄えるために、勉強会をすることもあります。
今回はatama plusのスクラムマスター3人で「ユニコーン企業のひみつ」という本の勉強会とその後の経過を示した”Spotify’s Failed”についての勉強会を行ったので、その紹介をしたいと思います。
この勉強会は「Spotifyモデル」という開発モデルと、それを生み出し運用している企業の文化について知ることで、同じくプロダクト開発をしている企業として、開発組織に関する知識（パターン）を蓄積することを目的に実施しました。
勉強会の進め方
■事前準備
勉強会当日を気づきや疑問点について話す場にするために、事前に書籍やWebページを読んできてもらいました。
「ユニコーン企業のひみつ」には、開発体制「Spotifyモデル」の説明だけではなく、Spotifyの企業文化についても丁寧に解説されているため、それがどのように開発体制に影響しているかを考えてもらいながら読んでもらうことにしました。
■当日
勉強会当日はスライドでSpotifyモデルについて簡単におさらいをした上で、2つのセクションに分けて付箋出しをして、その後議論を行いました。
「ユニコーン企業のひみつ」からSpotifyモデルを学ぶ
「SpotifyモデルとLeSS(Large-Scale Scrum)、何が同じで何が違う？」、「atama plusの現在の体制とは何が違う？」というテーマで付箋に書き出しを行い、現状のatama plusの体制を基準に両者の違いについて考えることで、理解を深めました。
主に3つの観点で議論が盛り上がりました。
(1)ビジネスモデルによる開発体制の違い
以下のような付箋があがりました。
「SpotifyはBtoCプロダクトなのでビジネスドメインの課題の相互依存関係がわりと分けやすそう」
「Spotifyモデルとatama plusの大きな違いは、スクアッド単位でバックログとPOが分かれていることだと思っていて、そこを共通化することで得られるアジリティを捨てている（その分学習コストが減るメリットがある）」
これらの付箋をきっかけにatama plusの現状の状態について、改めて考えてみました。
atama plusのプロダクトには、「生徒が学習するためのアプリ」、「塾の教室長の方向けのアプリ」、「現場で生徒に教えている講師の方向けのアプリ」があり、プロダクトにて現場の課題を解く際、同時に複数のアプリを開発する必要も出てきます。
課題の性質によって、どのアプリに手を入れるべきかの判断から行う必要があるため、アプリ毎にバックログを分けて効率を高めるより、局所最適な機能開発に陥りにくい（＝全チームが全体を意識しながら開発しやすい）体制にしているという状態だと改めて確認をしました。
(2)会社やプロダクトの規模や成長フェーズによる違い
「最適なドメイン分けが見つかればSpotifyモデルのように分けられると思うし、今後atama plusの開発チームが100人になる＆ビジネスドメインが整理されると自然とSpotifyモデルのような分け方になるはず。」
開発チームがいまの数倍の規模になり、各ドメインや各アプリでの新規/保守開発の規模が増えると、全アプリを全チームが開発できるようにすることは、学習コストがかかりすぎ、非効率な部分が出てくるため、おそらく自然とビジネス領域やコンポーネント毎に分けたチーム編成に移行するだろうという話になりました。
(3)モデル自体の違い
「Spotifyのギルド＝LeSSのコミュニティといってよさそう」
「POとバックログがチーム単位で存在するのは大きな違い」
自分たちが普段活動しているatama plusの体制を基準に理解を進めることで、Spotifyモデルの自体の理解が深まりました。
そこから、LeSS Huge体制との比較の話に発展し、(1)や(2)のような話も踏まえて
「Spotifyモデルでは、ミッションを基に、コンポーネント(※)単位で1チーム分けるような形であるものの、ある程度アジリティを持たせたい場合にはLeSS Hugeのように、各ミッションの下に複数チームが紐づく体制が良さそう」
「コンポーネントやビジネスモデルについて深い理解が必要とされる領域があれば、Spotifyモデルのようにアジリティよりも学習効率を重視した開発体制を検討する必要がある」
(※)アプリを構成するプログラム部品。例えば「ログイン処理」や「ユーザー登録処理」。
と、ビジネス領域やユーザー特性、またコンポーネントの特性など、複数の観点を基に考えると、Spotifyモデルのような組織編成とLeSS Hugeのような組織編成の両者を取り入れた体制も検討できそう、と議論が深まりました。
“Spotify’s Failed”から組織フェーズの推移による開発体制の変化について考える
「ユニコーン企業のひみつ」の訳者あとがきにも記載されていますが、Spotifyモデルはある時点でのSpotifyの開発体制を切り取ったスナップショットであり、その体制は常に変化していっているとのことです。
このSpotifyの開発体制の変化に関しては、"Spotify’s Failed #SquadGoals
"という記事が有名です。
この記事は2020年に元SpotifyのプロダクトマネージャのJeremiah Lee氏によって書かれたもので、日本語のブロクでもいくつか取り上げられています。
元の記事では失敗と表現されていますが、今回の勉強会では「どのような変化があったのか、またその際にはどういった対応が必要か」という観点で捉えた上で、atama plusでも同様の変化や問題が起きる可能性があるか、という点について議論をしました。
このセクションでは、主に2つの観点で議論が盛り上がりました。
(1)組織を分割するメリットとデメリット
「分断して良いところ良くないところの判断はミスれない」
「投資領域をクリアにすることと、領域間を疎にしていくこととチームをできるだけ小さくする」
atama plusではLeSSで開発しているため、PO1人、プロダクトバックログ1つの状態で開発していますが、組織がスケールした際には開発効率を求めて、領域を分断する際にドメイン領域毎かコンポーネント毎等、どの単位で切るかが重要となりそうという話となりました。
ただし、領域を分けると情報が分断されやすく、どうしても協力体制を取りづらくなるため、それぞれがなるべく独立できるような体制を取るべき、とった考慮すべきポイントについても議論をしました。
(2)チームの自律性と組織の戦略のアライメント
「知識創造企業で言われているミドルマネージャーの存在が重要に思える（上位の戦略的意図と現場の実態をなじませる役割）」
"Spotify’s Failed"ではチームに自律性を求めすぎてバランスが崩れたという記載があったため、上記のような付箋があがりました。
ここでは、組織をスケールしながら、各チームでの自律を維持しつつも、どのように全体で同じ方向（戦略）を向いて、プロダクトを開発していくかという話で盛り上がりました。
勉強会を終えて
自分で読書を進めるより、基礎的なモデルの理解についても、そのモデルの背景についても深く推察し、開発体制について新たな視点を得ることができました。
また、この勉強会からしばらく経ったタイミングで、atama plusではLeSSを複数のエリアに分割する話となり、実際に複数人のPO、複数のプロダクトバックログという体制になりました。
あらかじめこの勉強会で、POやプロダクトバックログを分けるメリット・デメリットについて考える機会があったことで、私自身としてもすぐキャッチアップでき、違和感なくスクラムマスターとしての開発支援を続けることができたと考えています。
We are Hiring
atama plusでは今回紹介したスクラムマスター内の勉強会だけでなく、エンジニアもUXデザイナーもQAも職能毎でも職能横断でも勉強会を開いています。
会社で書籍を購入し、基本的に業務時間内に開催しているので、勉強会も実施しやすい環境です。インプットもしながら、プロダクト開発でアウトプットもできる組織で一緒に開発しませんか？全職種募集していますので、ぜひ以下のリンクをご覧ください！
募集職種一覧
3分でわかるatama plusのエンジニア