仮説を立てたら、次は「この仮説が正しいなら、こういうデータが出るはずだ」を設計する。この「はず」を先に決めておくだけで、検証が速く、正確になります。
この記事でわかること
- 検証の設計とは何か
- 「はず」を先に決めると何が変わるか
- 検証の深さは判断の大きさで変える
「UI変更が解約の引き金ではないか」。Vol.3で仮説を立てました。次にやるべきことは「データを見る」ですが、ここに落とし穴があります。
漠然とデータを見始めると、Vol.2で整理した「目立つ数字に引っ張られる」問題が再び起きます。仮説を持っていても、検証のし方が曖昧だと、結局は「なんとなくデータを眺める」に戻ってしまう。
検証の設計とは何か
仮説を検証するとは、「この仮説が正しいなら、どういうデータが出るはずか」を先に決めて、実際のデータと照らし合わせることです。
「UI変更が解約の引き金ではないか」。この仮説が正しいなら：
「UI変更後の解約率は、変更前より高いはず」。
「解約した顧客の中で、変更された機能のヘビーユーザーの割合が高いはず」。
「UI変更の影響を受けない機能だけを使っている顧客の解約率は変わらないはず」。
この3つの「はず」が、検証の設計です。データを見る前に「何が出れば正しい、何が出れば間違い」を決めておく。
なぜ先に決めるのか。後から決めると、都合のいい解釈をしてしまうからです。データを見たあとで「この数字は仮説を支持している」と思えば、どんなデータでも支持しているように見えてくる。これがVol.1で触れた確証バイアスです。
「はず」を決めるときの3つの視点
「はず」を考えるとき、3つの視点が役立ちます。
視点①：正の証拠——仮説が正しいなら、何が「ある」はずか
「UI変更後に解約率が上がっているはず」。仮説が正しければ存在するはずのデータ。これが最もストレートな検証です。
視点②：負の証拠——仮説が正しいなら、何が「ない」はずか
「UI変更の影響を受けない顧客層では、解約率が変わらないはず」。仮説が正しければ起きないはずのこと。正の証拠と負の証拠を両方見ると、検証の精度が上がります。
視点③：代替仮説との区別——別の仮説でも同じデータが出ないか
「解約率の上昇は、たまたま競合のキャンペーンと時期が重なっただけかもしれない」。もし競合のキャンペーンが原因なら、ヘビーユーザーに限らず全顧客で解約率が上がるはず。ヘビーユーザーに偏っているなら、競合キャンペーンの説は弱くなる。
自分の仮説だけでなく、別の説明でも同じデータが出るかどうかを考える。 「データが仮説を支持しているように見えるが、実は別の原因だった」という見落としを防げます。
検証は「最小限」から始める
「はず」を3つも設計したら、検証に時間がかかるのでは？ いいえ。まず1つ目の「はず」だけ検証する。
「UI変更後の解約率は、変更前より高いはず」。これを確認する。もし差がなかったら、仮説はその時点で外れ。2つ目・3つ目を検証する必要すらない。
差があったら、2つ目に進む。「ヘビーユーザーの解約率が特に高いはず」。これも確認できたら、仮説はかなり有力。
全部を同時に検証するのではなく、一番早く白黒つく「はず」から順番に確認する。 仮説が早い段階で外れれば、そこで止めて次の仮説に行ける。これがVol.1で整理した「仮説は間違っていていい」の実践版です。
検証の深さは、判断の大きさで変える
仮説が有力そうだと分かった。ここからどこまで検証を深めるかは、その仮説に基づいて下す判断の大きさで変わります。
後戻りコストが大きい判断は、検証を深くする。 経営判断レベル——大きな投資判断、事業方針の転換、組織体制の変更——であれば、追加の検証を重ねて精度を上げるべきです。間違った仮説に基づいて大きな意思決定をすると、取り返しがつかない。3つの「はず」をすべて検証し、代替仮説も潰して、確度を上げてから動く。
後戻りコストが小さい判断は、検証を浅くして速く動く。 来週のキャンペーンの方向性、テスト的な改善施策、小規模な運用変更。こうした判断は、仮説が「有力」の段階で動いてしまっていい。やってみて違ったら戻せばいい。
「この判断を間違えたとき、どれくらい痛いか」で検証の深さを決める。 痛みが大きいほど深く、小さいほど浅く速く。すべての仮説を同じ深さで検証する必要はありません。
検証結果の読み方
データを見ました。結果をどう読むか。
「はず」通りのデータが出た場合。 仮説は有力。判断の大きさに応じて、追加検証に進むか、打ち手に進むかを決める。
「はず」と違うデータが出た場合。 仮説は外れ。ここで大事なのは、素直に外れを認めること。「いや、でも別の見方をすれば……」と仮説に固執し始めたら危険。外れたら、得られた情報を整理して次の仮説に進む。「UI変更は原因ではなかった」。これは有用な情報です。
どちらとも言えない場合。 追加の「はず」を検証するか、仮説を修正する。「UI変更が主因ではないが、一因かもしれない。他の要因と組み合わさっているのではないか」。仮説を調整して、再度検証する。
良い検証のゴールは「結論と根拠をセットで言い切れる」こと
仮説を検証したら、最終的にこういう形でまとめられるのが理想です。
「解約率上昇の主因はUI変更です。UI変更後にヘビーユーザーの解約率が2倍に上がっており、変更されていない機能だけを使う顧客の解約率は変わっていないからです。」
結論と根拠が1〜2文にまとまっている。 何が分かったのか、なぜそう言えるのかがセットになっている。これが言えれば、上司に報告するときも、チームに共有するときも、一発で伝わります。
逆に、検証したのにこの形でまとまらないなら、まだ検証が足りないか、仮説が曖昧だったかのどちらかです。「たぶんUI変更が原因だと思うんですけど、データを見てもよく分からなくて」。これでは検証した意味がない。
「結論はこうだ。根拠はこれだ」と言い切れることを目指す。 そのために仮説を立て、「はず」を設計し、データで確かめる。このプロセスの全体が、この言い切りに集約されます。
AIに検証を手伝わせる
仮説の検証は、AIが最も力を発揮する場面のひとつです。
「UI変更が解約の引き金ではないかという仮説がある。UI変更前後の解約率を比較してほしい。変更された機能のヘビーユーザーとそれ以外で分けて」。
仮説と「はず」を明確に渡せば、AIは的確にデータを分析してくれます。Vol.1で整理した「AIは検証が得意」の実践です。
ただし、AIの出力を鼵呑みにしない。「本当にこの比較で正しいか」「見落としている変数はないか」は人間が判断する。検証の設計と結果の解釈は人間の仕事。検証の実行はAIに任せる。この役割分担が効率的です。
まとめ
この記事のポイントを3つにまとめます。
- 検証の設計とは「この仮説が正しいなら、こういうデータが出るはず」を先に決めること。正の証拠・負の証拠・代替仮説との区別の3つの視点で「はず」を設計し、一番早く白黒つくものから検証する
- 検証の深さは判断の大きさで変える。後戻りコストが大きい判断ほど深く、小さい判断ほど浅く速く。すべてを同じ深さで検証する必要はない
- 良い検証のゴールは「結論と根拠をセットで言い切れる」こと。「主因はこれだ。なぜなら」と言えれば、仮説→検証のプロセスは成功
次回は「仮説が外れたとき」を扱います。外れた仮説は失敗ではなく情報。でも、修正して続けるべきか、捨てて別の仮説に行くべきかの判断は難しい。その判断基準を整理します。
