プロジェクトが,「品質」,「スケジュール」,「コスト」,「リスク」の観点から計画通り 順調に進行しているかどうか。この状況を継続的に把握するのが「トラッキング」だ。計画から外れていれば,対策を立てて計画に沿うよう「コントロール」しなければ ならない。いずれも,プロジェクトの遂行上きわめて重要な作業だ。

布川 薫/日本IBM

 これまで5回にわたって,情報システム開発における「プロジェクト計画」について解説してきた。今回からは,プロジェクトの遂行段階における「トラッキング」と「コントロール」の詳しい説明に進みたい。

 トラッキングとは,プロジェクトの状況を的確かつ継続的に把握する作業のことだ。一方のコントロールは,プロジェクトの状況(実績)が本来あるべき姿としての「計画」から外れたときに,その原因を解明して適切な対策を講じるプロセスのことである。

 的確にプロジェクトのトラッキングとコントロールを行うためには,当然ながら“しっかりした計画”が存在しなければならない。「適切かつ数値化された計画の存在」は,プロジェクトのトラッキングとコントロールを実施するための必須条件である。つまり,前回までに説明した品質,完了基準,見積もり,コスト計画,リスク評価,マスター・スケジュール,WBS(Work Breakdown Structure),進ちょく計画,組織と要員計画などのプロジェクト計画を適切に立案しておかなければならない。

 加えて,トラッキングを行うための仕組みの確立も必要になる。例えば,トラッキングを適切に実施・報告するための組織体制や会議体制(図1),品質管理や問題管理,変更管理の仕組みを,構築しておかなければならない。

図1●プロジェクトにおける会議の進め方の例(DFDで記述)
図1●プロジェクトにおける会議の進め方の例(DFDで記述)

 ユーザー企業などのスポンサーから多大なリソースの運用を任されているプロジェクト・マネジャーが,プロジェクトに対して的確なトラッキングを行い,その結果をユーザー企業に報告することは“義務”である。また,トラッキングの過程で計画からのかい離を発見したときには,これをうまくコントロールして問題の発生を未然に防止しなければならない。プロジェクトの遂行過程では,トラッキングとコントロールこそが,プロジェクト・マネジャーにとって最も重要な仕事となる。

対象は4種類ある

 トラッキングとコントロールは,その対象によって4つに分類できる。

 第1は,プロジェクトの成果物が指定された条件や仕様,基準に従って作成されているかどうかを把握し,問題があれば解決策を施す「品質」だ。第2は,プロジェクト全体あるいはフェーズごと,タスクごとにプロジェクトが予定通り進んでいるかどうかを把握し,遅れていればスケジュール面での適切な対策を講じる「進ちょく」。第3は,管理費目別にコストの実績値を把握し,計画値を超えないようにコントロールする「コスト」。そして第4は,リスク度合いの変化を監視し,リスクを低減するための対策を実施する「リスク」である。

 今回は,品質に関するトラッキングの概要を述べるとともに,問題を発見してから解決するまでの「問題管理」プロセス,開発過程で生じる様々な仕様変更を管理する「変更管理」プロセスについて,日本IBMの方法をベースに解説していこう。

QA活動で品質を把握する

図2●ウォーターフォール型における日本IBMの標準的な欠陥除去工程
図2●ウォーターフォール型における日本IBMの標準的な欠陥除去工程をもとに一部改訂

 品質のトラッキングは,プロジェクトマネジメントにおける「品質保証」(QA:Quality Assurance)プロセスを通じて行う。QAとは,プロジェクトの成果物が定められた品質基準を満足しているかどうかを把握するプロセスのことだ。

 図2に,ウォーターフォール型の開発プロセスを採用した場合の,日本IBMの標準的な欠陥除去工程を示した。要件定義や設計といった早い段階で,ウォークスルー(Walkthrough)やインスペクション(Inspection),デザイン・レビュー(Design Review),公式レビュー(Formal Review)などの品質管理手段を,頻繁に組み込んでいる。品質保証プロセスの典型例と言えるもので,何かユニークなことを行っているわけではなく,本来行うべきことを着実に実行していることがお分かりいただけよう。

 ウォークスルーやインスペクション,デザイン・レビューは,プロジェクトのメンバーが主体的に実施する。具体的には,システム構造やデータベース仕様,ユーザー・インタフェース仕様,他システムとのインタフェース仕様,ネットワークやセキュリティの仕様,各種の作業手順書,運用マニュアル,操作マニュアルなどを点検・レビューする。また,公式レビューはプロジェクト外部の第三者(IBMでは品質保証担当者)が客観的な立場で行い,すでに発生してしまった問題や今後発生しそうな問題を見極め,その対策方法をプロジェクト・マネジャーに進言する。

 プロジェクトの後半では,それまでに行った作業の品質面での成果が問われるテスト工程が,欠陥除去工程におけるメインの作業となる。テストは,「単体モジュール」,「コンポーネント」,「サブシステム」,「システム」の順に行うことで信用できるプログラムの割合を徐々に増やしていき,最終的にシステム全体を確実なものにする。これらの欠陥除去工程の具体的な進め方については,次回で詳しく説明する。