稼働後に発生する欠陥数は、総合テストで判明した欠陥数の約20％——ＪＵＡＳ「ソフトウェアメトリックス調査」から

プログラムの中に潜む、ミスや欠陥を「bug（バグ＝小さな虫）」と呼ぶのは周知の通りである。でも、なぜ単純にmistakeやfaultではなく、あえてbugと呼ぶのだろうか。自分の無知を恥じつつ、早速ネットで調べてみることにした。

諸説あるようだが、集積回路などがまだ発達していなかったその昔、機械に入り込んだ虫が電気系統に悪さをし、誤作動を引き起こす例が多々あったという。コンピュータがまだ真空管とリレーを使った巨大装置だったころ、1匹の蛾がマシン内に迷い込んでショートを起こし、計算ミスを誘発した事実も記録として残っているようだ。トラブルの元凶＝虫のしわざというあたりが、どうやら一般的なバグの語源の解釈のようである。

さて、そのバグと今日も我々は戦っている。何しろ、現代のバグは論理的な誤りが中心であり、実際の虫と違って目に見えにくい。一定規模以上のプログラムにおいてバグを根絶するのは非現実的であり、ある確率で潜んでいると考えるのが普通だ。

とはいえ、可能な限りバグを減らす努力は欠かせない。業務システムを開発する際には、プロジェクトの節目節目にプログラム精査のプロセスを設けることでバグの撲滅、すなわち機能品質の保証に努める。単体テスト→結合テスト→総合テスト（受け入れテスト）という流れで進めるのが一般的だ。

プログラミングミスなど初歩的な欠陥は初期段階の単体テストや結合テストで見つかることが多い。しかし、総合テストにもなると対象プログラムの規模や複雑度が増して、バグを発見・修正できる率が低下する傾向にある。このため、システムを納入して稼働を始めてからも、残念ながら再びバグが露呈してしまうことがよく起こる。

それは、どのぐらいの頻度なのだろうか。日本情報システム・ユーザー協会（JUAS）が「ソフトウェアメトリックス調査」などの各種調査から導き出した指標が1つの参考になる。これによると、「稼働後に発生する欠陥数は、総合テストで判明した欠陥数の約20％」だという。仮に、総合テストで100個のバグが見つかった場合、稼働後に20前後のバグがさらに発見されるという計算だ。

その後の修正でバグは漸減していくものの、いざ本稼働後にシステム障害を引き起こしてしまうと多大な混乱や損失を生むことにつながる。安易に妥協をせず、システムに求める品質と想定されるリスクに照らしながらテストの最終局面までに、徹底的にバグを減らすことがあくまで基本だ。「総合テストで発生した欠陥数と修正要員数を勘案し、1人1個以上の修正が必要ならば、もう1度総合テストを実施した方がよい」とJUASは推奨する。