有名な「ソフトウェア開発の定量化手法」（構造計画研究所発行）の第1版の序文で，著者のCaper Jonesは次のように述べている。

科学，工学の発展は物事を定量的に把握することから始まるが，ことソフトウェアに関しては例外である。ソフトウェアが産声をあげた20世紀半ばには，すでに経済学的，工学的な定量化基準が確立していたにもかかわらず，ソフトウェアは独自の世界に閉じ込もり，奇妙な歴史経過をたどってきた。生産性や品質，およびやそれらに影響を及ぼす要因をほとんど測定しないまま，すでに50年が過ぎ去ろうとしている。

　Caper Jonesが言う通り，日本でもソフトウエア開発の「定量化」（測定）はこれまでほとんど行われていなかった。だが，ようやく最近になって，「ソフトウエア・エンジニアリング（ソフトウエア工学）」の普及と歩調を合わせるように，ソフトウエア開発の定量化の重要性が認識されつつある。IPA（情報処理推進機構）内に2004年に設立されたソフトウェア・エンジニアリング・センター（SEC）でも，「定量データ分析部会」で，定量データの活用によるソフトウエア開発プロジェクトの客観的な把握・管理・改善を支援する活動を行っている。

　一口にソフトウエア開発の定量化と言っても，定量化する対象は様々だ。例えば，Caper Jonesは「ソフトウェア開発の定量化手法」の中で，「成功している大企業の観察結果をまとめると，定量化計画は次のようなパターンに従って発展するようである」として，次の9つのパターンを挙げている。

  1. 運用環境の測定
  2. 開発中のプロジェクトの測定
  3. ソフト資産とバックログの測定
  4. 顧客満足度の測定
  5. 完了プロジェクトの測定
  6. ソフト要因の測定
  7. ソフトの欠陥の測定
  8. 企業内従業員統計の測定
  9. 企業内の意識調査

　こうした様々な指標の測定には，一つの大きな障害がある。それは，プロジェクト・メンバーがプロジェクトに関する様々な指標を「入力する手間」が発生する，ということである。ソフトウエア開発プロジェクトはただでさえ忙しい。そんな中で，プロジェクトに関する各種の指標をプロジェクト期間中あるいはプロジェクト終了後に，メンバーに入力してもらうのは，なかなか大変だ。

　このため理想的には，様々な指標を「自動的に」計測できれば一番いい。実際に，こうしたコンセプトで開発されたツールもある。それが「EPM（Empirical Project Monitor）ツール」である。

　同ツールは，文科省の「e-Society基盤ソフトウェア総合開発計画」の1プロジェクトとして2003年4月にスタートした「EASE（Empirical Approach to Software Engineering）プロジェクト」で開発されたソフトで，既にβ版が公開されている。このβ版をベースに，現在SECが機能を拡張しているところだ。この4月と5月に，実際の開発プロジェクトでこのツールを利用する企業を募集。そのフィードバックを反映して，SECが2008年以降にオープンソースとして正式公開する予定である。

　EPMツールは，開発者に負担をかけないで自動的にプロジェクトのデータを収集して分析表示する。自動収集できるのは，構成管理データと電子メールに関するデータ，それにバグ・データの3種類。構成管理データを収集するためにバージョン管理ツール「CVS（Concurrent Version System）」または「Subversion」が，電子メールのデータを収集するためにメーリングリスト管理システム「Mailman」が，バグ・データを収集するためにバグ追跡システムの「Bugzilla-jp」，「影舞」または「GNATS」が必要になる。稼働OSはLinux。Apache，Tomcat，PosgreSQL，Rubyなども必要になるが，EPMツールを利用するために必要なソフトはすべてオープンソースなので，導入の敷居は低いと言える。

　バージョン管理ツール，メーリングリスト管理システム，バグ追跡システムからデータを収集して，累積／残留バグ件数，バグ滞留時間，ソースコード規模，更新時期とチェックアウト数，メール投票数などをグラフ表示するのが，EPMツールの主な機能である。いわば，“ソフトウエア開発プロジェクト用のBI（Business Intelligence）”だ。

　SECによれば，特にプロジェクト・マネジャーにとって，（1）開発グループごとの比較，（2）自己申告よりも正確な状況把握，（3）リスクや危機の早期発見，（4）見られることによるメンバーのモチベーションアップ，（5）メンバー間での共通認識の醸成－－といった効果が見込める。実際，「現場のリーダーよりも，マネジャー・クラスに受けがいい」（SEC）という。「状況が把握しにくいオフショア開発にぜひ適用したい」という声も多いという。

　現在は，実装・テスト・フェーズの定量化が対象だが，今後は，要求定義や設計フェーズも対象にしていく予定。例えば，ドキュメントの枚数やダイヤグラムの要素数などを計測する機能をEPMツールに取り込むことを検討しているという。

　EPMツール自体は，バージョン管理ツール，メーリングリスト管理システム，バグ追跡システムから構成管理データと電子メールのデータ，バグ・データを収集して分析表示する，という極めてシンプルなツールであり，特別にすごい機能があるわけではない。「バグ・データの分析なんてやってるよ」「電子メールの数を見て，何の役に立つんだ」といった声も聞こえてきそうだ。だが，プロジェクトの各種指標を人手を介さずに自動的に計測する，というアイデア自体は，非常に面白いし有意義だと思う。今後の機能拡張と普及具合を見守っていきたい。