前回のその3プロジェクトの計画策定に続いて解説します。最後は、プロジェクトの監視と制御、そして、測定と分析です。まとめて進捗管理といっても問題ないと思いますが、CMMI では次のことができている必要があるといっています。
1. 計画に照らしてプロジェクトを監視する
(1) プロジェクト計画策定パラメータを監視する
(2) コミットメントを監視する
(3) プロジェクトリスクを監視する
(4) データ管理を監視する
(5) 利害関係者の関与を監視する
(6) 進捗レビューを実施する
(7) マイルストーンレビューを実施する
(2) コミットメントを監視する
(3) プロジェクトリスクを監視する
(4) データ管理を監視する
(5) 利害関係者の関与を監視する
(6) 進捗レビューを実施する
(7) マイルストーンレビューを実施する
2. 是正処置を終結まで管理する
(8) 課題を分析する
(9) 是正処置をとる
(10) 是正処置を管理する
(9) 是正処置をとる
(10) 是正処置を管理する
3. 「測定と分析」活動を整合せる
(11) 測定目標を確立する
(12) 尺度を明記する
(13) データの収集手順と格納手順を明記する
(14) 分析手順を明記する
(12) 尺度を明記する
(13) データの収集手順と格納手順を明記する
(14) 分析手順を明記する
4. 測定結果を提供する
(15) 測定データを集める
(16) 測定データを分析する
(17) データと結果を格納する
(18) 結果を伝達する
(16) 測定データを分析する
(17) データと結果を格納する
(18) 結果を伝達する
測定と分析はプロジェクトの監視と制御だけに限ったことではありませんが、進捗管理が効率的、効果的に実施できていないのは、測定と分析をもとにした進捗管理ができていないケースが多いものです。測定と分析をもっとも活用するのは進捗管理であるのは間違いないでしょう。上記の「計画に照らしてプロジェクトを監視する」の部分は、測定と分析ができていなくても実施することは可能ですが、その場合は、リーダー個人の力量でやっているだけだったり、目を通すだけでも大変な大量の開発基準やチェックリストで対応している状態だと思います。効率的、効果的な進捗管理の仕組みにするためには、測定と分析をベースにした進捗管理の仕組みに進化・深化させる必要があります。
ところで、進捗管理の代表的な方法のひとつは、作成したスケジュール表を使って、個々の作業が遅れているかどうかを確認することです。このための線表をガントチャートと呼んだりします。多くのスケジュール表（ガントチャート）は、横軸は時間軸になっており、縦軸は開発する内部構造、つまり、機能ユニット／モジュール／ブロックになっているはずです。そして、矢印は具体的な開発作業要素になっています。
このようなスケジュール表で進捗管理する場合、プロジェクト管理者の多くは製品機能の開発進捗がわからないという悩みを抱えることになります。先ほど解説したように、スケジュール表は製品内部構造や開発作業を記述しており、開発メンバーにとっては自分たちが何をやるのか、どの作業が遅れているのかがわかるようになっています。しかし、外から見て開発進捗や完成度を把握したい管理者や顧客にとっては、このスケジュールでどんなに詳細に進捗管理をしても、全体の機能のうちどのくらいできあがっているのか、個々の機能の完成度はどのくらいなのかなどを知ることは非常に困難です。
システム設計が適切に実施され、図33に示すような成果物相互の関連づけができていれば、技術的には、機能ユニット／モジュール／ブロックという製品内部構造を縦軸にして矢印により開発作業の進捗がわかるようになっているスケジュール表を、製品全体の内部構造で見たときにどこがどのくらいできているか、そして、外部仕様（要求仕様）で見たときにどの機能がどのくらいできているのかが把握できるようなフォーマットに変換することが可能になります。かなり骨の折れる仕組みを必要としますが、進捗管理の進化・深化のひとつの要素であるといえます。
&n...
bsp;
図33.スケジュールが作成される過程
次回は、測定と分析をベースにした進捗管理について解説します。