こんにちは。エムスリーエンジニアリンググループ、プロダクトマネージャーの中村です。
今回のブログでは、とある新規プロダクトの製品発見フェーズで四苦八苦した経験をベースに、仮説検証サイクルの高速化について実体験からの学びをまとめたいと思います。
はじめに
今回は、現在開発中の「疾患チェックアプリ」を題材とします。
正式リリース前のため詳細は割愛させていただきますが、「疾患チェックアプリ」とは、特定の疾患に対して不安を抱えるユーザーの課題を解決することを目指すプロダクトです。
この新規プロダクトの立ち上げプロジェクトでの体験を通じて、仮説検証サイクルを高速化することの重要性を痛感しました。
今回のブログでは、
- 仮説検証サイクルの高速化がなぜ重要なのか
- 仮説検証サイクルを高速化するためのテクニック
について、考えてみたいと思います。
仮説検証サイクルの高速化がなぜ重要なのか
この点については、プロダクトマネジメントの教科書である「INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント」に「製品発見において何よりも重要なのはスピード」と記載されています。
具体的には、以下の記載があります。
製品発見の目標は、できる限り迅速に、コストをかけずにアイデアの妥当性を立証することである。 製品発見において何よりも重要なのはスピードである。スピードがあれば多くのアイデアが試せるし、見込みのあるアイデアを見つけるために多様なアプローチを試みることもできる。アイデアにも製品にもさまざまな種類があり、対処しなければならないリスクも（価値のリスク、ユーザビリティーのリスク、実現可能性のリスク、事業実現性のリスクなど）さまざまである。だから、多様な状況に対応できる幅広いテクニックを持っていなければならない。 （「INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント」P186 より引用）
つまり、スピードが速ければ、遅い場合と比べ、同じ期間内で仮説検証サイクルを多く回せるとということです。
1年ほど前に「INSPIRED」が出版された際にも上記の記載は読んでいましたが、疾患チェックアプリのプロジェクトにおいて、がっつりと製品発見フェーズに向き合う中で、なぜスピードが重要なのか、深い実感を伴って理解できました。
具体的には、
- 製品発見フェーズは不確実性が高く、当初想定していたスケジュール通り進まないことを前提として考えるべき
- 特に、プロトタイプが想定通りの評価を得られるとは限らない
- そうなった時に、新たなアイデアをあと何回試せるかが勝負となる
ということを痛感しました。
仮説検証サイクルを高速化するためのテクニック
このセクションでは、仮説検証サイクルを高速化するために、今回のプロジェクトで実践したことと、振り返りの中で学んだ今後実践していきたいことを紹介します。
プロダクトを開発せずに検証する
今回のプロジェクトでは、MVPを開発する前に、アンケートツールを使ってプロトタイプを作り、検証を行いました。
疾患チェックアプリのMVPは、「セルフチェック→結果の表示→結果に合わせた医療の提案」というシンプルなものだったため、アンケートツールを活用したプロトタイプでコアとなる体験が実現できました。
このプロトタイプを使って、ユーザーの反応を定量的に見つつ、インタビューを実施することで、ソリューションの解像度を高めていきました。
「ECRSの原則」を活用する
今回のプロジェクトを、VPoE兼プロダクトマネージャーである山崎との1on1の中で振り返った際に、「もっとプロセスをショートカットできたのでは？」という問いが投げかけられました。
振り返ると、私が2度に分けて実施していた検証が、実は1回の検証で実現できたかもしれない、ということに気が付きました。
上記の話の中で山崎から、「ECRSの原則」に則って考えると良いというアドバイスをもらい、非常に参考になったため、ご紹介します。
「ECRSの原則」とは、以下の通りです。
ECRSの原則は、「E（Eliminate)：排除、C（Combine)：結合、R（Rearrange)：再配置、S (Simplify)：単純化」の4つの改善の視点にもとづき、改善箇所を洗い出す業務改善のフレームワークです。 （引用元：https://logist.bz/improvement/2914/）
ECRSの原則は業務改善のフレームワークですが、製品発見フェーズにおいては、
- このプロセスは本当に必要なのか？
- 次のやろうとしている検証と一緒に検証できないか？
という風に活用できます。
タイムボックスを区切る
先にスケジュールを切って、そのスケジュールの中で検証サイクルの回し方を考えるという方法です。 そうすることで、MVPが大きくなりすぎる問題を解消でき、クイックに仮説検証サイクルを回すことができます。
今回のプロジェクトでは、この方法を活用できておらず、検証期間が延びてしまったという反省点がありました。
今後は、スクラム同様、1~2週間スプリントで検証サイクルを回すチャレンジをしてみたいと思っています。
まとめ
今回のブログでは、製品発見フェーズにおいて、クイックに仮説検証を回すことの重要性と、そのためのテクニックについてまとめました。
このブログを書くにあたり「INSPIRED」を読み返し、限られた時間の中でいかに仮説検証のサイクルを多く回し、成功の確度を高められるかが、プロダクトマネージャーとしての腕の見せ所だと感じました。
その観点でプロダクトマネージャーとしての自分を鑑みると、「改善の余地」＝「プロダクトマネージャーとしての伸び代」があると感じています。この学びを活かしてプロダクトマネージャーとして成長していきたいと思います！
We’re Hiring
エムスリーではテクノロジーを活用して医療業界を変えるプロダクト作りに取り組んでいます。 エンジニア、プロダクトマネージャー、プロダクトデザイナーを絶賛募集中です。
