設計レビューの観点チェックリスト｜基本設計・詳細設計別と記録票

設計レビューとは、設計書を書いた人以外の目で読み、漏れ・誤り・あいまいな記述を実装の前に見つけて直す活動です。 見る観点は工程で変わります。基本設計では「利用者や他システムから見た振る舞いが決まっているか」、詳細設計では「その記述だけで同じプログラムが書けるか」を確かめます。

この記事では、観点を基本設計・詳細設計の2工程 × 画面・テーブル・バッチ・インターフェースの4成果物に分けたチェックリストにし、すべての観点に指摘文の例と修正後の書き方を添えました。あわせて、表計算ソフトに貼れるレビュー記録票（タブ区切り）と記入例、記録票から分類別の件数と指摘密度を集計するPythonコードを実行結果つきで載せます。例は架空の「社内備品予約システム」です。

確認環境：Ubuntu 24.04、Python 3.11.15（集計コードはこの環境で実行した出力を掲載）。

設計レビュー観点の早見表

基本設計と詳細設計でレビューの観点はどう変わるか

同じ「画面」の設計書でも、工程によって問いが違います。基本設計のレビューは「何を作るかが決まっているか」、詳細設計のレビューは「どう作るかが一通りに決まるか」を確かめます。

工程を取り違えると、基本設計のレビューで変数名の議論が始まったり、詳細設計のレビューで画面の構成が見直されたりして、時間が足りなくなります。レビューの冒頭に「今日はどの工程の、どの観点を見るか」を伝えるだけで、指摘の粒がそろいます。

工程に共通する観点

成果物別の表に入る前に、どの設計書にも当てはまる観点を確認します。

基本設計レビューのチェックリスト

画面（基本設計）

テーブル（基本設計）

バッチ（基本設計）

インターフェース（基本設計）

詳細設計レビューのチェックリスト

画面（詳細設計）

テーブル（詳細設計）

バッチ（詳細設計）

インターフェース（詳細設計）

指摘の分類と重要度をそろえる

分類と重要度の定義を先に配っておくと、記録票の集計がそのまま改善の材料になります。

指摘文は「どこが」「どう読めて」「何が決まるとよいか」の3点を入れると、書いた人がすぐ直せます。

レビュー記録票のテンプレートと記入例

記録票は、指摘を1行ずつ書き、対応と確認まで同じ行で追える形にします。列は次の8つです。

次のブロックはタブ区切りです。そのまま表計算ソフトのセル A1 に貼り付けると、列に分かれます。1行目が見出し、2行目以降が記入例です。

指摘番号    対象文書    対象箇所    分類  重要度 指摘内容    対応  確認
R-001   画面設計書   3.2 予約登録画面 項目一覧 漏れ  高   利用終了日時の入力チェックが定義されていない  必須・開始日時より後・最長7日を追記  済
R-002   画面設計書   3.2 予約登録画面 メッセージ    あいまい    中   「適切なメッセージを表示する」の文言が決まっていない  メッセージID M-012 と文言を明記    済
R-003   画面設計書   3.4 予約一覧画面  不整合 中   一覧の並び順が画面遷移図の説明と異なる 利用開始日時の昇順に統一    済
R-004   テーブル定義書 2.1 reservation 誤り  高   同じ備品の時間帯重複を防ぐ制約がない  排他制約と登録時の重複チェックを追記  済
R-005   テーブル定義書 2.1 reservation 漏れ  中   更新日時の列がなく楽観ロックの条件が書けない  updated_at と version を追加    済
R-006   テーブル定義書 2.3 equipment   あいまい    低   status の取りうる値が書かれていない   コード定義表を追加   済
R-007   バッチ設計書  4.1 返却リマインド 漏れ  高   途中で止まったあとの再実行手順がない  処理済みフラグと再実行手順を追記    未
R-008   バッチ設計書  4.1 返却リマインド 不整合 中   起動時刻が運用スケジュール表と1時間ずれている 毎日 8:00 に統一 済
R-009   インターフェース設計書 5.2 社員マスタ連携 漏れ  高   相手先が応答しないときのタイムアウトと再送回数がない  10秒・3回・以降は通知と明記 未
R-010   インターフェース設計書 5.2 社員マスタ連携 誤り  中   社員番号の桁数が相手先仕様（8桁）と異なる   6桁を8桁に修正    済
R-011   インターフェース設計書 5.3 エラー応答   表記  低   エラーコードの表記が E001 と E-001 で混在 E-001 形式に統一 済
R-012   画面設計書   3.5 権限  漏れ  中   管理者以外が他人の予約を取り消せるかが書かれていない  権限表に取消の行を追加 未

空の記録票として使うときは、2行目以降を消して1行目だけ残します。開催日・参加者・対象の版・ページ数は、シートの上部か別シートに書いておくと、あとで密度を計算できます。

記録票から分類別の件数と指摘密度を集計する

記録票を review.tsv（タブ区切り）または review.csv（カンマ区切り、UTF-8）として保存し、次のコードで集計します。標準ライブラリだけで動きます。

"""レビュー記録票（CSV）から、分類別の件数と指摘密度（件／ページ）を集計する。"""
import csv
import sys
from collections import Counter

# 文書ごとのページ数（レビュー対象として配布した版のページ数を入れる）
PAGES = {
    "画面設計書": 24,
    "テーブル定義書": 10,
    "バッチ設計書": 8,
    "インターフェース設計書": 12,
}

