Spotifyは失敗が得意でありたい

いつでも実験のできる，失敗の得意な企業でありたい – エンジニアリングディレクタのMarcus Frödin氏は，Spotifyをこのように言う。Spark the Change London 2016で氏は，失敗から学んで成功を生むという概念をプレゼンテーションして，Spotifyが失敗から学んだ実例について紹介した。

Spotifyは“何でもやってみて”，“失敗することが得意な”会社になりたいのだ，とFrödin氏は言う。“何でもやってみる”というのは，たくさんのことを並行して行なえる組織でありたいと望んでいる，という意味だ。失敗を効果的に活かすためにSpotifyは，短いフィードバックループで学習のできる組織を目指している。

大規模な組織において，コミュニケーションが問題になるのは珍しいことではない。対処の秘訣は，コミュニケーションコストの上昇を上回るコミュニケーションの必要性低減を達成することだ，とFrödin氏は言う。コミュニケーションの必要性を低減するためにSpotifyでは，開発部隊と提供部隊を常に同じ場所に配置するようにしている。

リーダは，チームに自分の意図(Intent)を伝えること，チームから上ってくる情報をピックアップして知識(Knowledge)として拡げること，この２つに多くの時間を費やしている。意図は方向性(Alignment)をもたらすためだとFrödin氏は言う。誰かにアイデアがあれば，指揮命令を使わずにそれを広めたいのだ。

Frödin氏はこの意図 - 仮説(Hypothesis) - フィードバックというループを掘り下げて，組織が革新する方法について説明する。意図と仮説の間には方向性のギャップ(Alignment Gap)が存在する。ギャップにはこの他に，効果のギャップ(Effects Gap, 仮説とフィードバックの間)と知識のギャップ(Knowledge Gap, フィードバックと意図の間)がある。大部分の人たちが注目しているのは方向性のギャップだ，とFrödin氏は言う。しかし重要なのは，仮説とフィードバックによって生じる，効果のギャップと知識のギャップの方なのだ。

Spotityの描く意図 - 仮説 - フィードバックループ

学習と実験に関しては，これと意見を同じくする人たちもいる。InfoQはTiago Garcez氏にインタビューして，失敗から学ぶために実験を使用することについて尋ねてみた。

失敗は常に起こり得ます - 実際に失敗した場合にどうなるのか，想像さえしたくないことも時にはあります (...)。それ(“失敗は常に起こり得る”)を正しく認識できるならば，それを避けるための選択肢も明らかになるはずです。例えば“セーフ・ツー・フェール(Safe-to-fail)”などは，今日の私たちがよく耳にすることばのひとつです。考え方はごく単純です – 相応のリスクを伴った何らかの行動を起こす前に，成功結果と失敗結果が事前に明らかで，かつコントロールの可能な試験を使って，考えられる解決策や善後策を予め評価しておくのです。このようなアプローチによって，失敗を高価でミッションクリティカルなものにすることなく，学びの機会を(その試験がコヒーレントな方法で構造化されていれば)提供することが可能になります。

Frödin氏は，期待通りに進まなかったイノベーションのひとつとして，Spotifyアプリストアを例にあげた。基本的なアイデアは，サードパーティが開発したアプリをリスナに提供して，音楽を聴いたり，新たな検索をするために利用してもらう，というものだった。このアプリストアは，Spotifyがミュージックプラットフォームとなるのをサポートするとともに，既存のWeb技術を使ってオペレーティングシステムを仮想化することにより，内部ソフトウェアを短期間で提供可能にするものと期待されていた。

2011年，デスクトップ用アプリストアの最初のバージョンが公開されると，すぐに数百のアプリがストアに登録された。しかし2012年になってもアプリの数は大幅に増えず，調査の結果でも，Spotifyのリスナがアプリをそれほど使っていないという結果が示されていた。2013年になると，モバイルの本格的な普及が明らかになったため，同社はアプリをモバイルにも展開するか，あるいはシャットダウンするかを決めなければならなくなった。アプリストアに対する期待が満たされなかったことから，同社は2013年にアプリストアの段階的な終了を決定したが，完全にサービスが終了するまでには，さらに２年以上を待たなくてはならなかった。

