Spotifyはどのようにプロダクトを開発しているのか？

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

(注)昨日の「Spotifyのスケーリングアジャイル」に続き、ヘンリックの許可を得てversion 1.1をざっくり意訳しました。細かい表現は主観で訳したので、気になる方は原文：How Spotify builds productsをどうぞ。訳に対するヘルプも歓迎します。

プロダクト開発は簡単ではない。実際に、そのほとんどの努力が失敗している。そして、その失敗に共通するほとんどの理由が、間違ったものを作ってしまうことだ。

Spotifyはスウェーデンのリーンスタートアップだ。そして、Spotifyはプロダクトデリバリーにおいて素晴らしい実績を持っている。Spotifyのプロダクトはユーザーやアーティストによって愛されており、ウイルスのように世界へと広がっている。アクティブユーザーは2000万人を超え、課金ユーザ（paying subscribers）は500万人と急成長している。例をあげるとすれば、たくさんの競合がいるアメリカにおいて、ほぼ1年で課金ユーザをゼロから100万人に増やしたほどなのだ。

Spotifyのビジョンは「どんなときも、望みどおりの音楽をあなたに届ける」だ。これは世界中にあるすべての音楽に制限なくアクセスできて、簡単に共有できる力を持っていることを意味する。そして、よりたくさんの音楽が共有され、再生され、よりたくさんのお金がアーティストに還元されるのだ。Spotifyはミュージックプレイヤーとして数年前にはじまり、そのプロダクトは新しい音楽を発見するためや、アーティストとそのファンを直接つなぐために、どこでもアクセスできるプラットフォームへと今も進化している。

プロダクトは簡単で使いやすく、親しみやすく、面白みのあるものにデザインされている。ミュージックストリーミングサービスに対して、なかなか手ごわい抵抗者として長く知られるメタリカでさえ、現在はSpotifyを「圧倒的にナンバーワンのストリーミングサービス」や「簡単さに唖然としている」とコメントしているのだ。

Spotifyのような成功している企業は、人々が愛してくれるプロダクトのデリバリだけを考えている。しかし、Spotifyは人々がプロダクトを愛してくれるかどうか、デリバリするまでわからないのだ。これは矛盾した話だ。

では、Spotifyはどうやって愛されるプロダクトを開発しているのか？

この記事は、Spotifyのプロダクト開発のアプローチに関して、ハイレベルな概要を提供することを目的としている。

注意してほしいこと： この記事のすべてのモデルは現実の出来事を簡単に説明している。Spotifyはこのプロセスにいつも文字通りに従っているわけではない。たくさんのローカルバリエーションが存在するのだ。しかし、この記事が一般的な概念を提供してくれるはずだ。

謝辞： 僕がこのモデルを発明したわけではない。この記事の材料は、Gustav Söderström、Oskar Stål、 Olof Carlsonや、内部資料、「Think It, Build It, Ship It, Tweak It」というフレームワークのといったものがベースになっている。僕もまたデザイナーや開発者、アジャイルコーチとのたくさんの会話によって学んだのだ。みんな、ありがとう！

サマリー

僕らの核となる哲学は以下だ。

我々は革新的なプロダクトを早期、かつコストの低いプロトタイプによって、リスクを管理しながら作っていく。
我々は日付に対してローンチしない。品質に対してローンチするのだ。
我々はプロダクトがローンチ時にすばらしいものであっても、やがて驚くべきものになっていくことをローンチ後の厳格な微調整によって保証する。

すべての重要なプロダクトイニシアチブは、4つのステージ――「Think It」「Build It」「Ship It」「Tweak It」――を通り抜けていく。以下はアイデアがプロダクトになるまでの流れを表したものだ。それぞれのステージの途中でどういう結果になるかがわかるだろう。この図のより詳細を含むバージョンは、この記事の最後のほうで確認できる。

