「もう少し調べてから決めよう」。新規事業の会議が、今日もこの一言で締まりました。市場、競合、顧客、技術、法務。調査項目は前回より増えたのに、判断は保留のまま。この堂々巡りを断つのが仮説思考です。
仮説思考とは、限られた情報から問いへの暫定回答を先に置き、事実で更新していく考え方です。調べる前に正解を決めつけるのではありません。間違っている可能性を残した答えを先に書き、何が分かれば書き換えるかを決めておきます。この記事では、仮説検証・ロジカルシンキングとの違いから、BtoB新規事業での進め方、具体例、鍛え方までを実務の手順として整理します。
仮説思考とは|答えの候補を先に置き、事実で更新する
仮説思考とは、限られた情報から問いへの暫定回答を置き、反証情報で更新する思考法です。 判断に必要な情報と、今は集めなくてよい情報を分けられます。暫定回答・成立条件・反証条件の3点を並べれば、次に何を確かめるかが決まります。
中心にあるのは、少ない情報で正解を当てる技ではありません。現時点の答えを言葉にし、その答えを崩す情報から探しにいく姿勢です。
たとえば「法人向けサービスの市場を調べる」は作業であって、仮説ではありません。「最初に狙う顧客は、複数拠点の申請業務を管理する本社部門である」なら、誰を対象にするかという問いへの暫定回答になります。現場部門のほうが課題も導入意向も強いと分かった時点で、答えを書き換えればよいのです。
内田和成氏の著書と、本記事が扱う範囲
内田和成氏の『仮説思考 BCG流 問題発見・解決の発想法』(東洋経済新報社、2006年)は、情報を網羅してから結論を出すのではなく、仮説を先に置き、検証と修正を重ねて問題発見・解決を進める考え方を扱った一冊です。
この記事では、BtoB新規事業に合わせて、顧客、購買、社内判断を分けて仮説を立て、更新後の選択肢、判断者、実行責任者まで記録する手順を扱います。
仮説は事実でも願望でもない
事実は、すでに確認できた出来事や記録です。仮説は、事実の間をつなぐ未確認の説明で、問いに対する暫定回答にあたります。願望は「この事業を通したい」「この顧客に買ってほしい」という意思です。この三つを同じ欄に書くと、反対材料が出ても仮説を修正できなくなります。
根拠が薄い段階でも、回答は置きます。ただし、薄さは隠しません。「確認済みの事実」「事実から置いた仮説」「仮説を崩す条件」を分けて書きます。ここが、単なる思いつきとの境目です。
結論ありきとの違いは、更新条件にある
結論ありきの調査は、決めた答えを支える材料だけを集めにいきます。仮説思考は逆で、「どんな事実が出たら、この答えを捨てるか」を調査の前に決めておきます。支持材料と更新条件の両方を持っているかどうかが、二つを分けます。
仮説思考・仮説検証・ロジカルシンキングの違い
三つは競合する手法ではなく、同じ意思決定の別工程です。答えの候補を置く工程が仮説思考、候補を事実でふるいにかける工程が仮説検証、主張と根拠のつながりを点検する考え方がロジカルシンキングです。
考え方・工程 | 中心の問い | 主な出力 | 誤用しやすい点 |
|---|---|---|---|
仮説思考 | 現時点では、問いにどう答えるか | 暫定回答、成立条件、反証条件 | 仮説を確定した結論として扱う |
仮説検証 | その回答は確認した事実に耐えるか | 維持、修正、棄却、次の確認 | 支持する声だけを結果にする |
ロジカルシンキング | 主張と根拠に飛躍や重複がないか | 論点と推論の関係 | 論理が通れば前提も正しいとみなす |
仮説思考から仮説検証へ一方向に進むわけではありません。検証で得た事実から別の仮説を置き、論理のつながりを点検し、もう一度確かめます。この往復が実際の姿です。
新規事業で仮説思考が必要になる場面
新規事業で仮説思考が要るのは、結論を変える情報と、集めても判断が変わらない情報を分けたい場面です。顧客、課題、提供価値、購買、実現方法。前提が未確認な段階では、先に問いを置かなければ調査範囲が決まりません。
市場調査を始める前
市場規模、競合機能、価格、規制、技術動向を並べても、「誰から確かめるか」は決まりません。「初期顧客はどの部署か」という問いと暫定回答を先に置けば、その部署で課題が起きる場面、現行手段、支払い元へと調査を絞れます。
顧客インタビューを組む前
仮説がなければ、質問は「困りごとはありますか」「欲しい機能は何ですか」と広がる一方です。仮説があれば、「この業務が発生した直近の場面では、誰が何をしたか」「現在の方法を変えなかった理由は何か」と、出来事を確かめる問いへ絞り込めます。
社内会議で追加調査を決める前
会議で合意すべきは、調査項目の一覧ではなく「何が分かれば結論を変えるか」です。維持、仮説変更、追加確認、判定保留、停止、次段階への追加投資。分岐を分け、誰がいつ決めるかまで置いて初めて、追加調査が判断につながります。
仮説思考の進め方|問いから更新までの5段階
仮説思考は、意思決定の問いを定め、暫定回答を置き、成立条件へ分け、反証情報を確かめ、答えと次の行動を更新する順で進めます。
- 意思決定の問いを一文にする
「顧客について調べる」では、調査の終了条件がありません。「最初の検証対象を本社管理部門と現場部門のどちらにするか」まで絞れば、選択肢と次の行動が分かれます。
- 現時点の答えを選び切る
「どちらもあり得る」で止めず、現時点の回答を一つ置きます。根拠が弱ければ、その弱さも記録し、何を確認すべきかを表に出しておきます。
- 答えが成立する条件へ分ける
顧客がその業務を繰り返していること、現在の手段では未解決の負担があること、変更を起案する人が特定できること。こうした前提に分解し、崩れた場合に結論への影響が大きいものから確かめます。
- 仮説を崩す情報から確かめる
「どんな回答が出たら仮説を修正するか」を、調査の前に書きます。反対例が出た場面、対象者、条件を残しておけば、仮説を捨てるのか、適用範囲を狭めるのかを選べます。
- 答えと次の行動を同時に更新する
結果を「手応えあり」で閉じてはいけません。仮説のどの言葉を変えたか、誰が次に何を確かめるかまで記録します。維持する場合も理由を残します。
一枚の実務シートに入れる項目
仮説を会議の判断へ渡すには、問いと検証結果だけでなく、判断主体と決定後の動きを同じシートに載せます。
- 意思決定の問いと現時点の仮説
- 確認済みの事実、成立条件、反証情報
- 判断者、スポンサーまたは会議体、判定日
- 今回選ぶ分岐(維持、仮説変更、追加確認、判定保留、停止、次段階への追加投資)
- 未確認事項と、次に確かめること
- 更新した内容と理由
- 決定後の実行責任者と期限
仮説の一文だけでは、BtoB新規事業の判断は動きません。誰が、いつ、どの会議体で更新を決め、決定後に誰が何をいつまでに実行するか。そこまで書けて初めて、意思決定に使える仮説になります。
良い仮説は、外れた後の行動まで変える
良い仮説の価値は、もっともらしさではありません。何が起きたら外れたと判断でき、外れた後にどの行動を変えるか。この二つが明確な点にあります。
点検する軸 | 弱い状態 | 判断に使える状態 |
|---|---|---|
問いとの対応 | 市場や顧客への感想になっている | 意思決定の問いへ一文で答えている |
対象と場面 | 「企業」「担当者」と広い | どの役割が、どの場面で行動するか分かる |
観察できる行動 | 「関心がある」「魅力を感じる」で止まる | 相談、起案、申請、継続利用など行動で書かれている |
外れたと分かるか | どんな結果でも正しいと言えてしまう | 書き換える事実と条件が先に決まっている |
事業への影響 | 外れても次の行動が変わらない | 外れれば対象、価値、提供方法のいずれかが変わる |
次の確認 | 「追加で調べる」で止まる | 誰の、どの出来事を、何で確かめるか分かる |
「中小企業には業務改善のニーズがある」は、対象も行動も広く、外れたと判定できません。「複数拠点の書式を管理する本社担当者は、現場別の提出状況が見える試作画面を監査責任者へ共有する」まで書けば、確かめる行動が見えてきます。
仮説が長くなりすぎるなら、顧客課題、利用、購買、実現方法など、別の問いへの答えを一文に詰め込んでいるサインです。文章を削る前に、問いを分けましょう。
仮説思考の具体例|BtoB新規事業の顧客仮説を絞る
BtoB新規事業の仮説では、利用者の困りごとだけでなく、変更を起案する人、導入を承認する人、支払い元を分けて考えます。課題が確認できても、購買と導入の前提が別なら、顧客像は変わるからです。
以下は手順を示すための架空例です。
最初の仮説
想定するのは、複数拠点の申請書式をまとめる法人向け業務支援サービスです。検討チームは「最初の検証対象を現場部門と本社部門のどちらにするか」を決めようとしています。
最初の仮説:現場部門の責任者は、拠点ごとに異なる申請書の転記へ負担を感じており、書式を統一するサービスの初期顧客になる。
一見もっともらしい一文ですが、未確認の前提が混ざっています。
前提 | 確かめる事実 | 仮説を崩す情報 |
|---|---|---|
転記が現場で繰り返し発生する | 直近の申請で、誰がどの書式を使ったか | 転記は本社の担当者が一括している |
現場責任者が負担を問題として扱う | 手戻り後に誰へ改善を依頼したか | 負担はあるが、変更を起案していない |
書式統一が採用可能な解決策である | 書式の決定者と変更手続きを確認する | 書式は取引先指定で、自社では変えられない |
現場部門が導入を進められる | 過去の業務ツール導入で関わった人を追う | 予算と承認が本社部門に集約されている |
反証された前提
架空のインタビューで、次のことが分かったとします。現場責任者は確かに転記をしていました。しかし書式変更を起案した経験はなく、変更時期と予算は本社の監査担当者が決めていました。崩れたのは「困っている人が初期顧客になる」という購買側の前提です。
更新後の仮説
更新後は、「本社の監査担当者は、書式改定時の展開と回収状況を管理する必要があり、現場責任者を利用者とする仕組みの導入を起案する」と置き直せます。次に会う相手も、現場責任者から本社担当者へ変わります。
承認者と支払い元は、まだ分かりません。未確認事項として残し、本社担当者への次の質問にします。この例の成果は、最初の答えが当たったことではありません。どの事実で、対象、課題、解決策、購買のどこを書き換えたかが分かることです。
仮説思考の鍛え方|予想と事実の差分を残す
仮説思考は、調べる前の予想と、調べた後に確認できた事実の差分を記録し、見落とした前提を振り返ることで鍛えられます。知識を増やすだけでは、自分がどこで判断を外したかは見えません。
検索や資料作成の前に、暫定回答を書く
検索窓を開く前に、問いと現時点の答えを一文ずつ書きます。調査後に上書きせず、初稿を残しておきます。予想と事実のずれが、そのまま教材になります。
同じ事実を説明する別の仮説を置く
問い合わせが減ったという事実に対し、「需要が落ちた」だけで止めません。「流入経路が変わった」「対象者が問い合わせ前に離脱した」といった別の説明を並べてから、どれを確かめるか選びます。
反証条件を調査前に宣言する
「顧客が課題を語れば支持」とするだけでは、どんな会話も支持材料になりかねません。「直近の出来事を説明できない」「現在の代替手段を変える行動がない」といった反対材料も先に書きます。会議では、その条件を仮説の作成者以外にも読んでもらいましょう。
意思決定ログで更新理由を残す
ログには、日付、問い、調査前の仮説、確認した事実、変えた箇所、判断者・会議体、選んだ分岐、未確認事項、実行責任者、期限を残します。当たり外れの二択では、判断の癖も、決定後の責任も振り返れません。
会議では、資料を読む前に参加者が各自の回答を書き、議論後にどこが変わったかを確認します。個別に書いてから共有すれば、異なる回答と反証条件を議論の前に残せます。
仮説思考が機能しなくなるパターン
仮説を守ることが目的になると、情報収集の偏りが強まります。更新条件を先に書き、支持材料と反対材料を同じ記録に残すことが防止策です。つまずき方には型があります。
問いが広すぎる。 「この事業は成功するか」では、顧客課題、購買、収益、実現方法が混ざります。次の会議で実際に選ぶ内容まで、問いを小さくします。
仮説が方針へ変わっている。 上位者が述べた案を覆せない組織では、検証が賛成材料の収集になります。「誰の発言か」ではなく「どの事実で更新するか」を開始前に合意しておきます。
支持する回答だけを拾う。 「欲しい」と答えた人の発言だけを残し、使わない条件や現在の代替手段を削ると、顧客像が実態より広がります。反対例を別欄にせず、仮説と同じページへ置きます。
一人の発言を市場全体へ広げる。 一人の具体的な経験は、次の仮説をつくる材料になります。ただし、市場での発生率や顧客全体の傾向は示しません。誰の、どの条件で起きた事実かを残し、別の対象者や方法で確かめます。
更新しても意思決定が動かない。 判断者と判定日が決まっていなければ、検証結果は担当者の記録で止まります。維持、変更、追加確認、保留、停止、追加投資。どれを選ぶ会議なのかを先に定めます。
まとめ|仮説は当てるためではなく、更新するために置く
仮説思考は、少ない情報で性急に決める技術ではありません。限られた時間で、結論を変える可能性が高い情報から確かめる技術です。 問いへの暫定回答を置き、成立条件と反証条件を分け、確認した事実に合わせて答えと次の行動を更新していきます。
調査の前に「何を決めるのか」「現時点ではどう答えるのか」「何が出たら答えを変えるのか」を書きます。調査の後は、どの言葉をどの事実で変えたかに加え、誰がどの分岐を選び、誰がいつまでに動くかを残します。この反復が、仮説思考を会議の掛け声から実務へ変えます。
