2011年は日本におけるリーンスタートアップの元年とも言えるとしでしたが、まだまだ”LAMP+クラウド”による小資本起業のことをリーンスタートアップと呼ぶと思っている方も多いようです。

 

リーンスタートアップの本質は、ユーザやマーケットとの対話(フィードバックループ)の中から市場のニーズを学び、製品コンセプト、実装機能、価格などに反映をさせながらビジネスモデルを構築していく「サイクル型起業」であることです。

 

 

すでにサービスをローンチしているスタートアップの方と、ユーザ利用状況の「測定」について話しをする機会があるのですが、正直、あまり測定にチカラを注いでいる方は少ないのが現状です。測定しているにしても、登録ユーザ数やログイン回数などといった一般的な数値(メトリクス)が主流で、もう少し掘り下げた分析が可能になるようなデータを定期的に取得しているかたが少ないと感じています。

 

これでは、せっかく小資本による起業(サービスローンチ)ができたにも関わらず、成長の機会を自ら手放してしまっているも同然で、実にもったいないな・・・と思うのです。大企業に比べたら「とてつもないぐらいに早いスピード感」をもって意思決定を行える体制であるにも関わらず、そのスピードを最大化するチャンスを放棄しているも同然だからです。

 

そこで今回は、エリック・リースがメトリクスの重要性に気づいた際のエピソード記事をご紹介したいと思います。

 

当時、IMVUのCTOでもあり自らプログラミングを行なっていた彼は、当初はメトリクスの重要性に気づくことがありませんでした。しかし、来る日も来る日も売上「ゼロ行進」が続いたある日、自分たちでは発想することすらできなかった「事実」を、「測定結果」から知ることになります。

 

そうした事実を知るまでに費やした膨大な時間や資源がすべてムダであったことのショックとどのように向き合ったかも含め、

2009年2月にポストされた「動作するプログラムを捨てること “Throwing away working code”」という記事の抄訳を御覧ください。

 

原文はこちら
—————————————————————————————————
リーンスタートアップはシステマティックに「ムダ」を排除します。リーンスタートアップは以前から存在していた数々の優れた教えから構成されており、例えばアジャイルメソッドからは、開発チームの進捗とは「機能するコードの完成のみを進捗と呼ぶ」といった教えを参考にしています。しかしリーンスタートアップにおいては、この定義だけでは十分ではありません。なぜなら、スタートアップにおいては「動作するプログラム」自体がムダな存在になりえるシチュエーションが存在するからです。

 

私はかつて、メトリクスに対して(時間やリソースを)投資することはムダなことだと考えていました。第一に、ユーザはあなたが優れたメトリクスを使用していることなどは意に介さず、ただ良い製品かどうかだけを判断すると思っていたのです。時として良いメトリクスが良い製品開発へと導くことがあるにせよ、私の経験上ではメトリクスとは「下してしまった決定事項を過去の情報で正当化した、決して誰も読むことのない意味のないレポート」のような存在であり、事態の本質を表現するようなシロモノではなかったのです。

 

しかし、私がIMVUで「メトリクスをベースとしたディシジョンメイキング」の素晴らしさを学んだのは、必要に迫られた結果によるものでした。私たちはサービス開始初日から販売ターゲットを設定し、最初の1ヶ月は$300としました。たしか翌月は$350、そして翌月は・・・といった感じです。こうしたターゲットは単純に自分たちの友人、家族、親戚の人数から弾きだした数値で、初期段階にあるプロダクトの購入を個人的にお願いできる見込み顧客数から算出していました。そしてみなさんの予想通り、あっという間にその人数は頭打ちになったのです。

 

こうした頭打ちの状態を打破するために、SEM対策と称してGoogle AdWordsを1日$5ずつ購入したという失敗談は以前にも記事にしました。そこで得たユーザの何人かは有料ユーザになってくれることを信じて、$5で100クリックを毎日、毎日購入し続けたのです。そしてこのままでは誰も有料登録しないことに気づいた時、自分たちが数字の大切さに気づいていなかったことを憂慮し始めました。ターゲットした目標は哀れなほどに小さかったにも関わらずです。そしてようやく、プロダクトの改修に着手しました。より簡単に決済でき、かつ有料登録する価値があることを明確に訴え、ダウンロードを簡略にし・・・といったようなことにです。(こうした改修手順を)いま振り返ると、自分たちはファネルを逆行していたように思えます。しかも最も楽観的な観点でです。当然ながら自分たちのサービスに根本的な欠陥があることは信じたくもありませんでしたし、仮に失敗があるにしても、それは動作環境、ユーザビリティ、技術的な問題などであって欲しいと思っていたのです。

 

こうした「実験的な経営」を続けても、来る日も来る日も売上を上げることなく日々は過ぎ去りました。そこでようやく、簡単なデータを用いて、いくつかの重要なステージごとにユーザの行動分析をはじめたのです。結果は。。。実に惨憺たるものでした。本当にいつも「ゼロ」かそれに近い数値だったのです。この赤裸々な失敗の事実を目の当たりにしてようやく、問題がどこまで巨大なものなのかを把握するまで、一歩ずつ追求することを決意したのです。サービス品質が著しく低いことは歴然とした事実であり、非常に重要だと考えていた幾つかの機能すらまともに動作しなかったのです。最も衝撃的だったのは、誰も最初の数ステップすらも操作してくれていなかったのです!

 

