要件トレーサビリティ表の作り方｜要件・設計・テストをIDでつなぐ
要件はあるのに、どの設計で実現し、どのテストで確認するのか分からない。変更が入るたびに関係者へ聞き回る。こうした状況では、要件トレーサビリティ表で成果物同士の対応を残します。この記事では、要件・設計・テストをIDでつなぐ最小構成と、未対応の行の点検方法を説明します。要件の良し悪しではなく、決めた要件が最後まで追跡できるかを見る表です。
一つの要件に一つのテストとは限らない
要件には変更しても識別できるIDを付けます。行番号やページ番号だけでは、並べ替えや改版で対応が崩れるためです。IDを再利用せず、廃止した要件も理由を残します。一つの要件が複数の設計・テストへ対応することも、一つの設計が複数の要件を満たすこともあります。無理に一対一にそろえると、例外条件の確認が表から消えます。
要件・設計・テストをつなぐ記入例
社内申請画面の説明用の例です。文書名だけでなく、該当項目と版まで確認できる参照先を用意します。
| 要件ID・内容 | 設計ID | テストID・観点 | 状態・次の確認 |
|---|---|---|---|
| REQ-01 必須項目が空なら送信できない | DES-02 入力検証 v1.2 | T-01 空欄、T-02 入力後の再送信 | 設計対応済み・テスト未実施 |
| REQ-02 自分の申請履歴を見られる | DES-04 履歴表示 v1.1 | T-03 自分の履歴、T-04 他人の履歴を閲覧できない | 実施済み・結果の再確認待ち |
| REQ-03 承認者を部署別に選択する | 未対応 | 未対応 | 要件合意済み・設計担当へ確認 |
テストIDがあることと、テストに合格したことは別です。「紐づけ済み」「実施済み」「合格」を区別します。結果の証跡は、表に大量の画像を貼るより、権限を確認した保管先へリンクすると追跡しやすくなります。
表の穴を両方向から点検する
まず要件を起点に、設計とテストが存在するかを確認します。未対応なら、作業漏れ、対象外への変更、要件の未確定など理由を区別し、担当と確認日を入れます。次に設計やテストを起点に、どの要件のために存在するかを確認します。対応先がない作業がすべて不要とは限りません。共通のセキュリティ基準や運用要件など、機能以外の根拠があるなら参照IDを追加します。空欄をなくすために適当なIDを埋めてはいけません。「対応未確認」を見える状態にした方が、実際の漏れを修正できます。
変更時は対応先と確認範囲を更新する
REQ-02に履歴の保存期間を追加する場合、表示だけでなくデータ保持、削除処理、権限、関連テストへの影響を確認します。表に載っている対応先だけで影響範囲を断定せず、設計者と運用担当にも確認します。変更履歴には旧版・新版、変更理由、再確認する成果物、承認の参照を残します。過去に合格したテストを、新要件でも合格した扱いにしないことが重要です。対象外になった要件は削除せず、廃止状態と判断根拠を保存します。最新版と過去の承認版が混ざらないよう、表自体にも版と更新日を付けます。
最小構成で始め、更新を作業に組み込む
最初から全成果物を細かく追跡する必要はありません。変更の影響が大きい要件から始め、管理範囲を明記します。一部だけ管理している表を「全要件の確認済み一覧」と説明しないようにします。更新をPMOだけに集めるとは限りません。要件担当、設計担当、テスト担当がそれぞれ更新し、PMOが未対応や版の不整合を点検する方法もあります。要件変更やレビューの終了条件に表の更新を含めると、記録が取り残されにくくなります。使う列は、要件ID・名称・版、設計ID・版、テストID、対応状態、結果、証跡参照、未対応理由、担当、期限です。表の価値は行数ではなく、変更時に「どこを誰が確認すべきか」が分かることです。
次に確認したい実務ガイド
PMO実務テンプレート・確認表の一覧から、目的に合う記事を探せます。
参考情報とこの記事の位置づけ
要件と作業・テストを対応させる行列の考え方を確認しました。IDと表の例は独自作成です。 Atlassian：Requirements Traceability Matrix（確認日：2026年10月11日）。記入例・確認表は当サイトが説明用に作成したもので、実在の案件・実績ではありません。
課題管理表の作り方も必要な作業に合わせて参照してください。
アイキャッチ写真：Gabriel Cox / Unsplash。職場の実写ではなくイメージ写真です。
