システム開発の現場で作成される様々なドキュメントは、レビューを受けることでプロジェクトとしての品質を担保しています。

設計フェーズで作成される要件定義書・基本設計書・詳細設計書、テストフェーズで作成されるテスト計画書・テストケース・テスト結果報告書、リリース前に作成されるリリース手順書・操作マニュアル等々、作成されたドキュメントはすべてレビューにかけられます。

レビューの際に起こりがちな間違いは別記事ドキュメントレビューのポイント vol.1 〜レビューの間違い〜でご紹介しましたが、このような間違いを起こさないためにも、レビューの技法や進め方を理解し、正しく進めていきたいものです。

レビュー技法

レビューにも複数の種類がありますが、ここではシステム開発の現場でよく用いられる2つの技法「テクニカルレビュー」「ウォークスルー」をご紹介します。

テクニカルレビューの4つのステップ

レビューは下図の通り4つのステップで実行されます。

各フェーズ（要件定義・基本設計・詳細設計、等）で、作成されたドキュメントのレビューを実行します。場合によっては、フェーズごとにウォークスルーや簡易レビューを数回、実施する場合もあります。

また、レビューの各ステップを取り仕切るエンジニアを「リーダー」と呼び、レビュアーとは区別します。実際には、プロジェクトマネージャーやプロジェクトリーダー、チームリーダーが担うことが多いと思います。

レビューの準備

レビューの4つのステップのうち、最初のステップである「1.レビューの準備」は、下図のように5つのタスクから構成されます。

1. 問題種別の選定

最初のタスクは、レビューでどのような問題を検出すべきなのか、検討することです。このとき、「ボトムアップ」「トップダウン」の2段階のアプローチで検討を進めていきます。

2. シナリオの作成

検出すべき問題の検討結果を基にして、ドキュメントのどこをどのように調べていくのか、具体化させてシナリオとしてまとめます。シナリオをブラッシュアップしていく過程で、検出すべき問題の漏れに気付いたり、レビュアーに求められるスキルレベルの検討ができます。

3. レビュー実施検討

レビューを一度きりと定めるのではなく、テクニカルレビューよりも一段階カジュアルなウォークスルーや簡易レビューを数回実施し、テクニカルレビューの前にドキュメントの品質を高めておくことも重要です。そのため、レビューのリーダーは、作成されるドキュメントごとに、簡易なレビューをどのタイミングで何回実施するか検討しておく必要があります。

4. レビュアーの選定

作成したシナリオを基に、レビュー対象の分野への知見の有無やスキルレベルを確認して、レビュアーを選定します。選定したレビュアーそれぞれに、シナリオを割り当てていきます。レビュアーは、プロジェクト規模の大小に関わらず、5名程度が良いとされています。あまりに多くのレビュアーがいると、レビューに時間がかかり効率的ではありません。

5. ドキュメント配布・告知

レビュー会議の前に、ドキュメント作成者にレビュー対象のドキュメントを提出させ、レビュアーに配布し、レビュー会議開催の告知をします。仮にドキュメントの作成が間に合っていない場合でも、途中のドキュメントを提出させます。プロジェクトの進捗とスケジュール次第ですが、未完成の状態でもレビューを実施する場合があります。

まとめ

レビューをステップに沿って正しく進めていくためには、準備段階におけるタスクを理解しておく必要があります。効率的で確実なレビューを実施するために、準備に余念のないようにしたいですね。

■ドキュメントレビューに関するその他の解説記事

ドキュメントレビューのポイント vol.1 〜レビューの間違い〜
ドキュメントレビューのポイント vol.2 〜レビューの準備〜 【本記事】
ドキュメントレビューのポイント vol.3 〜レビュアーの準備〜
ドキュメントレビューのポイント vol.4 〜ドキュメントレビューの実施〜

【参考文献】
間違いだらけの設計レビュー [改訂版]　日経BP社
ソフトウェア開発へのSWEBOKの適用　オーム社