ソフトウェアメトリクスでもっとも大事なこと
ソフトウェア開発において何らかの定量データを収集して、状況を推測しようとしたり問題を解決しようとしたりすることは一般的になっていると思います。データ収集の対象はコードカバレッジかもしれないですし、工程毎の欠陥除去率かもしれないですし、スプリントのベロシティかもしれません。
現時点では、計測値か計測値による意思決定の基準の両方、またはどちらかが完全には客観的にはなっていないため、計測値や基準は、あくまで目安です。これだけ計測してモニタしてさえおけば十分ということはほとんどないでしょう。
計測と計測値による判断は、何らかの望ましくない状況や望ましい状況とメトリクスをひもづけて、計測値がこうなっていたら望ましくない状況が起き始めている、望ましい状況になっているということを事前合意しようとしていることだと解釈できるでしょう。実際にはお仕着せで合意なんてしていないという話はあると思いますが、根源をたどるとそのような事前合意があったのではないでしょうか。
合意が十分でなかったり、計測が想定している「望ましい状況」、「望ましくない状況」が伝えられないまま計測と判断だけが残ってしまっていることも少なくありません。計測値の正確性や再現性、判断基準に曖昧さが残るものであればソフトウェア開発に限定されないと思うのですが、計測結果の背景にある状況をそもそも意識できているかどうか、意識しているとして具体的に状況をイメージできたり、問題解決に向けた対策の姿勢があるかどうかが大切です。
特に、自身で計測しながら、基準外の場合にその理由を説明しなければならないときや結局自己解決しか方法がないときには、計測と説明のオーバヘッドばかりが目立ってしまい、必ずしも本質的な解決に至らない場合があります。
「基準値に達しなかったから（基準値の上限値、下限値の範囲を超えている）その理由を書く」というような手順が浸透していると、ついついその値と理由だけから状況を判断してしまいがちです。本来であれば、その背景にある状況や課題を推測して、解決を試みなければならないはずです。
どうやって計測するか、計測値の判断はどうするかということよりもその背景の状況や課題解決を試みることが大事な局面は多く、メトリクスを扱う上で最も大事なことの1つですが、気がつくと意識されていなかったりするのではないでしょうか。
ソフトウェアメトリクスの基本分類と本エントリの内容を日経SYSTEMS 2012年5月号に「メトリクスのきほん」という記事を寄稿しました（22～23ページ）。短い記事ですが、私が大事だと思っていることを要約できたように思います。お近くにあればご覧ください。目次はこちら。