レビュー
レビューとは、ソフトウェア成果物（要件、設計、コードなど）を人が検査し、欠陥や改善点を発見する静的テスト技法です。ISTQB FL シラバス v4.0（3.2節）および JSTQB AL TA シラバス v3.1.1（第5章）に定義されています。
早期フィードバックの利点（FL 3.2.1）
開発の初期段階からステークホルダーのフィードバックを得ることで、以下の効果が得られます。
- 顧客・ユーザーのニーズを早期に把握でき、手戻りコストを削減できる
- 要件の誤解を早期に修正し、開発が誤った方向に進むリスクを抑える
- 欠陥が後工程に持ち込まれる前に除去できるため、全体の品質と効率が向上する
レビュープロセスの活動（FL 3.2.2）
レビューは以下の5つの活動で構成されます。
| 活動 | 概要 |
|---|---|
| 計画 | スコープ、目的、対象成果物、役割、レビュー基準を定義する |
| レビューの立ち上げ | 参加者が成果物・チェックリスト・入力基準を受け取り、準備する |
| 個々人のレビュー | 各レビューアが成果物を個別に検査し、欠陥・コメントを記録する |
| 共有と分析 | 発見した欠陥を議論し、ステータス（受理・却下）と優先度を決定する |
| 修正と報告 | 欠陥を修正し、品質メトリクスを収集してレビューを終了する |
役割と責務（FL 3.2.3）
| 役割 | 主な責務 |
|---|---|
| マネージャー | レビューの実施を決定し、リソースと時間を確保する |
| 作成者 | レビュー対象の成果物を作成した担当者。修正を担う |
| モデレーター（ファシリテーター） | レビュー会議を進行し、議論が生産的になるよう調整する |
| 書記（スクライブ） | 欠陥・議論の内容を記録する |
| レビューア | 成果物を検査し、欠陥や改善提案を指摘する |
| レビューリーダー | レビュー全体を計画・調整し、参加者を選定する |
1人が複数の役割を兼務することがあります。モデレーターと作成者の兼務はオーナーシップの利益相反が生じるため避けることが推奨されます。
レビュー種別（FL 3.2.4）
非形式的レビュー（Informal Review）
定義されたプロセスを持たない最も軽量なレビュー。レビューアに成果物を渡してフィードバックを得るだけで実施できる。文書化は任意。
ウォークスルー（Walkthrough）
作成者が参加者に成果物を説明しながら進める。目的は欠陥の発見だけでなく、知識共有や代替案の議論も含む。正式な記録は任意。
テクニカルレビュー（Technical Review）
技術的な観点を持つレビューアが標準・仕様への適合を評価する。モデレーターが会議を進行し、欠陥リストを作成する。
インスペクション（Inspection）
最も形式的なレビュー種別。入口基準・出口基準が明確に定義され、メトリクスを収集してプロセス改善に活用する。チェックリストを必ず使用し、フォローアップで修正を確認する。
| 種別 | 形式度 | チェックリスト | 文書化 | メトリクス収集 |
|---|---|---|---|---|
| 非形式的レビュー | 低 | 任意 | 任意 | なし |
| ウォークスルー | 中 | 任意 | 任意 | なし |
| テクニカルレビュー | 中〜高 | 推奨 | 必須 | 任意 |
| インスペクション | 高 | 必須 | 必須 | 必須 |
レビューの成功要因（FL 3.2.5）
- 明確な目的設定：欠陥発見・標準適合確認・知識共有など、目的をレビュー前に明確にする
- 適切な参加者の選定：対象成果物に適した技術・ドメイン知識を持つ人を選ぶ
- 十分な準備時間の確保：参加者が事前に成果物を検査できる時間を設ける
- 小さいスコープ：一度に大量の成果物をレビューしない。集中力と精度が保てる量に絞る
- 欠陥・改善点のフィードバック：個人批判でなく成果物に集中し、建設的な議論をする
- 組織的なサポート：レビューをプロセスに組み込み、スケジュールとリソースを確保する
チェックリストベースドレビュー（AL TA 5.2）
テストアナリストは、要件やユーザーストーリーのレビューにおいてチェックリストを活用し、欠陥を体系的に発見します。チェックリストは過去の欠陥傾向に基づいて作成・更新します。
要件レビューのチェックリスト（AL TA 5.2.1）
要件文書（SRS など）をレビューする際に確認すべき観点の例：
| 観点 | チェック内容 |
|---|---|
| 完全性 | 機能・非機能要件に抜け漏れがないか |
| 一貫性 | 要件間に矛盾・競合がないか |
| テスト可能性 | 合格・不合格を客観的に判定できるか |
| あいまいさ | 複数の解釈が生じる表現がないか |
| 実現可能性 | 技術・コスト・スケジュールの制約内で実現可能か |
| トレーサビリティ | ビジネス目標・ユーザーニーズと紐付けられているか |
ユーザーストーリーレビューのチェックリスト（AL TA 5.2.2）
ユーザーストーリーと受け入れ基準をレビューする際の確認観点の例：
| 観点 | チェック内容 |
|---|---|
| INVEST 基準 | Independent・Negotiable・Valuable・Estimable・Small・Testable を満たすか |
| 受け入れ基準の明確さ | 「完了」の定義が明確で、テストケースに変換できるか |
| ユーザー価値 | 誰が何を目的に使うか（ロール・機能・目的）が明示されているか |
| エッジケース | 異常系・境界値が考慮されているか |
| 依存関係 | 他のストーリーや外部システムへの依存が識別されているか |
チェックリストの調整（AL TA 5.2.3）
チェックリストは組織・プロジェクトに合わせて継続的に更新します。
- 新たに発見された欠陥パターンを項目として追加する
- プロジェクト固有のリスク（規制要件・ドメイン特性）を反映する
- 使用されない項目は定期的に見直して削除し、リストを簡潔に保つ
- チームでレビューし、共通理解のもとで運用する
ポイント：チェックリストは「発見しやすい欠陥」を抜け漏れなく確認するためのツールです。チェックリストだけに頼らず、レビューアの専門知識に基づく自由な検査と組み合わせることが効果的です。