トレーサビリティマトリクスの作り方 要件・設計・テスト対応表

トレーサビリティマトリクスとは、要件・設計・テストのIDを1行ずつひも付けて、「この要件はどの設計で実現し、どのテストで確かめるか」をたどれるようにした対応表です。 追跡可能性（トレーサビリティ）を表の形にしたもので、要件の作り漏れ、テストの抜け、根拠の無い作り込みの3つを見つけるために作ります。

この記事では、IDの採番ルール、縦持ち（対応表）と横持ち（マトリクス）の2形式のテンプレート、備品予約システムを題材にした記入例を順に示します。さらに、対応表のCSVから抜けを洗い出して網羅率を計算するPythonコードを実行結果つきで載せました。テストケースそのものの書き方には触れず、ID同士のひも付けに絞って説明します。

確認環境：Ubuntu 24.04 / Python 3.11（標準ライブラリのみ）。掲載したコードと出力は、この環境で実行したものです。

トレーサビリティマトリクスの早見表

前方・後方・双方向の違い

追跡の向きは3つあり、向きによって見つかるものが変わります。

前方だけを確かめると「要件はすべて満たした」とは言えても、「要件に無いものを作っていない」とは言えません。 後方も確かめると、範囲の外にある設計やテストに気づけます。縦持ちの対応表を1枚持っておけば、同じデータで両方向を確かめられます。

要件ID・設計ID・テストIDの採番ルール

ひも付けはIDで行うので、最初にIDの形を決めます。おすすめは 「種類-区分-連番」の3つの部分をハイフンでつなぐ形です。

採番するときの決めごとは次の7つです。

IDは一度決めたら変えないことが、対応表を長く使う最大のコツです。 並べ替えたくなったら、IDではなく「表示順」の列を別に作ります。

縦持ちテンプレート（対応表）

縦持ちは、1行に「要件ID・設計ID・テストID」の組を1つだけ書く形式です。1つの要件に設計が2つ、テストが2つあれば4行になります。行は増えますが、絞り込み・並べ替え・集計がそのままでき、コードでも読みやすい形です。

表計算ソフトに貼るときは、次のタブ区切りを使ってください。

要件ID    設計ID    テストID   状態  備考
REQ-F-001   DSN-SCR-001 TST-IT-001  確認済み    
REQ-F-001   DSN-SCR-001 TST-IT-002  確認済み    
REQ-F-001   DSN-API-001 TST-IT-001  確認済み    
REQ-F-005           設計待ち    次の版で設計
REQ-N-002   DSN-TBL-002     テスト作成中  
    DSN-BAT-001 TST-ST-002  要確認 元になる要件を確認する

書き方の決めごとは3つです。

• 相手がまだ無いときは、空欄のまま行を残す。 「これから作る」ことが表に現れ、抜けの一覧にそのまま使えます
• セルには1つのIDだけを書く。 「TST-IT-001, TST-IT-002」のように1つのセルに並べると、絞り込みや集計ができなくなります
• 名称は対応表に書かない。 要件名・設計名・テスト名は、それぞれの一覧（台帳）にだけ書き、対応表はIDだけにします。名前を直すときに1か所で済みます

横持ちテンプレート（マトリクス）

横持ちは、行に要件ID、列にテストID（または設計ID）を並べ、対応する交点に○を付ける形式です。全体を1枚で見渡せるので、レビューや報告に向いています。

右端の件数が0の行は「テストの無い要件」、下端の件数が0の列は「要件に戻れないテスト」です。 行と列の合計を付けておくと、抜けがひと目でわかります。

2つの形式の使い分けは次のとおりです。

原本は縦持ちで管理し、横持ちは縦持ちから作り直す運用にすると、2つの表の内容がずれません。作り直すコードは後の節に載せています。

記入例：備品予約システムの台帳と対応表

ここからは、社内の備品予約システムを題材に、要件8件・設計10件・テスト10件の例で進めます。ファイルは、3つの台帳と1つの対応表の合計4つです。

