仮説検証

仮説検証とは、調査の前に「たぶんこうではないか」という仮の答え（仮説）を立て、それが正しいかをデータで確かめ、次の判断につなげる一連の進め方です。

混同しやすい言葉を先にほどいておきたい。差が偶然かを数字で判定する作業（統計的検定）は、仮説を確かめる「最後のひと押し」にすぎない。仮説検証とは、問いを立て、何を見れば仮説を捨てるかを決め、データで判断する——その流れ全体のことだ。

仮説検証を具体例で理解する

配信したメール（メルマガやアプリ通知）が、なかなか読まれない。とする。

「とりあえずアンケートを取って何か出ないか見る」のは、まだ仮説検証ではない。仮説検証は、先に賭ける。たとえば「件名が用件を示せていないのではないか」。これが仮説だ。そのうえで決める——もしそうなら、用件が分かる件名に書き換えた回ほど、開封率は上がるはずだ。逆に、件名を変えても開封率が動かなければ、この仮説は外れ。

データを見る。件名を変えた回も変えていない回も、開封率は同じだった。なら、潔く捨てる。原因は別だ。

当たったか外れたかではない。先に「何が観察されたら間違いと認めるか」を決めてあること。それが仮説検証だ。

仮説検証の仕組み

仮説検証は、問いから始まる。何を知りたいかを答えの出る形に絞ったリサーチクエスチョンがあり、その仮の答えが仮説だ。

仮説には、検証できる形が要る。「ユーザーは満足していないのではないか」では確かめようがない。「初回利用から 1 週間以内に再訪しない人ほど継続率が低い」のように、観察できる事実に落ちて初めて、データと突き合わせられる。

肝心なのは、データを取る前に「どう出たら仮説を捨てるか」を決めておくことだ。後から基準を動かせば、人は自分に都合よく数字を読む。

探索と検証を、どう使い分けるか

調査には、性格の違う二つのモードがある。まだ何が起きているか分からないときは「広く眺める」、もう見当がついているときは「正面から確かめる」。発注の前に見分けておけば、設計を間違えにくい。

• 探索的（仮説をつくる）：まだ何が起きているか分からないとき。自由回答やインタビューで広く眺め、「こうではないか」という候補を見つけにいく。ここで出た発見は、まだ「思いつき」だ。
• 検証的（仮説を確かめる）：仮説がすでに手元にあるとき。それを正面から確かめるよう設計し、結果から判断を下す。

この二つを混ぜると事故につながりやすい。探索でたまたま見えた差を、そのまま「検証された結論」として扱ってしまうのが典型だ。広く探せば偶然のパターンはいくらでも目に入る。確かめ直さずに信じると、根拠の弱い打ち手に進んでしまう。

検証では、もうひとつ要ることがある。人は無意識に、自分の仮説を支える証拠ばかり集めてしまう。だからあえて、仮説が外れていたら出るはずの反証データを取りにいく。「件名を変えていない回も、同じくらい開かれていないか」を確かめる姿勢が、検証の質を分ける。

仮説検証でわからないこと、間違えやすいこと

仮説検証は、正しい仮説を授けてはくれない。確かめられるのは、手元の仮説が今回のデータと折り合うかだけだ。立てた仮説が的外れなら、きれいに検証しても見当違いの答えにしかならない。

仮説が支持されたことも「証明された」とは違う。同じデータにうまく合う別の説明が残っているかもしれないし、次に取るデータで覆るかもしれないからだ。検証とは白黒をつける儀式ではなく、その仮説を残すか捨てるかを決める作業に近い。

p 値や有意かどうかの細かい話は、統計的検定に譲る。発注側が握るべきなのは、その手前の設計のほうだ。

確かめたい仮説を、ひとつ決めることから

調査の経験が浅いうちは、つい「データを見れば答えが出る」と思ってしまう。けれど、仮説を持たずに眺めた数字は、見たいものだけを映す鏡になりやすい。集める速さがいくら上がっても、そこは変わらない。

次に調査を頼むときは、確かめたい仮説をひとつ決め、何が出たらそれを捨てるかも、先に書いておく。

そこから始めれば、返ってきた数字は、見立てを正してくれる相手に変わっていく。