レビューの種類と違い｜ウォークスルー・インスペクション比較表

レビューの種類は、ISTQB／JSTQB の Foundation Level シラバス 4.0 では、インフォーマルレビュー・ウォークスルー・テクニカルレビュー・インスペクションの4つに整理されています。違いは「誰が主導するか」と「どこまで形式を決めるか」にあります。名前を覚えるより、目的に合わせてどれを選ぶかを決められることが大切です。

この記事では、4種類を同じ項目で横に並べた比較表、成果物の重要度と残り時間から選ぶ判断表、60分のレビュー会の時間割、指摘記録票のテンプレート、指摘密度とレビュー速度の計算例までを載せました。例は架空の「備品予約システム」の基本設計書（24ページ）です。

確認環境：Ubuntu 24.04、Python 3.11.15（標準ライブラリのみ）で、掲載した計算結果は2026-10-05に実行した出力です。4種類の特徴は、ISTQB Certified Tester Foundation Level Syllabus v4.0.1（2024-09-15、英語）の 3.2 節を2026-10-05に開いて確認しました。日本語版は JSTQB の Version 2023V4.0.J02（2024年7月10日）で版と発行日を確認しています。用語の日本語は一般に使われる呼び名に合わせています。

この記事の結論

レビュー4種類の比較表（早見表）

「シラバスの記載」はシラバス 3.2.4 に書かれている内容、「よく使われるやり方」はシラバスに定めがない部分を補う一般的な進め方の例です。

4種類それぞれの特徴と向いている場面

インフォーマルレビュー

決まった手順を持たず、正式な記録も求めないレビューです。隣の人に見てもらう、チャットで確認を頼む、プルリクエストにコメントをもらう、といった日常の確認がここに入ります。

• 向いている場面：小さな変更、影響の範囲が狭い成果物、早く返事がほしいとき
• 気をつける点：見た範囲と見ていない範囲が残りにくいので、重要な成果物はこれだけで済ませない

ウォークスルー

作成者が主導し、成果物を順に説明しながら進めるレビューです。目的が幅広く、欠陥を見つけるだけでなく、参加者の理解をそろえる・知識を共有する・合意を作る、といった使い方ができます。事前準備は任意です。

• 向いている場面：新しく加わった人への共有、関係者の認識合わせ、設計の初期の案
• 気をつける点：作成者の説明に沿って進むため、説明されなかった部分は見落としやすい

テクニカルレビュー

技術的な知識を持つレビューアが行い、作成者ではないモデレーターが進行するレビューです。主な目的は、技術的な問題について合意し、決めることです。「この方式でよいか」「この案とあの案のどちらを選ぶか」を決める場に向いています。

• 向いている場面：方式設計、性能やセキュリティにかかわる設計、複数案からの選定
• 気をつける点：決める人と決める基準を先に示しておかないと、意見交換で終わる

インスペクション

最も形式の度合いが高く、汎用のレビュープロセスの全活動に従うレビューです。主な目的は欠陥をできるだけ多く見つけることで、メトリクスを集めて進め方の改善に使います。作成者は、レビューリーダーと書記を務めることができません。

• 向いている場面：後の工程への影響が大きい成果物（要件定義書、外部とのインターフェース仕様、共通部品の設計）
• 気をつける点：準備と会に工数がかかるため、対象を絞る

レビュープロセスの5つの活動と6つの役割

シラバス 3.2.2 は、レビューのプロセスを次の5つの活動で説明しています。インスペクションはすべてを行い、ほかの種類は必要なものを選んで行います。なおシラバスは、汎用のレビュープロセスやより詳しい役割の説明の参照先として ISO/IEC 20246 を挙げています。

シラバス 3.2.3 に挙がる役割は次の6つです。1人が複数の役割を兼ねてもかまいません。

種類を選ぶ判断表（成果物の重要度 × 残り時間）

重要度は「欠陥が後の工程に残ったときの影響」で決めます。時間は目安の例です。

重要度と時間のほかに、目的で上書きする条件があります。

1つの成果物に1種類とは限りません。初期の案をウォークスルーで共有し、完成版をテクニカルレビューにかける、という組み合わせもよく使われます。

ピアレビュー・コードレビュー・マネジメントレビュー・監査との違い

これらは4種類とは別の切り口の呼び名です。シラバス 3.2.4 の4種類には含まれていないため、次の表は一般的な使われ方の整理です。

60分のレビュー会の時間割

テクニカルレビューやインスペクションで、事前準備を済ませて集まる場合の例です。対象は24ページ、参加者は5人（作成者、進行役、書記、レビューア2〜3人）を想定しています。

