不確実性の中で仮説を検証する：決める責任と、止める条件

「まだ分かりません」と言い続けるだけでは、判断は進みません。けれど「この案で成功します」と言い切っても、不確実性が消えるわけではありません。この二つの間で、どのように責任を持って選ぶのか。そこが、First byteが考え続けたい問いです。

私たちは、分かっていることを明確にし、分からない部分には仮説を置き、その仮説を変える条件を共有することを重視します。この記事で示す判断メモや手順は、そのための独自の方法論です。外部の統計・調査・実験の資料から確認した事実とは区別して説明します。

30秒で要点

• 観測した事実、理由を説明する仮説、何を選ぶかという判断を分けます。
• 成功確率だけでなく、利益・損失・制約と元に戻せる範囲を比べます。
• 検証には終わり方も必要です。安全停止、採用、見送り、追加確認の条件を先に置きます。

「断定しない」のではなく、言える範囲をはっきりさせる

記録を確認できたなら、「対象100件のうち20件が完了した」と言えます。ただし、対象の選び方や完了の定義も一緒に示します。そこから「説明を変えたので完了が増えた」「次の顧客でも同じ結果になる」へ進むには、別の材料が必要です。

私たちが避けたいのは、すべての文を曖昧にすることではありません。観測の確かさと、原因や将来への推測の確かさを一つにしてしまうことです。都合の悪い事実まで「仮説だから」とぼかしてよいわけではありません。

表が収まらない場合は、横にスクロールできます

仮説が外れたこと自体は、必ずしも無駄ではありません。ただし、何を観測し、どの説明が弱くなったのかを残せなければ、同じ試行を繰り返すだけになります。「失敗から学ぶ」を、記録のない免責にしないことが必要です。

データの限界を、使い道の限界として書く

例えば「20代、未婚、年収300〜400万円」という属性だけが分かっていても、その人が何を選ぶかは決まりません。さらに、属性の列があるだけでは、その集団の平均的な行動まで分かるわけではありません。何の行動を、どの人から、いつ集めたかが必要です。

居住地や生活の事情が未観測である可能性はあります。しかし、不足する属性を片端から集めることが答えとも限りません。今回の判断に必要か、適切に取得・利用できるか、記録した項目で本当に違いを説明できるかを確かめます。

AAPORの調査指針は、対象全体と実際に接触できる枠、回答の集まり方を分け、調査方法を明らかにするよう求めています。私たちは、これを「この数字で言える範囲」を決める問いとして使います。特定の回答者の傾向を、そのまま個人の性格や全顧客の性質に読み替えません。

一方で、完璧なデータを待つことも目的にはしません。英国政府の品質指針は、データ品質を用途への適合として考え、時点や完全性などの間に取引関係があることを説明しています。同じ記録でも、現場の不具合を発見する用途と、全社の予算を決める用途では必要な品質が違います。

ここでの線引きは「完全か不完全か」ではなく、この判断には何が足りず、それを放置すると何を誤るかです。分からないことを全て列挙するより、判断を変え得る不明点を選びます。

仮説には、考え直す条件まで含める

「使いやすくすれば成果が出る」では、何を見ても後から説明できてしまいます。例えば、次のように対象と変更を絞ります。

仮想のフォームで、入力例がないために必須項目の意味を取り違える人がいるのではないか。入力例を加えると、その誤解が減ると予想する。まず操作を観察して、どの言葉をどう読んだかを確認する。

これで確かめるのは、まず説明の理解です。少人数の操作確認から、全体の送信率の改善幅まで求めるわけではありません。理解の問題が見つからなければ、資料が手元にない、中断が必要になる、といった別の仮説を考えます。

送信率の差を調べる段階では、対象、比較相手、割付単位、主要指標、必要人数と期間を計画します。Microsoftの実験前の指針は、仮説と測る指標を結び付け、割付単位や限定利用者からの一般化に注意を促しています。

仮説を持つことには、見たいものだけを見る危険もあります。そこで私たちは、支持する観測だけでなく、説明が弱くなる観測、別の説明でも起こり得る観測を分けておきます。結果を見て仮説を修正することはできますが、最初から予想していたようには扱いません。探索して見つけた説明は、次に確かめる候補として残します。

成功確率が高い案が、いつもよいとは限らない

判断には、何を成功と呼ぶかに加えて、成功や失敗のときに何が起こるかが関係します。次は、確率も損益も説明のために仮定した例です。実測した成功率や将来予測ではありません。金額は同じ評価期間の純増減で、費用を含むとします。

