＜目的＞
(1)品質計画にて決定された検証（レビュー）時期、段階に応じたレビューを確実に実施するため
(2)開発作業全体の作業生産性を向上するため
＜タスク＞
1.レビュー目的・目標・実施方法を明確化する
2.モデレータと記録係、読み手を指名する
3.インスペクション対象物を選定する
4.インスペクション対象物がインスペクションに提出できる状態かどうかを判断する
5.インスペクション参加者を選定し、役割を割り当てる
6.インスペクションパッケージを作成する
7.以降のインスペクションの各段階スケジュールを立案する
レビュー方法の検討と決定
プロジェクト計画立案、見直し時、またはフェーズ内の詳細作業計画時などに、ソフトウェアを開発する過程で、どの段階で、どの成果物に対して、どのようなレビューを実施していくのかを検討し、決定します。
1.基本的な考え方
レビュー手法はそれぞれ特徴や効果が様々です。
ですから、どんな成果物に対しても、いつも同じ手法、同じやり方で対応するのは効果的、効率的とは思えません。
レビューの目的、対象物のリスク、プロジェクトの状況などに対して、これらの手法を適切に使いこなすことが求められます。
状況に応じて、相応しい、適切な手段を選択して実践するようにしましょう。
2.リスクを何で判断するか
ここでの主なリスクには「プロジェクトリスク」と「プロダクトリスク」の２つがあります。
レビュー手法を選択する際に最も考慮するべきは「プロダクトリスク」の方です。
プロダクトリスクとは、プロダクトの出来具合（質）が顧客やエンドユーザ、社会に与える影響度合いの可能性です。
レビュー目標、対象物の規模、重要度、難易度、対応要員スキルなどによりプロダクトリスクを把握して適切なレビュー手法を採用し、実践してください。
なお、リスク分析には定量的分析と定性的分析がありますが、まずは定性的でも構いません。
無理に数値化＝定量化しても、その数値が実態を表す、またはかなり当たっている状態でなければ意味はありませんので注意が必要です。
定性的な分析時によく使うのが「松」・「竹」・「梅」、「大」・「中」・「小」などの大枠の分類です。
たとえば、多くの対象物をその重要性と難易度で分析する方法があります。
－ | － | 難 | 易 | 度 |
－ | － | 梅:1 | 竹:3 | 松:5 |
重 | 梅:1 | 1 リスク小 | 3 | 5 |
要 | 竹:3 | 3 | 9 リスク中 | 15 |
度 | 松:5 | 5 | 15 | 25 リスク大 |
表内数値のみは便宜的に割り当てたリスク度合い
3.リスク度合いによるレビュー手法事例
リスクが大きい対象ほど、欠陥除去効果が高い手法、様々な切り口の確認が可能な手法（例えばインスペクション）で実施するようにする。また、リスクが小さい対象ほど簡易はレビュー手法まで様々な手法が選択できるように選択肢を広げるのがよいでしょう。
以上は基本的な考え方ですので、唯一の考え方ではないことに注意してください。
このような整理に基づき運営していき、その結果からさらに効果が高い方法を見いだしながらやっていくことが本当に求められるチーム、あるいは組織的な活動ではないでしょうか。
4.目的や難易度、要員のスキルによって手法を変える
高い精度を求められる成果物、製品リスクが高い成果物、難易度や複雑さが高い成果物は、インスペクションやチームレビューを行うのが妥当だと思います。
可能であれば、すべての成果物にインスペクションやチームレビューを実施するのがよいと言われていますが、実際のところそこまでリソースやスケジュールがうまく折り合うことはあまりないでしょう。
そこで、レビューの目的や難易度、要員のスキルにも着目して、レビュー手法を適切に割り当て、実施してください。
例えば、作成担当者のスキルが高く、レビュー対象物の難易度が中～低、技術的な対応にも長けているような場合は、数名によるウォークスルーを選択することも可能かと思います。
スキルが高い要員であれば、ウォークスルーで自ら第三者に説明しているうちに、自ら作成した成果物の内容不備に気がつく可能性が高いためです。
＃ 作成担当者が最も経験・知識が豊富である場合なども同じです。
この他にも、レビューに関わるメンバー全員に成果物の内容を理解してもらう趣旨（目的）を持つ場合でも、ウォークスルーが役立つ可能性があります。（他にはラウンドロビン（成果物のそれぞれの部分部分で対応する担当者を変えてレビューを行う形式）
規模も小さく、製品リスクも高くない、比較的容易な成果物がレビュー対象であれば、ピアデスクチェックや（時間的に余裕があるなら）パスアラウンド（回覧形式）での対応も可能な場合があります。
5.いろいろな視点・切り口で確認する方法で実施
同じ成果物でも、評価・確認の視点、切り口を変えることで、多くの欠陥や問題点が見つかることがあります。
また、できればそれ以降の作業についても首尾よく進行したいと願うのは当然です。
そこで、成果物に対する立場をそれぞれで変えて確認することをおすすめします。
例えば、
①成果物を作成するインプット情報（例えば上位設計書）を作成した方、あるいはその視点を持つ方
上位設計者であれば、どのような意図でそう設計したのか、その結果、下位の設計はどうあってほしいのかを最も知っています
②成果物が完成した後で、それを使って作業する予定の方（直接・間接）
自分が実際に作業する際に、成果物の内容だけで進めることができるかという視点で見ます。
このことで、実際に作業を行う場合の質問とその確認がレビュー時点で解消されますし、技術的な内容を含めた事前の認識共有、理解促進が可能になります。
6.メンバーの特性を考慮する
レビューを実施するメンバーは必ずしもベストな人たちになるとは限りません。
ですから、レビュー目的、レビュー対象物の特徴から”レビューで求められるスキルや経験への要件”を洗い出しておき、レビューメンバーが持つスキルや経験を把握して、誰にどんな役割を割り当てるかを決めると効果的です。
スキルが低い、経験が少ないなどは、どこの組織に行っても同じような状態です。
メンバーの特性を最大限生かして、強みを生かし、弱みを補完するためにはどうしたらよいかを考えてレビュー計画を立案してください。
7.メンバーで計画内容、各自の役割などを認識共有する
注意：この内容はレビュー実施前までに行われればよいものです。
レビュープロセス側にも同様の記載が入っていますが、２度実施することが必要という意味ではありません。
どんなによい計画でも、それを実行するメンバーがその内容を理解し、自らの役割を（他者の役割と連携して）認識できていないと実践できませんよね。
メンバー全員でレビュー計画内容に対して認識共有し、各自の役割に合意する。
不明点があればこの時この時点で解消することが必要になります。