PR

 要件定義書や設計書、ソース・コードなどシステム開発プロジェクトで作成する成果物の妥当性を検証する作業。成果物の「作り手」と「作成を依頼した側」の双方もしくはどちらかが、「意図したとおり作られているか」という観点で成果物の中身を確認する。

 レビューには大きく、インスペクションとウオークスルーの2種類がある。インスペクションは、プロジェクト・メンバー以外の第三者が出席し、あらかじめ用意したチェック・リストのような評価基準に基づいて成果物を検証する。プロジェクトにおける公式な行事として、参加日時や回数、場所などを決めて実施し、議事録も取るのが普通だ。

 ウオークスルーは、第三者は特に参加せず、成果物の作り手が中心になって行う。どちらかというと非公式なチーム内の打ち合わせに近いもので、議事録も取らないことが多い。レビューという場合、通常はインスペクションを指す。

 レビューはシステム開発における「要件定義」や「基本設計」などの工程ごとに実施する。成果物が仕様や機能の誤りを抱えたまま、プロジェクトを次の工程に進めることがないよう、チェックするのが狙いだ。

 レビューは基本的に、以下の流れで進行する。まずレビューを受ける側が成果物を持ち込む。作り手は成果物の中身を説明。成果物の依頼側はレビュアとして説明に対する質問を投げ、それに作り手が答える。すべての成果物に目を通した結果、成果物に問題がないことを確認できれば、その工程は「完了」となり、プロジェクトは次の工程に進む。

 問題が見つかった場合、解決方法をレビューの場で話し合う。検討結果にしたがい対策を講じ、後日再びレビューを開く。すべての問題に解決のメドが立つまで、レビューを繰り返すのが理想だ。

 レビューを効果的に行うためには、参加メンバーの選定や実施環境にも細心の注意を払う必要がある。レビューへの参加人数は、システムの規模にもよるが10~15人前後が最も望ましい。多くても20~30人程度が限度だ。参加者が少ないと誤りを見逃す可能性が高くなる一方、多すぎると議論がまとまりにくく、緊張感が薄れてしまう。

 レビューへの出席者は、ある程度の意思決定ができる裁量権の持ち主が望ましい。レビューの場で「持ち帰って検討します」と言っていたら議論が進まないからだ。レビューの実施時間は、集中力が持続する1~2時間前後にとどめたい。

 レビューは、システムの品質低下や稼働延期、費用オーバーを防ぐ有効な手段となる。トラブルの原因の早期発見につながるからだ。一般に、システム開発プロジェクトでは誤りの発見が遅れれば遅れるほど、修正にかかる費用が膨らむ。例えば、要件定義のミスをテストで見つけた場合、要件定義のレビューで見つけるのに比べて修正コストが100倍近くかかると言われる。

(大和田)