要件トレーサビリティマトリクスはなぜすぐ古びるのか
要件トレーサビリティマトリクス、すなわちRTMはそれ自体が十分に有用です。要件ごとにつながる設計・実装・テストを見つけられ、抜けた項目も表に現れます。問題は、表を最初に作った時点のつながりを、いまのつながりだと信じるときに生じます。
REQ-AUTH-014のパスワードポリシーがバージョン2からバージョン3へ変わったとします。テストTC-AUTH-007がいまもREQ-AUTH-014につながっているという事実だけでは、カバレッジが保たれたとは言えません。新しい長さ制限や例外条件、エラーメッセージをそのテストが反映したかを確認していなければ、リンクは存在しても古いリンクです。
NASA SWE-071もトレーサビリティマトリクスを時点固定の文書とは見ません。[2] プロジェクトが変わる間も更新し続け、要件が変わればどのテスト手順・ケース・スクリプト・データが影響を受けるかを探す道具として使います。したがってトレーサビリティ設計には三つが同時に必要です。何をつなぐかを決めるオブジェクトモデル、つながりの意味を区別するリンク種別、変更が起きたときにつながりを再検討する運用手順です。
何を追跡オブジェクトにすべきか
トレーサビリティは、すべての業務データを一か所に複製する作業ではありません。各システムに残るオブジェクトを安定した識別子とバージョンで参照できれば十分です。次の七つが最小単位です。
Release / Baseline Referenceはリリース承認の印ではありません。この表がどの要件・コード・テストのバージョンの上で作られたかを再現するための座標に近いものです。
オブジェクト | 役割 | 最小フィールド | このオブジェクトが答えるべき問い |
|---|---|---|---|
| Requirement | 実装し検証すべき現在の要件 | id, version, statement, source, acceptance_criteria, status, owner, updated_at | いま有効な要件は何で、どのバージョンか |
| Change | 要件がなぜ、何から何へ変わったかの記録 | id, reason, before_ref, after_ref, status, owner, captured_at | どの変更が発生し、変更の前後は何か |
| Implementation Artifact | 要件を実装するコード・API・DBスキーマ・設定・文書 | id, kind, location, revision, status, owner | どの成果物がこの要件を実装するか |
| Test | 要件をどの条件と結果で検証するかの記録 | id, revision, objective, preconditions, test_data_ref, expected_result, status, owner | どのテストがどの要件バージョンを検証するか |
| Defect | 検証または運用中に見つかった不一致 | id, summary, state, severity, source_ref, fix_ref, owner | 何がどの根拠で見つかり、どことつながるか |
| Release / Baseline Reference | ある時点の要件・実装・テスト集合を再現する参照 | id, requirement_set_revision, implementation_revision, test_catalog_revision, created_at | この追跡状態はどのバージョン集合を基準にするか |
| Change Package | 変更一件の影響検討とリンク更新をまとめる運用単位 | id, change_ref, target_baseline, impacted_objects, dispositions, orphan_result, freshness_result, reviewer, state | この変更で何を確認し、何が残っているか |
要件から承認までつながる根拠 — 要件、テスト、不具合対応、承認記録をつなぎ、共通の基準で品質を判断します。
表ではなくつながりの構造で見ると何が変わるか
認証要件が変わった状況をグラフに描いてみます。REQ-AUTH-014@v3がsupersedesでv2を置き換え、IMPL-auth-api@8f2aはimplementsで、TC-AUTH-007@v4はverifiesでそれぞれv3を指します。要件・実装・テストの三つはいずれもaffected_byでCHG-042につながります。DEF-088はfound_byでTC-AUTH-007@v4を指し、blocksでCP-042を押さえます。CP-042はCHG-042を対象変更、BASE-2026.08.3を対象ベースラインとし、そのベースラインはrequirements@v3、リビジョン8f2a、tests@v4を束ねます。
このグラフで重要なのはツールの画面ではありません。各つながりがどの関係で、どのバージョン同士のつながりで、どの変更で最後に検討されたかを読み取れることです。
リンクに名前を付けると何を説明できるか
リンク種別がなければ、つながりは一本の線にすぎません。名前が付いて初めて、その線をたどって何を確認すべきかが決まります。
すべての欠陥がテストで見つかるわけではありません。問い合わせや監視、コードレビューで出た欠陥に偽のfound_byリンクを作ってはいけません。その場合はsource_refに実際の発見根拠を残し、変更パッケージの影響オブジェクトにつなぎます。
blocksもリリース遮断の判定ではありません。ここでのblocksは、その欠陥の処理状態が整理されるまで変更影響検討パッケージを完了扱いにできない、という意味だけで使います。
リンク種別 | 方向 | 意味 | 検討する内容 |
|---|---|---|---|
| implements | Implementation Artifact → Requirement | その成果物が要件を実装する | 実装リビジョンが現在の要件バージョンと合うか |
| verifies | Test → Requirement | そのテストが要件を検証する | 条件・データ・期待結果が現在の要件を実際に確認するか |
| affected_by | Requirement・Implementation・Test・Defect → Change | そのオブジェクトが変更の影響検討対象である | 変更パッケージに処理結果と根拠があるか |
| found_by | Defect → Test | 欠陥がそのテストで見つかった | 再現可能なテストと欠陥がつながっているか |
| supersedes | 新しいRequirementまたはTestバージョン → 以前のバージョン | 新しいオブジェクトが以前のものを置き換える | 以前のオブジェクトが廃止・置換の状態で整理されたか |
| blocks | Defect → Change Package | 欠陥の処理が記録される前は変更パッケージを閉じられない | 修正・再現不可・別途移管などの状態と根拠が記録されたか |
双方向トレーサビリティは逆方向リンクを一本足す作業ではない
双方向とは、同じ関係を前からも後ろからも照会できるという意味です。TC-AUTH-007@v4がverifiesでREQ-AUTH-014@v3を指すリンクがあるなら、二つの問いに答えられなければなりません。この要件を検証するテストは何か、そしてこのテストはどの要件のどのバージョンを根拠に作られたかです。
順方向用の行と逆方向用の行を別々に保存する必要はありません。二行に分けて管理すると、片方だけが更新された瞬間につながりが矛盾します。リンクを一本だけ保存し、照会の向きを変えるほうが安全です。
関係が一対一である必要もありません。一つの要件を複数のテストが検証することもあり、一つの統合テストが複数の要件をまとめて検証することもあります。NASAの双方向トレーサビリティ指針も、こうした多対多の関係と孤立オブジェクトの検討を明示します。[1]
変更一件をどこまで確認したと言えるか
変更パッケージは圧縮ファイルの束でもデプロイパッケージでもありません。一つの変更が要件・実装・テスト・欠陥とリンクに残した影響を最後まで追うための検討単位です。
変更が入ったら、まず変更前後の要件バージョンを記録します。次に既存のリンクをたどって影響候補を集め、候補ごとに処理結果を指定します。内容を直すならupdate、再検討したうえで残すならretain、もう有効でないならretire、候補として見つかったが影響がないならnot_impactedです。retainとnot_impactedにも根拠が要ります。記録なしに状態だけ維持すると、検討して残したものと検討していないものを区別できません。
NASAの要件管理体系も、変更影響分析の結果と関連文書の更新措置を変更パッケージに含め、更新が終わるまで追跡させます。[4] 変わった要件だけでなく、関連する設計・コード・テスト・文書・追跡情報まで最新に保つよう求めます。ただし変更パッケージが閉じたということは、変更影響とリンクを定められた手順で検討したという意味であり、それ自体がリリース可否を示すものではありません。
確認項目 | 完了条件 |
|---|---|
| 変更の識別 | change_idと変更理由、要求者と所有者が記録されている |
| 変更前後の要件 | before_refとafter_refがバージョンまで識別されている |
| 影響候補の探索 | 要件から実装・テスト・欠陥へ、実装・テストから要件へ探索した |
| 実装成果物の検討 | すべての候補にupdate, retain, retire, not_impactedのいずれかと根拠がある |
| テストの検討 | 変更された要件を検証するテストのリビジョン・条件・期待結果を検討した |
| 欠陥の検討 | つながる未解決欠陥の状態と変更パッケージへの影響が記録されている |
| リンクの更新 | 追加・修正・削除・置換されたリンクと検討者が記録されている |
| 孤立の検出 | 定義された孤立ルールを実行し、結果を処理した |
| 鮮度の検討 | 関連リンクがpresent, reviewed, staleのいずれかに分類されている |
| ベースラインの固定 | 要件・実装・テスト集合の基準リビジョンが記録されている |
| 検討記録 | 所有者と検討者、検討時点、未解決の後続作業が残っている |
つながらない項目はどう扱うべきか
孤立項目が必ず誤ったデータだというわけではありません。ただし人が説明すべきつながりの空白です。自動検査は孤立を消したり任意のリンクを作ったりせず、検討待ち行列に上げるべきです。
NASA SWE-052も、出所のない設計や実装などの孤立要素を自動的に不要と断定しません。[1] チームが必要性を検討したうえで、抜けた上位根拠を追加するかオブジェクトを整理させます。
孤立ルール | 検出条件 | なぜ問題か | 必要な措置 |
|---|---|---|---|
| テストのない変更要件 | 現在の変更パッケージで変わったactive・検証可能な要件にreviewed状態のverifiesリンクがない | 新しい要件が検証体系から抜ける可能性がある | テストの追加・修正、または検証不要の根拠を記録 |
| 根拠のないテスト | activeなテストが現在有効な要件とも承認された別の根拠ともつながらない | 何を確認するテストか分からず、保守コストだけが残る | 要件とつなぐか根拠を補い、不要なら廃止 |
| つながらない欠陥 | 欠陥に実際の発見根拠がなく、関連する変更・テスト・影響オブジェクトも識別されない | 再現・修正・再検証の経路を見つけにくい | 実際のsource_ref、found_by、影響オブジェクトを補う |
| 影響検討のない変更 | 承認または実装された変更に変更パッケージがないか、候補の処理結果が未完了 | 一部のコード・テスト・文書が変更から抜ける可能性がある | 変更パッケージの作成と双方向の影響検討 |
| 廃止要件を検証し続けるテスト | activeなテストがretiredまたはsupersededな要件にのみつながる | テストは実行されるが現在の要件充足を説明できない | 新しい要件バージョンへ再接続・更新するかテストを廃止 |
リリース判断につながる検証 — 主要フローを検証し、実行結果と残る条件をリリース判断の根拠につなげます。
リンクがあることと信頼できることは別だ
リンクの状態を真偽一つで管理すると、真と記録された古いリンクが正常なつながりのように見えます。少なくとも三つの状態を分けるほうがよいでしょう。
次のいずれかが起きたらリンクを古い状態へ移します。要件が新しいバージョンに置き換えられたとき、テストの条件・データ・期待結果が修正されたとき、実装成果物のリビジョンが変わったとき、つなぐ相手が廃止または削除されたとき、現在の変更パッケージがリンクの端点を影響対象と判断したのにリンクの再検討が終わっていないとき、新しいベースラインができたのにそのベースラインでこのリンクが検討されていないときです。
古さを日付だけで判断する必要はありません。半年前に作られていても、両端のオブジェクトが変わらず現在のベースラインで再検討されていれば有効です。逆に昨日作ったリンクも、今日要件が置き換えられたなら古いリンクです。リンク記録一件には、link_id、from、type、to、作成情報、鮮度の状態、検討時点と検討者、検討文脈、両端のバージョン、古さの理由があれば十分です。
- present
- presentは両端のオブジェクトとリンク種別が存在する状態です。証跡はfrom、type、to、作成時点です。
- reviewed
- reviewedは現在の変更またはベースラインで両端のバージョンと関係の意味を検討した状態です。証跡は両端のバージョンとreviewed_at、reviewed_by、review_contextです。
- stale
- staleはリンクが指すオブジェクトや検討の文脈が変わり、現在の状態を説明できない状態です。証跡はstale_reasonと変わった端点、最後の検討文脈です。
追跡カバレッジとテスト合格率は何が違うか
追跡カバレッジは構造の完全性を見ます。テスト合格率は特定の実行の結果を見ます。検討済み追跡カバレッジは、検証可能な変更要件のうちreviewed状態のverifiesリンクが一本以上ある要件の比率であり、テスト合格率は今回の実行で行ったテストのうち合格した実行の比率です。
検証可能な変更要件が10件あり、検討済みのテストリンクを持つ要件が8件なら、追跡カバレッジは80%です。一方、テスト20件を実行して18件が合格したなら合格率は90%です。その90%は、つながっていない二つの要件を説明しません。逆に追跡カバレッジが100%でも、テストが実行された、あるいは合格したという意味にはなりません。リンク一本がその要件を十分に検証するかも、別に検討することです。
小さなチームは何から始めればよいか
最初から専用の要件管理プラットフォームを入れる必要はありません。NASA Software Engineering Handbookも、小規模プロジェクトではスプレッドシートや軽量マトリクスで要件・テスト・変更を管理できると説明します。[3] ツールより重要なのは固有の識別子とバージョン、関係、維持責任です。
最小の実装は六段階です。まずオブジェクト識別子を固定します。要件はREQ-、変更はCHG-、テストはTC-、欠陥はDEF-のように、ツールが変わっても残る形を使います。次にオブジェクトとリンクを分けます。要件の行の中にテスト識別子を文字列で足し続ける代わりに、from-type-to形式のリンク表を別に置きます。承認された変更ごとに変更パッケージを一つ開きます。規模が小さければ課題テンプレートやYAMLファイル一つでも構いません。PRやテスト、欠陥に関連する識別子を残し、実際の作業位置からも要件と変更を見つけられるようにします。存在しない識別子、許されないオブジェクト種別の組み合わせ、変更要件のテストリンクの欠落、廃止要件を指すテストを見る簡単な自動検査を付けます。最後に、再検討の周期を日付ではなく事象に合わせます。要件変更、テストリビジョンの変更、変更パッケージの終了、ベースラインの生成が検討を呼ぶ事象です。
複数の役割を一人が担っても構いません。ただしowner、reviewer、reviewed_atのフィールドは消さないほうがよいでしょう。役割が同じ人に集まっていても、どの責任で何を確認したかは残す必要があります。
ツールに縛られない最小レジストリ
レジストリ一つは四つのブロックで足ります。一つ目はベースラインです。識別子と要件集合リビジョン、実装リビジョン、テストカタログリビジョン、生成時点を持ちます。二つ目はオブジェクト一覧です。置き換えられた要件と現在の要件、変更、実装成果物、テスト、欠陥に、それぞれ種別・状態・所有者を付けます。三つ目はリンク一覧です。from、type、toに鮮度の状態と検討文脈を併記します。四つ目は変更パッケージです。対象変更と対象ベースライン、影響オブジェクトごとの処理結果と根拠、孤立検査の結果、鮮度の集計、検討者と検討時点を持ちます。
実際のリポジトリでは、オブジェクト情報が各業務ツールに残っていても構いません。このファイルはすべての原文を複製するデータベースではなく、オブジェクト識別子とリンク記録をつなぐ最小レジストリとして使えば十分です。
トレーサビリティが最後に差し出すものは何か
よく設計されたトレーサビリティは、要件ごとにテスト識別子が一つ入った表より多くを見せます。どの変更が発生したか、どの実装・テスト・欠陥が影響候補として見つかったか、各候補を修正・維持・廃止・影響なしと判断した根拠は何か、つながっていないオブジェクトは何か、存在するが今回の変更で再検討されていないリンクは何か、どの要件・実装・テストのバージョンの上でこの結果を再現できるか、です。
ここまで確認できれば、チームは変更のために見るべき範囲を説明できます。その候補のうちどの回帰テストを実際に実行するかは、別の選択規則が決めます。トレーサビリティだけでリリース可否が決まることもありません。トレーサビリティは、リリース判断に必要な証跡のうち、変更影響と検証のつながりの構造を担います。
