■レビューの主な観点（開発全体における考え方）
①正しいソフトウェアを作っているか：妥当性確認
主に上流工程で確認される事項：「設計品質」
目的に合致するか・用途に合うか（妥当性）が主な観点であり、仕様がユーザ要求に適合しているかが主な関心事
②正しくソフトウェアを作っているか：検証
主に下流工程で確認される事項：「実装品質」
正確性など仕様に合うようにコードが正しく実装されているかが主な関心事
■レビューの主な観点（個別レビューとしての一般的な考え方）
①仕様を満足しているか
②成果物に基づいて作業を進めることができるか
（例） ・次工程作業 ・テスト設計
③成果物を正しく作成しているか
（例） ・各種規約、標準に準拠しているか
■レビューの観点・切り口を導く見方の例
視点を変えると、それまで見えなかったモノが見えてきます。
開発者は開発する視点でモノを作ります。
開発する視点以外の視点が抜けていることが多いわけですから、別の視点を持ってレビューを実施して下さい。（もちろん、開発者の視点にモレや抜け、矛盾などがないかも確認が必要ですよ）
以下はその事例です。
□（製品）品質リスクを分析・評価してみる
□相手に説明する前提で対象物を見る
□実装する立場で対象物を見る
□使う立場で、使用想定者の立場で対象物を見る
□システム化目的と使用する状況（利用状況）で対象物を見てみる
□対象物が作成された過程（プロセス）を確認してみる
□関係する、連携する他の対象物と一緒に見てみる
□利用品質や品質特性などのモデルで確認してみる
□対象物でテスト設計・実施が可能かを確認してみる
□作り込みそうな欠陥、よくある見落としを確認してみる
■レビューの前にテスト設計を
レビューを行う前に対象成果物に基づいてテスト設計を行うのは、欠陥検出に効果的な方法の一つです。
作る側の論理で構築されがちな対象成果物を、評価する立場、使う立場で網羅的に調べてみるのです。
テストの段階で欠陥が検出されるよりも相当早い（例えば設計）段階で欠陥が検出できる、そしてもちろんテスト設計結果はテスト工程で活用できるわけですから、開発全体に占めるロスコストも少なくなります。
■さまざまな立場から対象物を見る
いろんな視点で＝いろいろな立場で、と考えることもできますので、たとえば・・・
・対象成果物を構築するためのインプット情報を構築・提供した要員は、自分が意図したとおりのとらえ方で成果物を作成しているか。
・対象成果物の内容に基づき作業を行う要員は、自分がこの情報、記載内容を理解して、作業することができるか、曖昧なところや不明確なところ、複数の受け取りができる表現などがないか。
・レビュー対象機能の利用者は、自分が使う立場で、使う環境や状況で考えると分かりにくいところ、使いにくいところ、利用時にはこうしてほしいなどの情報がないか。
など、異なる視点を持つメンバーに参画してもらうことがレビューの観点を網羅する意味で効果的です。
しかし、実際の現場では皆が忙しくてこれらの要員がレビューミーティングに参画できない場合も多いわけです。
その際には、レビューアとなった方が、本来の自分の立場ではなく、意図的にこれらの「さまざまな立場」からレビュー対象成果物を確認する方法があります。
複数のレビューアでそれぞれ立場＝役割を決めて確認するなどの工夫をしてみるのもよいでしょう。
■チェックリストの役割
レビューチェックリストは、さまざまな場面のレビューで確認すべき観点を網羅的に記載しておくことで、誰が、どのような局面でレビューしても同様の確認が実施されること、レビューで求める確認網羅性を維持し、対象成果物の質のばらつきを抑えて、成果物の質を保証します。
しかし、チェックリストはあくまでも一般的観点の網羅のための備忘録的な役割です。
記載事項以外の観点は必要ない、必ずすべての確認が該当する、どの観点も同じレベルで確認することを求めている、などはあきらかに誤認識となります。
これらの状況があればまずはこれらを解消し、正しい理解のもとで活用することが重要です。
■チェックリストの更新
それぞれのレビューで得られた結果から、チェックリストの記載内容にフィードバックし、ますます成果が上がるように更新していくことが、組織的なレビュー運営効果を向上させるために大事な視点です。