オルタナティブ・ブログ > 森崎修司の「どうやってはかるの?」 >

計測できそうでできない多くのこと。エンピリカル(実証的)アプローチで。

活用方法を見直しソフトウェアメトリクスを有効利用

»

ソフトウェアメトリクスは賛否両論の多いトピックであり、議論の中心は「それを計測して本質がわかるのか?」ということと「その値からどのような行動をとろうとしているのか?」にあると思います。

メトリクス自体の善し悪しではなく、「~の値が管理限界を越えたから実施エビデンスを全部揃えて提出するように」とか「~の値が低いということは本質を理解せずに活動しているということだ」というような、数値だけで乱暴な判断をしてしまうことへの抵抗やそのような苦い経験と重ね合わせて、その判断や行動を批判している場合も多くあります。

そのような判断や行動に合意がとれていれば問題はないのですが、当初は強制的ではなかったのに、いつのまにか強制されていたり、時代に合わないものになっているのに更新できていなかったりします。

メトリクスをうまく使えば、状況の確認や問題の兆候を把握することを簡単にしたり、合意を得たりするために使うことができます。テストにおいて不具合密度の上限、下限を設定して異常を発見しようとしていることがあると思います。これには賛否両論があると思うのですが、上限、下限を越えたり下回ったりすると、即、準備がたいへんであまり問題の解決につながらない場で責められることに問題があるのであって、自分達で詳細に事実を確認するためのきっかけに使っている場合には、問題になりにくいでしょう。

つまり、計測対象に問題があるのではなく、計測の結果をもとにどういう行動を起こすかに問題があるのです。最も望まれるのはどのように解釈しようとも現実を客観的に表わしていて問題発見につながるメトリクスを開発していくことですが、それができないときには、問題がないかを深掘りしてさがすための道具、合意を得る道具として使うことが、うまくメトリクスを使っていく秘訣です。

ソースコードの規模遷移のグラフをみながら、開発がどういう状況にあるかを規模遷移を通じて対話するという方法を実践したことがあります。ソースコード規模を時系列にそってグラフにしてみていくのですが、「こうなったらこうする」という対策を事前に決めずに「ここはなんで規模が小さくなってるの?」とか「ここはなぜソースコード規模が長期間かわってないの?」といった質問をきっかけに問題がないかを深掘りできたり、より詳細に状況を把握できたりします。

詳細はIPA SECで書籍化いただいていますのでご覧ください。実際のプロジェクトから収集したソースコード規模遷移のグラフ、プロジェクトの概観、プロジェクトメンバへのインタビューを収録した書籍はこちら。そのPDF版はこちら。ソースコード規模遷移のパターンだけを紹介した冊子もあります。

2012/10/25(木)15:30から札幌で、メトリクスをうまく活用する方法をセミナーで紹介します。セミナーでは、上述のソースコード規模遷移を含め、その他にもうまくいっている国内外の事例を紹介します。メトリクスの基礎を解説しながら、可能であれば、ご参加の方とともに活用方法を考えたり、ご参加の方の疑問に答えていきたいと思います。セミナーのタイトルは「ソフトウェアメトリクスの活用事例と国際研究動向」です。アブストラクト(概要)と申込みはこちらから。

Comment(2)

コメント

辰巳

開発プロセスを評価するための「ソフトウェアメトリクス(プロダクト、プロセス)」のお話しだと理解しました。プロダクトの品質そのものを測るメトリクス、例えばISO/IEC 9126やISO/IEC 25010で規格化されている品質モデルにおける(プロダクト)メトリクスは議論の対象外でしょうか?

辰巳様

コメントありがとうございます。
いえ、対象とするメトリクスに前提はおいておりませんので、もちろんISOをはじめとする規格も対象です。ここでは、そのメトリクスで合意できているかどうかという点とそのメトリクスからどのような判断、行動を起こすかというところをフォーカスしております。

ただ、ご指摘いただいたように、せっかく規格があるのに言及していなかった点は、本エントリで改善すべきところかと思います。ありがとうございます

コメントを投稿する