課題仮説を検証する方法｜4要素の書き方と判定基準

課題仮説とは、顧客の困りごとを検証できる形にした仮の答え

課題仮説は、商品アイデアを説明する文章ではありません。顧客が達成したいことを妨げている問題を、あとから事実で確かめられる形にしたものです。

たとえば「営業担当者は引き継ぎに困っている」だけでは、対象も場面も広すぎます。「異動後に案件を引き継ぐ営業担当者は、過去の経緯が複数の資料に分かれているため、不足情報の確認と再入力に時間がかかり、個別連絡と表計算で補っている」と書けば、誰に何を聞き、何を見ればよいかが分かります。

ここで確かめるのは、文章の言い回しではなく、次のような事実です。

• 実際に引き継ぎが発生したのはいつか
• そのとき、どの情報が足りなかったか
• 確認や再入力に、誰がどれだけ手間をかけたか
• 現在は何を使い、どこまで問題をしのげているか

事実が見つからなければ、課題仮説を修正するか、対象を変える必要があります。課題があることを証明するためではなく、限られた開発費を使う前に、重要な思い違いを見つけるための道具として使います。

888名調査が示すのは、対話回数より判断につながる設計の必要性

イノベーション総研の調査では、対象顧客との対話が10回以下だった回答群と、11回以上だった回答群で、有料提供開始以降の段階に到達した割合に差がありました。

この結果は、11回話せば事業が進むという因果や成功基準を示すものではありません。事業の難易度、期間、対話した相手や内容はそろえていないためです。

それでも、顧客との対話を早い段階から設計する価値は読み取れます。イノベーション総研では、件数ではなく、次の1回で変える判断を先に決めることが重要だと考えています。誰のどの前提を確かめるのかまで具体化します。

出典：イノベーション総合研究所「新規事業の実態と意思決定に関する調査」（2026年4月、n=888、調査実施：株式会社マクロミル）

価値仮説・解決策仮説とは、確かめる問いが違う

仮説検証が分かりにくくなる原因の一つは、顧客の課題と、自社が提供したい解決策を同時に確かめようとすることです。まず課題仮説を確認し、その後に価値仮説と解決策仮説を検証します。

顧客が「その機能は便利そう」と答えても、困りごとが頻繁に起き、現在の方法を変えたいとは限りません。反対に、強い課題が見つかっても、自社の案が選ばれるとは限りません。

この順序を分けると、課題は確かだが案が違うのか、そもそも対象者の課題が弱いのかを判断できます。仮説全体の立て方は、新規事業の仮説の立て方も参照してください。

課題仮説の4要素を、顧客の行動が見える言葉で書く

課題仮説は、対象者、場面、困りごと、現在の対処の4要素に分けます。属性だけでなく、仕事上の役割や責任まで書くと、話を聞く相手を選びやすくなります。

1．対象者：年齢や業種だけでなく、役割と責任を書く

「大企業の営業職」では広すぎます。「異動後に既存案件を引き継ぎ、顧客への説明責任を持つ営業担当者」のように、問題が起きる仕事と責任を含めます。

同じ会社でも、引き継ぐ本人、引き継ぎを管理する上司、情報を登録する事務担当では困りごとが違います。最初から全員を一つにまとめず、誰の課題かを決めます。

2．場面：問題が始まるきっかけと、終わる状態を書く

「引き継ぎのとき」だけでなく、「担当者の異動が決まり、後任が初めて顧客へ連絡するまで」のように範囲を決めます。前後が明確なら、観察する業務や必要な記録も絞れます。

月末だけ起きるのか、案件ごとに起きるのかも重要です。場面の頻度は、その課題へ時間や費用をかけて解決する理由に関わります。

3．困りごと：不満ではなく、行動や成果への影響を書く

「面倒」「分かりにくい」という感想だけで終わらせず、何が止まり、何が増え、どんな損失が出るかを書きます。確認の電話が増える、説明をやり直す、提案期限に間に合わない、といった変化です。

影響は、本人の作業だけでなく、顧客や上司など周囲へ広がる場合があります。ただし、推測した損失額を事実のように置かず、確かめられた範囲を明記します。

4．現在の対処：使っている手段と、残る不満を書く

顧客は何もしていないように見えても、メールを検索する、前任者へ連絡する、表計算に転記するなどの工夫をしています。現在の対処には、すでに費やしている時間・費用と、満たせていない条件が表れます。

