「問題の順位」の術 - PART1

現象と原因究明

計算結果を画面に表示するプログラムの出力が、正しい値よりも1だけ大きくなってしまうというバグが見つかったとします（ばかばかしいほど単純な例ですが）。さて、これを解決するもっとも直接的な方法は何でしょうか？そう、出力直前に1だけ引けば良いですね。では、これで問題を解決したことになるでしょうか？そうとも言えるし、そうとも言えません。

問題には「現象」と「原因」があります。上の解決方法は現象を直接訂正しただけです。しかし本当の原因は修正した部分より手前の計算方法にあるはずです。ですから、そちらの原因の方を修正しないと、もし同じ計算ルーチンを別のところで使用したら同じような現象がまた起こってしまいます。しかもそのときは、すでに以前に「1だけ引く」という無邪気な(?)解決方法をとってしまっているので、今度も同じようにするしかありません。さもないと、前になおした部分が今度は「1だけ少ない値になる」という現象になってしまいます。

と、話はそんなに単純ではないかも知れません。いま「これが原因だ」と思っていたものが、実は他の原因による現象でもあるかも知れないからです。だとすると、原因を取り除いているつもりが実はその場しのぎの対処でしかないのかも知れません。ですからさらにその原因を見つけなければなりません。いや待てよ、これももしかしたら、他の何かに起因する現象に過ぎないのかも・・・。と、どこまで行ってもきりがない無限ループです。

きりがないので、実際にはどこかで妥協することになります。だって、そもそもエンジニアがプログラムを作ってしまったのが原因なんですから、あまり原因を追及しすぎても無意味なのです。いま「プログラムを作ってしまったのが原因だ」と言いましたが、これだって何かに起因する現象な訳です。あまり原因究明が過ぎると、究極的には「生まれてごめん」みたいなことになってしまうのです。

問題の因果関係

重要なのは、ある問題（原因）が別の問題（現象）を引き起こすということです。そして、引き起こされる現象は、そのもととなる問題よりもずいぶん多く、１対多の関係になることです。もちろん原因が「１」で現象が「多」です。

デバッグをしていると、細かい問題がぱらぱらと出てきて、いくつ片づけても次から次へ際限なく新しい問題が浮上するということがあります。そういうときはだいたい、それらに共通する原因的な問題があって、それさえつぶせば一気に楽になります。ですからたくさんの問題点が出てきたときは、どれとどれが関係あって、しかも原因になっている問題はどれなのかを見極めようとするのが近道です。

私の経験上、大きな問題が小さな問題の原因になっていることが多いようです。ここで言う大小は、「シリアス度」とでも言いましょうか、直すのが大変そうな度合いです。ですから、小さな問題から先に片づけてとにかく問題の数を減らそうとするのは良くないアプローチです。というか最悪です。大きな問題から手をつけるのがセオリーです。

順位決定のセオリー：
大きな問題をつぶせば、小さな問題も消え去る

しかしまたしても、話はそんなに単純ではないかも知れません・・・。