要件一覧（req.csv）

要件ID,要件名,優先度
REQ-F-001,備品を検索する,高
REQ-F-002,備品を予約する,高
REQ-F-003,予約を取り消す,高
REQ-F-004,予約を承認する,中
REQ-F-005,返却を記録する,中
REQ-F-006,利用状況をCSVで出力する,低
REQ-N-001,検索結果を3秒以内に表示する,高
REQ-N-002,操作ログを1年間保存する,中

設計一覧（dsn.csv）

設計ID,設計名,種別
DSN-SCR-001,備品検索画面,画面
DSN-SCR-002,予約入力画面,画面
DSN-SCR-003,予約一覧画面,画面
DSN-SCR-004,承認画面,画面
DSN-API-001,備品検索API,API
DSN-API-002,予約登録API,API
DSN-API-003,予約取消API,API
DSN-BAT-001,返却期限の通知バッチ,バッチ
DSN-TBL-001,予約テーブル,テーブル
DSN-TBL-002,操作ログテーブル,テーブル

テスト一覧（tst.csv）

テストID,テスト名,レベル
TST-IT-001,条件なしで全件が検索できる,結合
TST-IT-002,名称の部分一致で検索できる,結合
TST-IT-003,空き時間に予約を登録できる,結合
TST-IT-004,重複する時間帯は予約できない,結合
TST-IT-005,自分の予約を取り消せる,結合
TST-IT-006,承認すると状態が承認済みになる,結合
TST-IT-007,予約一覧が開始日時の順に並ぶ,結合
TST-ST-001,1万件の備品で検索が3秒以内,総合
TST-ST-002,返却期限の前日に通知が届く,総合
TST-ST-003,画面の配色を切り替えられる,総合

対応表（trace.csv）。縦持ちで、相手が無いところは空欄です。

要件ID,設計ID,テストID
REQ-F-001,DSN-SCR-001,TST-IT-001
REQ-F-001,DSN-SCR-001,TST-IT-002
REQ-F-001,DSN-API-001,TST-IT-001
REQ-F-001,DSN-API-001,TST-IT-002
REQ-F-002,DSN-SCR-002,TST-IT-003
REQ-F-002,DSN-SCR-002,TST-IT-004
REQ-F-002,DSN-API-002,TST-IT-003
REQ-F-002,DSN-API-002,TST-IT-004
REQ-F-002,DSN-TBL-001,TST-IT-003
REQ-F-003,DSN-API-003,TST-IT-005
REQ-F-003,DSN-SCR-003,TST-IT-005
REQ-F-003,DSN-SCR-003,TST-IT-007
REQ-F-003,DSN-TBL-001,TST-IT-005
REQ-F-004,DSN-SCR-004,TST-IT-006
REQ-F-004,DSN-TBL-001,TST-IT-006
REQ-F-005,,
REQ-N-001,DSN-API-001,TST-ST-001
REQ-N-002,DSN-TBL-002,
,DSN-BAT-001,TST-ST-002
,,TST-ST-003

REQ-F-006 は対応表に1行もありません。このように対応表に書き忘れた要件は、対応表だけを見ていても見つかりません。 そこで次の節では、台帳と突き合わせて抜けを探します。

Pythonで抜けを洗い出し、網羅率を計算する

次のコードは、4つのCSVを読み込み、5種類の抜けと6つの網羅率を出力します。標準ライブラリだけで動きます。

trace_check.py

import csv

def load(path, key):
    with open(path, encoding="utf-8", newline="") as f:
        return {r[key]: r for r in csv.DictReader(f)}

reqs = load("req.csv", "要件ID")
dsns = load("dsn.csv", "設計ID")
tsts = load("tst.csv", "テストID")
with open("trace.csv", encoding="utf-8", newline="") as f:
    links = [(r["要件ID"], r["設計ID"], r["テストID"]) for r in csv.DictReader(f)]

