Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む（Spotifyモデル）

投稿日: 2013年10月16日作成者: daipresents (Dai Fujihara) — 2件のコメント

(注)ヘンリックの許可を得てざっくり意訳しました。原文は『Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds』です。訳に対するヘルプも歓迎します。Thanks Henrik, this article is great for me.

プロダクト開発をしている組織において、多角的なチーム構成を実現するのはいつもチャレンジな作業だ！

今まで見てきた中で印象に残っている例がひとつある。それはSpotifyだ。Spotifyは3つの都市にまたがって30以上のチームにスケールしているが、アジャイルなマインドセットをキープし続けている。

Spotifyは音楽産業を一変させている魅惑的な企業だ。創業してから6年しか経っていないのに、1500万ものアクティブユーザーを抱え、400万以上の決済が行われている。また、そのプロダクトは「世界中の音楽をすぐに見つけ再生できる、魔法のミュージックプレーヤー」と例えられている。

アリスター・コバーン（アジャイルソフトウェア開発の生みの親のひとり）がSpotifyを訪れたときにこう言った。「いいね。僕は1992年からこのようなマトリクス型の組織を実践する人物を探していたんだ！だから、本当に大歓迎な事例だ」

では、Spotifyではいったいどうやってそれを実現しているのか？

僕たちは「Spotifyでどんな風に働いているか」や「どうやって100人ものデベロッパーでアジャイル開発をまわしているか」を、カンファレンスや人を惹きつけるディスカッションで話したりしているが、沢山の人が興味を持ってくれたので、今回記事に書いてみようと思ったんだ。

注意してほしいこと： Spotifyは（他の優れたアジャイルな企業のように）急速に進化している。この記事は僕らの現在の仕事の進め方をスナップショットとして抜き出したものにすぎない。そして、僕らはまだ旅の途中であり、その旅に終わりはないのだ。だから、この記事をみんなが読んでいるときには、すでに色々変わっているかもしれない。

分隊

Spotifyにおける基本的な開発チームの単位は「分隊（Squads）」だ。

分隊はスクラムチームに似ている。そしてそれは小さなスタートアップのような雰囲気を持っているチームだ。分隊に所属するメンバーは同じ場所に集まって作業し、ソフトウェアの設計から開発、テスト、本番へのリリースに必要な一連のスキルやツールの知識を持っている。彼らは自己組織化されたチームであり、彼ら自身で自分たちの働き方を決めている。あるチームはスクラムのスプリントを使い、あるチームはカンバンをつかい、あるチームはいろんなアプローチを使っている。

それぞれの分隊は長期的なミッションを持っている。たとえば、Androidクライアントを開発し改善していくとか、Spotifyラジオという体験を作るとか、バックエンドシステムをスケーリングするとか、決済方法を提供するとかだ。以下の図は、ユーザーが体験するサービスのうち、どの部分に対して、どの分隊が責任を持っているかを表したものだ。

分隊ではリーンスタートアップの原則を適用することが推奨されている。たとえば「MVP（minimum viable product：実用最小限の製品）」や「検証による学び」だ。MVPは早期に頻繁にリリースすることを意味し、検証による学びはメトリクスやABテストを用いることで、実際に何が起きて何が起きてないかを見つけ出すことを意味する。リーンスタートアップのスローガンを要約すると「考えて、開発して、リリースして、微調整しよう」だ。

それぞれの分隊ではひとつのミッションをかかげており、長い時間プロダクトの一部分を担当するので、メンバーはその領域の真のエキスパートへとなっていく。たとえば、最高のラジオ体験を開発するといったスキルが身につくのだ。

ほとんどの分隊は、座席やラウンジ、分隊で使える「相談」部屋といったすばらしい職場環境を与えられている。ほとんど全ての壁はホワイトボードとして使える。まったく、これほどすばらしいコラボレーションスペースは見たことがない！

そうそう、サメもいたるところにいる。いたって普通の風景だ。

学びやイノベーションを推進するために、それぞれの分隊ではだいたい10％の作業時間を「 Hack Days」として使うことが推奨されている。Hack Daysの間、メンバーはやりたいことをなんでもやれる。通常は新しいアイデアを試してバディに共有したりする。いくつかのチームは1日使ったHack Dayを隔週で開催している。その他のチームは「Hack week」を行ったりする。Hack Daysは楽しいだけではなく、新しいツールやテクニックといった最新の知識を経験できる優れた方法でもある。そしてときどき、重要なプロダクト・イノベーションを引き起こしたりするのだ！

