システム開発プロジェクトにおいて「進捗会議」はなくてはならない会議体の一つである。PM（プロジェクトマネジャー）の役割の中でも、この会議で各メンバーの進捗状況を把握することは非常に重要だ。

　一般に小規模プロジェクトであれば、PMが直接各担当者の進捗状況を確認できるため把握しやすい。しかし、複数のサブリーダーがPMの配下にいるような大規模プロジェクトとなるとそうはいかない。このようなプロジェクトでは、各サブリーダーは自分の配下にいる担当者の進捗状況を確認し、その結果をPMへ報告する形を取る場合が多い。そのためPMは進捗会議でサブリーダーから報告された状況だけが唯一の情報源となることすらある。

　PMによっては、その報告内容をうのみにし、作業が進んでいると考えたばかりにプロジェクト後半で痛い目に遭ったことのある人も少なくない。そうならないようにするには、進捗状況報告の裏付けを取ることだ。裏付けの一つとして、各フェーズで行う成果物レビューを通過したか否かを判断材料にする方法がある。

　これは、サブチーム単位で行うレビューをマイルストーンとし、その結果が良好であれば次工程へ進む方法である。有効なプロジェクト管理手法の一つだが、進捗管理ばかりに気を取られてしまうと、本来のレビューの意味を忘れてしまい、それを通すことが目的となってしまうこともある。

「人」の問題ではなく「仕組み」の問題と捉える

　本来、レビューの目的は進捗を確認するためのものではない。レビュー［Review］を手元の英和辞典で調べてみると、［よく調べる／再調査する／再検討する／再審する／検閲する／検査する／評論を書く／批評する／復習する］とある。つまりシステム開発プロジェクトにおけるレビューとは、出来上がった成果物に対して正しく出来上がっているかどうかを調べたり検査したりするためのものであり、その方法として目視による確認が必須なのである。

　「進捗状況確認」と「成果物のレビュー」とでは根本的にその目的が異なっている。にもかかわらず、進捗確認のためにレビューというマイルストーンを設定し、自分では直接成果物に目を通すことなく、他者が目視確認した結果を元にチェックリストに従ってチェックするだけというPMがいる。これではせっかくの成果物レビューを、何のために行っているのか分からないことになる。

　プロジェクトを遅延させてしまうような事態に陥った場合、それを引き起こした「人（＝エンジニア）」に起因する問題としてしまうと、常に「人」を疑わねばならず、さまざまなスキルレベルのエンジニアが参加するプロジェクトでは大きなリスクになってしまう。

　「人」の問題ではなく「仕組み」の問題として捉えるべきである。どんな人が担当者になっても同様の問題が発生しない（させない）ための仕組み作りこそ重要で、そうした仕組みを作る責任者はPMである。そしてこの仕組みの最も有効な方法がレビューなのである。