今の方法で十分なら、新しい解決策の優先順位は上がりません。「使いにくいか」だけでなく、「それでも今の方法を続ける理由」を聞くと、切り替えの条件が分かります。

一文にすると、「異動後に既存案件を引き継ぐ営業担当者は、過去の経緯が複数の資料に分かれているため、不足情報の確認と再入力に時間がかかり、個別連絡と表計算で補っている」となります。これは架空の例であり、実在する企業・支援実績ではありません。

課題仮説は、反証条件と確認期限をインタビュー前に決める

仮説を支持する話だけを集めると、結論は最初から決まってしまいます。そこで、どんな事実が出たら仮説を修正するか、いつまでに判断するかを先に書きます。

架空の引き継ぎ例なら、支持条件は「直近の引き継ぎで不足情報の確認や再入力が発生し、本人や周囲の業務に影響した」です。反証条件は「必要な情報は一か所で確認でき、追加の確認や再入力がほとんど発生していない」と置けます。

確認期限は「来月末まで」のような日付だけでは不十分です。誰に何件聞き、どの記録を確認し、期限時に支持・修正・保留・棄却のどれを決めるかまで書きます。情報が足りない場合も、無期限に「検討中」とせず、次に必要な証拠と担当者を決めます。

反証条件は、仮説を否定するためではなく、追加開発を止めるべき場面をチームで共有するためにあります。技術や事業性を小さく確かめる方法は、仮説検証の進め方で全体像を説明しています。

顧客インタビューでは、意見より直近の行動を聞く

「この仕組みがあれば使いますか」と聞くと、相手は提案への感想を答えます。課題を確かめたい段階では、案を見せる前に、最後に問題が起きた日時・行動・使った資料を聞きます。

GOV.UKのユーザーリサーチ指針も、利用者が何をしようとしているか、現在どのように行っているか、どんな問題を経験しているかを調べるよう示しています。また、利用者の意見ではなくチームの意見や提案は、検証が必要な仮定として扱う考え方です。

「何分かかったか」を覚えていない相手へ、正確な数字を迫る必要はありません。使ったメールや表、関係者とのやり取りなど、思い出せる事実から範囲を確認します。社内情報や個人情報は、相手が共有できる範囲に限ります。

顧客の話だけでは判断できない場合は、実際の作業を見せてもらう、既存の問い合わせ記録や作業記録を確認するなど、別の方法を組み合わせます。顧客インタビューの準備と進行は、BtoB顧客インタビューのやり方で詳しく説明しています。

検証の証拠は、発言・観察・解釈を分けて記録する

インタビュー後は、聞いたことと、チームが考えたことを同じ欄に書かないようにします。GOV.UKの分析指針でも、まず見聞きした内容を記録し、その後に観察を整理して発見事項と次の行動を決める流れが示されています。

• 発言：相手が実際に話した内容と、話した人・日付
• 観察：使った画面、資料、手順、止まった箇所など見えた事実
• 解釈：事実からチームが考えた意味。確定事項として扱わない
• 未確認：判断を変える可能性があるが、まだ確かめていないこと
• 次の判断：仮説を続ける、変える、止めるために必要な行動

たとえば「面倒です」という発言だけを「高い支払意思がある」と解釈してはいけません。実際に何を使い、どれだけ手間をかけ、改善を試したかを別に確認します。対象顧客を選び直す場合は、ICPの考え方も役立ちます。

課題仮説の検証結果は、支持・修正・保留・棄却の4区分で決める

面談件数だけを報告しても、次の投資判断はできません。集めた証拠が仮説のどこを支え、どこを崩したかを確認し、結果を4区分に分けます。

1．支持：4要素を裏づける事実がそろい、次の仮説へ進む

対象者、場面、困りごと、現在の対処について、複数の具体的な事実が確認できた状態です。ここで課題が「証明された」と断定せず、対象範囲と確認できた条件を残します。

次は、どんな価値が選ばれるか、どの解決策なら現在の方法から切り替えてもらえるかを検証します。必要に応じてMVPの考え方へつなげます。

2．修正：課題はあるが、対象者・場面・影響の一部が違う

困りごとは確認できたものの、困っている人や発生場面が想定と違う場合です。たとえば営業担当者本人より、引き継ぎ後の状況を管理する上司の負担が大きいなら、対象者と確認する価値を変えます。

