　前回、「6．バグの発生が頭打ちになった」の説明では、「Gompertz Curve（ゴンペルツ曲線）」というS字曲線のパターンをテスト・フェイズでどのように解析して、ソフトウェア開発プロジェクトの現状の“健康診断”をしているのかについて述べました。今回は、同じくGompertz Curveをベースにして、具体的にどのような現象になれば「6．バグの発生が頭打ちになった」といえるのかについて解説します。

「バグの発生が頭打ちになった」の第1の意味

　以前、Gompertz Curveについて説明したとき、Gompertz Curve自体は非常に精密な曲線であると書きました。しかし、入力となる「バグの発生状況」や「テスト項目の消化状況」のデータは非常にいいかげんな要素が多く、1日に1人で30分しかテストしていなくても、20人が18時間も必死になってコンピュータに張り付いてテストしても、Gompertz Curve上は、同じ「1日」と見なされるので、厳密さを期待してはならないと解説しました。もちろん、正規化すればいいのですが、そのための多大な労力を考えると、誰もが二の足を踏んでしまいます。

　通常は、Gompertz Curveを正確に解析するのではなく、予想の曲線と現状の曲線がどのように乖離（かいり）しているのかをパターンとしてチェックし、プロジェクトの健康診断をする場合がほとんどです。通常、予想と現実は7つのパターンになり、このパターンを前回解説しました。

　今回は「バグの発生が頭打ちになった」の意味について考えてみます。常識的には、“頭打ち”ということは、「バグ発生のGompertz Curveが水平になった」ということですが、ここで図1-1と図1-2を見てください。図1-1は、バグ発生曲線がなだらかに水平に近づき、最終的にはフラットになっています。一方、図1-2では、急激に発生していたバグが、ある日突然、摘出されなくなり、発生曲線が一挙に水平になっています。

図1-1　バグ発生の収束（現実的なケース）

図1-2　バグ発生の収束（非現実的なケース）

　もし、自分のプロジェクトのバグ発生曲線が図1-1のパターンであれば、非常に良い傾向であり、開発中のソフトウェア品質は順調に上がっています。これが「バグの発生が頭打ちになった」ということの第1の意味です。とにかく第1義的な意味であり、表向き、表面的ではありますが（本質的な意味、さらに重要なことは後述します）、まずはこれを満足させないと、品質制御は進みません。

　一方、図1-2もバグ発生は“頭打ち”になっていますが、このパターンであれば、まだまだ品質は安定しておらず、深刻な問題が大量に隠れています。筆者は、過去三十年以上、国内外を問わずいろいろなバグ発生パターンを見てきました。合計は千を超えると思います。その中で、図1-2のパターンも数多くありましたが、このパターンのソフトウェアで高品質なものは1つもありませんでした。すなわち、この時点で、バグが収束しているように見えているだけにすぎません。

　猛烈な勢いで発生していたバグが、ある瞬間からゼロになることは絶対に、絶対に、絶対にありません。台風一過の10分後には透き通るような青空が広がることはあり得ますが、ソフトウェア開発ではそんな現象は絶対に、絶対に、絶対にあり得ません。

　もし、自分のプロジェクトで、図1-2のようなパターンになったとしたら、以下の原因が考えられます。

（1）単にテストを実行していない

　図1-2の原因のほとんどがこれです。当たり前ですが、テスト項目を実行しないと、バグは出ません。この場合、テスト項目を実施していないので、「テスト項目消化曲線」が水平になっているはずです。しっかり、テストを続行しましょう。

（2）テスト項目の品質がかなり低い

　テスト項目消化曲線が順調に下降しているのに、「発生バグ数」が水平になっている場合、テスト項目が簡単過ぎて、バグを摘出できていない可能性が大です。目前に大学受験を控えた高校3年生に、小学1年生用の四則演算問題を出しても、全問正解されてしまいます。テストの最終フェイズでは、ソフトウェアの品質もかなり上がっており、少々意地悪なテスト項目はウマくさばいてしまいます。図1-2のパターンになった場合、豊富なテスト経験を持った技術者に、テスト項目の内容をチェックしてもらうことが重要です。

（3）テスト項目が抜けている

　図1-2のパターンになるケースで、テスト項目に起因するものとして「テスト項目が抜けている」が挙げられます。ある機能に対するテストがスッポリ漏れている場合もありますし、過負荷テスト、性能限界テストなど、いわゆる、「キツいテスト」が実施されていない可能性も大きいといえます（いずれにせよ、この抜けは致命的です）。ベテランの技術者がテスト項目の過不足、妥当性をもう一度チェックする必要があります。