ウォークスルーで行う場合は、10〜45分を「作成者の説明と質疑」に置き換え、5〜10分は省きます。

会の前後にすること

指摘記録票のテンプレート（タブ区切り）

見出し行だけのテンプレート

No  ページ 箇所  指摘内容    分類  重要度 指摘者 対応方針    対応者 期限  状態

記入例（備品予約システム 基本設計書、10件）

No  ページ 箇所  指摘内容    分類  重要度 指摘者 対応方針    対応者 期限  状態
1   3   2.1 予約登録    同じ備品・同じ時間帯に2件登録されたときの扱いが書かれていない 漏れ  重大  高橋  排他の方式を追記する  佐藤  2026-10-09  対応中
2   3   2.1 予約登録    予約できる最大日数が要件定義書（30日）と異なる（14日）   誤り  重大  田中  30日に修正する    佐藤  2026-10-07  完了
3   5   2.3 予約取消    取消の締め切り時刻が「前日まで」としか書かれていない  あいまい    中   高橋  前日の17時と明記する 佐藤  2026-10-07  完了
4   6   2.4 検索  検索結果の並び順の記載がない  漏れ  中   山本  利用開始日時の昇順と追記する  佐藤  2026-10-09  対応中
5   8   3.1 画面項目    備品名の桁数がテーブル定義（100）と異なる（50）  不整合 中   田中  100にそろえる    佐藤  2026-10-07  完了
6   9   3.2 エラー表示   メッセージ番号 E-012 が一覧に無い    不整合 軽微  山本  メッセージ一覧に追加する    佐藤  2026-10-09  未着手
7   12  4.1 通知メール   送信に時間がかかったときの再送の回数が未定   漏れ  重大  高橋  再送3回・間隔5分と追記する  佐藤  2026-10-09  対応中
8   14  4.3 権限  「管理者」と「総務担当」の語が混在している   表記  軽微  田中  用語集の「総務担当」に統一する 佐藤  2026-10-07  完了
9   17  5.2 夜間処理    期限切れ予約の削除条件に「以上」「超」の区別がない   あいまい    中   山本  「利用終了日時から90日を超えたもの」と明記する    佐藤  2026-10-09  未着手
10  20  6.1 帳票  月次利用一覧の集計単位（部署別か備品別か）が読み取れない    あいまい    中   高橋  備品別と明記し、出力例を付ける 佐藤  2026-10-14  未着手

指摘密度とレビュー速度をPythonで計算する

上の記入例を findings.tsv として保存し、次のスクリプトを同じフォルダで実行します。

import csv
from collections import Counter

PAGES = 24            # レビューした成果物のページ数
MEETING_MIN = 60      # レビュー会の時間（分）
PREP_MIN = [45, 50, 40]   # レビューア3人の事前準備の時間（分）
ATTENDEES = 5         # 会の参加人数（作成者・進行役・書記を含む）

with open("findings.tsv", encoding="utf-8", newline="") as f:
    rows = list(csv.DictReader(f, delimiter="\t"))

n = len(rows)
by_sev = Counter(r["重要度"] for r in rows)
by_type = Counter(r["分類"] for r in rows)
major = by_sev["重大"]
effort_h = (sum(PREP_MIN) + MEETING_MIN * ATTENDEES) / 60

print(f"指摘件数: {n}件（" + "、".join(f"{k} {v}" for k, v in by_sev.most_common()) + "）")
print("分類別: " + "、".join(f"{k} {v}" for k, v in by_type.most_common()))
print(f"指摘密度: {n / PAGES:.2f}件/ページ（10ページあたり {n / PAGES * 10:.1f}件）")
print(f"重大の指摘密度: {major / PAGES * 10:.2f}件/10ページ")
print(f"重大の割合: {major / n:.0%}")
print(f"会のレビュー速度: {PAGES / (MEETING_MIN / 60):.1f}ページ/時間")
avg_prep = sum(PREP_MIN) / len(PREP_MIN)
print(f"事前準備の速度: {PAGES / (avg_prep / 60):.1f}ページ/時間（1人平均 {avg_prep:.0f}分）")
print(f"かけた工数: {effort_h:.2f}人時（準備 {sum(PREP_MIN)}分 + 会 {MEETING_MIN}分×{ATTENDEES}人）")
print(f"1人時あたりの指摘: {n / effort_h:.2f}件")
print(f"完了率: {sum(1 for r in rows if r['状態'] == '完了') / n:.0%}")