分隊には公式に指定されたリーダーががいるわけではない。しかし、プロダクトオーナーは1名いる。プロダクトオーナーはチームによって完了されていく作業の優先順位づけに責任をもっているが、チームがどのように作業するかまでは関与しない。プロダクトオーナーは別の分隊のプロダクトオーナーと、全体としてSpotifyが向かっている方向性を示すハイレベルなロードマップドキュメントを保持するためにお互い協力しあう。つまり、それぞれのプロダクトオーナーは自分の分隊のために、プロダクトバックログを他チームのものとうまく調整し、維持していく責任もあるのだ。

分隊はアジャイルコーチにも協力を求めることができる。アジャイルコーチは、分隊の仕事の進め方について進化や改善の手助けをする。コーチはふりかえりや計画ミーティング、マンツーマンでのコーチングなどを実施する。

理想を言えば、それぞれの分隊はそれぞれのステークホルダーと直接連絡を取り合い、完全に自立したチームとなり、お互いに依存関係を持たないことが望ましい。これは基本的に小さなスタートアップと同じだ。これを30を超えるチームでやるのはチャレンジだ！僕らは大きな発展を遂げてきているが、まだやるべき改善がたくさん残っている。

こういった改善を手助けするために、それぞれの分隊に向けて年4回の調査を行っている。この調査は改善の成果に集中する手助けとなり、どんな種類の組織的サポートが必要かを見つける手助けとなるのだ。以下にそんな調査のひとつを紹介しよう。これは5つの分隊に行った調査結果だ。

円のマークは現状を表していて、矢印はトレンドになる。たとえば、3つの分隊はリリースに対して問題をレポートしているのがわかるだろう。そして、その問題は改善されていないように見える。だから、このリリース問題は急いで解決する必要があるのだ！また、分隊4はアジャイルコーチのサポートによっていい状態になっていなかったが、現在はよくなってきたみたいだ。

プロダクトオーナー – 分隊には専任のプロダクトオーナーが1名いる。仕事の優先順位を決めたり、ビジネス価値と技術状況の両方を考慮する。
アジャイルコーチ – 分隊にはアジャイルコーチがいる（[訳注] 図を見る限り、分隊に1名ではなく部隊に1名のようだ）。アジャイルコーチはチームの障害を明確にする手助けをしたり、チームのプロセスを継続的に改善していく。
影響力のある仕事 – それぞれの分隊のメンバーは、計画づくりで能動的に動く必要があったり、どの作業を選ぶか考えたりするので、お互いの仕事に影響を与え合っている。メンバーは10％の時間をHack Daysとして過ごすことが可能だ。
リリースの容易さ – 分隊では、面倒な作業や同期をできるだけ少なくしている。
チームに合ったプロセス – 分隊は自分たちのプロセスを自分たちで管理し、継続的に改善していく。
ミッション – 分隊はミッションを持っていて、メンバーの誰もがそれを理解し、心に留めている。バックログにあらわれているストーリーはミッションに関係している。
組織的なサポート – 分隊は問題解決のサポートや、技術的な問題、簡単な問題（soft issue）のために、どこに問い合わせればいいかを理解している。

部隊

部隊は分隊が複数集まったものだ。部隊ではミュージックプレーヤーやバックエンドのインフラといった関連する領域を担当している。

部隊は分隊という小さなスタートアップのためのインキュベーターのようになものだ。そして、部隊には公平な裁量範囲や自律が存在する。それぞれの部隊には部隊長がいて、部隊の中で分隊のためにベストな仕事環境を提供する責任をもっている。部隊の中にいる分隊のメンバーは同じオフィスに席を持ち、通常はお互い肩を並べて座っている。そして、すぐそばにあるラウンジでは分隊間のコラボレーションが推奨されている。

部隊の大きさは「ダンバー数」のコンセプトがベースになっている。ダンバー数とはほとんどの人たちが100人以上のソーシャルリレーションシップを維持できないというものだ（その数字は極端な生き残りをかけたプレッシャーを受けているグループよりも大きい数字だ。信じるかどうかわからないけど、Spotifyでの事例とは明らかに違う……）。人数があまりにも大きくなった場合、制限のためのルールやお役所仕事、社内政治、余計なマネジメントレイヤーといった数々の無駄を探そうとしてしまう（[訳注] 原文「under intense survival pressure」の意味がわからず）。

