確度の高い仮説検証を実現する「定性×定量 2刀流」のススメ
「開発の優先順位決めで困っている」──。プロダクト（サービス）グロースの現場でありがちな悩みです。
事業数値に貢献するし、ユーザーからの支持も得られる。そんな効果の高いアイデアや機能から手をつけるのが理想的ですが、効果の高い施策を見極めるのは簡単ではありません。開発に投資をするためには、一定の確証が欲しいところ。
そのために必要なのは、施策に対してユーザーが価値を感じてもらえるかどうかを検討する「仮説検証」しかありません。
この記事では、プロダクトマネジメントを行う組織において、確度の高い仮説検証を行うための定性調査と定量調査を組み合わせたプロセスの一例を紹介します。
目次
定性調査と定量調査を組み合わせるべき理由
定性調査と定量調査は単独で行うのではなく、両方の手法を組み合わせることで高い効果を発揮します。それぞれの調査は以下のような目的や特徴があります。
- 定性調査とは：
- 数値化できない対象者の気持ちや意識、行動を「言葉」で把握する調査
- 課題解決のためのアイデア・ヒントの発見や仮説の構築、顧客のニーズの深堀、また事実の背景や原因を探る際に適しています。
- 例：グループインタビュー、デプスインタビュー、エスノグラフィーなど
- 定量調査とは：
- 対象者群から収集された数値化されたデータを統計学的に分析する調査
- 仮説の確かさを数値で検証したい場合や、市場の実態/傾向を量的に把握したい場合、満足度や認知率などを数値指標で確認したい場合、キャンペーンや広告の効果をボリュームの観点で測定したい場合などに適しています。
- 例：インターネットリサーチ、アクセス解析、ABテスト結果分析
しかし、定性調査と定量調査、どちらか片方だけを実施しても確度の高い仮説検証には届かないケースは少なくありません。例えば、以下のようなカベにぶつかった経験はありませんか？
- 定性調査だけで失敗するパターン
- 対象者のユーザーボリュームが十分でなく事業影響が出ない
- 統計的に有意な検証結果とならずネクストアクションがしづらい
- 成長させたい指標と噛み合わない検証になってしまう
- 定量調査だけで失敗するパターン
- ニーズの確度が低い施策を進めてしまう
- 独自の仮説だけで施策の検証サイクルが良くないループに入ってしまう
- 成長しづらいKPIに固執してしまう
このように、定性だけだと事業影響が見えづらかったり評価しづらい部分があり、定量だけだとユーザー目線が抜けて仮説の確度が低くなってしまうのです。両者を組み合わせることで、確度の高い仮説検証が評価しやすい形でチームに還元できるようになります。
定性と定量を組み合わせた仮説検証のプロセス
それでは、定性調査と定量調査をどう組み合わせればいいのか。今回紹介するのは、全8つのステップで行うプロセスです。
- 第1段階
- KPIツリー作成
- GrowthKPIの設定
- Growthセグメントの設定
- 第2段階
- KPI成長シナリオのSim
- PostGrowthセグメントへのインタビュー
- Growth施策の策定・評価（リスク検証とパフォーマンス検証2つの軸）
- Growth施策被験者へのインタビュー実施
- 施策の定常化・機能化
基本設計は第1段階のステップ1からステップ3までで行い、有効な仮説検証結果になるまで第2段階のステップ1からステップ4をループさせます。結果が良ければ第2段階のステップ5の定常化・機能化へと進みます。第2段階がうまく進まないときは、第1段階のステップ3やステップ2の見直しを行う必要もあります。
ここからは各ステップについて詳細を紹介します（ステップ8は仮説検証後のプロセスのため、本記事では割愛します）。
1. KPIツリーの作成
アクティブユーザー数や売上のようなKGIが設定されていることが前提ですが、まずはKGIから要素分解してKPIツリーを作成します。
仮に購買率や購入単価などのKPIに目標が定まっていたとしても、それをさらに分解したり、その前後の指標との依存関係などを図解するためにKPIツリーを作成し、改善に注力するファネルや箇所を明らかにします。ECサイトで例えると以下のような形です。
===
売上＝EC流入数×商品詳細遷移率×カート遷移率×サンクスページ遷移率
===
必ずしも数式形式で要素分解されている必要はなく、過不足なくKPIが網羅されているのか、KPI同士の関係性が明示的に伝わるかが重要です。
また「KPIの集計期間をどのような単位にするか」は、KPIツリーのあり方が変わる重要なポイントです。
例えば、売上の集計期間は月ごとになっていることが一般的ですが、KPIツリーを週ごとや日ごとにする場合は、会計上の月ごとに合わせて週や日の平均を取るのか、または月中の変動を鑑みるのかなど、KPIツリーを改修する必要が出てきます。KPIツリーの集計単位は、施策のPDCAサイクルに影響するので適切な集計期間を選ぶべきでしょう。
2. GrowthKPIの設定
KPIツリーの作成を通じて、最終的に向上させたいKGIに対する要素分解が網羅的に完了したら、次はその指標群の中で、どの指標を向上させるのかを決めましょう。ここで決定した指標をGrowthKPIと呼びます。
GrowthKPIはチームの意思で決定しても良いですが、その後の施策が取り組みやすい指標かどうかで絞り込みもできるので、その制約条件をいくつか紹介します。
- 結果が出るまでにどの程度の期間を要するか
- 特定のアクションに対して直接的な影響を受けるか
- 結果の上下によって、別のKPIに及ぼす悪影響はどの程度か
このとき、上記の制約条件で評価する過程で定量分析を行い、GrowthKPIをさらに分解しても良いでしょう。
上記のECサイトの例で言えば、カート遷移率をGrowthKPIと定めてみたものの、特定のアクションに紐づかない気がするので、カート遷移率と相関の高い指標を分析した結果、商品詳細閲覧数と一定までは正の相関が認められたので、カート遷移率ではなく商品詳細閲覧数をGrowthKPIにする、といった形です。
3. Growthセグメントの設定
「向上させたいKPI＝Growth KPI」が定まったら、その指標を向上させるべきユーザー群＝セグメントを設定します。新規・既存のようなざっくりした区分けではなく、行動の条件によって区分されたセグメンテーションが好ましいです。
例えば、先ほどの「商品詳細閲覧数」をGrowth KPIとした場合の簡易的な工程は下記です。
- 全体のEC訪問者のうち、当日訪問の商品詳細閲覧数0〜Xまでのグラデーションを大きく3つに分類（例：ロイヤル・ミドル・ロウ層）し、ユーザーボリュームを確認
- 各セグメント分類の売上を確認
- ユーザーボリュームと売上比率からどのセグメントに注力するかを決定
最後の注力セグメントの決定時には、事業的な影響力を持つようにある程度のボリュームのあるセグメントを選択することをお勧めします。
今回Growthセグメントは「当日サイト訪問者のうち商品詳細閲覧数がミドルな層」に定めたと仮定します。
4. KPI成長シナリオのシミュレーション
指標と対象が定まったので、次は「どういう体験によって該当対象者の行動がどう変わり、結果的に該当数値に反映されるのか」というシナリオを作成し、そのシナリオがうまくいった場合のシミュレーションを行います。
例えば、商品詳細閲覧数のミドル層（ボリュームY）に対して、商品詳細閲覧数がα％伸びるとし、ステップ2での導出したカート遷移率との相関関数の傾きをγとして、それがカート遷移率をβ％アップさせるとしたら
「Y×β％×平均購買単価（定数）」が増加分の売上となります。
上記のような事業影響的なシミュレーションと併せて、次ステップのインタビュー設計のためにユーザー体験のシミュレーションも行います。
例えば、ロイヤル層と比べてミドル層は何が障壁になってるのか、同種の商品を比較していて、本来の購買目的は1つの商品なのか（例：電動歯ブラシの購入を検討しており、機能や値段で比較している）、とあるカテゴリについて複数の選択肢を検討しているのか（例：プロダクトマネジメントを学ぶ書籍を複数閲覧している）、のように商品詳細閲覧という同種の行動であっても、その実態によっては、ユーザー体験のシナリオが大きく変わるので、こちらもデータを見ながらどういった行動因子によって数字がどう変わっているのかを観察し、ユーザー心理の仮説を立てておくと良いです。
加えて、この時そのKPI成長シナリオの撤退ラインとする下限数値を定めておくと、施策結果の評価がしやすくなります。
5. PostGrowthセグメントへのインタビュー
KPIもセグメントも定まり、シナリオも決定したら、そのシナリオの確度がいかに高いのかをユーザーインタビューで検証します。
インタビューの目的はシナリオ作成時の仮説検証ですが、想定しきれなかったユーザーの実態を探るという観点でもインタビューを設計できると良いです。
このときのインタビュー対象は成長させたい対象ではなく、既にGrowthKPIをクリアした対象とします。なので“PostGrowthセグメント”としています。
これは、KPI未達成のユーザーに未達成の理由をヒアリングするよりも、既に達成しているユーザーに達成した背景を調査する方が再現性が高いからです。加えて、KPIを達成したタイミングは、インタビュー実施時期に近いタイミングの方が情報の鮮度が高いので好ましいです。
また、KPI成長シナリオ作成時に参照した行動ログの絞り込み条件をインタビュー対象者の絞り込みに加えると、よりリアリティの高いインサイトが得られます。例えば、書籍カテゴリを複数閲覧しているロイヤル層をインタビュー対象とする、のような絞り込みです。
インタビュー内容としては、上記シナリオのユーザー体験の仮説をベースとしつつも、ある程度オープンクエスチョンになるように、幅広くヒアリングするように設計します。
例えば、基礎的な質問として、何をきっかけにサービスに流入したか・期待する内容は何だったか・期待以上や期待未満な体験や事柄は何かあったか、などからその時にどういった感情になったか、や今後の使い方の想定について深掘りをしていくイメージです。
6. Growth施策の策定・評価（リスク検証とパフォーマンス検証2つの軸）
インタビューを通じて得られたインサイトを基に、Growthセグメントに対してGrowthKPIを成長させるための施策のアイデエーションを行います。案出し段階では投資対効果などは一旦度外視で案出しをチームで行い、そのアイデア群に対して下記条件に従って絞り込みや優先度付けを行います。
- 開発の必要有無
- 該当施策を実施するのにシステム構築する必要性はあるのか
- 工数の高低
- 該当施策を実施するための工数はどの程度なのか
- リスクの高低
- 最低限投資するコストの定量観点に加えてブランドイメージやプロダクトビジョンとの整合性などの定性的なリスクについても検討する
- パフォーマンスの高低
- 指標貢献度だけでなく施策結果がチームの情報資産となることも考慮する
ポイントとなるのは、施策の目的を「パフォーマンス検証」にするのか「リスク検証」にするのかを決めるという点です。リスクの高低に寄りますが、順序としては小さい規模でリスク検証を行い、リスクに対してパフォーマンスの比率が高ければ、次点としてサンプル数も増やしてパフォーマンス検証を行うのが堅実です。
経験則上は稀なケースではありますが、初回の施策の実施結果が想定よりも良かった場合、施策として定常化したり、機能化したりといったステップに進んでも良いでしょう（ステップ8）。
7. Growth施策被験者へのインタビュー実施
施策を実施したものの、想定より反応が悪かったりパフォーマンスが悪かったり、どちらとも言えなかったり、といった状況はよくあります。そういった状況において、打開策となるのは実際のユーザーに対するインタビューです。
施策後であれば、どんなに小さいボリュームでも期待するアクションを行ったユーザーがいるはずなので、どういった心理変化によって想定アクションを行ったのか、それはステップ4でのユーザー体験のシナリオと沿うものなのか、違うとすれば何が違うのかといった確認を行います。
残念なことに期待するアクションを行ったユーザーが一人もいない場合は、ステップ4のシナリオから練り直すか、一つ手前のステップ6での施策の練り直しを行います。
今回は「定性×定量」を組み合わせた仮説検証のプロセスを1つの例として紹介しましたが、プロダクトグロースのプロセスはチームごとの色合いに合わせて最適化されるものであり、これから多くのクライアントのチームに伴走する中でより汎用的なプロセスの型化を目指していきます。
仮説検証にお困りの方は、ぜひ以下のバナーからお問い合わせください。
