ちょっと前にRunningLeanを読み終わりました。リーンスタートアップの基本は顧客の欲しいものを作りましょうで、特別な事はなにも言ってないのですが、ここまで徹底した姿勢は衝撃でした。

今まで一番影響を受けたのがポールグレアムのエッセイだとしたら、RunningLeanはその次ぐらいかもしれない。この本を読んでると、”まるでスタートアップを受託開発してるみたいだな”と思いました。

受託開発だと顧客は最初からいるしお金も発生する。でも、スタートアップが新製品を作る時はリリースするまで売れるかわからない。人々が欲しいものと維持可能なビジネスモデルを模索するのがスタートアップなので最初は実証前の仮説しかない。

リーンスタートアップではこのリスクを出来る限り減らすために、これでもかというぐらい顧客に意見を聞いて、顧客にお金を払う価値があるかを確認しながら作っていくので、スタートアップの受託開発みたいという感想が頭に出てきました。

ちなみに、著者のAshさんは、90％以上は失敗するスタートアップの成功確率を、1,2％でも上げるための本だよと書いてます。いろいろ勉強になったのですが、特に重要だと思った部分を今回は書いてみます。

＠目次
「顧客に欲しいものを聞いてはいけない」
「顧客の話を聞く順番と意味」
「自分が欲しいものなら顧客の意見は聞かなくてよいか」
「芸術作品やネットワーク効果が必要なものはどうするか」

顧客に欲しいものを聞いてはいけない

顧客の意見を聞くのは大事だけど、顧客の意見を聞くなっていうのもよく言われます。例えば、iPadやiPhoneは人々が何が欲しいかを聞いてたらできなかっただろうし、「人々になにが欲しいかを聞いてたら、速い馬車を作ってたわ！」というフォードの言葉も有名です。（LeanstartupのgoogleGroupでは、フォードは実際にはこんなこと言ってないとか話題になってたけど）

僕もこのへんの違いがよくわかってなかったのですが、RunningLean読んですっきりしました。本では、「困っている問題を聞くのはよいけど、解決策は自分で考えないといけない！」と書いてた。

つまり、顧客は問題を説明できるけど、解決策を説明するのは難しい。なので、顧客には今抱えている問題をまず聞く。それが解決する価値のある大きな問題かを考え、そうであれば解決策を自分で考える。その後、自分で思いついた実現可能な解決策のアイデアを、実際胃に作る前に顧客に聞いてみるという順番になるらしい。

顧客の話を聞く順番と意味

このインタビューの段階も、「問題だけ聞くインタビュー」から始り、「問題を確認して、解決策への反応を聞くインタビュー」に続き、「試作品を作って、これを作ったらお金払ってくれるか聞いてみるインタビュー」と、ひたすら製品を作り始めるまで地道な作業が続きます。

RunningLeanでは、このインタビューの相手の探し方、聞き方など、具体的にどうやるかまでめちゃくちゃ詳細に書かれているのが素晴らしい。ポイントは、製品を売ろうとしないで、どういう点で困っているか問題を聞くことに集中しろとのこと。

開発する前に顧客の意見を聞く利点は２つあり、一つ目は誰も欲しがらない製品を作って時間を無駄にするのを防ぐ。二つ目は、製品を作る前から顧客との接点を開拓してるので、出来上がった時すぐに一番欲しい人に伝える事ができる。特に、二つ目が重要だと思った。

僕が作っているLisgoは自分が死ぬほど欲しかったものなので、周りの意見なんてあまり聞く前からオラオラで作り始めたわけです。もちろん、周りにはアイデアを話しまくっていたのですが。

しかし、最小限の機能で最初にリリースした時に使ってくれる人は、最小限の機能でもよいから本当に欲しい人だけです。でも、そういった最初の顧客となってくれる人たちとのつながりがないので、今はけっこう苦労しています。作った後に分かった事もいろいろあるので、次からは製品を凄く欲しいと言ってくれる人の意見を聞いてから開発を始めようと思った。

ちなみに、RunningLeanではインタビューでなにを聞けばよいかなど、とても詳細な例があって分かりやすい。自分も最初に買ってくれたアメリカ人の人にスカイプでインタビューしてみたり、いろいろ試しているので、このへんの詳細は次回に書いてみます。

自分が欲しいものなら顧客の意見は聞かなくてよいか

37signalsやグレアムが言うように、自分が欲しいものを作るのは一番の近道だと思います。でも、Ash師匠は「自分が欲しいものを作るだけでは十分ではない。顧客の意見を聞かない理由にはならないよ！」と書いてます。

自分一人専用に作るのなら問題ないのですが、他の人にも使って欲しい場合は、自分の感覚と他の人の感覚が同じかどうかは検証するまで分からない。特にスタートアップはスケールしないといけない。早い段階で重要な部分を検証しないと、誰も欲しくないものを作って時間を無駄にするリスクが高まってしまう。

Lisgoの場合、「自分が死ぬほど欲しいから間違いない！」と思って作ってました。他の人もモノを試せば絶対によさがわかるであろうという感じです。でも、今考えてみると、周りの友達に受けなくても諦めることはないけど、自分がターゲットとしているユーザを探して、開発する前にアドバイスを聞くべきだった。

というのも、やはり自分の考えてた予測と違っていた部分がたくさんあったからです。

最初、LisgoはWeb記事の音声読み上げだからオーディオブックユーザなら良さが分かってくれるだろうと考えていました。日本でオーディオブックは普及してないから、まあ作るまでは分からないだろうと。

でも、オーディオブックユーザがWeb記事読むとは限らないし、ライフハックに興味がある人でもオーディオブックに興味があるとは限らないとも後々わかってきました。自分の予想のズレを少しずつ修正している毎日です。こういうことは、早めにすればするほど無駄な機能を作るリスクが減ると思います。

芸術作品やネットワーク効果が必要なものはどうするか

これに関してはよくわからない。おそらく芸術作品は問題解決ではないので、リーンスタートアップの手法はなかなか適用できないのではないかと思う。ネットワーク効果のあるものに関しては、ピンポイントの記事がリーンスタートアップジャパンにあります。とても面白い。

とにかく、特定の問題がある場合は顧客に意見を聞いても教えてくれると思うのですが、絵画とかを小説とか書く時はどうなんでしょう。この場合、問題を聞いてもしょうがないから、プロトタイプの感想を聞きながら作るのがよいのでしょうか。うーむ、不可能ではないけど、なかなか当てはめにくいと思う。

特にゲーム開発などは、問題解決ではないから、問題のインタビューしても意味ない気がする。この場合は、とにかくモックを作ってから意見を聞き始めるのがいいのでしょうか。

ネットワーク効果が必要なTwitterのようなサービスの場合、まず少人数で価値を確かめる事が重要だとして、数が増えた時に価値が増幅する体験はその時になるまでユーザには体感できないのが悩みどころです。なにかアイデアある方教えてください。

ちなみに、Ash師匠は、ネットワーク効果の必要なモデルに有効だと思うリーンスタートアップの手法はあるけど、実際に自分が経験したのは課金モデルのWebサービス(SaaS)なので、本では書かないとRunningLeanで最初に言及しています。

さて、ここまで書いてみて、顧客の声を聞くのは重要だと分かったけど、友達でもない限り、わざわざアドバイスくれる人はいないっすと思うのが自然な考えではないでしょうか。これはその通りで、自分も今苦労している所です。どうやって最初の顧客を探すかという方法、自分の事例も含め、このへんを次回は詳しく書いてみようと思います。