「真の爆速は速すぎて見えない」 ヤフーにおけるリーンスタートアップの実践。IBM Innovate 2013
大規模な組織であってもリーンスタートアップのような方法論は重要である。IBMが10月28日に都内で開催したイベント「Innovate 2013」の基調講演に登壇したヤフーの河合氏は、同社におけるリーンスタートアップの事例を通してこのことを示しました。
エンタープライズ向けのサービスであっても、つねに改善のサイクルを迅速に回すことが不可欠になってきています。ヤフーの取り組みがどのようなものなのか、河合氏の講演内容をダイジェストで紹介しましょう。
大組織におけるリーン・スタートアップ
ヤフー株式会社 CMO (Chief Mobile Officer)室。河合太郎氏
ヤフーはいま、「爆速」や「課題解決エンジン」を掲げています。
そして「!」なサービスを生み出そうとしています。課題を解決する「!」なサービスとは何かというと、それは誰も答えを持っていないわけです。
それを開発して世の中に提示していかなくてはいけません。
新しいサービスを作るときの企画書の「あるある」では、「このマーケット規模は1283億円」や「初期DUBの想定は11万8000……」のような、やたら具体的な数字が並ぶわけですが、これは全部ウソです。控えめに言っても希望的観測です。
この段階でそういうのが分かっている訳がありません。
まずこの、事実として我々は何も分かってないことを認識する必要があります。
こうした曖昧な課題を確かなものに変えていくための方法論が「リーンスタートアップ」です。
曖昧なものを確かなものに変えていく。どうやって? 不確かなものを検証し、修正し、確からしさを高めていく。
これを速く回すほど、仮説がどんどん確からしくなっていく。では、どうやって速く回すか。完全な製品はそんなに速く作れるものではない。
なのでリーンスタートアップではある一部分の仮説を立てて、それを検証するのに十分な製品を作ります。それがMVP(Minimum Viable Product)と呼ばれるものです。
「僕の来た道」ができるまで
ヤフーに「僕の来た道」というライフログアプリがあります。訪れた場所や滞在時間などを自動記録して、日記スタイルで分かりやすく表示してくれます。
特徴は電池消費が気にならないところです。
この「僕の来た道」の発端となったアイデアは、ずっと位置情報を記録し続けたら面白いじゃないか、というものでした。プランAはGPSロガーだったんです。
でもそれが本当に面白いのか、そもそも実現できるのか、という疑問がありました。そこで、GPSを記録し続け、地図上にその軌跡を表示するだけのアプリを作成し、社内で配布しました。
そのフィードバックは、何もしなくても位置が記録されるのは面白いけれど、バッテリーが半日も持たず、使い物にならないということでした。
そこでバッテリー消費問題を繰り返し検証しました。
しかし改善せず、丸一日バックグランドでGPSを記録するのは無理だと。ということで、ピボットする必要性に迫られました。
社内にインタビューしたところ、正確に位置を記録したいというのは数少ないGPSマニアの要望で、正確な位置情報ではなくても日記的にあとから見たい、というニーズは思った以上に多く、特に女性に多くありました。
そこで基地局の情報から位置を表示して記録するアプリを作ってみました。
精度は低いのですが、バッテリーが持ちます。ここでピボットが決定されました。「おしゃれ女子のための自動日記ツール」と言う人までいました。
これでゴール。おめでとうございます。
ユーザー体験は理不尽に減衰する
本当にそうでしょうか? いいものができるとゴールした気になります。しかし、ユーザー体験はあっという間に減衰します。
魅力的なライバルの登場やバグの発覚、ユーザー数が伸び悩んだり、モノは変わってないのにユーザー体験は減衰していくという、ある意味で理不尽なことが起きます。
私たちはついつい最大値のところがそのサービスのスループットだと勘違いしてしまいますが、それは減衰していくのです。サービス提供側はライフタイム全体のスループットを積分した面積をどれだけ上げられるか、を考えなければなりません。
フィードバックのサイクルが速ければ速いほど、面積を増やせます。
リーンスタートアップもアジャイル開発もDevOpsも、すべてのモダンな方法論は、このスコープ中のスループットを最大化する、これに集約されると思います。
我々が爆速を掲げるのは、このスループットを高く保つための速さが爆速だということです。爆速は「なるはや」とはノットイコールです。なるはやは最初だけが速いのに対して、爆速はサイクル間も速いことを目指しています。
「爆速」と言い始めたのは社長の宮坂ですが、宮坂は「私は井上(前社長)より頭は良くないが、二倍速く失敗して二倍速くリカバリする」と言いました。
その意味で、真の爆速は速すぎて見えない。目指すところはこういうことになります。
もう1つの爆速
爆速のもう1つの面は、人やカルチャーに影響する点です。
実は爆速とは何かとは、社内ですら明確に語られておらず、曖昧なままです。とにかく分からないけれど速くなければいけないのだろう、というコンセンサスはできていて、爆速でお願いします、爆速でやります、という文化は根付いてきました。
メソッドの応用はどうしても座学の面が多くて、頭では分かっていても体がついてこないですし、体は動いてもメソッドがイマイチよく分かっていなければそれもだめです。
なのでビジョンとボトムアップの両輪が必要で、それによって魚群のようにみんなが一斉に素早く動くのがいいわけです。「爆速」はそのための言霊になっていて、そういう言葉の力も重要になっているのかなと感じているところです。
あわせて読みたい
オラクル、GlassFish商用版を廃止へ。参照実装の役割は変わらず。商用サポートはWebLogicへ一本化
≪前の記事
JavaScriptだけでAmazonクラウドのストレージ、NoSQLデータベース、プッシュ通知、ソーシャルログインなどを実現する「AWS SDK for JavaScript in the Browser 」公開