表が収まらない場合は、横にスクロールできます

この仮定では、成功確率が高いAの期待値が低くなります。期待値は、各結果を確率で重み付けした値です。一度実行したときに、この金額を受け取るという意味ではありません。

これをもってBが常に正しいとも言えません。5万円の損失さえ受け入れられないなら、Bも選べないかもしれません。お金に置き換えにくい利用者の負担、守るべき条件、回復にかかる時間もあります。そもそも90%や60%を根拠付きで推定できないなら、数字を精密に見せるべきではありません。

私たちは、確率を置ける場合でも、その根拠と変えたときの選択を確認します。この例のBは、成功確率を仮に30%へ下げると期待値が−0.5万円になります。確率を3分の1と置いたときが、金額上の期待値ゼロの境目です。このように条件を変える点検は、どの仮定が判断を左右するかを見つけるために使います。

待つことにも、試すことにも費用がある

追加調査で何が分かるのか。その情報があれば、選ぶ案は変わるのか。変わりそうにないなら、調査を増やす価値は限られます。反対に、取り返しのつかない判断なら、少し待って確かめる価値が大きいこともあります。

待つ費用には対応の遅れや機会の損失があり、試す費用には実装・運用・利用者への負担があります。どちらかを常に正しいとするのではなく、「待てば得られる情報」「待っても分からないこと」「試した後に戻せる範囲」を分けます。

小さく試すことにも限界があります。対象が少なくても重大な不利益は起こり得ますし、限定された利用者だけの結果が全体で再現するとは限りません。「小さいから安全」「試せば必ず学べる」を前提にせず、観測できる結果と止め方を設計します。

検証の出口を先に置く

検証を続ける姿勢と、同じ検証を際限なく続けることは別です。新しい情報を集めるたびに基準を緩めれば、何かを確かめたつもりで、自分の案を守る作業になってしまいます。

運用上の見直し日を決めても、その日までに統計的に十分な情報が集まるとは限りません。その場合は「不明のまま見送る」「戻せる範囲に限る」「別の計画で追加確認する」などを選び、証拠が十分だったことにはしません。

また、通常の固定期間の検定で、毎日p値を見て有意になったときだけ成功として終えると、誤検出の扱いが変わります。早期判定には、それを考慮した方法が必要です。実験分析のチェックリスト研究では、こうした問題と、重大な悪化による停止を区別しています。

p値そのものも成功確率ではありません。ASAの声明は、閾値だけで事業判断をしないよう示しています。私たちの採用判断も、統計量に責任を肩代わりさせるものにはしません。

AI・心理学・統計を、役割を分けて使う

First byteでは、この三つを判断の補助として組み合わせる方法を考えています。ただし、組み合わせれば成功確率が上がるという一般的な効果を、この記事で確認したわけではありません。ここで述べるのは、私たちの役割分担の提案です。

• AIには、論点の整理、別の仮説、反例、計算の候補を出す補助を担わせます。出典や計算は、元の資料へ戻って確かめます。
• 心理学の知見は、人がどこで迷い得るかを考える手がかりにします。個人の内面を決め付けたり、研究条件を越えて反応を保証したりしません。
• 統計は、比較や推定の条件、不確実性の大きさを点検するために使います。価値観や許容損失まで一つの数値に決めさせません。

誰が何を決める権限を持つか、どの負担を受け入れるかは、関係者が共有する必要があります。もっともらしい説明ができたことと、その判断を引き受けられることは別です。

最初の一枚に、判断が変わる条件を残す

まず、いま決めかねていることを一つ選び、次の項目を一枚に書いてみます。これは独自の整理案で、万能の採点表ではありません。

表が収まらない場合は、横にスクロールできます

最小の検証は、仮説を一つ選び、その根拠になった記録を確かめるところからでも始められます。フォームの例なら、まず数件の記録と操作を見て、完了の定義や説明の読み方を確認します。そこで全体の改善効果まで結論しないことも、検証の一部です。

私たちが残したいのは、変わらない正解ではなく、判断した理由と、判断を変える条件です。何が確かめられ、何が不明で、誰がどの選択をしたか。それを共有できれば、続けるときも終えるときも、次の人が考え直す足場になります。

判断の枠組みはFirst byteの意思決定の考え方、不明な部分を残して選ぶ場面は正解が分からない状態での意思決定、数字の読み方は統計的思考とビジネス判断へつなげて考えられます。