実行結果です。

指摘件数: 10件（中 5、重大 3、軽微 2）
分類別: 漏れ 3、あいまい 3、不整合 2、誤り 1、表記 1
指摘密度: 0.42件/ページ（10ページあたり 4.2件）
重大の指摘密度: 1.25件/10ページ
重大の割合: 30%
会のレビュー速度: 24.0ページ/時間
事前準備の速度: 32.0ページ/時間（1人平均 45分）
かけた工数: 7.25人時（準備 135分 + 会 60分×5人）
1人時あたりの指摘: 1.38件
完了率: 40%

結果の読み方

• 指摘密度（10ページあたり4.2件）は、単独では良し悪しを決められません。同じ種類の成果物の過去の値と比べて、極端に少ない・多いときに理由を確かめます。少ないときは「品質が良い」と「レビューが浅い」の両方がありえます。
• 重大の割合（30%）が高いときは、前の工程の成果物との食い違いを疑います。記入例では、重大3件のうち2件が「漏れ」です。
• 会のレビュー速度（24ページ/時間）は、事前準備を前提にした値です。準備なしでこの速度だと、読みながら進むことになり指摘が出にくくなります。
• 工数は会の時間だけでなく、準備を足して数えます。記入例では、会が5人時、準備が2.25人時で、合わせて7.25人時です。

確かめて分かったこと

• シラバスが「作成者が主導」と書いているのはウォークスルーだけでした。テクニカルレビューはモデレーターが進行し、インスペクションでは作成者がレビューリーダーと書記を務められません。主導者を見ると種類を見分けやすくなります。
• 事前準備が「任意」と明記されているのはウォークスルーです。準備なしで集まれることが、理解をそろえる目的に向いている理由の1つです。
• メトリクスを集めると明記されているのはインスペクションだけでした。指摘密度を工程の判断に使いたいなら、インスペクションを選ぶ根拠になります。
• ピアレビュー・マネジメントレビュー・監査は、シラバス 3.2.4 の4種類には含まれていませんでした。4種類と並べて「5種類目」として扱うより、別の切り口の呼び名として整理するほうが混乱しません。
• 60分の会でも、5人が参加すると工数は5人時になります。準備を含めた7.25人時で10件の指摘なので、1人時あたり1.38件でした。対象を絞る判断は、この数字で行えます。

つまずきやすい点と直し方

よくある質問

Q. ウォークスルーとインスペクションの違いは何ですか？ A. ウォークスルーは作成者が主導して説明しながら進める軽めのレビューで、インスペクションは決まったプロセスと役割に従って欠陥を数えるレビューです。前者は理解の共有に、後者は欠陥の検出と記録に向いています。

Q. ピアレビューとテクニカルレビューの違いは何ですか？ A. ピアレビューは「同じ立場の同僚が見る」という見る人の立場を表す呼び名で、テクニカルレビューは「技術的な問題について合意し、決める」という進め方の種類です。同僚どうしで行うテクニカルレビューは、ピアレビューでもあります。

Q. レビュー会は何分が適切ですか？ A. 1回60分以内に収めると集中が続きやすくなります。対象が多いときは、会を長くするより成果物を分けて回数を増やします。

Q. インフォーマルレビューでも記録は必要ですか？ A. シラバス上は正式な文書の出力を求めていません。ただし、あとで「誰がどこを見たか」を確かめたい成果物なら、コメントやチャットの履歴が残る方法で行うと安心です。

Q. インスペクションで作成者は何をしますか？ A. 質問に答え、指摘を受けて修正します。レビューリーダーと書記は別の人が務めます。

まとめ

• レビューはインフォーマルレビュー・ウォークスルー・テクニカルレビュー・インスペクションの4種類で整理できる。
• 日常はインフォーマル、理解をそろえるならウォークスルー、技術的な合意ならテクニカルレビュー、欠陥を数えて残すならインスペクション。
• 種類は成果物の重要度と残り時間で選び、目的（共有・選定・測定）で上書きする。
• 主導者を見ると種類を見分けやすい。作成者が主導するのはウォークスルー。
• 60分の会は事前準備が前提。会では重大な指摘から扱い、直し方は持ち帰る。
• 指摘密度とレビュー速度は、準備の工数も含めて記録し、過去の値と比べて読む。

参考・出典

• ISTQB「Certified Tester Foundation Level Syllabus v4.0.1」（2024-09-15）3.2 Feedback and Review Process　https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf
• JSTQB「テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J02」（2024年7月10日）　https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。