ソフトウェアメトリクスのライフサイクル

ソフトウェアメトリクスにライフサイクルがあるように思う。メトリクス（このエントリでは管理指標と言いかえても差し支えない）によって意思決定する（判断する）者、メトリクスを報告する者の2者がいるとする。意思決定はメンバ全員でするかもしれないし、1つのメトリクスを全員で報告するかもしれない。いろいろな形態を思い浮かべていただきたい。メトリクスには古典的な不具合密度があったり、比較的新しめといえるテストコードのカバレッジがあるとする。

ライフサイクルは大きくわけると以下の3フェーズ。1が最も初期段階になる。

1. 収集当初は報告者もありのままを報告するし、判断する者も手探りの中、あくまで判断材料の1つとしてメトリクスを扱う。状況をきちんと見た上でメトリクスとの関連を考えたり、その背景を考えている健全な状態。
2. しばらくすると、判断する者が判断基準を値だけに頼りはじめる。
3. 最後はこなれたメトリクスとして定着する、もしくは、形骸化する。

最後のフェーズで形骸化した場合、開発上の問題を検出することもできない上、計測、報告コストと判断コストのムダになる場合が高い。具体的には、判断する者が「問題なし」と判断してくれるように値を操作して報告し、判断する者もそのことに気づかないまま（あるいは気づいていても変更せずに）になり、判断基準として適切でなくなる。

ここを読まれている皆様の組織やプロジェクトで「形骸化」しているメトリクスはあるだろうか？もしあるならば、いつ頃から収集されたり、盲目的な判断に使われるようになったのだろうか？