課題仮説の立て方と検証の順番

課題仮説は「誰が、どんな場面で、何に困っていて、今どう対処しているのか」を、後から正誤を判定できる形の一文で書くことから始めます。そのうえで仮説を小さな前提に分け、「重要なのに根拠が乏しいもの」から順に確かめると、検証の手戻りが減ります。

アイデア検証の全体像（顧客、課題、解決策、支払意思の順に確かめる流れ）は新規事業のアイデア検証でやることと進め方で解説しています。この記事では、その最初の段階にあたる「課題仮説」を、どう書き、どう分け、どの順で確かめるかに絞って説明します。

課題仮説とは何か

課題仮説とは、「ある顧客が、ある課題を、一定以上の強さで抱えている」という、まだ確かめていない主張のことです。新規事業のアイデアは、たいてい解決策の形で思いつきます。「〇〇を自動化するアプリ」「△△のマッチングサービス」といった形です。しかし解決策は、その裏にある課題が実在して初めて意味を持ちます。

課題仮説を明文化する目的は、次の3つです。

検証の対象をはっきりさせる：何が確かめられれば前に進めるのかが決まる
チームの認識をそろえる：同じアイデアでも、人によって想定している顧客や課題が違うことはよくある
解決策への思い込みから距離を置く：課題を先に書くと、別の解決策の可能性にも気づきやすくなる

課題仮説の書き方

5つの要素を埋める

課題仮説は、次の5つの要素を入れて書くと、検証できる形になります。

顧客：誰が困っているか（業種、規模、職種、立場などで具体的に）
場面：どんなときに困るか（頻度、きっかけ、時期）
課題：何に困っているか（時間、費用、ミス、心理的な負担など）
現状の対処：今どうやってしのいでいるか（手作業、表計算ソフト、外注、我慢など）
不満：今の対処の何が不十分か

これをつなげると、たとえば次のような一文になります。

従業員30〜100人の食品製造業の品質管理担当者は、取引先から原材料の規格書の提出を求められるたびに、紙とメールで散らばった書類を集め直すのに毎回数時間かけており、担当者の退職や異動のたびに所在が分からなくなることに不満を持っている。

この例は説明のための架空の仮説です。ポイントは、読んだ人が「これは本当か」を確かめに行ける具体さがあることです。

悪い書き方の例

次のような書き方は、正誤を判定できないため仮説として機能しません。

「中小企業はDXに困っている」：誰の、何の業務の、どんな困りごとかが分からない
「ユーザーはもっと便利なサービスを求めている」：「便利」の中身がなく、否定のしようがない
「〇〇機能があれば使ってもらえる」：課題ではなく解決策の仮説になっている

「現状の対処」を必ず書く

5つの要素のうち、最も見落とされやすく、かつ重要なのが現状の対処です。人は本当に困っていることには、不完全でも何らかの手を打っています。表計算ソフトで自作の管理表を作る、外部に頼む、担当者を増やす、といった行動です。対処の手段が思い浮かばない課題は、実は困っていないか、困っていても優先度が低い可能性があります。

また、現状の対処は、新しい製品が置き換える相手、つまり実質的な競合になります。この視点は新規事業の競合調査のやり方でも扱います。

仮説を前提に分解する

一文の課題仮説は、いくつもの前提の組み合わせでできています。上の例なら、次のように分けられます。

対象の企業では、取引先から規格書の提出を求められることがある
その頻度は、手間を感じるほど多い
書類の所在が分散している
集め直しに相応の時間がかかっている
担当者の交代で情報が失われた経験がある
今の方法を変えたいと思うほど不満がある

分解すると、「どれかが外れたら仮説全体が成り立たない前提」と「外れても修正で済む前提」が見えてきます。

どの前提から確かめるか

重要度と根拠の2軸で並べる

前提を並べたら、「事業の成否にどれだけ重要か」と「今どれだけ根拠があるか」の2軸で整理します。Strategyzerの記事では、デビッド・J・ブランド氏が「Assumptions Mapping（仮説マッピング）」として、重要度と証拠の有無を軸に仮説を配置し、成功に欠かせないのに証拠が乏しい領域から実験を行う方法を紹介しています。同記事では、仮説を市場が望むか（望ましさ）、実現できるか（実現可能性）、利益が出るか（収益性）といった種類に分けて考えることも示されています。

課題仮説の段階では、主に「望ましさ」に関わる前提が中心になります。

根拠の強さを区別する

