こちらは先の稿 プログラムは圧縮だ の実務面への分岐です。

悪魔の証明

悪魔の証明という言葉を知っていますか？
何かが「ある」ことを証明するのには、実物を持ってくればいい。 では「ない」ことを証明するにはどうしたらよいでしょうか？

すべての網羅して初めて「ない」ということが言えるのです。 「ある」ことを証明するのに比べ、「ない」ことを証明するのは非常に難しい。 例えば、「ネッシー」が存在しないことを証明しようとしたらどうすればよいでしょうか？ 「写真は捏造だったし、これまで信憑性のある物証はみつかっていないんだから」 ということでは証明できません。「まだ」見つかっていないだけじゃないの？という指摘に 反論する術がないのです。

それこそネス湖を干上がらせて全てを網羅して調査して見るぐらいのことをしないと 「ない」ことの証明をすることができないのです。

さて、プログラムの話に戻ります。intの引数を2個とる場合、その組み合わせは1600京ほどに なるということを先の稿で述べました。 そして、バグが「ある」ことを証明する場合、バグの例をひとつ探し出せばよいのに対し、 バグが「ない」ことを証明するにはこの1600京のパターンすべてを網羅して検査し、 全て正常に動いたということを提示しなければなりません。

そう、たったintをふたつ引数にとるだけで、バグのないことを完全に証明することが とてつもなく大変であるということがわかると思います。 1600京という数は、コンピュータで結果を比較するにしても結構な時間を必要とします。 そもそも、結果を比較するプログラムは信用できるの？比較対象となるプログラムにはバグはないの？ そう言い出すと、たったこれだけのプログラムに バグがないことさえ現実的な工数では証明ができないのです！

「システムにバグがひとつも存在しないようにテストをしてくれ」 そうお客さんに言われたら、 テストの工数見積に無量大数人月を記載しても足りないことでしょう。

このような事情から、現実的な手間で、できる限りバグをなくすという方向でIT業界は工夫してきました。 未知のバグについては、いままでの検出数からの推測値を用い、概算をだすような工夫をしたりします。 しかし、これらは0に向かって徐々に近づくことはあっても、決して0にはなりません。 0に近づくに連れ、品質向上にかかる工数は逆数となって爆発的に増えるのです。

また、バグを検出したからといって全てを完全に取り除くまで修正がされるかというと そうとも限りません。 費用対効果といいますか、そのバグが深刻であればともかく、影響が軽微でかつ修正コストが 高いのであれば修正を見送ることもあります。 オープンソースのプロダクトなどでは、bugzillaなどのトラッキングシステムでバグを管理しています。 リリースがあるたびにこの一覧がクリアになる(その時点で検出されているバグが全て修正される)わけではありません。

もし、検知したバグを全て修正しないと出荷してはいけないという法律を作ったとしたら、 ドッグイヤーとも言われるIT業界の時計は勢いを失い、何十年も同一プロダクトをのんびりと使う そんな日々が訪れることでしょう。