要件トレーサビリティとは、要件から設計、実装、テストへ関係をたどり、変更がどこへ影響するかを確認できる状態です。対象は、画面、API、データ、権限と、変更後の検証結果までです。
要件IDとテストケースIDを並べた表がある。作成した時点では整っている。それでも、変更が入った後に誰も更新しなければ、その表が示すのは過去の対応関係です。
一度作った対応表は、変更とともに更新されて初めて現在の影響範囲を示します。ID、関係、版、検証結果、更新担当と更新契機が、変更影響を追える状態の五つの確認点です。
- 要件と各成果物を固有のIDで区別できる
- 上流と下流の関係を双方向にたどれる
- 現在の版と変更内容を確認できる
- 変更後の検証結果へ戻れる
- 誰がどの変更をきっかけに更新するか決まっている
要件から検証へ
追跡対象にIDを付ける
名前だけで成果物を結ぶと、似た画面や同名の処理が増えたときに区別できません。要件、画面、API、データ、権限、テストへ固有のIDを付けると、どの成果物を指しているかを固定できます。
ただし、IDだけでは足りません。例としてREQ-07とTEST-14が存在していても、両者の関係が記録されていなければ変更影響は追えません。追跡に必要なのは識別子と関係の組です。
上流と下流を双方向にたどる
TestRailの解説は、要件からテストケースと結果へ、反対方向にも関連付ける考え方を説明しています。要件変更時に関連するテストを更新する例も示されています。[1]
追跡先はテストだけではありません。要件から画面、API、データ、権限、テストへ進む方向と、障害が起きた画面からAPI、ルール、元の要件へ戻る方向を扱います。
下流へたどると変更候補を洗い出せます。上流へ戻ると、その実装が何のために存在するかを確認できます。片方向だけでは、変更箇所か変更理由の一方を見落としやすくなります。
例として、出荷指示後の納品予定日変更を考えます。業務要件を変えると、入力画面の活性条件、更新API、変更を拒否する業務ルール、操作権限、監査記録、回帰テストが影響候補になります。要件とテストの二点だけを結んでも、この変更の全体は追えません。
変更時に更新する五つの項目
上の五つの確認点を変更後も保つため、変更要求を受けたら次の五項目を同じ記録へそろえます。
- 01変更の起点
どの要求、障害、制度変更から始まったか。 - 02影響先
どの画面、API、データ、権限、テストを確認するか。 - 03変更内容と版
何がどの状態から変わり、現在どの版か。 - 04再検証結果
何を確認し、合格、不合格、未確認のどれか。 - 05更新担当と契機
誰が、どの完了条件に合わせて関係を更新するか。
この例では、変更要求を起点に六つの成果物を影響候補へ置き、成果物ごとに版と再検証結果を更新します。担当者を置かなければ、テストが終わっても関係表だけが古い版に残ります。
要件トレーサビリティマトリクスの最小例
対象が小さく、変更頻度が低い案件は、Excelなどの表から始められます。先に更新担当と更新契機を決め、成果物の変更と同時に表を更新します。TestRailの解説も、表計算による基本的なマトリクスの作り方と、成果物の変更に合わせて更新する必要を説明しています。[1]
小規模な対象では、要件IDを起点に、関連成果物、現在の版、再検証結果、更新担当と契機を並べるところから始められます。次の表は、納品予定日変更ルールの記入例です。
| 要件ID | 関連成果物 | 現在の版 | 再検証 | 更新担当・契機 |
|---|---|---|---|---|
| REQ-07 | SCR-12 | v1.3 | 合格 | 画面設計担当・画面定義完了時 |
| REQ-07 | ROLE-03 | v1.1 | 合格 | 権限設計担当・権限レビュー完了時 |
| REQ-07 | API-04 | v2.1 | 合格 | API担当・API定義更新時 |
| REQ-07 | RULE-03 | v2.0 | 未確認 | 業務責任者・業務ルール承認時 |
| REQ-07 | TEST-14 | v1.4 | 業務確認待ち | テスト責任者・回帰テスト完了時 |
| REQ-07 | EV-22 | 未作成 | 証跡未登録 | 品質担当・全結果確定時 |
静的な表が陳腐化する条件
変更対象が増えると、同じ要件に複数の版と担当者が並びます。画面担当が自分の行を更新しても、業務ルールと証跡が旧版のままなら、要件単位では完了していません。更新が誰の完了条件にも入っていない、実装の版と表の版を照合できない、テスト結果への参照が切れている。このどれかが残ると、表は整って見えても現在の状態を示せません。
| 確認点 | 追跡できる状態 | 古くなりやすい状態 |
|---|---|---|
| 更新契機 | 変更要求の完了条件に更新を含む | 定例会の前だけ更新する |
| 版 | 成果物の版と関係の版を照合できる | 最新版という名前だけで管理する |
| 検証 | 対象ごとの結果へ戻れる | テスト済みという記号だけが残る |
表を使い続けるか、関係をシステムで管理するかは規模と変更頻度で決めます。道具を変える前に、誰がいつ更新するかを決めなければ、管理先を移しても同じ問題が残ります。
Formula AIのID相互参照
Formula AIでは、画面、API、ルールなどが固有のIDを持ち、画面が呼ぶAPI、ルールの出所、変更の起点までたどれる構造を採っています。変更時は、関連する実装と検証観点を同じ変更の単位で更新します。[2]
Formula AIのID相互参照をこの例のREQ-07へ当てはめると、画面、権限、API、業務ルール、テスト、検証証跡を影響候補として確認できます。各担当者は、自分が受け持つ成果物を変更の起点と再検証結果へ結び直します。
公開している成果物には、画面、API、DB、権限、テスト、各種設計書、検証証跡が含まれます。実際の成果物と形式は生成成果物の一覧で確認できます。[3]
よくある質問
- Excel、Jira、ALMのどこから始めますか
- 対象が小さく更新担当が一人なら、Excelで五項目をそろえるところから始められます。変更作業をJiraなどの課題管理ツールで追っている場合は、変更チケットを起点に成果物IDと検証結果を結びます。複数チームが同じ成果物を高い頻度で変更する段階では、関係と版を一元管理できるALMなどを検討します。同じ情報を三つの道具へ重複入力しないことが先です。
- 変更チケットには何を書けばよいですか
- 変更要求ID、変更した要件ID、影響を確認する成果物ID、変更前後の版、再検証結果へのリンク、関係を更新する担当者を持たせます。未確認の成果物が残る場合は、チケットを完了にせず、判断者と期限を置きます。
- マトリクスはいつ更新しますか
- 変更要求を登録したときに影響候補を置き、成果物を変更したときに版を更新し、再検証の完了時に結果を結びます。三つの更新を変更チケットの完了条件へ入れると、定例会の直前だけ表を直す運用を避けられます。
直近の変更チケット一件を五項目で書き直す
直近で完了した変更を一件選び、変更要求ID、影響先、版、再検証結果、更新担当と契機を埋めます。成果物IDや結果へのリンクが書けない欄は、そのまま空欄にします。
空欄を埋めるために誰へ確認するか決まれば、トレーサビリティは表の整備から運用の改善へ変わります。
AIで変更を生成する工程まで扱う場合は、AI駆動開発の統制チェックリストで権限、検証、公開の境界も確認できます。