Think It ＝どんな種類のプロダクトを作るか。それはなぜか。
Build It ＝小さな実行できるプロダクトを作る。これはリアルユーザーのための準備なのだ。
Ship It ＝全ユーザーに徐々に見せていく。その間は測定と改善を行う。
Tweak It ＝プロダクトを継続的に改善する。この状態は最終段階だ。プロダクトはシャットダウンされるか考えなおされるまで（つまり、Think Itに戻るまで）この状態にいる。

Spotifyには30以上の分隊（「分隊」とは小さい職能横断型の自己組織化された開発チーム。詳しい情報は「Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む」を参考に）がある。さらにたくさんの異なるプロダクトがあるため、「何が進んでいるのか」を追跡しつづけ、それを会社の別のメンバーのために可視化している。僕らはプロダクトステータスボードというものを使っており、このボードによって、どのプロダクトがどのステージにいるのかがわかる。ざっくりいうとこんな感じだ。

そのうえ、僕らは予測のためのメカニズムを実験中だ。分隊は定期的に更新する日付のレンジ（X日からY日といった予測日数）を提供することに責任をもっている。この日付によって、分隊のプロダクトがいつ次のステージにたどりつくと考えているかがわかるようになるのだ。

なぜ4つのステージなのか？

最大のリスクは間違ったプロダクトを作ることだ。そんなプロダクトだとユーザーに楽しんでもらえないし、ユーザーの獲得や維持といった成功要因となるメトリクスを改善できない。僕らはこれを「プロダクトリスク」と呼んでいる。

4つのステージモデルはそのリスクを低減し、プロダクトをすばやく公開できる手助けとなる。以下のグラフは、それぞれのステージでどのようにプロダクトリスクを軽減しているか、どれぐらいコストが大きいかを表している。

見ての通り、Think Itステージではリスクを低く抑えている。また、僕らができる限りBuild Itステージを短くしたいと考えている理由もわかってもらえるだろう（高い運用コストと少しのリスク削減がポイント）。Tweak Itにおける少しずつの運用コスト削減によって、時間とともに多くの更新作業の必要性をなくし、分隊は別のことにとりかかる行動に移せるのだ。

それぞれのステージの期間はいろいろ変化する。上に書いたパーセンテージは一例でしかない。トータルの時間も同じだ。あるプロダクトは本番にリリースされるまで何ヶ月もかかかるし、他のプロダクトだと半年かそれ以上かかる場合もある。だが、それぞれのステージ内において、リリース（内部リリースであっても）は極めて絶え間なく完了していっているのだ。

よし、ではそれぞれのステージを詳しく見ていこう。

Think It

プロダクトのアイデアはあらゆるタイミングで生まれ、企業内のあらゆるメンバーから出てくる。ほとんどのアイデアは既存のプロダクトの改善案（Tweaks：微調整）であり、分隊は簡単に実装し、自分たちでリリースまで持っていく。

「Think It」ステージは新しいプロダクトのアイデアの全貌を誰かが考えたときや、既存のプロダクトの再考慮をしたいときのためにある。

もし、マネジメント側がアイデアを探求する価値に同意した場合、小さな職能横断型「Think It」分隊が作られる。通常は開発者やデザイナー、プロダクトオーナーで構成されている。彼らの仕事はプロダクトの定義を書き、説得力のあるプロトタイプを作ることだ。

プロダクト定義は簡単なドキュメントであり、以下のような質問に答えたものだ。

なぜそのプロダクトを作るべきなのか？誰がどのように利益を得るのか？
プロダクトが改善されていると予測でき、鍵となるメトリクスはなにか？このメトリクスによって、どれくらいの音楽がストリーミングされているか？どのくらいダウンロードされているか？どのくらいログインされているか？といった計測できる単位となる。
仮説は何か？このプロダクトが成功した場合、どうやってそれを知ることができるか？
これは「大胆な変更（狙っていたメトリクスを少なくとも2倍にすると予測できそうなプロダクト）」なのか？メトリクス上でちょっとの改善でしかないなら、例えば「戦略的な理由がある」といった、そのプロダクトを作る別の理由があったほうがいい。

