仮説検証・顧客開発
良い仮説と悪い仮説の違い｜顧客検証できる問いの作り方
良い仮説と悪い仮説の違いを解説。対象・状況・困りごと・確かめ方を分けて、顧客に検証できる問いへ変える作り方を紹介します。
（更新: ）
事業の議論で「ニーズがある」「価格は受け入れられる」と言っても、何を見れば判断できるかが曖昧なら検証は進みません。仮説を検証可能な問いへ変える手順を紹介します。
悪い仮説は、反対の結果でも学べない
「中小企業はAIを必要としている」は対象も用途も広すぎます。反応が薄いとき、それが対象の問題なのか、聞き方なのか、提案内容なのかを切り分けられません。
4要素で書く
| 要素 | 例 |
|---|---|
| 対象 | 月次決算を担当する従業員 |
| 状況 | 締め日前に差戻しが集中する場面 |
| 想定する困りごと | 原因確認と依頼の往復に時間がかかる |
| 確認方法 | 現在の手順、直近の事例、代替手段、導入条件を聞く |
この書き方なら、相手が実際には別の問題を抱えている場合も発見できます。解決策を先に売り込まず、現在の行動から確認を始めることがポイントです。
反証できる形にする
仮説には「どんな情報なら見直すか」も書きます。たとえば、対象者が課題をほとんど経験していない、既存の手段で十分に解決している、導入決定者が別にいる、という情報は重要な反証候補です。
反証条件がない仮説は、どんな結果でも「やはり必要だ」と解釈しやすくなります。検証前にチームで反証条件を合意すると、確認バイアスを抑えやすくなります。
まとめ
- 対象・状況・困りごと・確認方法を分けて書く
- 解決策の評価より、現状の行動を確かめる
- 先に反証条件を決め、都合のよい解釈を避ける
関連記事: 仮説検証とは何か
書き換えの例
| 曖昧な表現 | 検証可能にした表現 |
|---|---|
| 忙しい人は効率化を求めている | 月次締め担当者は、差戻し原因の確認に時間を使っており、現在の対処に不満がある |
| この機能は便利だ | 既存の表計算・メールで行う作業のうち、どの工程が負担かを説明できる |
| 低価格なら導入される | 想定利用者、予算保有者、決裁者が導入条件を満たせる |
右側も、まだ「正しい答え」ではありません。対話や観察で確かめるための、より具体的な問いです。
チームで合意したいこと
仮説の文面だけでなく、用語の意味をそろえます。たとえば「顧客」は利用者を指すのか、支払う組織を指すのか。「導入」は試用開始か、有償契約か。定義がずれると、同じ調査結果から別の結論を出してしまいます。
また、仮説には期限を置くとよいでしょう。「今月中に確認する」のような期限は、真偽を急ぐためではなく、情報が増えないまま議論を繰り返すことを防ぐためです。期限時点で結論が出なければ、必要な追加情報を定義して保留にします。
確認前のチェックリスト
- 対象者と利用場面を第三者にも説明できる
- 観察したい行動または聞きたい過去の事実がある
- 反証となる情報を一つ以上書いた
- 用語と判断基準をチームで共有した
仮説の言い回しを整える目的は、もっともらしい文章を作ることではありません。顧客との対話や観察によって、どこを更新すべきか分かる状態を作ることです。
Startups with AIでの扱い
Startups with AIの第4章では、仮説を顧客・課題・ソリューション・価格の4つに分け、判定基準と質問紙をつくります。書いた仮説は、あとから「新しい仮説Ver」で見直せます。