# 1. 台帳に無いIDが対応表に書かれていないか
for no, (r, d, t) in enumerate(links, start=2):
    for value, master, label in ((r, reqs, "要件"), (d, dsns, "設計"), (t, tsts, "テスト")):
        if value and value not in master:
            print(f"台帳に無いID: {no}行目 {label} {value}")

# 2. ひも付けを集合にまとめる
req_to_dsn = {r: set() for r in reqs}
req_to_tst = {r: set() for r in reqs}
dsn_to_req = {d: set() for d in dsns}
dsn_to_tst = {d: set() for d in dsns}
tst_to_req = {t: set() for t in tsts}
for r, d, t in links:
    if r in reqs and d in dsns:
        req_to_dsn[r].add(d); dsn_to_req[d].add(r)
    if r in reqs and t in tsts:
        req_to_tst[r].add(t); tst_to_req[t].add(r)
    if d in dsns and t in tsts:
        dsn_to_tst[d].add(t)

def show(title, ids, master, name):
    print(f"\n■ {title}: {len(ids)}件")
    for i in ids:
        print(f"  {i}  {master[i][name]}")

no_design = [r for r in reqs if not req_to_dsn[r]]
no_test_req = [r for r in reqs if not req_to_tst[r]]
no_req_dsn = [d for d in dsns if not dsn_to_req[d]]
no_test_dsn = [d for d in dsns if not dsn_to_tst[d]]
no_req_tst = [t for t in tsts if not tst_to_req[t]]

show("設計にひも付いていない要件", no_design, reqs, "要件名")
show("テストにひも付いていない要件", no_test_req, reqs, "要件名")
show("要件に戻れない設計", no_req_dsn, dsns, "設計名")
show("テストの無い設計", no_test_dsn, dsns, "設計名")
show("要件に戻れないテスト", no_req_tst, tsts, "テスト名")

def rate(title, total, ng):
    ok = total - ng
    print(f"  {title}: {ok}/{total} = {ok / total:.1%}")

print("\n■ 網羅率")
rate("要件→設計（前方）", len(reqs), len(no_design))
rate("要件→テスト（前方）", len(reqs), len(no_test_req))
rate("設計→テスト（前方）", len(dsns), len(no_test_dsn))
rate("設計→要件（後方）", len(dsns), len(no_req_dsn))
rate("テスト→要件（後方）", len(tsts), len(no_req_tst))

high = [r for r in reqs if reqs[r]["優先度"] == "高"]
rate("優先度「高」の要件→テスト", len(high), len([r for r in high if not req_to_tst[r]]))

実行結果

$ python3 trace_check.py

■ 設計にひも付いていない要件: 2件
  REQ-F-005  返却を記録する
  REQ-F-006  利用状況をCSVで出力する

■ テストにひも付いていない要件: 3件
  REQ-F-005  返却を記録する
  REQ-F-006  利用状況をCSVで出力する
  REQ-N-002  操作ログを1年間保存する

■ 要件に戻れない設計: 1件
  DSN-BAT-001  返却期限の通知バッチ

■ テストの無い設計: 1件
  DSN-TBL-002  操作ログテーブル

■ 要件に戻れないテスト: 2件
  TST-ST-002  返却期限の前日に通知が届く
  TST-ST-003  画面の配色を切り替えられる

■ 網羅率
  要件→設計（前方）: 6/8 = 75.0%
  要件→テスト（前方）: 5/8 = 62.5%
  設計→テスト（前方）: 9/10 = 90.0%
  設計→要件（後方）: 9/10 = 90.0%
  テスト→要件（後方）: 8/10 = 80.0%
  優先度「高」の要件→テスト: 4/4 = 100.0%

結果の読み方と次の一手

抜けが見つかること自体は、対応表が役に立っている証拠です。 大事なのは、0件にすることではなく、残った1件ずつに「追加する・次の版に回す・対象から外す」の判断と理由が書かれている状態にすることです。

網羅率の式と分母

網羅率は、どれも同じ形の式で求めます。

網羅率 ＝ ひも付けのあるIDの数 ÷ 台帳にあるIDの総数