よって、部隊は100人より少なくなるように設計されているんだ。

部隊は定期的に集まり、その非公式なパーティーでは、ある部隊が他の部隊に対して（別に話したい人がいるならその人が話してもいい）自分たちの働き方やリリースした成果物を紹介し、そういった話から他の部隊はさまざまな学びを得る。このパーティーでは動くソフトウェアのデモ、新しいツールやテクニック、クールなHack Daysプロジェクトなどが共有される。

分隊の依存関係

多角的な構成になっている分隊では、常に依存関係が生まれるだろう。だが、依存関係は必ずしも悪いわけではない。本当にすばらしいものを作るために、一緒に働く必要がある場合もあるからだ。それにもかかわらず、僕らのゴールは自立した分隊になることだ。特に分隊の作業の邪魔になったり、遅くなったりする依存関係を最小限にしようとしている。

これを支援するために、定期的に依存関係のある全分隊に対して、依存関係が邪魔になったり遅くなったりしている影響の範囲を問いかけるようにしている。以下がその例だ。

それから、問題のある依存関係を取り除く方法を議論する。特に、邪魔になるものや複数の部隊に関連する依存関係をだ。これによって再度優先順位づけされたり、再組織化したり、アーキテクチャ的な変更やテクニカルな解決策を導いている。

こういった調査は、分隊がどのように依存しあっているかというパターンを見つける手助けとなる。たとえば、運用によって多くの分隊の速度が落ちているケースがそうだ。僕らはシンプルな図を使い、さまざまな種類の依存関係が時間とともにどのように増えたり減ったりしているか追跡している。

スクラムには「スクラムオブスクラム」というプラクティスがある。このプラクティスは依存関係に関して議論をするために、それぞれのチームから1名が参加して同期するミーティングだ。しかし、Spotifyではスクラムオブスクラムを実施していない。なぜなら、ほとんどの分隊はほぼ独立していて、スクラムオブスクラムのような調整のためのミーティングの必要がないからだ。

そのかわりに、「要求に応じて」スクラムオブスクラムを実施している。たとえば、最近だと数ヶ月の間、複数の分隊において調整作業が必要となる大きめのプロジェクトがあった。

プロジェクトを進めるために、チームは分隊間の依存を明確にし、解決するために毎日同期ミーティングをしていた。そして、解決していない依存関係を追跡するために付箋をボードに貼りつけていた。

たくさんの企業に共通する依存問題の原因は、開発と運用のバランスだ。僕らが一緒に働いたことのあるほとんどの企業は、開発から運用に作業を引き継いだりしている。これは意見の不一致や遅延に関係してくる作業だ。

Spotifyでも運用チームを分けてはいるが、分隊のためにリリースするのが仕事ではない。彼らの仕事とは、分隊が彼ら自身で自分たちのソースコードをリリースする必要があるため、インフラの構成やスクリプトや所定の手順のサポートを提供することだ。

これは日常的なものだが、詳細なプロセスが書かれたドキュメントではなく、顔を突き合わせたコミュニケーションが基本となる効果的なコラボレーションだといえる。

支部とギルド

すべてにおいてマイナス面になる状況もあるだろう。完全な自律性においてマイナス面に陥るおそれのあるのは、スケールの節約（economies of scale）だ。たとえば、A分隊のテスターが、先週B分隊のテスターが解決した問題と戦っている場合もありえる。こういった問題は、テスター全員が分隊や部隊を横断して集まっていれば、全員で知識を共有し、全分隊の資産となるツールを作ったりして防げたはずだ。

それぞれの分隊が完全に自立していて、お互いコミュニケーションをとっていないならば、会社に意味なんてあるんだろうか？ Spotifyなら30の異なる小さな会社に分割するかもしれない。

よって、僕らは支部とギルドを設置している。これによって会社がまとまる団結力が生まれ、自立し過ぎて犠牲となるものをなくし、スケールの節約に多少なっていくのだ。

支部は同じようなスキルを持った人たちで構成された家族みたいなものだ。同じ部隊内で、同じ能力をもった人たちが集まる。

それぞれの支部は自分たちの専門領域や特定の難題について定期的に議論する。支部にはテスト支部、Web開発支部、バックエンド支部といったものがある。

支部長は自分の支部メンバーのラインマネージャーだ。彼らは従来型の職責である人材開発や給与の設定等を行っている。ただ、支部長は分隊のメンバーでもあるので、日々の開発にもかかわっている。だから、現実とたえず接触し続けているのだ。。

