メトリクスをはかったものの．．．というときに

ソフトウェアの開発規模が大きくなるにつれ、多くの組織では何らかのメトリクスを計測し異常の検出に使っている。もちろん、はかることによるオーバヘッドが無視できない、はからなくてもうまくいっているのであれば、そのまま進めたほうがよいだろうが、なかなかそうもいかないというのが実情ではないだろうか。

よく用いられるメトリクスとして、規模（ソースコード行数、ドキュメントページ数、Funtion Point）や品質（テスト密度、バグ密度、レビュー指摘密度、チェックリスト密度）がある。これらが一定の範囲におさまっていなければ、会議の議題にあげたり、再チェックしたり、というふうに使っているだろう。また、EVM（Earned Value Management）のような利用用途が明確なものであれば、利用方法に困ることはないだろう。

それ以外のメトリクスをどう使うかというところに悩んでいる組織も多い。たとえばソースコードメトリクス（サイクロマチック数、Fan-in Fan-out）はそういうものの1つであろう。ソースコードメトリクスは、ソースコードや設計の複雑度合いを表すメトリクスとして一定の効果が認められているものの、その結果がプロジェクト全体やシステム全体にどう影響するかがあまり明確ではない。そのため「集めたもののどうしましょう」という話になりやすい。

そのような問題を解決する手段の1つとして、GQM(Goal Question Metric)アプローチがある。GQMはトップダウンにメトリクス収集の目的とメトリクス値とを関連付ける方法の1つである。ビビっときて、いきなりトップダウンにGQMの関連を作れるといいのだが、必ずしも全てがそうとは限らない。かといって、はかるのをやめてしまうのも．．．という方に、特に目的を定めず、チームのコミュニケーション活性に使ってみてはどうかと思っている。ここで吉川さんが紹介されているIBMのMany eyesのオフライン/社内版のようなイメージである。メトリクス自身から何かを得られなくても共通の理解が生まれたり、改善につながることはよくある話である。

我々のプロジェクトや共同検討においても、EPMというツールを使って収集したコード行数の遷移も同様にして、GQMアプローチによるものと、特に目的を定めず行数遷移のこういう動きに対してはこういう傾向がある、というディスカッションの両方をしている。

一般には、目的のないデータ収集（トップダウンでないデータ収集）はあまりよくないとされていてそれはある程度正しいと思うのだが、品質（不具合密度）や規模（工数）を表すプロジェクトの特徴データを蓄積したものから得られた知見（ボトムアップな傾向）をもとに、見積りや計画を実施することもよくある話であり、必ずしもボトムアップな傾向分析が悪いというわけではないことを示す例ではないかと思う。

また、計測メトリクスにはライフサイクルがあり、計測しても以前ほどありがたくないメトリクスや計測すべきだけれどもできていないメトリクスを検討する等、見直しをする時期が必要だと思う。GQMアプローチは新規に計測メトリクスの目的を設定するのに役立つが、何年かに一度程度で計測目的や計測メトリクスを見直す目的にも有用な方法であると考えている。