「仮説を持て」と言われても、どうやって立てればいいか分からない。事実を3つ並べて、パターンを見つけて、「こうではないか」を一言にする。これだけです。
この記事でわかること
- 仮説の素材は「観察」から生まれる
- 事実を並べてパターンを見つける方法
- 「こうではないか」を一言にするコツ
「仮説を立ててから動け」。前回までで、その理由は理解できた。でも、実際にやろうとすると手が止まる。「仮説ってどうやって立てるの？」。
仮説は空から降ってくるものではありません。材料があります。その材料は「観察」です。
仮説の素材は「観察」から生まれる
仮説を立てるとき、いきなり「答え」を考えようとしなくていい。まず事実を見る。
「解約率が上がっている」。これだけでは仮説は立てられません。でも、もう少し事実を集めると見えてくるものがあります。
「解約率が上がっている」。「先月のUI変更のあとから上がり始めている」。「解約した顧客の多くが、変更された機能をよく使っていた」。
3つの事実が並ぶと、パターンが見えてきます。「UI変更が解約の引き金になっているのではないか」。これが仮説です。
仮説は「事実を観察して、パターンを見つけて、そこから推測する」ことで生まれます。 いきなり答えを出そうとするから難しい。事実をまず並べる。並べると見えてくる。
仮説の立て方：3ステップ
具体的な手順は3つです。
ステップ1：事実を3つ以上集める
いきなり仮説を立てようとしない。まず、手元にある事実を並べます。
解約率の例なら：「今月の解約率が前月比0.4ポイント上昇」「先月UI変更を実施」「解約顧客の70%が変更された機能のヘビーユーザー」。
ポイントは3つ以上並べること。1つの事実だけで仮説を作ると偏ります。「解約率が上がった」だけで「競合に負けている」と結論づけるのは飛躍。3つの事実が揃うと、根拠のある推測ができます。
事実がまだ手元にないときはどうするか。簡単に手に入るデータだけ見る。社内のダッシュボード、最近の報告、チームの声。5分で集められる範囲で十分です。完璧に調べてから仮説を立てるのでは、仮説を持つ意味がなくなります。
ステップ2：パターンを探す
並べた事実を見て、「つながり」を探します。
「解約率上昇」と「UI変更」と「ヘビーユーザーの解約」。この3つを見ると、「UI変更 → ヘビーユーザーが困惑 → 解約」という流れが見えてくる。
パターンの探し方にはいくつかのコツがあります。
時間の一致を見る。 「あの出来事のあとから、この数字が動いた」。時間的に近い出来事と数字の変動は、因果関係の手がかりになる。
共通点を見る。 「解約した顧客に共通する属性は何か」。属性が偏っていたら、そこに原因の手がかりがある。
例外を見る。 「解約率が上がっている中で、解約していない顧客は何が違うか」。例外の方がパターンを浮き彫りにすることもある。
ステップ3：「こうではないか」を一言にする
パターンが見えたら、それを一言の仮説にまとめます。
「UI変更によって操作方法が変わり、ヘビーユーザーが離脱しているのではないか」。
この一言が仮説です。Vol.1で整理した通り、「検証できるかどうか」を確認する。UI変更前後の解約率を比較する、解約顧客にUI変更後の操作について聞く。検証方法があるなら、仮説として成立しています。
一言にまとめるのが大事です。 長い文章で書くと、何を検証すればいいか分からなくなる。「こうではないか」を1文で言えること。それが仮説の条件です。
仮説が立てられないときのヒント
「事実を並べても、パターンが見えない」。こういうこともあります。
そのときは、「変化点」を探してみてください。 「この数字が動き始めたのはいつからか」。動き始めた時期に何が起きたかを調べると、仮説の手がかりが見つかることが多い。
もうひとつは、周囲の人に聞くこと。 「最近、何か変わったことはないですか」。自分が見ていない事実を持っている人がいます。現場の営業担当、カスタマーサポート、プロダクトチーム。視点が違う人から事実を集めると、自分だけでは見えなかったパターンが浮ぶことがあります。
それでも難しければ、AIに手伝ってもらう。事実を3つ渡して「この3つの事実から考えられる仮説を3つ出して」と聞く。AIはパターンを見つけて仮説を提案するのが得意です。ただし、AIが出した仮説をそのまま使うのではなく、自分の現場感覚と照らし合わせて「これはあり得る」「これは違う」と判断すること。
よくある失敗：仮説を作り込みすぎる
最後に、仮説を立てるときの注意点。作り込みすぎないこと。
「UI変更による操作性の低下が、特にダッシュボード機能を週3回以上利用していた中規模企業の管理者層において、代替ツールへの移行を促進し、結果として解約率の上昇に寄与しているのではないか」。
正確かもしれませんが、検証するのに何日もかかります。
「UI変更が解約の引き金ではないか」。これで十分。検証してみて、正しそうなら細かく掘る。最初から完璧な仮説を作ろうとすると、仮説を立てる段階で時間を食います。
Vol.1で「精度よりスピードで始める」と整理しました。仮説の立て方もまったく同じです。粗くていいから「こうではないか」を1つ持って、動く。
仮説思考が上手い人は、普段から「見て」「回して」いる
仮説をパッと立てられる人がいます。「たぶんUI変更が原因だと思う」と、会議の場ですぐに仮説が出てくる。
これは才能ではありません。普段からサービスの基本的な指標を見ているからです。
解約率の推移、新規の商談数、顧客の利用頻度。こうした数字を日常的に見ていると、「いつもと違う」に気づけます。「先月からこの数字が動いている」「この指標だけ傾向が変わった」。普段の数字を知っているから、変化に気づく。変化に気づくから、仮説が立てられる。
逆に、普段から数字を見ていない人は、問題が起きたときに初めてダッシュボードを開きます。「いつもの状態」を知らないから、何が異常なのか分からない。仮説の素材がないまま、ゼロから考えることになる。
もうひとつ大事なことがあります。施策を打ったら、ちゃんと結果を評価しているかどうか。
「先月、解約防止のためにオンボーディングを強化した」。でも、その結果どうなったか確認していない。解約率は下がったのか。下がったなら、オンボーディング強化が効いたのか、別の要因か。確認していないから、次に何をすべきかも分からない。
驚くほど多くの人が、施策を打ちっぱなしにしています。アクションは起こすが、その結果を検証しない。これは仮説を立てたのに検証しないのと同じです。仮説→検証→次の仮説、というサイクルが回っていない。
仮説思考が上手い人は、普段から小さなPDCAを回しています。「この施策を打てば、この数字が動くはずだ」という仮説を持って施策を実行し、結果を見て「効いた」か「効かなかった」かを判断する。効かなかったなら、なぜかを考えて次の仮説に進む。
この小さなサイクルを日常的に回しているから、いざという時にも素早く仮説が出せるし、検証の精度も高い。
特別な訓練は必要ありません。週に1回、5分でいいから自分の担当領域の基本指標を見る。 「先週と比べてどうか」「打った施策は効いているか」を確認するだけ。これを続けると、数字に対する「普段の感覚」ができます。普段の感覚があるから、異変に気づけるし、仮説も立てられる。
まとめ
この記事のポイントを3つにまとめます。
- 仮説は「事実を観察して、パターンを見つけて、推測する」ことで生まれる。空から降ってくるものではない
- 手順は3ステップ。事実を3つ以上並べる、パターンを探す（時間の一致・共通点・例外）、「こうではないか」を一言にまとめる
- 仮説思考が上手い人は普段から指標を見て、施策の結果を評価して、小さな仮説検証サイクルを回している。いざという時だけやろうとしても遅い
次回は「仮説の検証」を扱います。仮説を立てたら、次は「何を見れば確かめられるか」を設計する。仮説が正しいなら、こういうデータが出るはず。この「はず」を先に決めておくことで、検証が速くなります。