そうはいっても自分たちが考えているより現実はいつもやっかいだ。たとえば、支部のメンバーは分隊全体に均一にばらけているわけではない。ある分隊だとWeb開発者が多く、別の分隊にはWeb開発者がいなかったりする。ただ、支部のような考え方は一般的な概念を提供してくれるのだ。

ギルドはより本質的なもので、広い範囲に及ぶ「好奇心を持ったコミュニティ」だ。コミュニティには知識やツール、コード、プラクティスを共有したいメンバーが集まる。支部は部隊の中にあるが、通常ギルドは組織全体に横断して広がっている。ギルドの例をあげると、Web技術ギルド、テスターギルド、アジャイルコーチギルドなどがある。

ギルドは多くの場合、関係する領域で働いている全支部やメンバーが所属している。たとえば、テスターギルドにはテスト支部にいる全テスターがいる。ただ、興味があれば誰でもどんなギルドにでも参加可能だ。

それぞれのギルドには「ギルドコーディネーター」がいて、うーんと、その名の通りの仕事をする：o)

ギルドの仕事を紹介すると、最近、「Webギルドアンカンファレンス」というものを開いた。これはオープンスペースで開催されたイベントで、Spotifyの全Web開発者がストックホルムに集まり、彼らの活動領域の難題や解決策を議論した。

アジャイルコーチギルドも紹介しよう。アジャイルコーチは組織のあちこちで活躍している。しかし、継続的に知識を共有したり、定期的に会って組織として改善の必要なハイレベルな領域について協力しあい、改善ボードを使って改善を追跡している。

ちょっとまって、これってマトリクス型組織かな？

うん。まあ、そのようなものだ。今回紹介した事例はこれまでのマトリクス型組織とはちょっと違った種類になっている。

たくさんのマトリクス型組織の人たちは、似たようなスキルを持つ人が機能的な部署として「集められる」。そして、プロジェクトに「アサインされ」、自分のマネージャーに対して「レポート」をする。

Spotifyではめったにそんなことしない。僕らのマトリクス型組織はデリバリに重点を置いているのだ。

Spotifyのメンバーは、同じ場所にいて信頼できる分隊に所属している。すばらしいプロダクトを作るために、異なったスキルセットを持つメンバーがコラボレーションして自己組織化しているのだ。これはマトリクスでいうと垂直に区切った部分だ。重要なのはどう物理的にグループになっているかと、どこでメンバーが時間をすごすかという点だろう。

一方、水平に区切った部分は、知識やツール、コードを共有するためのものだ。支部の役割はこれを手助けしたり、支援したりするためにある。

マトリクスという言葉は、「What」を垂直方向に、「How」を水平方向に考えている。マトリクス構造は、それぞれの分隊メンバーのために「次に何を作るか」「どうやってうまく作るか」という疑問に答えるための手引書になるのだ。

この組織構造はメアリー＆トム・ポッペンディークが推奨する「教授や起業家」モデルにマッチする。プロダクトオーナーは「起業家」や「プロダクトチャンピオン」に相当し、すばらしい製品をデリバリすることに集中する。これに対して支部長は「教授」や「コンピテンシーリーダー」に相当し、技術的に卓越することに集中する。

それぞれの役割には健全な緊張感がある。起業家はスピードアップや節約に気を取られやすいし、教授はゆっくりと適切に作りたいと思ってしまう。この2つの面は必要不可欠であり「健全な」緊張感というのはまさにこれを指している。

アーキテクチャについてはどうだろう？

Spotifyのテクノロジーは高度なサービス指向アーキテクチャになっている。100以上にわかれたシステムがあり、それぞれは個別に整備やデプロイされているのだ。このシステムにはプレイリスト管理や検索、決済といったバックエンドサービスも含まれている。そして、クライアントサイドを見ると、iPadのプレーヤの固有の構成であるラジオや、ミュージックプレーヤーの「What’s new」部分も含まれている。

技術上は、だれでもどんなシステムでも修正することが許されている。なぜなら、分隊は効率的なフィーチャチームであり、メンバーは新しいフィーチャを本番環境にリリースするため、複数のシステムを更新する必要があるからだ。

この方法のリスクは、もし全体としてシステムのまとまりを誰も考慮しない場合、システムのアーキテクチャが乱雑になってしまうことだろう。