　どの原因にせよ、図1-2のパターンは品質制御上、非常に重大な問題を抱えており、早急、かつ、的確な対策が必要です。

「バグの発生が頭打ちになった」の本当の意味

　先ほど「バグの発生が徐々になだらかになり、最終的に水平になる」ことは、「バグの発生が頭打ちになった」ことの第1義的なものにすぎない、さらに、“重要なこと”があると書きました。この「さらに重要なこと」とは、類似バグの検出です。

　有名な3匹の猫の話として、「ダメ猫は、そこにいてもネズミが出てくる。普通の猫は、そこにいればネズミは出てこない。優秀な猫は、そこにいなくてもネズミは出ない」というのがあります。テスト項目を実行していてバグに突き当たり、このバグを修正する。これは、ソフトウェア技術者なら誰でも実行するごく当たり前のことであり、「普通の猫」です。では、「優秀な猫」はどうするのか？摘出したバグをじっくりチェックし、以下のように、技術的、心理的に分析して、類似バグ、同件不良をたたき出すのです。

（1）技術的な分析

　なぜ、勘違いしたかの技術的要因を探ります。ビットの意味を間違えていたり、データ・サイズを誤解していたりなど、いろいろな原因があります。ほかの場所で、それと同じ間違いをしていないか、チェックする必要があります。

（2）心理的な分析

　時間がなくて焦ってバグを作り込んだのか、時間がタップリあったのに間違えたのかですが、やっつけ仕事でバグを作ることはよくありますし、自然なことですが、熟慮のうえの間違いなら、事態は深刻です。何らかの抜本的な見直しが必要です。

　「優秀な猫」は、1件バグを摘出すると、7～12件の類似不良を見直すといわれています。この類似バグも含めて、バグの発生が水平になった場合、本当の意味で「バグの発生が頭打ちになった」といえるのです。

バグの重要度と「バグの発生が頭打ちになった」の関係

　バグ発生のGompertz Curveが水平になっても、簡単には喜べません。テスト項目を実施して、それが摘出したバグの発生件数が頭打ちになっただけでなく、類似バグ分析で見つけたバグも収束しなければ、本当の意味で、「バグの発生が頭打ちになった」とはいえないからです。

　「バグの発生が頭打ちになった」ことを分析するうえで、もう1つ重要なことがあります。それは、発生したバグの重要度です。テスト・フェイズの最終段階（アメリカ人技術者のいう「エンド・ゲーム」）に入り、バグの発生がなだらかになったとしても、見つかったバグが、データベース破壊、無応答、システム・クラッシュのような超重要バグばかりだと、まだまだ収束には程遠い状況です。

　バグの重要度を「重大」「通常」「軽微」の3つに分類しますと、「通常のバグ」の件数は「重大なバグ」の10～20倍、「軽微なバグ」は同様に「通常のバグ」の件数の10～20倍発生するといわれています。テストの終盤では、以下のチェックが必要です。

（1）バグ全体の重要度分析

　これまで摘出したすべてのバグの重要度をチェックし、重大、通常、軽微が常識的な配分になっているかを分析します。なっていなければ、それを説明できる理由があるかどうかをチェックする必要があります。

（2）最終フェイズのバグの重要度分析

　最終フェイズで出たバグの重要度をチェックし、極端に「重大バグ」が多くないかを分析します。重大バグが多いと、まだまだ重大バグが隠れている可能性は大きいでしょう。図1-2でも示しましたが、ある日突然、事態が急激に好転することは、ソフトウェアの品質に限っては、絶対に、絶対に、絶対にあり得ません。

　欧米に「自然は『真空』を嫌う（Nature abhors vacuum）」ということわざがありますが、ソフトウェア開発では「品質は『突然』を嫌う」が基本原則中の基本原則です。

　次回は、「7．未修正のバグが残っていない」を解説します。この条件も、ごく当たり前に見えますが、非常に面倒な要素が隠れています。（次回に続く）

【筆者紹介】

山浦恒央（やまうらつねお）
東海大学大学院組込み技術研究科助教授（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科助教授、現在に至る。

主な著書・訳書は、「Advances in Computers」（Academic Press社、共著）、「ピープルウエア第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。