プロダクト定義にはドキュメントやプロジェクト計画が必要なわけではない。フィーチャの一覧や予算、リソース計画などが必要なわけでもない。プロダクト定義はデータ駆動の主張のようなものだ。

どんな物語（narrative）を僕らは世界に伝えたいのか？どんなプレスリリースにしたいのか？プロダクト定義の中でもっとも重要な部分は、経験に基づいた物語なのだ。

例えば、最近のプロダクトに「Discover」タブというものがある。この2分間の動画は、以下のような物語を提供している。

音楽を発見するよりよい手段を紹介する。これを見てほしい！あなたによってあなたのお気にいりのアーティストがまさに共有された。僕らはアーティストを以前よりもファンに近い場所に連れてくるんだ。そのアーティストが好きかな？だったら彼らをフォローして、その発見を友人に共有してほしい。

別の例をあげると、モバイルフリーラジオがある。その物語は「保存できるラジオ」というものだ。このケースでは、Google Adwordsを使っていくつかの異なった物語を試し、一番説得力のあるものを経験で学んだ（live and learn）。

物語はプロダクトが作られる前に書かれるというのが鍵だ！僕らのこの方法は、プロダクトの説得力を作る前に生み出すのだ。

さらにいうと、Think It分隊はプロダクトの見た目を実験するために、たくさんの異なったプロトタイプを作る。「忠実度の低い」ペーパープロトタイプでも「忠実度の高い」動くプロトタイプ（ただし偽データを使ってる）でもいいのだ。どれが物語を伝えられる最善のプロトタイプなのかを明らかにするために、内部の調査グループがこのプロトタイプを使うのだ。

これは締切のないイテレーティブなプロセスだ。説得力のある物語や、実際に動くプロトタイプを確認できるまで、作っているプロダクトにはまったく価値がない。だから、前もってどれぐらいの時間がかかるかなんて決めたりしない。

上に記したリスクとコストのカーブが描かれているように、Think Itステージはとても費用対効果のある方法でプロダクトリスクを軽減してくれる。僕らは単にプロトタイプづくりと実験をしているだけだ。この方法は安く済むし、失敗を避ける安全な道を提供してくれる。だから、僕らは作るべき正しいプロダクトが何かを探しながら、チャレンジを続けることができるのだ。

完了の定義： Think Itステージは、マネジメント層や連携している分隊が「このプロダクトは作る価値がある」と信じたら完了だ。もしくは、決して作る価値がないとか、廃止すべきだと判断されたら終わりとなる。

この定義を支えるカッチリしたデータがあるわけではないので、これは主観的な意思決定だ。カッチリしたデータはShip Itステージに登場する。だから、僕らは可能な限り素早くそこに向かうのだ。

Build It

現在、Think It分隊はより長い期間その分隊を維持する形に広がっている（多角的な分隊の場合もある）。Think It分隊のメンバーは開発やテスト、実際のプロダクトの出荷に関係する全てのスキルが必要なのだ。分隊はBuild Itの間だけではなく、長い期間をかけてプロダクトに関わっていく。

Build ItステージのゴールはMVP (Minimum Viable Product)を作ることだ。MVPとは、外部のユーザに十分提供できるものであり、プロダクトとして十分に信頼のあるものを指している。MVPはスクラムやカンバン、エクストリーム・プログラミングのようなアジャイルソフトウェア開発手法を用い、繰り返し作られていく。

そして、MVPにはバランスが存在する。以下の図にあるような、使いものにならないプロダクトと完璧なプロダクトの基準というバランスだ。

出荷後に得られる学習が遅れてしまうため、僕らは出荷する前に完璧なプロダクトを作ろうと思っていない。リアルなユーザーにリアルなソフトウェアをデリバリするまで、正しい方向性かどうかを確認できないので、可能な限りすばやく学習したいと思っている。一方で、使いものにならなかったり、人に見せるのが恥ずかしいプロダクトをリリースしたいとも思わない。たとえプロダクトがアルファ版やベータ版と呼ばれていようとも、ユーザーはSpotifyからすばらしいソフトウェアが登場すると期待している。そして、僕らがどんなプロダクトをリリースしたのかで判断するだろう。

