その内容を少しだけ書こうと思います。
「計測できないものは制御できない」とは、著名なソフトウェア工学者トム・デマルコさんの言葉です。
メトリクスとは指標を意味し、ソフトウェアメトリクスとは「ソフトウェア開発プロセス全般に亘って、定性的な情報を数値化して計測管理すること」を指します。
品質管理はプロセス管理であるという原則に従って、QAプロセスもある程度数値化して管理
するとこが重要だと考えます。たとえば何か問題が発生したとき、数値化して管理していないと上層部に対する報告も主観的であいまいなものになり、本来のQAの目的である「リスク管理」が正しく実施できなくなってしまいます。またメトリクスをほかの部署に対するマーケティングに利用したり、上層部対する予算確保の根拠などにも利用できます。
このメトリクスを決めるにあたって、注意するべきポイントがあります。
- メトリクスの評価対象はあくまでプロセスそのものであり、個人の業務評価に使用してはならない
- 収集の目的を明確にしなければならない
- メトリクス用データ収集作業が、実務を阻害してはならない
まず１番に関して補足すると、特にマネジメント層にある人は部下の業務評価の材料としてメトリクスを利用しようと考える傾向があるのではないかと思います。しかしこれは大きな間違いで、そんなことをしたら、部下は積極的にメトリクス導入に賛成せず、また正直にデータを集計したりもしないでしょう。メトリスクの収集はあくまでプロセスの管理・向上を目標としていることを明確にすることが大切です。
２番はあえて言及するほどことではないかもしれませんが、メトリクスの収集にあたってはその指標をどんな目的で使うのかを共通認識として持つことが大事です。データの意味や目的がはっきりしていないと、それを有効に使うことはできません。
３番も非常に重要で、メトリクス収集は通常業務の妨げにならないように、その仕組みを体系化し、簡単に繰り返し実行できるようにすることが求められます。つまり最初から欲張って完璧なデータを収集しようとせずに、簡単に実践できて結果が見えやすい指標から試すことが大事です。
ここまでが、ソフトウェアテストメトリクス導入のおおまかな指針です。実際にどのような値を収集するかは、その会社のビジネスモデル、開発プロセス、品質管理方針などによって千差万別だと思います。一般的な指標としては、DRE（欠陥除去率）やTCE（バグの総数に占めるテストケース貢献率）などがあります。
それぞれの指標をどのように収集・活用していくかに関しては、また後日書きたいと思います。
60
