システム開発プロジェクトの開発プロセスを改善したり，品質を向上させたり，トラブルを未然に防ぐために有効なのが，バグやプログラム規模，進ちょくなどプロジェクトに関する様々なデータを収集して分析する，「プロジェクトの見える化」であることに異論はないはずだ。ただし通常，プロジェクトのデータを収集するためには，現場のエンジニアがデータを入力しなければならず，開発現場に負荷がかかる。このため，「必要なことは分かるがなかなかできない」というのが実態だろう。
この「開発現場でデータを入力する手間」を省くために，「プロジェクトのデータを自動的に収集する」というコンセプトで開発されたのが，プロジェクトの「見える化」ツールである「EPM（Empirical Project Monitor）ツール」（関連記事）だ。構成管理ソフトの「CVS（Concurrent Version System）」や「Subversion」，メーリングリスト管理システムの「Mailman」，バグ管理システムの「GNATS」，「Bugzilla-jp」，「影舞」から，構成管理の情報と電子メールに関する情報，バグの情報を，人手を介さずに自動的に収集して分析表示できる。もともとEASE （Empirical Approach to Software Engineering）プロジェクトで開発されたソフトだが，現在はSEC（ソフトウェア・エンジニアリング・センター）が機能を拡張している（関連サイト）。
このEPMツールを，大手ベンダーとしては初めて全社展開している会社がある。NTTソフトウェアだ。
もともとデータ収集・分析の文化があった
同社は，NTT研究所のソフト開発を担当してきた組織を核として設立された会社であり，伊土誠一社長によれば，「NTT研究所ではデータをとって分析することがあたりまえだった。NTTソフトウェアでもこの文化が残っている」という。このため，EPMツールを利用した全社的なデータ収集・分析に関しても，「会社としてはごく自然な流れ」だったそうだ。データ収集・分析の仕組み作りは，2003年に社内に設置した「生産性革新センター」が担当している（図）。
 |
| 図●NTTソフトウェアが構築したプロジェクトの「見える化」の仕組み [画像のクリックで拡大表示] |
まず2006年2月に，それまでプロジェクトごとに管理していたソースコードや問題処理票（バグ票）を，「@depotサーバー」と呼ぶ全社サーバーで一元管理するようにした。同社では，構成管理ソフトとしてCVSとSubversion，バグ管理システムとして「影舞」を全社的な標準ツールとして推奨している。各プロジェクトの開発担当者が，これらのツールを利用してWeb経由でソースコードや問題処理票を@depotサーバーに格納する。
EPMツールを導入したのは2007年4月。全社共通サーバー上で稼働し，規模情報やバグ情報を，@depotサーバーから自動的に収集する。各プロジェクトの開発担当者がソースコードや問題処理票を@depotサーバーに入れさえすれば，後はEPMツールが規模情報やバグ情報を自動的に収集してくれる（EPMツールにはメールの情報を収集する機能もあるが使っていない）。
ただし，導入当時のEPMツールは同社が全社展開するには，機能が足りなかった。そこで同社は，以下のような機能拡張を施した。いずれも「EPMツールを本当に使いこなそうとすると必要な機能ばかり」（伊土社長）。機能追加したEPMツールを同社では「EPM++」と呼んでいる。
（1）バグ密度やテスト密度を算出するためには正確なプログラム規模が必要なため，NCLOC（Non Comment List of Code）や物理SLOC（Source Line of Code），論理SLOCを計測できるようにした。
（2）機能追加・改造プロジェクトでは母体と改造部分に分けて分析する必要があるため，プログラム改造量の計測機能を追加し，テスト密度を改造部分と母体部分に分けて管理できるようにした。
（3）適度な粒度に分割して管理単位を設定できるようにし，モジュールなどの管理単位でデータを収集できるようにした。
（4）各プロジェクトが，GUIでEPMツールの設定を行えるようにした。
（5）プロジェクトによっては，他のプロジェクトから見られてはまずいデータがあるため，プロジェクトごとのアクセス制御機能を追加。
（6）問題管理票の項目を整理するとともに，問題管理表の項目やバグ・カウントの基準を設定できるようにした。
（7）既存の分析ツールとのインタフェースがなかったため，CSVファイルのエクスポート機能を追加。
（8）導入当時のバージョンは影舞，Subversionに対応していなかったので，影舞とSubversionからデータを収集できるように改良した。
品質のばらつきをなくせる
同社は，EPM++の導入と同時に，プロジェクトの情報を一元管理する「@PJPサーバー」と呼ぶ全社共通サーバーも設置した。@PJPサーバーは，EPM++が収集した規模情報やバグ情報をプロジェクトごとに管理するほか，プロジェクトの進捗管理機能も提供する。プロジェクトごとのEPM++の設定もこのサーバーで行う。
@PJPサーバーで管理するプロジェクトの情報（EPM++で収集した規模／バグ情報と進捗情報）の分析・表示には2つのツールを利用している。1つは，バグ密度やテスト密度などの品質指標をグラフ表示する「@PJP品質分析・可視化ツール」。このツールは，主にプロジェクト・マネジャーやプロジェクト・リーダーが自分のプロジェクトを分析するために利用している。
もう一つは，社内の全プロジェクトの生産性や品質などをグラフ表示できる「MAST」と呼ぶツールである。こちらは，主にプロジェクト・リーダーが見積もりの参考値として利用しているほか，生産性革新センターが「開発データ白書」を作成するために利用している。開発白書データはWebで社内に公開しており，経営トップはこれを見てプロジェクトの状況を把握できるようになっている。
同社では，すべての新規プロジェクトに関して，上で述べたデータ収集・分析の仕組みを適用している。伊土社長は「効果が出るのはこれからだと思う」としたうえで，「バグ情報などをPMO（プロジェクト・マネジメント・オフィス）などプロジェクトの外の人が見ることでトラブルの早期発見につながるほか，品質のばらつきがなくなり，プロジェクトの底上げにもつながる」と期待する。「EPMツールは，プロジェクトごとに局所的に導入しても効果は出ない。やはり全社的に取り組み，プロジェクトの底上げや品質の均一化につながってはじめて意味がある」と伊土社長は締めくくった。
