Spotify Modelの虚像と実像
フジイ タカヒロ
19/Sep · 20 min read
まえがき
WealthParkではいわゆるSpotify Modelをアレンジした開発手法・組織体系を導入しています。私の過去の記事でも、部分的にこの点に対して言及していましたが、明確にSpotify Modelに焦点を当てた記事を書いていなかった為、今回書いてみました。
まず、この組織モデルに対して、賛否両論ある点は理解しています。また、Spotidy Modelの一部を取り入れ、実際に運用する中で、いい所も、課題感も感じることができました。この記事が、Spotify Modelに対するCase Studyと、組織改善、そして自治と調和について考えるきっかけになれば幸いです。
Spotify Modelについてご存知無い方は、まずは原文を一度見ることをおすすめします。すごく量があるわけではないのと、日本語訳の記事も上がっているので、すんなり読めると思います。
Spotify Modelについてご存知無い方は、まずは原文を一度見ることをおすすめします。すごく量があるわけではないのと、日本語訳の記事も上がっているので、すんなり読めると思います。
· · ·
Spotify Modelの目的
Spotifyではその開発、組織手法がもたらす最大のメリットとして、'Autonomy(自治)'を上げています。Squad + Chapterという組織構造で、より一人一人のOwnership、責任と自由を強化していくことが、この開発手法を取り入れる一つの大きな目的と捉えています。SquadとChapterについては、この後のセクションで説明していきます。
· · ·
Squad
Spotify Modelの一つの特徴は、開発チームの単位として明確にSquadというものを定義していることです。Squadは、垂直型の組織で、あるプロダクトや機能に対して働く、職責混合の1チームのことを指します。Squadのように明確に名前がなくとも、プロジェクト、あるいはプロダクトチームという形で、様々な役割のメンバー(PDM, FrontEnd, BackEnd, QA, etc..)が一緒に仕事することがあると思います。Spotify Modelはそのような集合を、明確にSquadという組織として定義しています。
その為、1Squadは例えば1つのプロダクトや1つの機能について責任を持ちます。あるいは、皆で1つの新しい機能やプロダクトを開発します。ある責任範囲について、Squadだけでリリースまで遂行できるような組織が望ましいとされています。(実際は他のSquadと協力する部分は少なからず発生します。)
そのような形でSquadを結成することにより、Squadは自治権を得ます。高い自治権を持い、さながら1つのスタートアップ、会社のように働きます。
Squad毎に責任が移譲されることは、属しているメンバーの1人1人が大きな責任をもつということです。その為、あるSquadにおいて、あるChaper(FrontEnd, BackEnd)の責任はEngineering Managerではなく、Chapterのメンバー1人1人にあります。(必要に応じてEngineering Manager(Chapter Lead)は支援を惜しみません)
Squadを用いた自己組織の究極の目的、目標としては、1Squadがほぼ独立した会社の用に、プロダクトやビジネスのKPIの達成のために邁進できることです。
· · ·
Chapter
一方、Chapterは職能・役割別の水平型の組織です。例えば、FrontEnd Chapterだったり、Backend Chapter, Product Manager Chapter, QA Chapterがあります。Chapterを会社の1部署、チームとして定義する組織も比較的多いでしょう。
Squadに対して、Chapterは同じようなスキルセットを持った人で構成される為、技術的な課題についての議論や、FrontEnd(BackEnd)のアークテクチャの議論などは、各Chapterで行われることが多いです。組織の規模にもよるかもしれませんが、コードレビューなども、Chapter間で行われることがあります。
この説明を見て、Chapterは至って普通のチームのように感じられるかもしれません。しかし、実態は異なります。その点を次に説明します。
· · ·
SquadとChapterの関係
SquadとChapterそれぞれは、非常に普遍的なことに見えます。但し、それら2つを明確に定義することで、Squadの自治・Chapterの調和の両者を目指すメッセージ性があります。
これは筆者の主観も含みますが、多くの場合、組織の拡大に伴いChapter型の組織が肥大化し、調和にかける時間が増えます。(規模の大きいChapterが必ずしも悪いということではないです。あくまでこのような現象が起きやすくなる、という観点です。)
そこで、Squadという組織が明確に定義し、自律性やアウトプットを維持する、加速することを目指します。
私が実際にSpotify Modelを取り入れていて感じていることは、Spotify Modelでは、Chapterより前にSquadがきます。確実に自治重視の組織構成です。Squadがある程度独立して動けることが前提にあります。
Spotify Modelは理想としては両者を取りに行く手法ですが、どちらを重視しているか、と聞かれれば、明確に自治です。最初から自治を重んじる組織に利用するケースもあれば、Chapter型の組織が成熟していく中で、再び自治を高めるアプローチとして部分的に取り入れていく、というケースが考えられると思います。両者を目指す為にこのアプローチをとることもあるでしょう。
すると何が起きるか。Chapter内で議論や共有はされど、各Squadの動きは止まりません。時に、Squadを超えてマネジメント、調整をしたい場合、その難易度は水平型のみの組織より格段に高いと言えます。次に、その自治を重んじる組織において、調和の鍵を握る、Chapter Leadという役割について説明します。
· · ·
Chapter Lead
リーダーシップ(マネジメント)
改めてですが、Spotify Modelでは、縦割りはSquad(Product, Project毎), 横割りはChapter(FrontEnd, Backend等)と定義してマトリックス型の組織体系で構成されています。Chapter Leadは、横割りのChapterを支援するLeadポジションです。
Chapter Leadは、Engineering Manager要素がやや強いですが、Technicalな期待値も持ち合わせています。マネジメントと、IC(個人の貢献)の両者が明確に記載されている点が特徴です。
まず、リーダーシップの点についてですが、Scaling Agileでは、次のように書かれています。
ChapterLeadは、Chapterのメンバーのためのラインマネージャーであり、人の育成、給与の設定などの伝統的なすべての責任を負います。
Chapter leadはいわゆるEngineering Managerの側面を持ち合わせていて、Chapter間での技術スタック、知識、ツールの共有などをファシリテートします。また、メンバーの開発のサポートや、目標設定なども行います。
· · ·
ハンズオン
次にハンズオンについてです。Scaling Agileには次のように書かれています。
Chapter LeadもChapterの一員として日々の業務に携わっているため、現場との距離を縮めることができます。
この"現場との距離を縮める"の部分が非常に大切です。一見、このChapter Leadはプレイングマネージャのように見えますが、必ずしもそうではないと考えています。
この現場という言葉は、色々な読み取り方が出来ます。1エンジニアとしての技術力、エッジなTechnologyに対する理解、プロダクトに対する知識、プロダクトの課題、技術的な負債など。
僕は、'プロダクトに対するリアルな課題感の把握' を '現場' として捉えています。
例えば、組織としてリファクタリング、リアーキテクトを進めたいが、思ったより進んでない。というIssueがあったとき、どうやって具体的な課題、原因を特定していくことになるのでしょうか。どの粒度で課題を見るのが良いでしょうか。それは、プロダクトがMonolithだからなのか、レガシーすぎるからなのか、コードが複雑(らしい)からなのか、コードのドメインが綺麗に分かれていないからなのか。ある複雑な関数のテストコードがなく、リファクタリング後のテストコードがかけないからなのか、メンテナンスタスクに追われて、リファクタリングに時間が避けないからなのか。どれもが正しい可能性がある一方、どこに現場の人が一番課題を感じているのか、あるいはそれが'実際どれくらい大変なのか'という肌感は、現場にいる人とそうでない人には違いがあることが多いと考えています。
· · ·
リーダーシップとハンズオン
Chapter Leadが実装にかけられる時間は他のメンバーよりも少ないですが、それでも1Chapterのメンバーとして手を動かすことで、Realな現場感を持つことができると考えています。とはいえ、Leadership, Managementをどちらも頑張ることで、Chapterのメンバーと同等以上のアウトプットを出してほしいというわけではありません。リーダーシップとハンズオンにかける比重については、柔軟に考えています。パターンを考えると、
- 一定の割合を維持する
- どちらかに多めの比重をかける(それはもしかしたら、EMっぽいChapter LeadとTechleadっぽいChapter Leadなのかもしれない)
- 状況に応じてMenagementに専念している時もあれば、開発に専念しているときもある
などがあります。どれも一番良いアプローチになりうると考えています。大切なのは
リーダシップとハンズオンの2つの側面で、組織の生産性を最大化すること
に貢献できているかどうかです。
· · ·
その他
Tribe
Squadの中でも関連が強いSquadなどをグルーピングすることがあります。複数のSquadをさらにグルーピングしたものをTribeといいます。ちなみに、Scaling Agileには次の記述があります。
Tribeのサイズは「ダンバー数」という概念に基づいて決められています。これは、ほとんどの人が100人以上の人とは社会的関係を維持できないというものです（実際には、生存圧力が強いグループほどこの数は大きくなりますが、Spotifyではそうではありません。グループが大きくなりすぎると、制限的なルール、官僚主義、政治、余分な管理層、その他の無駄が増えてきます。だから、Tribeは100人以下になるように設計されています。
その為、Tribeとはそれなりに成長した組織で発生するイメージがあります。(例えば、弊社ではこの概念はありません)
· · ·
ギルド
ギルドは、より有機的で広範囲な「関心のあるコミュニティ」であり、知識、ツール、コード、実践を共有したい人たちのグループです。Chapterは常にTribeのローカルなものですが、ギルドは通常、組織全体を横断するものです。例としては、ウェブ技術ギルド、テスターギルド、アジャイルコーチギルドなどがあります。
Guildは特定の興味について、Chapterを超えて議論を進めるコミュニティです。例えば、パフォーマンスの改善や、全体的なアークテクチャの指針、監視ツール・プロセスの選定などは、1Chapterで完結しない議論になることがあります。
そういった場合は、Chapterを横断して、Communityとして議論やプロジェクトを進めることがあります。こちらも、実際に現場では比較的実際に起きているものだと思います。例えば、何とか委員会とか、そういうやつです。
· · ·
その他の要素
Scaling Agileに記載されていて、本記事では触れていないものもあります。それは、Squadの依存関係の管理や、Squadのステータス分析などです。もしも興味がありましたら、原文を読んでみることをお勧めします。
· · ·
Spotify Modelのメリット
・組織の自治、自己組織化の推進
明確にSquadの自律・自己組織化を推進できる。そしてトレードオフに目を瞑れば、比較的その効果はすぐに出始める。
・個々の責任感の醸成
Squadの自律性に伴い、メンバーは高い期待値・責任が与えられていることを多くの場合実感する。大きな組織でも、スタートアップのような責任をここのメンバーに与えることができる。
・Squadとして、小規模な独立した組織で高い生産性を発揮する(できないこともある)
Squadが一度ワークすると、そのSquadは非常に高い生産性、アウトプットを出しうる。但し、全てのSquadがこの状態になることは非常に難しい。
· · ·
Spotify Modelのデメリット・考慮点
・Chapter Leadの組織マネジメントの難しさ
いわゆるEMをやってきた人はこのChapter Leadという責任範囲の特殊さに悩むだろう。コードも書きつつ、マネジメントもする。おまけにSquad毎に独立してどんどん進んでいくから、Chapter全体をサポート、マネジメントするのも難しい。その人の今までのキャリア次第だが、TechLeadでもEM一辺倒でもないこの役割の難しさは高い。
・Alignmentのバランス
基本的には、どこまでいってもAlignmentはSquadが無い状態よりも劣る。その中で、Alingmentのレベルを組織としてどこまで求めるか、というバランス感が非常に難しい
・高いAgileに対しての理解
各Squadに、少なくともAgileに対するある程度の理解が求められる。Agileに対する理解がない状態では、Squadは上手く機能しないことが多い。会社組織で考えた時に、AgileのExpertは少なからずいるとは思うが、1Squadに1人いるかとなると、難しいケースもある。
・間違った自律を制御できない可能性
高い自律性は組織を次のレベルに引き上げる為に必要ですが、自立している各Squadが正しい道を歩んでいるのかに常に気を配る必要があります。例え高い自律性があったとしても、方向性が合っていなければ、最終的に失敗してしまう可能性があります。
· · ·
Spotify Modelが書かれた次点でのSpotifyの規模感
Scaling Agileには次の情報が書かれています。
Spotifyは非常に急成長しています - 3年間で30人から250人の技術職に成長しました。
これを書いている時点で、250人規模の開発組織です。最初にも書いていますが、Spotify Modelは比較的大規模な組織においてAgileを実現しようとしている方法です。例えば、僕らの組織は20人強です。20人強でこのエッセンスを取り入れていることと、250人でこれをやるのでは、似て非なる部分が沢山あります。もしも、Spotify Modelを検討される場合は、この前提を理解しておいた方がよいでしょう。
· · ·
Spotify Modelという虚像
ここまで読んで頂いた方に、この内容をここで出すのは、性格が悪いと思われるかもしれません笑。Spotify Modelについて比較的最近調べた人なら、下記の記事にたどり着いている可能性が高いと思います。ここまでの文章を読んで、もしもSpotify Modelをやってみようと思った人にこそ、これを読んで欲しいです。
これらの記事から一部を抜粋すると、
Spotifyでは、Spotify Modelが会社全体の仕組みとして定着し、適用されることはありませんでした。
特に、自律に対するコントロールが制御できずに管理に苦しんだ。
Squad, Chapter間の協力が出来なかった。
ProductManagerのAlignmentコストが肥大化する。
などが書いてあります。この全ては、実際に起こりうる問題です。また、要求されるスキルセットが高く、機能不全に陥るSquadが比較的発生しやすいのかなという印象もあります。
ここに書かれているCase Studyはどれも具体的なものです。もしもSpotify Modelの考えを適用する、一部取り込む場合は、こちらに書かれている失敗のケースについても学んでおくことをおすすめします。
但し、これはSpotify Modelの全てを否定するものではありません。規模が拡大していく中で、AgileやAutonomyを維持する為に検討できる項目やヒントはSpotify Modelの中にいくつもあります。ただ、悪い目に目を向けること、そして様々なブログでも言及されているますが、Spotify Modelを再現することを目的としないことが大切です。また、Spotify Modelは、凄く'人'に依存する手法です。単にアジャイルとしての1手法として取り入れるのではなく、メンバーの1人1人をみて、うまくいくかを議論する必要があります。
Spotify ModelをそのままSpotifyが利用しなかった、あるいはそれによって組織を成功に導くことが出来なかったのであれば、Spotify Modelは確かに虚像かもしれません。しかし、その1要素毎には、自治と調和を追い求める思考や施策を感じるとることができるはずです。また、その1部や、それに影響を受ける形で何かしらの実践もされていたでしょう。そこには、実像を垣間見ることができます。もしも、あなたがSpotify Modelに興味を持ったのであれば、組織をよくする為のヒントをSpotify Modelの様々な要素の中から見つけて、自分の組織に落とし込むべきです。
· · ·
さいごに
Spotify Modelに焦点をしぼり、説明させていただきました。最後に考えされられる文章をのせてしまいましたが、これがあるお陰で、Spotify Modelそのものをみるのではなく、その1つ1つに目を向けることが出来ると思います。
Spotify Modelを参考にしようがしまいが、この記事が組織改善の糸口を考える助けになれば幸いです。
· · ·
リファレンス
· · ·