■PMBOK ドリルダウン！_No.24
　　PM定量化の実践技術（８）

前回は、「目に見える効果的な進捗管理方法は何か」という問題について、進捗管理を次のように分類して考えてみました。
　 (1)プロセス進捗管理
　 (2)プロダクト進捗管理
そして、プロセス進捗管理が抱える問題と特徴について説明しました。
今日は、プロダクト進捗管理の問題と特徴について説明を行い、問題解決への改善点について話しを進めて行きたいと思います。

　　　開発実績・成果物の量をベースとしたプロセス進捗管理は、開発作業（開発者）に質的な変化がない場合には有効です。
　　　 　　しかし、開発者の経験年数、開発言語、開発方法などの変化が起こると、それまでに蓄積したデータを使った進捗管理ができなくなるという問題を抱えています。
　 そこで、プロセス進捗管理の抱える問題点を克服するために異なった視点から進捗管理を検討する上で、「プロダクト進捗管理」が有効であると考えられます。
　 プロダクト進捗管理では、任意の製品における要求分析からテストまでのすべての開発工程に対して、連続性・一貫性をもった進捗管理ができることを狙っています。
　 プロダクト進捗管理を進める上で、まず、「工程によって違う製品表現」をどう相互に関連付けるのか・・・という問題を解決する(Breatdh管理と呼ぶ)必要があります。
　 例えば、
・ 要求分析工程では、ユーザの要求を表現します
・ 基本設計工程では、実現する機能を表現します
・ 詳細設計工程では、計算機の特性に応じた機能の実現方法を表現します
　 などです。
　 次に、製品の表現方法は変わりませんが、その詳細化のレベルを把握・管理する(Depth管理と呼ぶ)必要があります。たとえば、ＤＦＤなどは、詳細化の過程が分かるようになっているのであまり問題にはなりませんが、文章形式で設計文書の詳細化を行う場合には、詳細化された下位レベルの記述と上位レベルの記述との間の関係付けを行い、どのような過程を通じて詳細化したのかを把握できるようにしておく必要があります。
　 よって、「プロダクト進捗管理」にも、以下のような欠点があります。
（１） 分割した機能が同一の作業量であるとは限りません。ｎ個の機能に分割しても、その中の１機能の作業を完了するために９割の工数を費やすこともあります。
（２） 機能項目で管理する場合は、完了したか未完了かの２値しかなく、１機能項目の中で進捗を把握することが困難です。
（３） 要求項目や機能項目をすべて上流から下流まで一貫してトレースし管理することは、実際には相当な労力を要します。これらは、機械的に収集できる項目ではありません。
このため、効果的に進捗を管理するには、前回説明の「プロセス進捗管理」と「プロダクト進捗管理」の両方を上手に組み合わせていく必要がありそうです。
その組み合わせた全設計作業の特徴を以下に示します。
（１） 上流工程のほうがα期が長く、下流工程に進むにつれてβ期が長くなります。よって、α期における進捗管理はBreadth管理で行います。そしてβ期における進捗管理は、プロセス進捗管理とDepth管理を併用して行います。
（２） 基本設計工程と詳細設計工程では、α期とβ期の比率が変わります。基本設計工程ではα期が長いため、Breadth管理が重要です。詳細設計工程ではβ期が長いため、プロセス進捗管理とDepth管理を併用した進捗管理が重要です。
以上を具体的に管理項目で例示してみます。

管理方法 工程	プロダクト進捗管理		プロセス進捗管理
	Breadth管理	Depth管理
要求分析	−	詳細化が完了した要求項目数	要求仕様書枚数
基本設計	必要機能項目の洗い出しが完了した要求項目数	詳細化が完了した機能項目数	機能仕様書枚数
詳細設計	必要モジュールの洗い出しが完了した機能項目数	詳細化が完了したモジュール数	詳細設計書枚数
プログラミング	−	コーディングコンパイル・レビューが完了したモジュール数	ソースステップ数

以上が、２回に渡って説明したプロダクト進捗管理とプロセス進捗管理の改善です。
次回は、もっと「軽い」管理者にとって負荷のかからない実のあるＷＢＳを用いた進捗管理について話を進めてみたいと思います。
お疲れ様でした。

参考資料：２１世紀へのソフトウェア品質保証技術、日科技連