仮説思考とは、情報を集めきる前に「たぶんこれが答えだろう」という仮の答えを置き、それを確かめながら書き換えていく考え方です。最初に答えの候補があるので、集める情報が絞られ、調査に使う時間が短くなります。この記事では、仮説の立て方の手順と、外れたときの扱い方を、業務改善の現場でよくある場面を例に説明します。
仮説思考とは何か
ここでいう仮説は、まだ証明できていないけれど、いま手元の情報で考えるかぎり最も答えに近そうなものを指します。答えの中身は「問題はここにある」という問題の特定のこともあれば、「こうすれば解決する」という解決策のこともあります。
日常生活でも人は仮説を使っています。「雨の日は外食する人が減るから、あの店も空いているはずだ」と考えて出かけ、空いていればその考えは当たり、混んでいれば考えを直します。仕事での仮説思考も、これを意識して速く回しているだけです。
流れは次のサイクルです。
- 限られた情報から仮の答えを立てる
- 実験・ディスカッション・分析のどれかで確かめる
- 当たり・部分的に当たり・外れの結果に応じて仮説を書き換える
このサイクルは、1回ごとの仮説の出来よりも、回す速さのほうが成果に効きます。最初の仮説が外れても、外れたという事実がわかった分だけ答えに近づいています。
情報を集めてから考えると何が起きるか
実装の経験を積んだエンジニアが初めて上流工程に入ると、「まず現状を全部把握しないと何も言えない」と考えがちです。業務の資料を読み込み、関係者全員に話を聞き、データを片っ端から集める。ところが、集めるほど細部が気になって、肝心の「で、何が問題なのか」に答えられなくなります。細かい分析はできるのに全体の筋が描けない状態です。
情報収集には終わりがありません。答えの候補がないまま集めると、どの情報が重要でどれが捨ててよいかを判断する基準がないからです。結局、時間切れになって根拠の薄い結論を出すか、必要なデータが揃わないまま止まってしまいます。
仮説を先に置くと、見るべき情報は「その仮説が当たっているかどうかを判定できる情報」に限られます。次のような情報は思い切って捨てて構いません。
| 観点 | 捨ててよい情報 |
|---|---|
| 仮説との関係 | 仮説の検証に直接関わらない |
| 鮮度 | 環境が変わって前提が古くなっている |
| 重複 | 同じ事実を別の言い方で書いているだけ |
| 信頼性 | 出所がわからない、件数が少なすぎる |
仮説の立て方の5ステップ
手順にすると次のとおりです。
- 問いを1文で書く。何の答えを出したいのかを言葉にします。「経費精算の締めが毎月遅れるのはなぜか」のように、主語と知りたいことを入れます。
- 手元の情報をざっと眺める。データ、現場の声、自分の直感のメモを並べます。この段階で網羅は狙いません。
- 仮の答えを1〜3個書く。完璧でなくて構いません。
- 検証できる形にする。何を見れば当たり・外れがわかるかを書き添えます。
- 確かめて書き換える。結果を見て、仮説を残す・直す・捨てるを決めます。
書くときは次の型を使うと、検証の手段まで一緒に決まります。
[原因 / 解決策] は [仮の答え] である。
これは [どのデータ / 誰へのヒアリング / どんな小さな試行] で確かめられる。
仮説はどこから出てくるか:推論の3型
「仮説を立てろと言われても思いつかない」という人は多いのですが、仮説の出どころは大きく3種類に分けられます。論理学でいう演繹・帰納と、哲学者パースが整理したアブダクション(仮説的推論)です。
| 推論の型 | 流れ | 仮説での使い方 | 注意点 |
|---|---|---|---|
| 演繹 | 一般的な法則から個別の結論を出す | 経験則や業界知識を目の前の案件に当てはめる | 元の経験則が外れていると仮説も外れる |
| 帰納 | 個別の事実から共通点を引き出す | ヒアリングやデータの共通項から仮説を作る | 集めた事例が偏っていると一般化を誤る |
| アブダクション | 観察した事実を最もよく説明する答えを選ぶ | 複数の事実を一度に説明できる筋を探す | もっともらしいだけで、必ず正しいとは限らない |
経験の長い人が「話を聞いた瞬間に答えが見える」のは、目の前の案件を過去の似た案件と照らし合わせて演繹しているからです。経験が浅いうちは、先輩の事例や他社の導入事例を意識してためておくと、演繹に使える材料が増えます。
対象を「属性の組み合わせ」で見る
3つの型のどれを使うにしても、前提になるのは対象を属性の組み合わせで捉えることです。たとえば「A社の在庫管理システム刷新」という案件は、そのままでは他の案件と比べようがありません。「BtoB卸売 × 基幹システム連携あり × 承認が2段階 × 帳票の種類が多い × 期間4か月」のように属性で書き直すと、同じ属性を持つ過去の案件と比べられるようになります。
属性は比べることで見つかります。似た事例を3つ以上並べ、「AとBはこうだったが、Cは違った」という差を探して言葉にします。その差が、次の仮説で使える新しい属性になります。
発想が止まったときの4つの視点
仮説が出てこないときは、見る角度を変えます。
| 視点 | 自分への問い |
|---|---|
| 反対側から見る | 相手の立場ならどう見えるか |
| ゼロベースで考える | そもそもこの業務はなぜ必要なのか |
| 極端に振る | 件数が10倍、あるいはゼロになったらどうなるか |
| So What? | 並べた事実から、つまり何が言えるか |
これらは仮説を「立てる」ための道具です。検証の段階で使うものではない点に気をつけてください。
例題:経費精算の締めが毎月遅れる
ある会社の経理部から「月末の経費精算の締めが毎月3営業日ほど遅れて困っている。システムを入れ替えたい」と相談を受けたとします。
情報を集めてから考える進め方だと、経理部全員へのヒアリング、精算システムの全画面の確認、過去1年分の申請データの取得から始めることになります。仮説思考では、まず仮の答えを置きます。
- 仮説1:申請者の提出が月末に集中していて、経理の確認作業が後ろに詰まっている
- 仮説2:差し戻しが多く、やり直しの往復で日数がかかっている
- 仮説3:部門長の承認が止まっていて、経理に回ってくるのが遅い
それぞれ、何を見れば判定できるかを書き添えます。
| 仮説 | 確かめる方法 | 当たりと判断できる状態 |
|---|---|---|
| 提出の集中 | 申請日の分布を日別に集計 | 最終3日間に申請が偏っている |
| 差し戻しの多さ | 差し戻し履歴の件数と理由 | 同じ理由の差し戻しが繰り返されている |
| 承認の停滞 | 申請から部門承認までの日数 | 特定の部門だけ承認日数が長い |
まず経理の担当者に30分ほどこの3つをぶつけてみます。すると「差し戻しは月に数件しかないが、領収書の添付漏れの問い合わせに時間を取られている」という話が出てきました。仮説2は外れ、代わりに「添付漏れの確認作業が締めを押している」という新しい仮説に書き換わります。次は申請データから添付ファイルなしの件数を数え、分析で裏付けを取ります。
この時点で、システムを丸ごと入れ替えるより、申請時に添付を必須にする入力チェックを入れるほうが効果がありそうだ、という方向が見えてきます。全部を調べていたら、ここにたどり着くまでにずっと長い時間がかかっていたはずです。
よい仮説の条件
何でも仮説と呼べばよいわけではありません。次の点を確認します。
- 具体的:主語、対象、指標が入っているか。「営業に問題がある」は仮説として弱く、「既存顧客への訪問回数が前年より減り、更新率が下がっている」なら検証できます
- 検証できる:データ、ヒアリング、小さな試行のどれかで確かめられるか
- 当たり前で終わっていない:誰でも言えることを並べていないか
- 次の行動につながる:当たったら何をするかが見えるか
- 他の有力な可能性を見落としていない:別の説明が残っていないか
仮説の検証3手法
| 手法 | 強み | 弱み | 向く場面 |
|---|---|---|---|
| ディスカッション | 速い、反論をたくさん集められる | 主観に寄りやすい | 仮説を早めに揺さぶりたいとき |
| 実験 | 実際の反応がわかる、意外な発見がある | 時間とコストがかかる | 小さく試せる領域 |
| 分析 | 客観的で説得力がある | 準備に時間がかかる | 承認や最終報告の根拠にするとき |
順番の目安は、まずディスカッションで粗く揺さぶり、必要なら小さな実験をし、最後に分析で数字の裏付けを取る流れです。ディスカッションは仮説を守るためではなく、崩すためにやります。反対意見の中に、まだ見えていない事実が混じっていることが多いからです。
よくある失敗
- 仮説を1つだけ立てて固執する。外れたときに次の候補がなく、検証結果を都合よく解釈し始めます。最初から2〜3個並べておくと、1つが外れても動揺しません。
- 検証方法を決めずに仮説を立てる。「何を見れば外れとわかるか」がないと、いつまでも当たりとも外れとも言えません。
- 4つの視点を検証に使う。「Aではないか」を極端に振ってみても、Aを否定できるだけで別の答えは出てきません。検証は3手法で行います。
- ヒアリングで仮説を言わない。顧客に「何が困っていますか」と白紙で聞くと、話は散らばります。「こういうことではないですか」とぶつけたほうが、相手も具体的に答えられます。
- 外れた仮説を記録しない。なぜ外れたかを書き残しておくと、次の案件で同じ間違いを避ける材料になります。
この記事のまとめ
- 仮説思考は、情報を集めきる前に仮の答えを置き、検証して書き換えていく考え方
- 立て方は「問いを1文で書く→情報をざっと見る→仮の答えを1〜3個→検証方法を添える→書き換える」の5ステップ
- 仮説の出どころは演繹・帰納・アブダクションの3型。土台は対象を属性の組み合わせで捉えること
- よい仮説は具体的で、検証でき、次の行動につながる
- 検証はディスカッション→実験→分析の順で、反論を集めるつもりで行う
仮説思考は、ロードマップのステップ3「課題を構造化する」で、イシューツリーや俯瞰思考と組み合わせて使う技術です。ヒアリングで仮説をぶつける進め方はヒアリングでASISとTOBEの差を掴む記事も参考になります。体系的な解説はFDEガイドの「仮説思考」にまとまっており、スライド・演習問題・テストは lecture.iplot.jp で取り組めます。FDE Guild のトレーニングでも同じ教材を使っています。
