　ここまでが野中氏の品質管理に対する根本的な考え方だ。続いて、バグからいかに学んで、それをソフトウェア品質管理（プロジェクト管理、レビュー、プロセス改善などの活動）に役立てるのかの紹介がなされた。なお、本稿では、プロジェクト管理、レビュー、プロセス改善といった各活動の詳細ではなく、これら活動を行う上での大前提となる、「バグ」の数え方・分類についてフォーカスし、その考え方を紹介したい。

　講演の中で、野中氏は、日本・米国・欧州・インドの各地域で実際に行われた開発プロジェクト、各地域20～30件程度を対象にした市場流出欠陥のベンチマークデータ（2003年）を示した。

市場流出欠陥のベンチマークデータ

　このデータでは、新規ソースコード行数（中央値）が200～500KLOC規模のプロジェクトにおける出荷後のバグ密度（中央値）が示されている。それぞれの出荷後のバグ密度を見てみると、日本が0.02と最も優秀で、5万行に1件程度のバグが発見されることを示している。続くインド／欧州はその10倍、米国は20倍と、品質が悪いことがこのデータから読み取れる。

　「しかし、こういう数値は本当に信頼できるメトリックスなのか？」と、野中氏はいう。

　「例えば、このデータにある米国の数値には、世界中で使用されているような大規模なソフトウェアのプロジェクトが含まれている。その上での『0.4』である。これをどう捉えるか。また、バグ密度をとらえて自分たちのプロジェクトの品質状況を把握することも大切だが、そもそもこのメトリックスにおける“バグ1件”はどのように数えたものなのか」（野中氏）。

　続いて、野中氏は自身が副委員長を務める日本科学技術連盟 SQiPソフトウェア品質委員会での活動、「SQiPソフトウェア品質保証部長の会」で行われた“バグの測定・測定精度”に関する調査結果を示した。

欠陥の測定と、測定精度確認の実態

　この結果から読み取れるのは、「バグを測定することへの意識は高まっているが、その粒度の定義や測定精度、例えば、『自分たちの組織ではこういうルールで測ろう』という定義を品質部門（組織）として作り、管理しているところはまだ少ないということだ」（野中氏）という。

　では、バグの粒度、つまりバグの数え方をきちんと組織として定義していないとどうなるのか。

　例えば、バグ粒度の判断を技術部門に任せているような組織において、品質管理部門から「上流工程から下流工程への移行判定は“上流工程でのバグ除去率75％”でなくてはならない。従って、少なくとも残り2件のバグを除去しなければ下流工程には行かせられない！」と、突き返されたらどうだろうか。

上流工程での欠陥除去率に関する期待外れな行動

　「場合によっては、“期待外れな行動”を取られてしまう可能性がある。この例ではバグ粒度の判断をしているのは技術部門である。そこで、技術部門は開発・出荷を急ぐあまり『実はこの修正済みのバグは1件ではなく3件分で、実際ソースコードを3カ所修正したんだよ。だから75％は達成しているはず』と、除去済み件数を水増しして申告することもできてしまう」（野中氏）。

　実際にこういうことが行われているとは信じたくないが、可能性としてゼロとはいい切れない。組織全体として“バグ粒度のガイドライン”をきちんと定め、運用すること。この重要性がこの例からも分かる。この整備を怠ると、“期待外れの行動”を組織内で生み出しかねないということだ。

　では、ここで問題だ。以下Q1～3のケースで、あなたはバグを何件だと数えるだろうか？