 |
プロジェクトのレビューには，重要な意味がある。
一つは，質的（品質）な進捗の把握である。レビューをすると，機能の漏れや抜け，不具合などがある程度分かる。特に，その分野の有識者や顧客が参加するレビューには効果がある。上流工程で品質が確保できるので，手戻りを削減でき，生産性向上にもつながる。
もう一つは，メンバーの育成である。レビューを通して，機能や業務，システム全体を理解してゆくことができるからである。
プロジェクト・マネージャ（PM）は，各種レビュー日程を計画に反映しておく必要がある。しかし，プロジェクトに遅れが生じると，ついレビューを省いたり，簡単に済ませてしまったりするケースをみかける。そのようなプロジェクトは，後工程（テスト）で問題が発覚し，手戻りのコストや工数が膨れ上がり，不採算や納期遅延となっている。だから，レビューを省いてはいけない。
優秀なPMほどレビューを受けることを大事にする
プロジェクトでは，中間成果物として様々なドキュメントが作られる。特に要件定義書などのレビューは，顧客を含めた公式レビューとして実施する。このレビューで顧客ニーズの把握や不明確な仕様を確定させていくことができる。
社内ではメンバー以外の第三者（専任レビュワーや品質保証部門など）を加えた公式レビューを実施したい。それによって，漏れや不具合を排除できるし，客観的な質の評価も可能となる。基本設計書や仕様書のほか，プロジェクト計画書やテスト計画書などの計画書類もレビューの対象とし，妥当性を検証する。
多くのPMはレビューで不具合を指摘されることを嫌う。しかし，レビューを活用してPM自身がプロジェクトに対する客観的な評価を把握するのは，非常に有効である。プロジェクトを成功させる優秀なPMに話を聞くと，レビューの重要性，とりわけ第三者が参加するレビューの重要性を十分認識している。各種ドキュメントのレビューを通して，PMはリスクを想定でき，事前に対応策を検討することができるからだ。つまり，想定できるリスクが発生しないように予防措置（予防対策）を取ったり，不幸にも発生した場合の対応策（発生時対策）を検討しておくことができる。
リスクが発生した場合のPMのオペレーションに会社（組織）として権限を委譲しておくことで，即断即決できるようにしておくことは重要である。また，対応策を検討することでリスクの共有化も図ることができる。
レビューにも準備が必要
実際のレビューでよく聞くのは，ドキュメントの記述内容の説明と質疑応答で時間切れになって，肝心の問題発見まで至らないケースだ。必ずレビュー対象のドキュメントを事前に参加者へ配布し，一読させておき，レビュー時には説明を省いたりポイントのみの説明としたりする。解決策の検討に時間がかかる案件は，別途開催とすることも必要だ。業種ごとに共通してよく指摘される事項については，チェックリストにまとめておき，事前にチェックし，チェック結果をレビュー時に提出して時間を有効に活用するといった工夫も必要だ。
レビュー時間は，長くても2時間程度に抑えたい。これは人間の注意力が持続する限界がほぼ2時間であると言われているからである。2時間で終わらない場合は，いったん休憩をはさみ再開する。
ドキュメントが分厚い場合は，すべて出来上がってからレビューを実施するのでなく，ある程度まとまった段階で少しずつ実施していく。段階的にレビューの質を高めていくのも効果的である。
レビューの記録を残す
レビューを実施した場合は，必ず記録を残す。レビューで指摘されたことが反映されているか，後で確認するためである。せっかく時間をかけて有効な指摘が得られても，反映されなければ何の意味もない。
特に，顧客を加えたレビューの記録は残しておく必要がある。システムが完成した時点で「こんな仕様ではない」などと言われた場合，確認や検証が可能となるからだ。また，参加者や指摘事項の記録を残すことで，定量的把握やレビュー実施前の「事前チェックリスト（図）」としても利用できる。
 |
| 図●事前チェックリストの例 [画像のクリックで拡大表示] |
|
