はじめに

こんにちは！
back check で PdMとして活動しているもっちゃん（@ayakchan）です！
私は、昨年実施した仮説検証で「仮説検証のやり方」を大失敗しました。アイディアをプロダクトに実装するしないの結論を出すまで、3ヶ月も費やしてしまったのです。その失敗経験から「計画」こそ仮説検証でもっとも大事なプロセスだと改めて気がつき、改善を重ねた結果、1ヶ月で仮説検証の結論を出せる様になりました。
本記事では、私が取り組んでいる「仮説検証の計画の立て方」について紹介します。
アイディアの実装や仮説検証の進め方で悩んでいるPdMやPMのみなさんのお役に立てると嬉しいです。

仮説検証の計画を立てる

実際に1月に実施した仮説検証をもとに計画の立て方を紹介します。

スケジュール

先に「判断日」を決めてから逆算してスケジュールを立てます。大事なことは、検証期間を1週間と設定し絶対動かさないこと。マイルストーンでリリース日と撤去日は各所としっかり握ります。

仮説検証計画マップを作成する

次に「仮説検証計画マップ」を作成します。計画内容を構造化してまとめるのに便利です。実際作成したものはお見せできませんが、miroを活用し下記図のようにまとめます。下記は本記事用に作成したサンプル画像です。仮説検証計画マップに沿って、上から順に埋めます。

ゴールを設定する

最初に仮説検証の方針となる「ゴール」と「キークエスチョン」を設定します。ゴールは「誰が」「どのような状態になっている必要があるか」を表します。明文化する際に意識した書き方です。

ゴール
◯◯ （ターゲット）が △△△（実装する機能から得られたもの）によって ◇◇◇◇ （ターゲットの行動）が変わる

「キークエスチョン」は、目指すゴールを疑問形に言い換えた形式です。疑問系にするとどんなものが必要かが自然と考えやすくなりました。

参考文献「構造化思考トレーニングコンサルタントが必ず身につける定番スキル | 中島将貴 |本 | 通販 | Amazon」より

構造化思考トレーニング　コンサルタントが必ず身につける定番スキル

作者:中島将貴
日経BP

Amazon

以前はゴール（終了の定義）を明確に定めなかった結果、どこまで検証すればよいのか仮説検証の無限ループに陥り、抜け出せなくなることが多くありました。ゴールを設定しておけば、必ずスケジュール内で終わります。

仮説を定義する

専門用語や難しい表現を使わず、誰がみてもわかりやすい言葉にします。新しい機能を追加する施策だったので、「 ◯◯したらユーザは△△してくれるのではないか 」というシンプルな仮説にしました。

背景を書き出す

誰のための機能なのかを絶対忘れてはいけません。仮説を想起するきっかけとなったユーザのできことや課題をすべて書き出します。

検証方法を考える

繰り返しになりますが、ここでも「検証期間を1週間と設定し絶対動かさないこと。」が重要です。1週間で終わらせるHOWを考えます。

検証方法

1月の仮説検証は、「フィーチャーフラグ」を活用しました。フラグの管理はlaunchdarklyというツールを使用します。仮説検証はエンジニアさんの協力なしに進みません。開発者ブログでも度々登場している秋葉さんに協力いただきました！（いつも大感謝❤️）

フィーチャーフラグとはコードを変更せずにシステムの動作を変更する開発手法です。

検証対象範囲を決める

ユーザへの影響をより最小限にするため、短期間で多くの情報を収集します。まず実施条件として、
・期間：1週間
・最低有効回答数：◯◯件以上
と決めます。最低有効回答数は、プロダクトによって異なります。過去実施したデータ分析で結論を出せた最低件数を目安にするとよいです。

次に、フィーチャーフラグを適用させる範囲を決めるため、検証対象数を割り出します。その際に使った計算式です。

計算式
1日あたりの検証対象数 ＝  有効回答数 / 回答率 / 検証日数

回答率は、過去に実施した仮説検証結果の数値を参照します。検証対象数を出したら、数を確保するためどの範囲まで適用するかセグメント条件を決めていきます。条件が決まったら、適用範囲の情報をカスタマーサポートチームに確認し、実施可否を判断します。

判断基準を決める

実装可否を判断するため、判断基準を定量と定性それぞれ設定します。データから判断することがポイントです。ここを出しておかないといつまでも判断できません。判断時に注意すべきことは、バイアスのかかった意見に惑わされないことです。権限の持った役職者やプロダクトの解像度が高いメンバーの意見は、バイアスが含まれていることがあります。誰が見ても納得できるように客観的な視点で言語化しましょう。

ここまで計画準備できれば、検証・検証結果の分析・判断までスムーズに進めることができます！ぜひ試してみてください。

さいごに

既存のプロダクトに新しいアイディアを導入するのはリスクがつきものです。私自身も過去の経験から猛省してますが、「やってみなきゃわからない」精神で進めるとプロダクトの負債となって積み重なり、改善しにくいシステムになりかねません。負債を生まないためにも、実装前の仮説検証は重要です。でも、やり方を間違えると判断を誤ったり何度もやり直しをするなど時間を無駄にします。
しっかり計画を立てて取り組めば、効率よくヘルシーな仮説検証が実施できますよ。