バグは、コードではなく「判断されなかった場所」に潜む
コードレビューをしていて、
こんな感覚を覚えたことはありませんか。
- 差分は小さい
- テストはすべて通っている
- 特に指摘すべき点も見当たらない
それなのに、
「このまま出して大丈夫か?」
という、言葉にしにくい違和感が残る。
バグが生まれる瞬間は、意外と静か
多くの人は、
バグ=実装ミス
だと考えます。
でも実際の現場では、
もっと静かな形で問題が入り込むことがある。
それは
誰も明確に判断しなかった前提が
そのまま通過したとき。
- 変わった部分は見た
- でも「変わっていない前提」は確認していない
- そもそも、誰がそこを見る役割なのか決まっていない
この状態は、
バグというより
判断の空白に近い。
QAで見落とされやすいのは「正しさ」ではない
テストは、
「壊れているかどうか」は教えてくれる。
静的解析も、
「おかしな書き方」は指摘してくれる。
でも、
- この変更で、前提は本当に変わっていないか
- 変えてはいけない暗黙の条件はないか
- そもそも誰がそれを確認するのか
こうした問いには、
ツールも人も答えづらい。
だから多くの場合、
「たぶん大丈夫」という感覚で
レビューが終わる。
AIを「実装者」ではなく「判断の補助線」として使う
最近、
私はAIの使い方を少し変えました。
コードを書かせるためではありません。
バグを自動検出させるためでもありません。
代わりにやっているのは、
こんな問いを投げることです。
- この差分で、何が変わったと言えるか
- 逆に、変わっていないと仮定している部分はどこか
- ここで誰も判断していない前提は何か
AIに答えを出させるのではなく、
判断が置き去りになっている場所を可視化する。
それだけで、
レビューの質はかなり変わる。
これは効率化の話ではない
AIを使うと早くなる。
QAが楽になる。
そういう話ではありません。
むしろ、
安心して判断できる状態を作る
という話です。
「直ったと言えるのか」
「本当に出していいのか」
その判断を、
根拠を持って引き受けられるかどうか。
もう少し詳しく書きました
この考え方と、
ChatGPT / codex を
QA・レビューの補助線として使う話を
別の記事にまとめています。
売り物ではありません。
手法の押し付けでもありません。
ただ、
同じ違和感を持ったことがある人なら、
何か引っかかる部分はあると思います。
▶ 記事はこちら
https://x.gd/3ul82
最後に
バグは、
派手なミスから生まれるとは限りません。
多くの場合、
誰も「判断」しなかった場所から、
静かに入り込む。
この視点が、
あなたの現場の見え方を
ほんの少し変えるなら。
それで十分だと思っています。