「急がば回れ」開発しない仮説検証

リスクを抑えながら、スピード感を持って検証を進めていくための考え方

2018/07/07に行われた「プロダクトオーナー祭り 2018 Summer ～プロダクトマネジメントが世界をツナぐ～」にて、登壇させていただきました。その際に使用した資料を共有します。
（スライド＋話した内容をキャプションで書いています）

新機能を頑張って開発してリリースしたけど、思ったような成果が出ない…

リーンスタートアップを読んでみたけど、いまいち自分のプロダクトで活用するイメージが湧かない。とりあえずA/Bテストを回してみるけど、結果につながらない…私も昔、こういう悩みを抱えていました。

このトークで、いかに素早く仮説検証するか？を考えるキッカケが作れたら嬉しいです。

リスクを積み上げるのではなく、短いサイクルで「作る、測る、学ぶ」を繰り返すことによって、リスクを抑えてムダを減らそうというのが、リーンスタートアップのアプローチです。

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

チームの中で、こういう会話ってよくあるんじゃないかなと思います。ユーザー数が伸びないという悩みに対して、文言を変える、チュートリアル、SNS連携などの案が出てきました。

例えば登録フォームの改善、いいアイデアに思えます。やらないより、やったほうがいいですよね。でも、本当に今、登録フォームを最適化することが優先順位の高い施策なんでしょうか？

また、SNS連携という施策ですが、本当に自分たちのプロダクトにおいて効果があるんでしょうか？

もう一歩遡って考えると、そもそもこの課題設定は正しいんでしょうか。プロダクトの価値が伝わっていなければ、使いたいと思ってもらえていないかもしれません。更に遡ると、ユーザーが本当に持っている課題を解決しているか、実は検証できていないのかもしれません。

私自身も昔は文言や画面の見た目、機能改善など、つい細かい最適化に走ってしまいがちでした。新規プロダクトでは課題の検証が重要なことが分かっていても、機能追加や改善などの場合は課題の検証を飛ばしてしまいがちです。でも、ある程度労力がかかりそう（例えば数日以上）なら、課題の検証にまず時間を使ったほうが、結果的に早く成果が出ることが多いです。

検証にはたくさんの方法があります。

この中で開発を一切せずに出来ることはこんなにあります。「ユーザーはこの課題に困っているはずだ」という仮説は、ユーザーと直接話せば半日で検証ができたりするのに、つい1ヶ月かけて動くモノを作ってしまったりします。そうすると、成果が出なかった場合に時間がムダになってしまうだけでなく、「せっかく作ったし」という気持ちが発生するので捨てにくく、プロダクトの負債につながってしまいます。

「ユーザーと話すだけじゃ、本当に使ってもらえるかは分からなくない？」と言われたりしますが、そのとおりです。それでいいんです。目的はあくまでリスクを抑えることなので、素早い検証を繰り返しやっていきながら、精度を高めていけばいいと考えています。

今やっている実際の案件では、こんな感じで検証を細かく進めています。

人間は社会的な生き物なので、つい目の前の人に気を使ってしまったり、「こうあるべき」が自分の行動の予測をねじ曲げたりします。マクドナルドで市場調査をすると「サラダが欲しい」という意見が毎年出てくるのに、実際に出してみると売れないという話もありますね。施策の検証なら対価を差し出してもらうこと、課題の検証ならユーザーの過去の行動を見ることが重要です。

リスクを抑えながらプロダクト開発を進めるためには、自分たちの検証にかける労力と、ユーザーからの対価がバランス取れている状態を目指します。「この施策に対して、どうやって対価をもらうか？」と考えてみるのがポイントです。

まとめ

「自分たちが今フォーカスするべき仮説はなんなのか？」
「どういう手法で検証したらいいのか？」

を考えるのは、特に慣れないうちは非常に難しいと思います。

でも、検証に完璧を求める必要はありません。
真っ暗な部屋から脱出する時に、一歩も踏み出さずに詳細な脱出方法を計画したりはしませんよね。
まず一歩踏み出して、手を動かしてみる。何かにぶつかったら、その手応えから次の動きを考える。それが結局は一番大切なのではないかと思います。

Pivotal Labsでは、定期的にワークショップ型イベントを開いたり、ブログでプロダクト開発やチームビルディングなどについて紹介していきます。

イベントの最新情報：
Meetupグループに参加すると、いち早く案内が届きます😎📩

公式ブログ：
Product Runも是非フォローお願いしますっ🙌🏻🗒