だから、分隊は完全なものではなくて、基本的な物語を実装した、ユーザに喜びを与える、できるだけ小さなものを考えだす必要がある。おそらく、それは「最小の愛らしいプロダクト」と言ったほうがいいかもしれない。自転車は移動手段という意味で愛らしいし便利なプロダクトだ。しかし、自転車がオートバイになるには程遠いだろう。必要最小限の物語を実現する必要があるが、そうしない場合、「ねえ、タイヤをリリースしたけど誰も使ってくれないんだ。だから、プロダクトは失敗でバイクの残りの部分を作るべきではないよ！」というように、作るものの大きさを誤解をしてしまうことだってあるだろう。

Think Itの場合、僕らはできるかぎり全てをショートカットしていき、技術的な品質なんて気にしていない。一方でBuild Itの場合、本番レベルのコードを書き、品質を作っていく。Think ItとBuild Itにはそういった重要な違いがある。

完了の定義： Build Itステージでは必要最小限の物語を実現し、「リアルなユーザーに対してリリース開始可能、かつユーザーを十分に満足させられるプロダクト」になっていて、マネジメント層や連携している分隊がそれを信じたときに完了になる。

これで正念場のための準備ができた！

Ship It

Ship Itステージの目的は、全ユーザーに対して徐々にプロダクトを公開していくためにある。これはプロダクトが市場の期待を実現していくために、測定したりや確実性を高めたりする時間なのだ（[訳注] the product fulfills its promise out in the wildの意味がわからなかった）。

分隊はきちんとしたデータを集めるために、一部のユーザー（通常、1〜5％）にリリースを開始する。そのユーザーはどう行動するか？残りのユーザーと比べたらどうなのか？こういったことを確認するのだ。

思い出してほしい。Thikn Itステージでは、プロダクトのためにいくつかの仮説を定義していた。現在のShip Itステージでは、それらの仮説が正しいかを最終テストできるのだ。そして、必要があればプロダクトをイテレーティブに改善していく。最初のトライで正しい結果を得るのはまれだ。このモデルの強みのひとつは、正しい結果を得る必要がないことだ。

小さなユーザーグループに対して、意図したインパクトを与えているとマネジメント層や分隊が同意した場合、測定や改善を続けながら、より多くのユーザーへとそのプロダクトを公開していく。これによって、ハードウェアのキャパシティやモニタリング、デプロイスクリプト、スケーラビリティといった、運用面を保証するために必要な時間を得られる。

完了の定義： Ship Itステージは、プロダクトが全ユーザーから利用できる状態になったら完了となる。

ここで注意すべき点は、プロダクトはまだ「完全なフィーチャ」になっていないことだ。Ship Itが終わるということの本当の意味は、プロダクト（MVP ＋必要な改善）が100％公開されたときになる。「完全なフィーチャ」なんてものは存在しない。なぜなら、プロダクトはShip Itのあとにも進化し続けるからだ。

Tweak It

Tweak Itはもっとも重要なステージだ。なぜなら、すべてのプロダクトが最後にたどり着く場所だからだ（途中で捨てられなければだけど）。また、プロダクトがほとんどの時間を過ごすステージでもある。

現在、プロダクトは本番環境にあり、すべてのユーザーが利用可能だ。そのプロダクトは、Ship Itステージでちょっとは価値が証明されているが、改善の余地はいつも存在する。分隊はメトリクスを追いかけながら、ABテストで継続的に実験しながらプロダクトを改善していく。この改善はマイナーな微調整のときもあれば、重要な新機能の場合もある。

将来のいつか、プロダクトが衰えていくポイントに到達するかもしれない。たとえば、プロダクト自体はすばらしくて、ほとんどの重要な改善も完了していているが、新しい機能開発のコストと利益の割り合いは下回っている。さらにメトリクスを見ると、新しいフィーチャや改善が目立った変化を起こしているように見えない。

