いきなり結論

増えたのは不具合じゃない。見つかる量かもしれない。

「チェック項目を増やしたら、不具合件数が増えた」──この現象、品質改善や業務改善をやっていると高確率で出会います。
そして多くの場合、ここでこう言われます。

「チェックを増やしたせいで、現場が荒れてるんじゃない？」

でもそれは、因果の取り違えかもしれません。

このケースの典型的な正体は、

見える化が進んで、今まで見逃していた不具合が“見つかるようになった”

です。

相関はヒント。因果は証拠。
今日は「増えた＝悪化」と決めつけて、改善の芽を自分で潰さないための話をします。

---

1. なぜ「チェックを増やすほど不具合が増える」が起きるのか

まず、当たり前のことを言います。

チェックを増やすと、見つかる不具合は増えます。

これは品質が悪化したからではなく、単に“発見できる範囲”が広がっただけ。

例を出すとわかりやすいです。

例：健康診断

検査項目を増やせば、病気が「増えた」ように見えます。
でも実際は、病気が急に増えたのではなく、

・見つかるようになった
・早期に拾えるようになった

だけです。

仕事でも同じ。

・レビュー回数を増やしたら指摘が増える
・監査を強化したら不正が増える
・問い合わせ窓口を増やしたらクレームが増える

「増えた」という結果は、悪化ではなく“観測の精度が上がった”可能性があります。

---

2. 用語を“日本一やさしく”整理する

今回のキーワードは3つだけ。

相関（correlation）

Aが増えるとBも増える（または減る）という「いっしょに動く」関係。
チェックが増えれば、検出件数が増える相関は普通に出ます。

因果（causation）

Aが原因でBが起きるという関係。
相関があるだけで「チェックが不具合を増やした」とは言えません。

検出効果（見える化効果）

今回の主犯。
不具合の総量が増えたのではなく、“見つかる率”が上がっただけという現象です。

そして、もう一つありがちな落とし穴があります。

逆因果（reverse causality）

不具合が増えた（炎上した）から、チェックを増やしたケース。
この場合もデータ上は「チェック増→不具合増」に見えます。

---

3. 「これは本当？ 嘘？」をちゃんと分ける

今回も2つに分解します。

Q1：相関は本当？

本当です。
チェック項目やレビューが増えれば、見つかる不具合（指摘）は増えやすい。

Q2：因果（チェックが不具合を増やす）は本当？

嘘かもしれない。
少なくとも「相関がある」というだけでは因果は言えません。

むしろ起きがちなのは次のどれかです。

・検出効果：見つかるようになっただけ
・逆因果：不具合が増えたからチェックを増やした
・黒幕：大型リリースや仕様変更が増えた（両方が増える）

---

4. ビジネスでの“実害”：改善が「やめる理由」にされる

ここで因果を取り違えると、やりがちな誤判断がこれです。

・間違い：チェックを減らす／監査をやめる／レビューを省略する
・正しい：検出が増えた理由を分解し、重大度と再発を見て改善する

不具合件数が増えたのは、

失敗が増えた

ではなく

失敗が“見えるようになった”

かもしれない。

見える化をやめるのは、暗闇に戻るのと同じです。

---

5. 今日から使える：観測のワナチェック「3つだけ」

初心者でも迷わないよう、3つに絞ります。

チェック①：増えたのは「発生」？それとも「検出」？

不具合は、次の流れで数字になります。

発生 → 検出 → 報告 → 集計

チェックを増やすと、増えるのはたいてい「検出」「報告」「集計」です。
発生そのものが増えたとは限りません。

チェック②：重大度で分けると、どう見える？

件数だけだとブレます。
最低限、重大度で分けてください。

・致命的（止まる・危険）
・中（不便・手戻り）
・軽微（表示崩れなど）

チェック強化直後は軽微が増えやすい。
ここを見ないと、誤解します。

チェック③：再発率は下がっている？

本当に品質が悪化しているなら、再発率も上がりやすい。
逆に、再発率が下がっているなら、

数は増えたけど、改善は進んでいる

という可能性が高いです。

---

6. 実務の最小アクション：「件数」ではなく「質」で追う

じゃあ、どう運用すればいいか。最小手を3つ。

最小手①：「件数」より「率」にする

母数が変わると件数は簡単に増えます。

・1,000件あたりの不具合
・1万ユーザーあたりの不具合
・リリース1回あたりの不具合

のように“率”にすると解釈が安定します。

最小手②：KPIは「重大度×再発」に寄せる

おすすめはこの2つ。

・致命的不具合率
・再発率

ここが改善していれば、チェック増はむしろ良い兆候です。

最小手③：「どこで見つかったか」を追う

理想は、ユーザーが気づく前に見つけること。

・開発中に見つかった
・リリース前に見つかった
・リリース後にユーザーが見つけた

チェックを増やして、検出が前倒しになっているなら、成果です。

---

まとめ

・「チェックが増えるほど不具合が増える」という相関は出る（これは本当）
・でも「チェックが不具合を増やす」という因果は言えない（これは嘘かもしれない）
・正体は、検出効果（見える化）＋逆因果＋黒幕（大型変更など）の可能性
・追うべきは件数ではなく、重大度・再発率・検出タイミング

最後に一言。
増えたのは悪化じゃない。見える化が進んだ証拠かもしれない。

---

次回予告：第5回「残業が少ないチームほど成果が低い？」
“忙しい＝成果”に見えるワナを、相関と黒幕で解きます。