例）要件→テスト ＝ テストにひも付いた要件 5件 ÷ 要件一覧の 8件 ＝ 62.5%

分母を対応表の行数や、対応表に出てくるIDの数にすると、書き忘れた要件が分母から消えて、数字が良く見えてしまいます。 この例で対応表に出てくる要件は7件なので、それを分母にすると 5÷7＝71.4% になり、REQ-F-006 の抜けが数字に現れません。分母は必ず台帳の件数にします。

もう1つ、全体の数字に加えて優先度別の網羅率も出しておくと判断しやすくなります。この例では全体は62.5%ですが、優先度「高」の4件は100%で、残っているのは「中」と「低」だけだとわかります。

台帳に無いIDを書いたとき

対応表のIDを打ち間違えると、ひも付けが切れているのに気づきにくくなります。上のコードは最初にこれを調べます。対応表の末尾に、要件一覧に無い REQ-F-009 の行を足して実行すると、先頭に次の1行が出ます。

台帳に無いID: 22行目 要件 REQ-F-009

行番号は見出し行を1行目として数えています。

縦持ちから横持ちのマトリクスを作る

縦持ちの対応表から、要件×テストの横持ちマトリクスを作るコードです。

to_matrix.py

import csv

with open("trace.csv", encoding="utf-8", newline="") as f:
    links = list(csv.DictReader(f))
with open("req.csv", encoding="utf-8", newline="") as f:
    req_ids = [r["要件ID"] for r in csv.DictReader(f)]
with open("tst.csv", encoding="utf-8", newline="") as f:
    tst_ids = [r["テストID"] for r in csv.DictReader(f)]

pairs = {(r["要件ID"], r["テストID"]) for r in links if r["要件ID"] and r["テストID"]}

with open("matrix.csv", "w", encoding="utf-8", newline="") as f:
    w = csv.writer(f)
    w.writerow(["要件ID"] + tst_ids + ["件数"])
    for r in req_ids:
        marks = ["○" if (r, t) in pairs else "" for t in tst_ids]
        w.writerow([r] + marks + [marks.count("○")])
    w.writerow(["件数"] + [sum((r, t) in pairs for r in req_ids) for t in tst_ids] + [len(pairs)])

print(open("matrix.csv", encoding="utf-8").read())

実行結果（matrix.csv の内容）

要件ID,TST-IT-001,TST-IT-002,TST-IT-003,TST-IT-004,TST-IT-005,TST-IT-006,TST-IT-007,TST-ST-001,TST-ST-002,TST-ST-003,件数
REQ-F-001,○,○,,,,,,,,,2
REQ-F-002,,,○,○,,,,,,,2
REQ-F-003,,,,,○,,○,,,,2
REQ-F-004,,,,,,○,,,,,1
REQ-F-005,,,,,,,,,,,0
REQ-F-006,,,,,,,,,,,0
REQ-N-001,,,,,,,,○,,,1
REQ-N-002,,,,,,,,,,,0
件数,1,1,1,1,1,1,1,1,0,0,8

右端が0の3行（REQ-F-005、REQ-F-006、REQ-N-002）と、下端が0の2列（TST-ST-002、TST-ST-003）は、前の節の結果と一致しています。行と列を台帳から作っているので、対応表に1行も無い REQ-F-006 も0件の行として現れます。 設計×テスト、要件×設計の表がほしいときは、読み込む台帳と列名を入れ替えれば同じコードで作れます。

仕様変更時に影響範囲を逆引きする手順

対応表がいちばん役に立つのは、仕様変更のときです。手順は次の5つです。

1. 変更するIDを決める。 「予約テーブルに列を足す」なら DSN-TBL-001、「予約の条件を変える」なら REQ-F-002 です
2. 対応表をそのIDで絞り込む。 表計算ソフトならフィルター、コードなら下のスクリプトを使います
3. 同じ行にある他のIDを重複なしで拾う。 これが影響範囲の候補です
4. 候補を1件ずつ確かめ、直すもの・再テストするものを決める。 候補は「関係がある」ことを示すだけなので、直す必要があるかは内容を見て判断します
5. 変更に合わせて台帳と対応表を更新する。 追加した要件・設計・テストの行を足し、網羅率を計算し直します

