「相関があるから」と盲信する前に読んでほしい、相関と因果の話

Posted at 2026-07-09

はじめに

こんにちは、もんすんです。

「行数が多いPRほど、バグが多い。だからPRは小さく分割しよう」

こんなレビューの鉄則みたいなことを我が物顔で語る人がいます。
私もやったことがないとは言い切れません。。

データを見れば確かにそう見えるし、経験的にも納得感がある。
一方、統計学では「相関と因果」に関する考え方が極めて重要視されます。

上記の例においては、**「行数とバグ数に相関がある」という事実を、いつの間にか「差分がバグの原因だ」**という因果にすり替わっているんです。

今回はそんな、現場に転がる「相関と因果の混同」を、回帰分析という切り口で疑ってみます。

厳密な定義は教科書に譲るとして、実務で使う分にはこう捉えておけば十分です。

相関＝「片方の変数が増えると、もう片方も増える（or 減る）傾向がどれくらい強いか」
回帰分析＝「その関係を数式で表して、片方から片方を予測しようとする」

「経験年数が増えるほど見積もり精度が上がる」なら正の相関、「テストカバレッジが上がるほど障害件数が減る」なら負の相関。関係の強さは相関係数（-1〜+1）という数字で表されます。

ここで押さえておきたいのは、相関は「一緒に動く」ことを示すだけで、「片方がもう片方を動かしている」とは一言も言っていないということです。

この一線を越えて解釈した瞬間に、話がおかしくなります。

我々の現場は、実は相関だらけです。

どれも「言われてみればそうだよね」と頷けるものばかりです。
そして厄介なことに、実際に相関はあるんです。
データを取れば、それらしい傾向は本当に出てきます。

問題は、この相関を根拠に「じゃあ行数を減らせばバグが減る」「カバレッジを上げれば障害が減る」と、施策の因果に直結させてしまうことです。

相関があるのに因果ではない。
その典型的な理由が交絡因子です。
交絡因子とは、ある原因と結果の間に、見せかけの因果関係を生み出してしまう第三の変数のことです。
AとBの両方に影響を与える「第三の要因C」が裏に隠れているケースです。

「行数とバグ数」で考えてみます。

複雑な機能変更は、当然コード行数も増えるし、バグも埋め込みやすい。
つまり**「変更の複雑さ」という第三の要因が、行数とバグ数の両方を押し上げている**だけかもしれない。
この場合、行数はバグの「原因」ではなく、複雑さの「結果」にすぎません。

だとすると、複雑な変更を無理やり小さいPRに分割しても、総量としての複雑さは減らないので、バグは大して減らないことになります。
行数という見かけの数字だけを削っても、本丸に手をつけていないからです。

「経験年数と見積もり精度」も同じ構図です。

経験年数そのものが精度を上げているのか、それとも 「同じドメインを長く担当している」などの別の要因 が効いているのか。
ドメイン知識が本命なら、経験10年でも初めての領域では見積もりを外す可能性が見えてきます。

ここで「じゃあ経験則なんて当てにならない」と結論するのは、行き過ぎです。

相関は、因果を探すための入口としては極めて優秀です。

大事なのは、相関を見つけたときに、そこで思考を止めないことです。

相関を見つけたら、まず「なぜそうなるのか」の因果仮説を立てる
- 「行数が多いとバグが多い → なぜ？ → 複雑だから？レビューが雑になるから？」と一段掘る
交絡因子を疑う
- 「AとBの両方に効いている第三の要因Cはないか？」を必ず自問する
施策は"原因"に打つ
- 行数（結果）ではなく複雑さ（原因）を狙う
- 「分割」ではなく「そもそも仕様を単純化できないか」を考える

経験則を使うこと自体は悪ではありません。危ないのは、相関という「一緒に動く」だけの事実を、「片方がもう片方を動かす」という因果に無自覚に格上げしてしまう瞬間です。

「相関を因果と勘違いする」のは、人間が結果から原因を後付けしたがる生き物だからで、これは前回のp-hackingやデバッグの話とも根っこは同じです。

統計学は、そういう私たちの都合の良い解釈に、ちゃんと待ったをかけてくれます。

それでは、また。