ソフトウェアメトリクスの共通認識を形成せよ

ソフトウェアの開発進捗状況や品質に関するさまざまな特性を定量的に把握するための計測基準であるソフトウェアメトリクスは、プロジェクトマネジメントにおいて不可欠なものである。限りある資源・工期などの条件下でできるだけ良いものをつくる、または開発現場と管理者、顧客の間で各々にフェアな共通認識を形成する、などといった目的のために利用される。

近年、ISO/IEC JTC1SC7/WG6により定まったメトリクス標準を核としてデータ測定・蓄積が進み、各企業ごとに行なっていたメトリクスデータ収集活動から、業界横断的なデータ共用やメトリクス標準化の動きが見られる。さらにはソフトウェアの国外輸出等における品質証明への活用の可能性が論じられている。

メトリクスデータ収集における最近の傾向

今日、ソフトウェア開発企業は既に各々なんらかのメトリクスデータを蓄積しているケースが多い。ソフトウェア工学においてメトリクスの概念自体は新しいものではなく、1970年ころから研究が進んだ。何をどう測るべきかとう研究から始まり、ソフトウェア開発におけるプロダクト・プロセス・リソースといった観点で様々なメトリクスが提案された。各企業は自社の開発プロジェクトにおいてメトリクスデータを収集し、今日では多くの企業が過去プロジェクトの蓄積データを活用し、新規プロジェクトの見積りや進捗管理を行なっている。

実際のソフトウェア開発におけるメトリクスデータを公開しているリポジトリも増えている。NASA
MDPや、Promisedata.orgにおける公開データはその例である。オープンソースソフトウェアのソースコードの発展過程や不具合の報告・対応状況など詳細な情報を得ることができる。日本においては、IPA/SECの「ソフトウェア開発データ白書」やJUASの「ソフトウェア・メトリックス調査」が協力企業から開発データを収集し、個々の開発プロジェクトに言及できる粒度ではないものの、集計データの統計情報などを公開している。

このような公開データを活かし、今日のメトリクス関連の研究では数理モデルやデータ解析技術の研究が多くを占めるようになっており、Fault-prone
module予測や工数見積もりといった研究が盛んである。企業においても、自社の蓄積データを用いて独自の数理モデルを組みプロジェクトマネジメントに活かしている事例は少なくない。

またメトリクスデータを扱うのは開発企業や研究者だけではない。特に受託開発において、メトリクスデータは発注者側にも重要な意味を持っている。発注した開発プロジェクトの投資額が妥当なものであるか、品質が十分なものであるか、生産性はどうかと言った観点で収集データを用いた分析が行われている。

業界標準化における危険

先に述べたようにメトリクスデータは、各開発企業の蓄積が進み、多くのステークホルダに利用されるようになっている。さらに、経済産業省における「ソフトウェアメトリクス高度化プロジェクト」にあるような業界標準化の動きも起きているが、それらにともなって様々な課題が表出している。

特に大きい問題が、いわゆる「業界標準値」のひとり歩きである。メトリクスを用いて収集することで、各企業が似た観点で集めたデータをとりまとめることができ、それらの統計情報を参考できるようになった。しかしこの統計情報は、様々な開発コンテキストが混在するデータの統計であるということを踏まえず誤用されることが少なくない。例えば、生産性の平均値が、あたかも”どの業種・どのような開発難易度にも関係なく”生産性の高低を判別する閾値として扱われ、発注者・受注者間の認識相違を招く一因となっている。

単位や測定基準の未統一も問題の一つである。各社が自社の開発プロジェクトにあわせたメトリクスを独自基準で収取しているため、同業種かつほぼ同じ開発環境であっても、比較を行うことがむずかしくなっている。このため、開発ベンダが自社の測定メトリクスの観測基準やその値の意味するところを、発注者に説明する際大変な労力が割かれることが多い。先に挙げた、経済産業省の「ソフトウェアメトリクス高度化プロジェクト」はこのような状況を打開するため、国際標準化もにらみつつメトリクスの統一を進めているが、基準を詳細に定めるすぎると企業を苦しめる側面もあることから、現場レベルでの収集基準には踏み込まずある程度抽象的な基準に留めているのが現状である。

また、業界標準化が、先進的な企業やチャレンジングなプロジェクトを締め付けすぎないかという議論もある。メトリクスの標準化により、品質評価のために行わなければならないプロセスが増大し、開発以外にかけなければならないコストが増大することが懸念される。メトリクスとして測定しやすい欠陥や障害がないという意味での品質を確保することと、新規性や革新性という意味の品質を獲得することは必ずしも一致しないからだ。

業界全体を巻き込んだ共通認識への期待

以上のような問題を解決しつつ、客観的指標としてメトリクスをうまく活用していくには業界全体で共通認識を深める必要がある。

ベンダ企業がメトリクスの説明責任を持つのはもちろんだが、ユーザ企業も単に数値結果を受けとるだけでなく、その測定背景について理解を深めねば先の生産性に関する認識相違などの問題が起こりうる。また開発現場と管理者の相互理解も必要である。現場での開発スタイルにあった測定方法を取らなければ、実体のないものを管理することになりかねない。開発にかかった工数をV字モデルの各工程に無理やりあわせて収集することなどはその最たる例である。フェアな共通認識が形成されてこそ、双方にとって健全なソフトウェア開発が行えるはずだ。

また、メトリクスの収集コストを抑えるため収集ツール等の整備も必要である。現在測定ツールとしてはEclipse Metrics pluginやCCCC、CCFinderXなどソースコードに対するものがほとんどであるが、EPMなど開発プロジェクトに対するものも出てきている。ツールとして取り込み様々な観点のメトリクスを自動収集できるようにして、なるだけコストを抑えた計測が可能とすることが望ましい。

メトリクスは必ずしも万能ではなく取扱いには注意すべきだが、ソフトウェア開発における正しい評価・フィードバックの一助となるはずだ。共通認識の形成や収集環境の整備等をすすめ、ソフトウェア業界全体に良いフィードバックループが形成されることを期待する。