プロトタイプを作る前にやっておきたい、開発しない仮説検証

短いサイクルで仮説検証するために必要なこと

安西結氏：Pivotal Labs Tokyoの安西結です。よろしくお願いします。

みなさん、こういうことありませんか？　「機能のアイデアを考えて、開発してリリースしたんだけど思ったように成果が出ないな……」とか、仮説検証の本を読んで悩んだ挙句、「とりあえずA/Bテストに回してみたけど、なんかちょっと違う気がする……」とか。これ、私が昔、実際に悩んでいたことなんです。

今日は「短時間でいかに素早く仮説検証をするか」を考えるきっかけになったらうれしいなと思ってお話しします。

まず「おまえ誰やねん」という方がけっこういらっしゃると思うので、自己紹介します。（スライドを指して）こういう者です。価値のあるプロダクトを作る方法を、リーンスタートアップとかアジャイルとかの手法を使ってお客さんにコーチングする仕事をしています。

みなさんはご存知だと思うんですけれども、「短いサイクルで作る、学ぶ、測るということをやりながら、リスクが上がらないように抑えましょう」というのがリーンスタートアップの考え方です。

ここで肝になるのが「短いサイクルで」というところです。短いサイクルで素早く仮説検証するために大切なのは、「課題の仮説、施策の仮説、最適化という3つのフェーズがある」という考え方なのかなと思っています。

そもそもの課題設定自体が正しくない可能性

例えば、とあるアプリの定例会議の光景（を思い浮かべてください）。ユーザー数がなかなか伸びないという悩みに対して、「文言を見直したらどうか」「チュートリアルを作ろう」「SNSログインがいるんじゃない？」といった、いろいろな案が出てきたりしますよね。

例えば「登録フォームを改善しよう」っていうのは、すごく良いアイデアに思えます。けれども、そのときって「登録フォームを改善することで、登録完了率を上げることができる」という最適化の仮説のもとに動いてるんですね。

でも、本当に今「登録フォームの改善をする」ことが、1番優先事項が高い施策なんだろうか？　あるいは「SNS連携」という施策が、自分たちのプロダクトにおいて本当に有効な施策なんだろうか？　もう1歩遡って考えると、そもそもこの課題設定って正しいんでしたっけ？　そういったことが考えられます。

「ユーザーはこのプロダクトを使いたいと思ってるんだけど、面倒なので途中で諦めている」という思い込みの仮説が、さっきの会話の中であると思うんです。でも、そもそもこのプロダクトの価値ってユーザーに伝わっているんだろうか。あるいはそれが伝わっていたとしても、本当にユーザーにとって「お金を払って解決したい」と思うほど重要な課題なんだろうかということが、実は検証できていないのかもしれない。

個人的な経験としても、文言だったり画面の見た目や機能の改善といった、細かい最適化に走ってしまいがちだったんです。それがすごくもったいなかったなと、今になって思ってます。

すぐに動くものを作って検証してしまいがち

課題の検証って、新しいサービスなら意識してやっていたとしても、機能追加とかデザインを変えようとかっていうときには飛ばしてしまいがちな工程なんじゃないかなと。ある程度労力がかかりそうな施策をする場合は、サクッと仮説検証をしたほうが、実は成長への近道なんじゃないかと考えています。

じゃあ「仮説検証って具体的になにをやるの？」ということについてです。一部書き出すだけでも、すごくいろんな方法あるんですね。1つ1つ話していくと時間が終わっちゃうので、詳細な説明はできないんですけれども。

（スライドを指して）この緑色になっているところは、開発なしで全部できることです。「ユーザーはこの課題に困っているはずだ」という仮説って、ユーザーと直接話したり、あとソーシャルメディアに落ちている声を拾ったり、ユーザーが実際にやってる行動をその場に行って観察してみることで、半日くらいでわかることなのに、つい動くものを作って検証しちゃいがちです。

そうすると、その作った時間がムダになってしまう可能性が高くなる。さらに、ダメだったとしても「せっかく作ったし、とりあえずリリースすればいけるかも……」みたいな、謎の捨てにくい気持ちが発生して、プロダクトの負債につながってしまうことが多いんじゃないかなと思います。

検証はスピードが重要で、精度は徐々に上げていけばいい

ただ、「ユーザーと話すだけで、本当に使ってもらえるのかなんてわかんないじゃん」と聞かれることもあるんですね。それはそのとおりです。それでいいんじゃないかなと思っています。目的はそもそものリスクをゼロにすることじゃなくて、抑えることなので。抑えるためには、あくまで検証スピードのほうが大事。検証の精度というのは徐々に上げていけばいいもの、と考えています。

完璧な検証をしようとするのって、「真っ暗な部屋にいてなんにも見えないのに、完璧な脱出プランを練ろうとする」みたいなこと。とりあえず、1歩踏み出す。なにかにぶつかったら戻って、別な方向に踏み出すということを1歩ずつやっていくのが大事だと考えています。

（スライドを映しながら）それで、こちらです。今実際にやっているプロジェクトでの検証の進め方を書いてみました。こんな感じで課題の検証も、電話から観察から、ユーザーとのインタビューなどから行ないます。そのあとはプロトタイプで検証して、実データをもらう。

そのあと実際に「いけそうだな」とわかって初めて、作り始めると。作るのも全部まるっと作るんじゃなくて、コア機能だけを作って短期間テストをしてもらって、それで「いけそうだな」という手ごたえがあって、初めて全体を作り始める……というような進め方をしています。

検証するときの注意点として、「ユーザーの意見は当てにならない問題」というのがあります。これはなにかというと、マクドナルドで市場調査すると、毎回「サラダがほしい」という声が出てくるんです。けど、サラダを出してみるとまぁ売れないという実際の調査結果があるんですね。

検証に対価を差し出してもらうことの意味

どうしても人間って、「こうあるべき」という自分の思いが自分の行動の予測を曇らせたり、あと目の前の人に気を使って「うん、使うよ使うよ！　そのプロダクト良さそう！」と言っちゃったりということがあります。

なので、施策の検証だったら対価を差し出してもらうのがすごく大事です。対価は別にお金である必要はなくて、例えば時間とか手間を割いてもらう、なにかしらデータとか情報をもらう、あるいは「これが完成したら払います」という一筆とクレジットカード番号をもらうとか。いろんな方法があります。

この施策を検証するためにユーザーからなにをもらえるかと考えてみるのは、非常に大事なことじゃないかなと思っています。課題の検証であれば、実際に「過去にユーザーはこの課題を解決するためになにをしていたか」という、やっぱり行動について聞いてみることが大事です。

こっちが検証に使う労力と、ユーザーからの対価が比例してる状態を保てると良いと考えています。さっきの例をプロットしていくと、（スライドを指して）こんな感じです。チームが使う労力と、ユーザーにもらう対価が比例して増えていくような進め方を意識すると、「がんばってすごい作りこんじゃったけど、ユーザーからのコミットが得られなかった」というリスクの積み上げを防げるんじゃないかなと思っています。

これでトークは最後になるんですけれども、Pivotal Labs Tokyoで公式ブログをやってまして、今のスライドもここにアップしてます。ぜひブログをフォローしてください。ありがとうございました。

（会場拍手）