（C）標準化を重視
カスタマイズの容易さにも注目
開発における標準プロセスの徹底を重視して，製品を選択するケースもある。PM支援組織であるPMO（Project Management Office）の担当者がプロジェクト管理ツールを選定する場合が典型的だ。
この場合，標準プロセスに基づいて工程管理できるツールを選定する。具体的には，標準プロセスが「要件定義→設計→開発→単体テスト→総合テスト→受け入れテスト」という工程で構成されるときに，「要件定義のレビューが終わらないと設計に移れない」など，工程を制御する仕組みが不可欠だ。また，ウォータフォール，スパイラル，テスト・ファーストなど，利用する開発手法に対応したプロセスを設定できることも確認しておきたい。
標準プロセスの形骸化を避けたい
あるSIベンダーは，進捗管理や品質管理の標準手法を「PMフレームワーク」と呼ぶドキュメントに整理した。このフレームワークでは，PMに対して定量的な進捗管理，課題の状態管理，成果物（ドキュメントやソース）の検証，不具合の状態管理などを徹底するように求めている。文書だけでは形骸化しがちなPMフレームワークを徹底するため，進捗や品質を管理するシステムを構築することにした。
同社はプロジェクト管理ツールをベースに進捗・品質管理システムを開発しようと，五つの基準で製品を評価した。（1）社内の標準プロセスに適合可能，（2）適合させるための開発は最小限，（3）全員がWebブラウザで利用できる，（4）既存システムとの連携に利用するAPIが提供されている，（5）CMM（能力成熟度モデル）に適用できる---である。
カスタマイズの柔軟さで現場に定着
標準プロセスの徹底を重視した製品はいくつかあるが，プロジェクトの実情に合わせてカスタマイズしやすいかどうかは重要な選択ポイントである。
あるユーザー企業の情報システム子会社は，CMMに基づくプロセス改善活動を続けている。その過程で，標準プロセスに基づく工程管理に対応したプロジェクト管理ツールを導入することにした。55項目からなる比較表を作って調査・検討した。
同社は，全社標準プロセスを基にプロジェクト固有プロセスを作成するという機能を持つ製品を選んだ。実際には，この機能を次のように運用する。
あらかじめ最大規模のプロジェクトを想定し，標準プロセスをプロジェクト管理ツールに登録しておく。このとき，プロセスごとの成果物とレビューのひな型も登録する。そして，各プロジェクトのPMは，プロジェクト開始時に不要なプロセスを削除し，カスタマイズして利用する。現場の実情に合わせられるツールを選定したことと，教育に半年以上も費やしたことが功を奏し，「導入から約1年半で現場に定着した」（担当者）という。
大規模開発は“マトリックス管理”
一般的なプロジェクトでは，サブシステムごとに「要件定義→設計→開発→テスト」というプロセスを線形に管理すれば済む。だが大規模開発では，そのような単純な管理では破綻しかねないこともある。
あるSIベンダーは，複数のサブシステムで構成されたシステムを，特定業界の複数企業向けに並行開発するという，数千人月規模のプロジェクト管理を担当した。その際，標準プロセスに基づいた開発を徹底するためにプロジェクト管理ツールの導入を決意したものの，サブシステムごとにPLを配して管理する一般的な方法では心許なかったという。
そこで同社は図3のように，ユーザー企業ごとにもPLを配置し，プロジェクトのプロセスや進捗をマトリックス型で管理することを考えた。具体的には，サブシステムA担当のPLはユーザー企業を縦断する形で，ユーザー企業α社担当のPLはサブシステムを横断する形で，それぞれ管理する。
 |
| 図3●プロジェクトをマトリックス型で管理できるツールを選択 あるSIベンダーは，数千人月の大規模プロジェクトを管理する際に，標準プロセスに基づいて作業を推進するため，プロジェクト管理ツールを導入した。このとき，サブシステムとユーザー企業という二つの視点でマトリックス型の組織を編成し，それぞれの視点から状況を把握できるツールを探して採用した（画面写真は，米Artemis International Solutionsの「Artemis7」）。 |
同社はこうしたマトリックス型のプロジェクト管理に対応したツールを探し，選択した。これにより，工程の“見切り発車”を防ぐことができた。例えばα社担当のPLは，α社向けの全サブシステムに対する単体テストの網羅率がしきい値を超えないと総合テストに移れないなどの制御が可能になる。