path = sys.argv[1] if len(sys.argv) > 1 else "review.csv"
delimiter = "\t" if path.endswith((".tsv", ".txt")) else ","
with open(path, encoding="utf-8-sig", newline="") as f:
    rows = list(csv.DictReader(f, delimiter=delimiter))

print(f"指摘の総数: {len(rows)} 件")

print("\n[分類別]")
by_class = Counter(r["分類"] for r in rows)
for name, n in by_class.most_common():
    print(f"  {name:<6} {n:>2} 件  {n / len(rows):6.1%}")

print("\n[重要度別]")
by_sev = Counter(r["重要度"] for r in rows)
for name in ("高", "中", "低"):
    print(f"  {name}  {by_sev[name]:>2} 件")

print("\n[文書別の指摘密度]")
by_doc = Counter(r["対象文書"] for r in rows)
total_pages = 0
for doc, pages in PAGES.items():
    n = by_doc[doc]
    total_pages += pages
    print(f"  {doc:<12} {n:>2} 件 / {pages:>2} ページ = {n / pages:.2f} 件／ページ")
print(f"  {'全体':<12} {len(rows):>2} 件 / {total_pages:>2} ページ = {len(rows) / total_pages:.2f} 件／ページ")

print("\n[確認が済んでいない指摘]")
open_rows = [r for r in rows if r["確認"] != "済"]
for r in open_rows:
    print(f"  {r['指摘番号']} [{r['重要度']}] {r['対象文書']} {r['対象箇所']}")
high_open = sum(1 for r in open_rows if r["重要度"] == "高")
print(f"\n未完了 {len(open_rows)} 件（うち重要度「高」 {high_open} 件）")
print("判定:", "レビュー完了" if not open_rows else "再確認が必要")

実行結果（上の記入例12件を review.tsv に保存して実行）：

$ python3 review_stats.py review.tsv
指摘の総数: 12 件

[分類別]
  漏れ      5 件   41.7%
  あいまい    2 件   16.7%
  不整合     2 件   16.7%
  誤り      2 件   16.7%
  表記      1 件    8.3%

[重要度別]
  高   4 件
  中   6 件
  低   2 件

[文書別の指摘密度]
  画面設計書         4 件 / 24 ページ = 0.17 件／ページ
  テーブル定義書       3 件 / 10 ページ = 0.30 件／ページ
  バッチ設計書        2 件 /  8 ページ = 0.25 件／ページ
  インターフェース設計書   3 件 / 12 ページ = 0.25 件／ページ
  全体           12 件 / 54 ページ = 0.22 件／ページ

[確認が済んでいない指摘]
  R-007 [高] バッチ設計書 4.1 返却リマインド
  R-009 [高] インターフェース設計書 5.2 社員マスタ連携
  R-012 [中] 画面設計書 3.5 権限

未完了 3 件（うち重要度「高」 2 件）
判定: 再確認が必要

読み方のポイントは3つです。

• 分類別：「漏れ」が12件中5件（41.7%）で最も多いので、次回は設計書のひな形に「異常時の動き」「権限」の欄を足す、といった手が打てます。
• 文書別の指摘密度：テーブル定義書が 0.30 件／ページで最も高く、ページあたりの指摘が集まっています。密度は文書どうしや過去の回と比べるための数字で、高い文書から優先して見直します。
• 確認が済んでいない指摘：重要度「高」が2件残っているため、判定は「再確認が必要」です。早見表の完了の条件に沿って、次の工程へ進む前に確認を終えます。

密度が極端に低いときは、設計書の品質が高い場合と、読む時間が足りなかった場合の両方がありえます。レビューにかけた時間と読んだページ数を一緒に記録しておくと、どちらなのかを判断できます。

レビューの進め方

会議の時間は、直し方を議論する場にすると足りなくなります。会議では「指摘が事実かどうか」と「重要度」だけを決め、直し方は書いた人に任せると、予定の時間で終わります。

よくある質問

Q. チェックリストの項目が多くて、1回で見きれません。 A. 成果物ごとに回を分け、1回に見る表を1〜2個に絞ります。参加者ごとに担当する観点を割り振る方法も有効です（例：1人は権限と異常時、もう1人は項目の定義）。

Q. 基本設計のレビューで、詳細設計の内容の指摘が出たらどうしますか？ A. 記録票に書き、対応欄に「詳細設計で定義」と記入して確認欄を「済」にします。指摘そのものは次の工程への申し送りとして残るので、内容が消えません。

Q. 重要度の判断が人によって分かれます。 A. 「そのまま実装するとどうなるか」で決めます。作り直しになるなら高、実装する人が質問すれば解決するなら中、動きが変わらないなら低です。迷ったら高いほうにして、会議で合意します。

Q. 指摘密度はいくつなら合格ですか？ A. 文書の種類や書き手の経験で変わるため、一律の値は置けません。同じチームの過去の回と比べ、大きく外れた文書を見直す使い方が向いています。

まとめ

• 基本設計のレビューは「何を作るかが決まっているか」、詳細設計のレビューは「どう作るかが一通りに決まるか」を確かめる
• 観点は成果物別（画面・テーブル・バッチ・インターフェース）に分けると、参加者と時間を割り振りやすい
• 指摘文は「どこが・どう読めて・何が決まるとよいか」を書き、修正後の書き方を具体的な値で示す
• 分類は5種類（漏れ・誤り・不整合・あいまい・表記）、重要度は3段階にそろえる
• 記録票は指摘から対応・確認までを1行で追える形にし、タブ区切りで表計算ソフトに貼って使う
• 分類別の件数と指摘密度を集計し、多かった分類を次回のひな形とチェックリストに反映する

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