「根拠がある」といっても、その強さはさまざまです。リーンキャンバスの考案者であるアッシュ・マウリャ氏は、Mediumの記事で、アイデアを支える考えを「信念の飛躍（根拠のない思い込み）」「逸話的な観察」「事実」に分類して見直すことを勧めています。

実務では、次のように区別しておくと判断しやすくなります。

根拠の種類	例	扱い
自分の経験や推測	前職で自分が困った	出発点にはなるが、根拠としては弱い
少数の発言	知人2人が困っていると言った	仮説を補強するが、偏りに注意
複数人の具体的な行動	複数の対象者が、実際に外注費を払っている	強い根拠になる
公開データ	統計で対象企業の数が分かる	市場の輪郭の根拠になる（困りごとの強さは分からない）

自分の経験から生まれたアイデアは、本人の確信が強いぶん、検証が甘くなりがちです。「自分が困った」は、他の人も同じように困っていることの証拠にはなりません。

検証の順番

課題仮説は、おおむね次の順で確かめると効率的です。

1. 存在：その課題を持つ人がいるか

まず、想定した顧客の中に、想定した課題を実際に経験した人がいるかを確かめます。ここで見つからなければ、顧客の定義か課題の捉え方を見直します。

2. 頻度と深刻さ：どのくらい困っているか

課題が存在しても、年に1回しか起きない、起きても影響が小さいのであれば、お金を払って解決したいとは思われにくいでしょう。直近でいつ起きたか、そのとき何時間かかったか、どんな損失があったかを聞きます。

3. 現状の対処と支出：すでに手を打っているか

今の対処法と、それにかけている費用や時間を確かめます。すでにお金や人手を使っている課題は、置き換えの余地がある課題です。

4. 切り替えの意欲：今の方法を変えたいか

最後に、今の対処法をやめて別の方法に移りたいと思うほど不満があるかを確かめます。不満があっても、切り替えの手間や社内手続きが重く、現状維持を選ぶ顧客は少なくありません。

1〜4の多くは顧客ヒアリングで確かめます。質問の組み立て方は顧客ヒアリングの質問項目と聞き方を参照してください。

判断基準を先に決める

検証を始める前に、各段階で「どんな結果なら次に進むか」を書いておきます。たとえば「対象者に話を聞き、直近3か月以内にその課題を経験し、何らかの対処に時間や費用を使っている人が過半数なら、次の段階に進む」といった形です。ここでの期間や割合は例であり、事業の性質に合わせて自分たちで決めてください。

基準を後から決めると、どんな結果でも「手応えがあった」と解釈できてしまいます。否定的な結果が出たときに、仮説のどの要素（顧客、場面、課題、対処）を変えるのかも、あわせて考えておくと次の手が早くなります。

仮説を修正するときの考え方

検証の結果、仮説がそのままでは成り立たないことが分かった場合、多くは次のいずれかの修正になります。

顧客を絞る・変える：困っているのは中小企業全体ではなく、特定の業種だけだった
場面を変える：日常業務ではなく、監査や取引先の変更といった特定の時期に強く困っていた
課題を捉え直す：手間ではなく、担当者が替わると誰も分からなくなる属人化が本当の困りごとだった

修正した仮説は新しい仮説として書き直し、もう一度検証します。元の仮説と検証結果も残しておくと、なぜその方向に進んだのかを後から説明できます。

大企業と起業家で異なる点

大企業の新規事業担当者の場合

大企業では、テーマが経営方針や既存技術から与えられることが多く、課題よりも解決策が先に決まっている場合があります。その場合でも、「この技術で解決できる課題は何か」を課題仮説の形で複数書き出し、どれが最も強いかを比べることが大切です。仮説と判断基準を文書にして審査側と共有しておくと、ステージゲートでの議論がかみ合います。

起業家・スタートアップの場合

起業家のアイデアは、本人の原体験から生まれることが多くあります。原体験は強い動機になりますが、根拠としては一人分です。仮説を書いたら、自分と似た立場の人だけでなく、少し条件の違う人にも話を聞き、課題の広がりを確かめます。

まとめ

課題仮説は、顧客、場面、課題、現状の対処、不満の5要素で、正誤を判定できる一文に書きます。仮説を前提に分解し、重要なのに根拠が乏しいものから、存在、頻度と深刻さ、現状の対処と支出、切り替えの意欲の順に確かめます。判断基準は検証の前に決め、否定的な結果が出たら仮説のどの要素を変えるかを考えて書き直します。