昔からプロジェクト・マネジメントの世界では，「プロジェクト・マネジャの経験に依存した“属人的”なやり方だけに頼っていてはダメだ。もっと定量的なアプローチを取り込んで，“エンジニアリング”にしていく必要がある」と言われてきた。

　実際，大抵のプロジェクトでは，工数，コスト，要件数（機能量）またはプログラム数（行数），進捗率…，くらいは定量的に管理しているだろう。これ以外にも，過去に実施したプロジェクトの完了報告書を蓄積し，システムの内容と開発規模・コストなどとの相関を分析して，見積もり手法を洗練させていくといった定量的アプローチがある。

　しかし，プロジェクト・マネジメントにおける定量化への取り組みは，まだ限られたところでしか実践されていないようだ――。私は，『ITプロジェクトの「見える化」上流工程編』（情報処理推進機構 ソフトウェア・エンジニアリング・センター著作・監修，5月1日発行）という書籍の編集をつい先日終え，このように感じた。

　この本は，プロジェクトの上流工程に潜むリスクを“見える化”するための解説書だ。優秀なプロジェクト・マネジャ（PM）が持つノウハウを基にした「定性的アプローチ」と，ソフトウエア・エンジニアリングを基にした「定量的アプローチ」を組み合わせた手法を紹介している。

　定量的アプローチに関しては，78の管理指標を解説している。もちろん，すべての指標を計測する必要はなく，プロジェクトに必要なものだけを選べばいいのだが，とにかく78個というバリエーションの多さに，「そんなことも測れるのか」と思った。

　ここでは，その定量的な指標や見方をいくつか紹介しよう。

　システムの要件数（発生数，確定数，未確定数）の推移は，プロジェクトのコスト，納期に大きく影響するため，トラッキングしているプロジェクトは多いだろう。だが，視点を広げ，その数字の時間的推移に注目すれば，要件定義の品質にかかわるリスクを見つけ出すことにも利用できるという。

　例えば，要件定義工程の後半で，要件の確定数が急増していることを見付けたとしよう。この場合，「要員を追加投入して，短期間で無理やり決めてしまったのかもしれない」というリスクがある。本当にそうかどうかは現場にヒアリングして総合的に判断する必要があるが，事実だったとしたら，後工程で大変なことになる可能性がある。早急に対策を検討しなければならない。

　もう一つの例は，要件定義の品質を見える化するために，要件定義のレビュー回数やレビュー時間（累計）をトラッキングすることである。これらを，プロジェクト計画時に見積もったレビュー回数，累計時間の「計画値」と比べることで，様々なリスクを見つけられる可能性がある。仮に，レビューの回数，累計時間が計画値を上回っていれば，「要件定義書の品質が元々悪い」「レビューの進め方が非効率」などの問題が潜んでいるかもしれない。逆に，計画値を下回っていれば，「要件定義作業が遅れていてレビューを始められないのでは？」「重要な要件を見落としているからレビューが少ないのでは？」といった疑いがある。いずれの場合にも，早期発見できれば手の打ちようがあるが，発見が遅れるとプロジェクトへの悪影響はどんどん大きくなる。

　作業時間を詳細なレベルで管理しているプロジェクトなら，要件定義のレビュー回数や累計時間を計算することはできるだろう。だが，それだけでは，上記のような重大なリスクに気付くとは限らない。これらの例で肝心なところは，ある程度精度の高い「計画値」を見積もり，それに基づいて予実績管理をする，という定量化手法を採っているかどうかにある。

　上記2つの例以外にも，プロジェクトの現状を“定量的に見る”方法は，性能設計の進捗度やプロジェクト体制の強さを測るなど，多様な場面に応用できる。プロジェクト・マネジメントで次の一手を考えているPMなら，こうしたソフトウエア・エンジニアリングを研究してみてはどうだろうか。