これは、プロダクトが「局所的な最大値」に達したという意味だ。

このポイントに来ると、マネジメント層や分隊はこんな議論を開始するだろう。プロダクトの最高地点だけど僕らはハッピーなのだろうか？まだ高みは望めるだろうか？ハッピーじゃないならば、分隊は徐々に別のプロダクトへとシフトしていく。高みが望めそうならば、分隊は「Think It」に戻り、プロダクトを再考するかもしれない。そして、全体的な最高地点のために躍進しようとする（少なくとも今より高い地点に……）。

ひとつの例としてspotify.comがある。spotify.comは2012年の夏に再考されたウェブサイトであり、再考する前に4年間にわたって微調整されてきた。現在ではSpotifyのビジョンを、昔とまったく違った方法であり、劇的でより効果的な方法で伝えている。

全体図

最後に

楽しんでもらえたかな！

もし、このモデルのある部分で「何言ってるの、そんなこともう知ってるよ。僕らはもう10年やってるしね」と思うのであれば、それはきっと正しい方法だ。このモデルは新しくて驚くべきものではないし、単純な仕事の本質は新しいか古いかなんて関係ない。僕は今回のようなプラクティスのコンビネーションを、自分自身のひらめきや力にするために発見した。そしてなによりも僕は、みんながみんなのコンテキストの中で便利なモデルを見つけることを祈っている。

もしフィードバックや質問があれば、気軽に連絡してほしい。僕のブログにコメントを書いてくれてもいい。たぶん、質問に詳しく答える時間がないだろうけど、この記事に関して共通する質問があれば、それをベースとしたFAQを追加するかもしれない。

/Henrik Kniberg
henrik.kniberg@spotify.com
http://www.crisp.se/henrik.kniberg
2013年1月18日

訳者あとがき

エリック・リースが示したリーンスタートアップはいまやプロダクトやサービス開発のコンテキストのみならず、ソフトウェア開発全般に影響を与えている。誰も答えを持っていない世界で(これを作れば売上が必ずいくら上がる!なんて誰も言えない)、どんなプロダクトを提供すれば良いのか、その探し方を示すものだ。Bulid – Measure – Learnのサイクルの下、小さな失敗を重ねてプロダクトを育てていく。立てた仮説を検証するために、MVP(minimum viable product)を動くソフトウェアもしくは人力で提供する。こういったリーンスタートアップの原則を実践するにあたって、アジャイル開発は必要不可欠となるスタイルだ。

というのは教科書的に良く耳にすることだ。確かに、リーンスタートアップのコンセプトは参考になる。だが、このコンセプトに則り実際にモノを作る、ソフトウェア開発に落としこむには距離を感じる。ソフトウェアはチームで作る。Build – Measure – Learnのサイクルにどんな役割がどのように関わるのだろうか。このサイクルをそのままアジャイル開発のイテレーションに当てはめれば良いのだろうか。そのステップはどのような完了の定義をすれば良いのだろうか。MVPとは実際にはどの程度まで作りこまれたソフトウェアなのだろうか。いくつもの疑問がよぎるのだ。

ヘンリックは、ここでも活きた道筋を僕たちに示してくれている。「Think It」「Build It」「Ship It」「Tweak It」という4つのステージによって、プロダクトの状態を管理する。各ステージ内にはBulid-Measure-Learnのステップを内在させている。ステージの完了の定義も明快だ。プロダクト開発がどこから出発し、どこへどうやって向うのか、その道のりを彼は具体的にかつ明確に示しているのだ。しかも、理論(考えたこと)ではなく、実践(やったこと)。説得力がある。

Spotifyにおけるプロダクト開発の方法は、もちろんSpotifyの現場やコンテキストの下にデザインされたものだ。書籍「リーン開発の現場」でのスウェーデン警察内の開発と同様に、その場その時に最も適したやり方を模索し実装し改善し続ける、彼のその自在さに私たちはここでも脱帽させられるのである。