手順2〜3を行うコードです。

impact.py

import csv
import sys

with open("trace.csv", encoding="utf-8", newline="") as f:
    links = list(csv.DictReader(f))

def impact(target):
    column = {"REQ": "要件ID", "DSN": "設計ID", "TST": "テストID"}[target.split("-")[0]]
    rows = [r for r in links if r[column] == target]
    print(f"{target} を含む行: {len(rows)}行")
    for label in ("要件ID", "設計ID", "テストID"):
        if label == column:
            continue
        ids = sorted({r[label] for r in rows if r[label]})
        print(f"  影響する{label[:-2]}: {', '.join(ids) if ids else '（なし）'}")

for target in sys.argv[1:]:
    impact(target)

実行結果

$ python3 impact.py DSN-TBL-001 REQ-F-002 TST-IT-005
DSN-TBL-001 を含む行: 3行
  影響する要件: REQ-F-002, REQ-F-003, REQ-F-004
  影響するテスト: TST-IT-003, TST-IT-005, TST-IT-006
REQ-F-002 を含む行: 5行
  影響する設計: DSN-API-002, DSN-SCR-002, DSN-TBL-001
  影響するテスト: TST-IT-003, TST-IT-004
TST-IT-005 を含む行: 3行
  影響する要件: REQ-F-003
  影響する設計: DSN-API-003, DSN-SCR-003, DSN-TBL-001

3つの読み方ができます。

IDの先頭（REQ・DSN・TST）で列を決めているので、採番ルールをそろえておくと、このような逆引きが短いコードで書けます。

よくあるつまずきと直し方

よくある質問

Q. トレーサビリティマトリクスと対応表は別のものですか？ A. 目的は同じで、形が違います。IDの組を1行ずつ書く縦持ちを対応表、行と列にIDを並べて○を付ける横持ちをマトリクスと呼び分けることが多いです。縦持ちを原本にし、横持ちは必要なときに作ると、内容のずれを防げます。

Q. 設計を飛ばして、要件とテストだけをひも付けてもよいですか？ A. 小さな開発では、要件×テストだけでも十分に役立ちます。設計IDの列を持っておくと、仕様変更のときに「どの設計を直すか」まで逆引きできるので、設計書にIDを振っているなら3列にするのがおすすめです。

Q. 網羅率は何%を目指せばよいですか？ A. 決まった数字はありません。優先度の高い要件は100%を目標にし、残りは「次の版に回す」「対象から外す」などの理由が1件ずつ書かれていれば、数字が100%でなくても説明できます。割合だけでなく、抜けの一覧を一緒に見ることが大切です。

Q. どのくらいの頻度で更新しますか？ A. 要件・設計・テストのどれかを変えたときに、同じ変更の中で対応表も直すのが確実です。掲載したコードのように検査を自動にしておくと、レビューのたびに数秒で抜けを確かめられます。

まとめ

• トレーサビリティマトリクスは、要件ID・設計ID・テストIDをひも付けて、両方向にたどれるようにした対応表
• 前方（要件→テスト）で作り漏れとテスト漏れ、後方（テスト→要件）で根拠の無い設計・テストが見つかる
• IDは 「種類-区分-連番」でそろえ、欠番を再利用せず、一度決めたら変えない
• 原本は縦持ち（1行1組）で管理し、横持ちの○表は縦持ちから作る
• 網羅率は ひも付けのあるIDの数 ÷ 台帳の件数。分母を対応表にすると、書き忘れた要件が数字に現れない
• 例の8要件・10設計・10テストでは、設計の無い要件2件、テストの無い要件3件、要件に戻れない設計1件・テスト2件が見つかった
• 仕様変更では、変更するIDで対応表を絞り込み、同じ行のIDを影響範囲の候補として拾う

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