アプリストアが失敗した大きな理由は，収益化の可能性が不十分であったことと，ユーザ数が少ないままであったことだ。そこに基本的な知識のギャップがあった，とFrödin氏は言う。この失敗から同社が学んだのは，彼らが想定していた程度の規模では，目的を特定したアプリストアは成功しないということだ。

現実の厳しさと学習に関するJeffrey Fredrick氏とのインタビューで，氏は，失敗からいかに学ぶかについて説明している。

何よりもまず考え方だ，と私は思います。まずは願望です。その次には，可能な限り自己批判的かつ寛容になって，自分が失敗をしたという事実を受け入れるのです。失敗が自分自身，つまり個人としてのあなたそのものだという考え方では，失敗から学ぶのは非常に難しくなります。対して，失敗を訂正可能な振る舞いとして理解するならば，失敗を受け入れて改善し，それを意図的な向上の手段とできるのならば – 同じ失敗を繰り返さないためには何を変えればよいのか，具体的に意識できるような考え方や実践方法に達することができるのです。

Frödin氏はSpotifyのモバイル移行にも触れている。モバイル移行は大変な難作業だった。3年にわたって，当初はたったひとつのチームが６ヶ月周期でモバイルソフトウェアをリリースしていた。企業がモバイルに移行する間，Spotifyチームはデスクトップでデモを続けていた。氏は2013年2月に送信された，SpotifyのCTOがSpotifyがモバイル企業になる戦略をローンチしたEメールを見せてくれた。その後，モバイルソフトウェアを提供するSpotifyの開発チームは，当初の１チームから全チームへと拡大した。 振り返ってみれば，知識を構築するためにもモバイル移行はもっと早く始めるべきだった，と氏は述べている。モバイル用プラットフォームの構築にもっと注力すべきだったのだ。

Spotifyには，彼らがデータ/洞察/確信/予想 (Data/Insight/Belief/Bets, DIBB)と呼ぶ概念がある。DIBBについて氏は，“私たちの信頼の拠り所であり，それを信じる理由を理解したいもの”だとしている。DIBBは戦略に対しても，文化に対しても適用される。文化に関わるDIBBの一例は，イテレーションのスピードはイテレーションの品質に勝る，という“確信”だ。この確信からの“予想”に基づいてSpotifyは，同社の組織，文化，アーキテクチャ，プロセスを，それまでの開発リソースの使用率や機能毎の構築コストといったものから，学習と実践のスピードに対して最適化するようになった。その基礎となる”洞察”は，コードはユーザに提供されて始めてそれを学ぶことができる，従ってリリースの頻度を上げればより多くを学ぶことができる，という考え方だ。提供価値を高めるには，頻繁なリリースが必要なのだ。この洞察の元になった“データ”は，ソフトウェア開発の現代的メソッドはすべて定常的な学習を伴う短いイテレーションに依存している，実現されなかった多くのアイデアが存在する，というものだ。このようなアイデアのテストを開発し，提供する必要がある。

Spotifyは予想，すなわち自分たちがすぐに行なうべき事をボードに貼り出している。この予想ボードは，社内の誰でも参照可能だ。

プレゼンテーションのまとめとして，氏は次の３つを挙げた。

• 自立と方向性の相互関係 – ピアベースのチームに権限を付与し，失敗が迅速に通知されること，ボキャブラリが文化を具現化することを確認する。
• Darwinを打ち破るためのイテレーション – 失敗の予測と振り返り，意図的なコピー，DarwinではなくBayesであれ。
• 過剰反応は対応不足に勝る – 出荷に疑問がある時は，担当者を価値提供の最も近くに置いて，代わりの者を雇い入れること。