このリスクを和らげるために「システムオーナー」という役割を設置している。すべてのシステムにはシステムオーナーがいて、ひとりの場合もあればペアの場合もある（僕らはペアを推奨している）。クリティカルなシステムを運用するために、システムオーナーはDevOpsのペアになっているのだ。つまり、あるメンバーは開発者視点を持ち、あるメンバーは運用視点を持っているということだ。

システムオーナーはそのシステムに関係するあらゆる技術的、アーキテクチャ的な課題に対する「大黒柱（go to）」のような人物だ。そして調整役であり、そのシステムのコードを守るメンバーがつまづかないための案内人にもなる。システムオーナーは、品質、ドキュメント、技術的負債、安定性、拡張性、リリースプロセスに注意を払っている。

システムオーナーはボトルネックでもないし、浮世離れ（ivory tower）もしていない。全ての意思決定をしたり、全てのコードを書いたり、全てのリリースに自ら関わったりするわけではないのだ。一般的にはシステムオーナーは分隊や支部長で、日々の作業に加えて、システムのオーナーシップに関しても責任をもっている。ただ、たまに「システムオーナーDay」を開き、システムの掃除をしたりもする。いつも僕らは1日にひとりが使える時間のうち、10分の1以下のコストを使ってシステムオーナーシップを維持しようとしている。しかし、もちろんシステム間にはたくさんの違いがある。

チーフアーキテクトという役割も存在する。チーフアーキテクトは複数のシステムを横断するハイレベルなアーキテクチャの課題を調整する。よくある問題を回避するために新しいシステム開発のレビューをしたりもするし、アーキテクチャビジョンに同調している。そのフィードバックは常に提案や意見になっていて、システムの最終的な設計のための意思決定は、開発を担当している分隊ができるようになっている。

このやり方は全部ちゃんと機能しているの？

Spotifyはとても急速に成長している。技術者は3年ちょっとで30人から250人になった。だから、成長の痛みの共有をしたんだ！このスケーリングモデル――分隊、部隊、支部やギルド――は年月をかけて徐々に取り入れられたものだ。だから、メンバーはみんな慣れ親しんでいる。でも、今までのところ、調査やふりかえりを参考にすると、このスケーリングモデルは本当にうまく機能しているようにみえる！そして、「成長感」のようなものをみんな感じているんだ。急成長にもかかわらず、従業員の満足度は2012年4月で4.4だったのが、5以上へと継続して上昇している。

ただ、急成長する組織ならばどんな組織でも、今日見つけた解決策が明日問題になってしまう場合もある。だから、このまま見守っていてほしい。僕らの物語は続くのだから：o)

/Henrik & Anders
henrik.kniberg@spotify.com http://www.crisp.se/henrik.kniberg
anders.ivarsson@spotify.com

訳者あとがき

アジャイル開発のようなテーマで何かを書いたり、発表したりする場合、「概要」「はじめ方」といった教科書に書いてある眠いお決まりの話になったり、「チームビルディング」「リーダーシップ」のような根性論や精神論になりがちな話になったり、なかなか伝えるのが難しいものです。

しかし、ヘンリックの物語は一味違います。

そこにはビジョンがあり、知識や経験があり、臨場感や現場感がある。だから、彼の物語は人々を魅了し、共感を呼び、読み終わるとソフトウェア開発に対する情熱がふつふつと湧いてくるのではないでしょうか。

そう、彼の物語には血が流れている。

今回、ざっくり翻訳させていただいた「Agile @ Spotify with Tribes, Squads, Chapters & Guilds」の原文は、ヘンリックのブログに掲載されています。彼のブログには彼の経験が惜しげもなく書かれており、様々な言語に翻訳されているため、空いた時間を見つけて日本語版の翻訳をしたのが今回の記事です。

彼は現在、Spotifyという音楽ストリーミングサービスの会社（日本でもちょっと話題ですよね）にいて、今回のようなマトリクス型組織の運営に取り組んでいます。その仕組みはある程度計算しているように見えますが、有機的であり、ところどころに彼らの苦労を感じる言葉がちらばっています。

彼は『リーン開発の現場』にも書いてあるように、アジャイルやリーンの原則の上で、しっかりとゴールを見失わないように歩いていくエキスパートです。そして、ビジネスと開発の両方で成果を出し、知識を共有し続けています。

恐らく、ここまでコミットメントできるアジャイルコーチは日本にまだいない気がしますが（いたらごめんなさい）、彼のような存在が、日本のアジャイル実践者に勇気をもたらすように思うのです。