文章だけを言い換えず、変更した根拠、旧仮説との違い、次に確認する相手を記録します。

3．保留：判断を変える情報が足りず、確認範囲を限定して続ける

対象者に会えていない、直近の事例を確認できないなど、証拠が不足している状態です。否定と混同せず、未確認事項を一つか二つに絞り、担当者と期限を決めます。

期限までに必要な相手へ届かなければ、さらに件数を増やすのではなく、対象の見直しや検証停止も判断します。

4．棄却：反証条件に当たり、同じ課題仮説への追加投資を止める

現在の対処で十分、問題の発生がまれ、影響が小さいなど、事前に決めた反証条件に当たる状態です。インタビューが否定的だったことを失敗とせず、開発前に思い違いを発見できた成果として扱います。

別の対象者や場面に課題が見つかったなら、新しい仮説として分けます。元の仮説を上書きせず、なぜ止めたかを残すことで、同じ議論の繰り返しを防げます。

判定に迷うときは、賛成・反対の人数を数える前に、反証条件に当たる事実と、まだ会えていない役割を確認します。次の行動を決められない判定は、保留のまま残さず、期限と担当者を追加してください。

チームレビューでは、事実から次の判断までを1枚で共有する

課題仮説の台帳は、インタビュー1件につき1行を増やす名簿ではありません。仮説ごとに、現在の文章、重要な前提、支持・反証する事実、未確認事項、判定、次の行動をまとめます。

レビューでは、最初に新しく得た発言・観察を読み、次に解釈が妥当かを確認し、最後に支持・修正・保留・棄却を決めます。「5件実施した」「好評だった」という活動報告だけで終わらせません。

経営会議へは、結論と同時に、その結論を変える未確認事項を示します。追加予算を求めるなら、何を確かめるための費用か、いつ判断するか、反証された場合に何を止めるかまで説明します。

まず現在の課題仮説を4要素に分け、空欄と推測を書き出してください。次の顧客対話では、最も重要な空欄を一つだけ選び、その事実が支持・修正・保留・棄却のどれにつながるかを決めてから質問します。

課題仮説の検証に関するよくある質問

課題仮説を実際の新規事業へ当てはめるときに迷いやすい点を整理します。

Q. 課題仮説の検証には、何人へインタビューすれば十分ですか？

A. 一律の人数では決めません。対象者や場面が偏っていないかを確認し、同じ事実が繰り返し見つかるか、新しい対話で判断が変わるかを見ます。重要な未確認事項が残る場合は、件数を増やす前に次に会う役割と質問を変えます。

Q. 課題仮説の検証は、アンケートだけでもできますか？

A. アンケートは、選択肢ごとの傾向や分布を広く見るときに役立ちます。一方、問題が起きた場面や現在の対処を詳しく知るには、インタビューや行動観察が適しています。知りたいことに合わせて組み合わせます。

Q. BtoBの課題仮説は、誰に聞けばよいですか？

A. 実際の利用者だけでなく、運用する人、費用を負担する人、導入を決める人も確認します。一人が複数の役割を持つ場合でも、利用時の困りごとと購入・導入の条件を分けて聞きます。

Q. 課題仮説が棄却されたら、検証は失敗ですか？

A. 失敗ではありません。開発や販売へ大きな費用を使う前に、重要な思い違いを発見できた結果です。棄却した事実と理由を残し、別の対象者や場面で見つかった課題は新しい仮説として分けます。

Q. 一つの課題仮説に、複数の困りごとを書いてもよいですか？

A. 検証する単位では、主な困りごとを一つに絞る方が判断しやすくなります。複数ある場合は仮説を分け、どの課題がどの場面で起き、現在の対処にどのような影響を与えているかを別々に確認します。

まとめ：課題仮説は、次の開発判断が変わる事実で検証する

課題仮説は、対象者、場面、困りごと、現在の対処の4要素で書きます。商品の魅力を説明する前に、顧客が実際に経験した出来事と行動を確かめてください。

検証では、仮説を支持する話だけを集めず、修正・棄却する条件と期限を先に決めます。発言、観察、解釈、未確認を分けて記録すれば、面談件数ではなく、何が分かり、次の判断がどう変わったかを共有できます。

最初の一歩は、いま使っている課題文を4要素に分けることです。具体的な事実が入っていない箇所を一つ選び、次に会う相手と質問、判断日を決めてください。