こうして私たちはついに「問題」と向き合いました。製品のコア・コンセプトこそが大きな欠陥を持っているという問題にです。「メトリクス(測定を行うこと)の効果」という重大な学びを通じて私が悟ったのは、後に「スタートアップにおけるフィードバックループ」の主要なパートをとなります。もしあの時にまだ資金面で余裕があったり、進捗をページビューやプログラムの開発工程で測定していたとしたら、決して気づかなかったことでしょう。

 

IM(インスタントメッセンジャー)機能を実装した3Dチャットという元々のコンセプトがなぜ機能しなかったかという疑問については、別のブログポストで触れていますが(Bowling Aloneという記事を参照のこと)、少なくともこうした機能が適切に動作していないことがビジネスの成長を妨げているわけではない、ということはハッキリしたのです。

 

IMVUのクライアントアプリケーションは、ありとあらゆるIMソフトウェアとの連携を考慮しつつ私自身がコーディングしたものでした。私たちは膨大なコードの開発とテストに数えきれないほどの時間を費やし、他のメンバーもメンテナンスに明け暮れたのです。

 

そして訪れた経営方針の転換のタイミングで、私は(開発担当者として)叫びたくなるほどの苦悩に直面しました。それは、これまで開発したソースコードを手放し、1から再設計するという新方針との戦いです。経営会議に頻繁に参加しては、なんとかソースを守ることはできないかと願ったものです。当時のタイミングでは、まだ成果は出ていないものの、こうした機能が将来的にはユーザに受け入れられる可能性をすべて否定することができませんでした。自社の価値は、ありとあらゆるIMネットワークへのコネクションにあるという考えとビジネスの結果がすでに矛盾していたにも関わらずです。さらに深刻だったのは、すでに開発済みのプログラムを「資産」だと考え、それを放棄するということはさらにコストがかかることだと考えていたことです。しかし実態は、開発済みのプログラムは我々を成功に導くことができなかったばかりか、実は埋没費用(回収不可能なコスト)だったのです。

 

私が幸運だったのは、のちに共同創業者がプロダクトの活路を見出し、ユーザが本当に求める製品の開発に移行できたことです。このエピソードは私にとっての重要な気づきをもたらしました。「メトリクスの効果」という気づきです。そして多くの時間を費やした成果物を放棄することの辛さを通じて、「本当の浪費」とは何かという難題を理解することが出来たのです。

 

偉大なる企業を創り上げるには、あなたは「自分自身がなにを成し遂げようとしているのか」というゴール設定に対して、少しの曖昧さも持ってはいけません。創業初期のスタートアップにとっては、ユーザが何を欲し、何に対してなら対価を支払うかを学ぶことができる「素早いフィードバックループ」を構築することがゴールであるべきです。たとえ他のすべてのゴールが重要に思えたとしても、フィードバックループなきゴールはすべてが「浪費」なのです

—————————————————————————————————

今日ご紹介した記事は、エリック・リースがフィードバックループという考えに至ったきっかけとなる大きな失敗の告白記事でした。

 

PDCAサイクルで有名なエドワード・デミング博士は「測定されていないものは改善できない※注という言葉を残しました。

PDCAサイクルにしても、Build, Measure, Learnのフィードバックループにしても、ループ状に形成された活動(プロセス)によってより高みを目指す場合には、「測定(メジャー)」「測定指標(メトリクス)」は絶対不可欠な存在となります。

 

急速に成長する企業は、例外なく「表面上は見えない強み」を持っています。

表面上には見えない強みとは、ユーザが理解できる製品そのものの強みではなく、企業が「内部で創り上げた圧倒的な優位性」のことです。例えばトヨタが世界品質標準となる自動車を創り上げた背景には、カンバン方式に代表される徹底された生産管理システムを産み出したことが圧倒的な優位性につながっています。しかし消費者もマーケットも「トヨタはカンバン方式を産み出したからトヨタ車を購入しよう」とは思いません。見えるのは製品化された優れた品質のプロダクト(自動車)だけなのです。

 

企業の強みとは、常にマーケットから見えないところに存在します。

もう一度フィードバックループの図を見ていただきたいのですが、マーケットから見えるのは「Build」のプロセスによって世に出た製品・サービスのみです。しかし、本当の企業の強みとは、Measure, Learnのプロセスによって生み出され、Buildへとフィードバックされていくのです。

 

 

今回の記事で測定の重要性は感じていただけましたでしょうか。

次回の記事ではスタートアップが測定すべき指標についてもう少し掘り下げて、具体例をご紹介しようかと思います。

お楽しみに!

 

※注(元プロセス・コンサルタントとしてのひとりごと)

この言葉に対しては、実は世間で多くの反証意見があります。主なものは、測定を行なっても大きな改善やイノベーションを生み出すことはできないというものであり、デミング自身やデマルコ(ソフトウェア工学の第一人者)もこの言葉のひとり歩きを否定しています。しかし反証のポイントは「測定した結果にただ対処していてもイノベーションにはつながらず、対処療法的経営になるだけだ」ということです。つまり測定そのものを否定しているのではなく、その後のプロセス”Learn”や”Action”の問題だということです。経営プロセスは、プロセスそのものの実行を目的とした瞬間に価値を失います。よくプロセスを「実行する順序」だと勘違いする方がいらっしゃいますが、プロセスとは「思考順序」のことです。プロセスに従って思考することによって最も効率的に価値を最大化させることができるのです。プロセスの進捗を測定する場合、プロセスの実行そのものを測定するのではなく、プロセスに従って思考したことで得られた「効果」や「価値」に対して測定を行う必要があるのです。

 

 

あ、今年もMeetupやります!

よろしければぜひご参加下さい。豪華ゲストです!

http://everevo.com/event/839