■PMBOK ドリルダウン！_No.40
　　PM定量化の実践技術 (20)

　今日は、「欠陥重度レベル」について説明します。
皆さんは、お客さんから、「軽微な障害はある程度許されるが、重大な障害はゼロで納品してほしい」と言われたことはありませんか？　その重度のレベル、欠陥の割合をどう見るか世間の見方を学んでみましょう。
　 ＰＭＢＯＫでは、品質マネジンメントに該当します。

　ほとんどのソフトウェアの欠陥追跡システムは、欠陥をいくつかの「重度レベル」に分けています。皆さんの企業でもそうでしょう。通常は３ないしは５段階が用いられており、ＩＢＭは以下の通り４段階の重度を用いています。
　 重度１：全体アプリケーションの利用が不可能になるような欠陥
　 重度２：主要な機能に関する欠陥
　 重度３：軽微な欠陥
　 重度４：処理に対して影響を与えたい。たとえば表示ミスのような欠陥

　レベルによって対応が異なることから、重度レベルで分類した欠陥の分布は実際のレベルとは異なってきます。たとえば多くの企業は重度１の欠陥は可及的速やかに、時には数時間で修復が要求されます。重度２の欠陥も迅速に修復されるが、重度３、４のレベルの修復は通常はまとめられて時には何ケ月もの後、正規のアプリケーションの次回リリースに実現されます。
　 通常ユーザはこれらの欠陥修復に対する対応の早さに差があることを知っているので、誤りを発見するとそれを早く修復してもらうために重度２の欠陥とみなしていることにしているケースが多いのではないでしょうか。
以下に示すのは、米国においてリリース後発見された欠陥を重度レベルごとにアプリケーション規模との関連でまとめたものです。

出所：「ソフトウェア開発の定量化手法」、Capers Jones著

上の表で見られるように重度１と２の欠陥は、全体の引渡し時の潜在欠陥量においては小さい比率ですが、この部分に大きなコストが集中します。

　 ある種の市販ソフトウェア製品は通常、重度２レベルの大量の欠陥を抱えています。このことは、重度の高い欠陥については重度の低いものよりも早く修復を行なうために、ベンダが意図的に重度レベルをあげて報告されるところからきていると思われます。

　 重度１の欠陥レベルを偽ることは難しい。しかし重度２はかなりあいまいであって、その修復までの時間を短くするために多くの欠陥が顧客報告で意図的に重度２と指定されると考えられます。

　 重度３の欠陥が重度４より多いのは不思議な気がしますが、それは重度４の欠陥が非常に軽微であるために多くが報告されてないことから来ています。また重度４の欠陥の多くは、報告はされても修復はされていないのでしょう。

　 皆さんの組織の年間障害件数比率を上の表の比率と見比べてください。かなり近い割合になっているのではないでしょうか？

本日はここまでにします。次回も更にPM定量化の実践技術をご紹介します。ご期待ください。お疲れ様でした。

参考資料：「ソフトウェア品質のガイドライン、共立出版」