2026.08.22 テスト

ITのトレーサビリティとは？要件から設計・実装・テストを紐付ける実装手順

ITの現場でトレーサビリティの問題が表面化するのは、たいてい変更要求が届いた瞬間です。「この仕様を変えると、どのテストをやり直せばいいのか」に即答できないとき、要件と成果物の紐付けが切れています。この記事では、IT開発におけるトレーサビリティを要件トレーサビリティに絞ります。扱うのは、前方向と後方向の追跡の違い、要件トレーサビリティマトリクス（RTM）の列構成と採番規則、Jira・Backlog・Gitでの紐付けの残し方、変更時に影響範囲を引き当てる手順です。あわせて、受託開発の検収や規格監査で求められる証跡の水準と、追跡を全要件に広げず部分適用で止めるべき条件も示します。製品ロットを追う製造業のトレーサビリティとは対象が別で、その線引きも扱います。

まとめ｜ITのトレーサビリティで先に決める識別子とリンクの単位

IT開発のトレーサビリティとは、要件・設計・コード・テストという成果物どうしを識別子で結び、どちらの向きからも相手をたどれる状態を指します。仕組みの核は単純で、要件に一意のIDを振り、設計書・課題・テストケース・コミットからそのIDを参照させる、それだけです。ツールを入れる前に決めるのは、要件IDの採番規則と、リンクを張る粒度の2点になります。

紐付けの向きは2つあります。要件から設計・実装・テストへ下っていく前方向の追跡は、仕様がどこまで実装されたか、テストされていない要件が残っていないかを示します。逆に、不具合やコードから要件へ遡る後方向の追跡は、その修正が何のための実装だったかを示す。この両方が成立して初めて双方向トレーサビリティと呼べます。CMMI-DEV v1.3 が要件管理のプラクティスとして双方向の維持を挙げているのも、片方向だけでは変更時の判断材料にならないためです。

実務上の分岐点は、全要件に追跡を張るかどうかにあります。医療機器の IEC 62304、車載の ISO 26262、航空機搭載の DO-178C のように規格が証跡を求める領域では全件が前提になりますが、社内業務システムの改修でそこまで揃えるのは過剰です。変更頻度が高い領域と、障害が事業に直結する領域だけに絞り、残りは課題管理ツールの標準機能で拾える範囲に留める。この部分適用が、更新されないまま形骸化したマトリクスを作らない現実解になります。

IT開発におけるトレーサビリティの定義と製造業の追跡との対象の違い

同じ「トレーサビリティ」でも、ITと製造業では追う対象が違います。まず何を何に結ぶのかを揃えないと、社内の会話がかみ合いません。

要件から設計・実装・テストへ前方向にたどる追跡の対象範囲と成果物

前方向の追跡は、要件定義書に書かれた1件の要求が、外部設計・内部設計・ソースコード・テストケースのどこに反映されたかを結ぶ経路です。結ぶ相手は工程ごとの成果物で、基本設計書の画面項目、詳細設計書の処理仕様、リポジトリのコミット、テスト管理表のテストケースIDが並びます。工程ごとにどんな成果物が出るかはシステム開発の7フェーズと成果物を整理した記事に譲りますが、追跡の設計では「工程の名前」ではなく「IDを持つ成果物」を単位に考えます。

ここで効くのが、要件1件に対して紐付く相手が複数になる点です。1つの要件が3つの設計項目と5つのテストケースに広がることは珍しくありません。逆に1つのテストケースが複数要件をまとめて検証することもある。多対多の関係になるため、階層構造ではなく対応表の形で持つのが定石です。ISO/IEC/IEEE 29148 の2018年版が、良い要求の特性として traceable（追跡可能）を挙げ、要求に識別子や出所などの属性を持たせるよう示しているのも、この対応表を成立させる前提を要求側に置いているからです。

不具合から要件へ後方向にたどる双方向トレーサビリティの成立条件

後方向の追跡は、コードや不具合票から「これは何のための実装か」を遡る経路にあたります。運用で効くのはこちら側です。障害が出たとき、該当モジュールがどの要件に由来し、その要件を出したのがどの部門かをたどれれば、修正可否の判断と関係者への確認が同じ導線で終わります。

双方向が成立する条件は2つあります。1つは、リンクが一方の成果物にだけ書かれていないこと。要件一覧にテストケースIDを並べるだけでは、テスト側から要件を引けません。もう1つは、リンクを持つ情報源が1つに定まっていることです。要件一覧・テスト管理表・課題管理ツールの3か所に別々の対応表があると、更新のたびにずれます。情報源を1つに寄せる設計はSSOT（信頼できる唯一の情報源）の考え方を扱った記事と同じ発想で、トレーサビリティはSSOTを要件管理に当てはめた実装形態と捉えると整理しやすくなります。

製造業のロット追跡と対象が分かれる理由と相互参照での線引き基準

製造業のトレーサビリティは、原材料のロット番号や製品のシリアル番号を軸に、いつどの工程を通ってどこへ出荷されたかを追う仕組みです。追う対象は物理的なモノで、目的はリコール時の回収範囲の絞り込みや原因究明にあります。牛肉や米の記録義務、医療機器のバーコード表示といった法制度が絡むのもこちら側で、詳細はトレーサビリティの意味と2種類・法制度を扱った記事にまとめています。

一方、IT開発で追うのは成果物どうしの対応関係で、法令ではなく契約や規格が要求の出所になります。ただし完全に無関係ではありません。製造業向けに生産管理システムを開発する案件では、「製品ロットを追跡する機能要件」自体をIT側のトレーサビリティで管理することになり、2つの追跡が入れ子になります。この場合、モノの追跡はシステムの機能、成果物の追跡は開発プロセスの管理と役割を分け、同じ表に混ぜないのが線引きの基準です。

要件トレーサビリティマトリクスの列構成と粒度を決める設計手順

対応関係を表にしたものが要件トレーサビリティマトリクス、略してRTMです。列の設計と粒度の決め方で、その後の維持コストがほぼ決まります。

マトリクスに置く列項目と要件IDの採番規則で決まる追跡の解像度

RTMの列は、要件を主キーにして各工程の成果物IDを横に並べる構成が基本になります。最小構成なら次の表の範囲で足ります。

列項目	入れる値の例	目的
要件ID	REQ-0142	追跡の主キー
要件概要	承認者の代理設定	表上での識別
出所	業務部門ヒアリング	後方向の遡り先
設計項目	BD-07-3	設計への反映確認
課題キー	PRJ-318	実装状況の参照
テストケースID	TC-221, TC-222	検証済みかの判定
状態	実装済み・検証待ち	抜けの可視化

採番規則で解像度が変わります。REQ-0142 のように連番だけを振ると並べ替えに強い反面、要件が属する機能領域が読めません。REQ-APPROVAL-014 のように領域を含めると、変更要求が来たときにIDの見た目だけで担当範囲を絞れます。どちらでも構いませんが、途中で規則を変えると過去分との突合が崩れるため、プロジェクト開始時に決めて動かさないでください。追加要件用の予備番号帯を空けておくと、後から挿入するときに詰まりません。

要件の粒度を機能単位へ揃えて紐付けの数を抑える分解の判断基準

RTMが重くなる原因の大半は、要件の粒度がばらついていることです。「勤怠管理機能」という粗い要件と「打刻時刻を秒まで保持する」という細かい要件が同じ表に並ぶと、リンク数が偏り、抜けの検出も効きません。

粒度を揃える基準は、テストケースを書ける最小の単位に落とすことです。1件の要件から少なくとも1本のテストが書けて、かつテストの合否で要件の充足を判定できる。この2条件を満たさない要件は粗すぎるか細かすぎます。実務では、外部設計で確定する画面・帳票・インターフェース単位に揃えると収まりが良く、設計成果物の粒度については外部設計と内部設計の違いと成果物を扱った記事が判断の下敷きになります。目安として、要件1件あたりのリンク先が10を超えるようなら分解が足りていません。

マトリクスの空欄が示すテスト漏れと要件なきテストの検出手順と対処

RTMの価値は、埋まっているセルではなく空いているセルにあります。見るべき空欄は次の3種類です。

テストケースID列が空の要件：仕様として合意したのに検証されていない。リリース判定で最初に潰す対象
設計項目列が空の要件：設計に落ちていない。実装が始まっていれば設計書との乖離が起きている
どの要件にも紐付かないテストケース：要件外の作り込みか、要件一覧への記載漏れのどちらか

3つ目は見落とされがちですが、放置するとテスト工数だけが膨らみます。要件側の記載漏れなら要件を追加し、要件外の作り込みなら仕様変更として扱うか、テストを削る。どちらかに寄せて宙ぶらりんにしないでください。なお空欄の解消は要件の充足を示すもので、コードのどこを通ったかまでは保証しません。実行経路の網羅はC0・C1・C2の網羅率と計測を扱った記事の指標で別に測る必要があり、RTMの充足率とカバレッジ率は別物として扱います。

課題管理ツールでトレーサビリティを実装する連携方式と運用ルール

RTMを表計算ソフトで作るか、課題管理ツールのリンク機能で持つか。ここは規模と変更頻度で分かれます。

JiraやBacklogの課題リンクとGit連携で紐付けを残す手順

課題管理ツールを情報源にする場合、手順は次の順序で組みます。

要件1件を課題1件として登録し、課題種別を「要件」など専用の型にする（既存の不具合・タスクと混ぜない）
設計・実装のタスクを子課題または関連課題として作り、要件課題へリンクする
コミットメッセージの先頭に課題キーを書く。JiraもBacklogも課題キーの記述でコミットやプルリクエストを課題へ結ぶ仕組みを備えている
テストケースを課題またはテスト管理ツールの項目として持ち、要件課題との間に検証リンクを張る
要件課題の一覧をリンク付きで抽出し、RTMの代わりに使う

この形なら、表を別途保守する手間が消えます。GitHub中心の体制なら、Issueを要件として使い、プルリクエスト本文の Closes #123 のような参照で紐付けを残す方法が同じ役割です。テスト結果まで含めて1つのツールで完結させたいなら、Azure DevOpsや、Polarion ALM・codebeamer・Jama Connectといった要件管理専用ツールが選択肢に入ります。

表計算での管理が破綻する要件数の目安とツールへ移す判断の分岐点

表計算ソフトのRTMは、要件が数十件で変更が少ないプロジェクトなら十分に回ります。破綻するのは、要件が数百件を超えたとき、複数人が同時に更新するとき、そして要件が頻繁に増減するときです。ファイルの版が分かれ、誰の手元が正なのか分からなくなった時点で追跡としては死んでいます。

移行の分岐点はシンプルに置けます。要件件数が3桁に乗る、更新者が3人以上になる、変更要求が月に何度も届く。このうち2つが当てはまるなら、課題管理ツール側にリンクを持たせた方が安く済みます。逆に、要件が固定された短期の改修案件で表計算から移すのは、移行コストのぶんだけ損です。ツールを入れること自体は目的にならないため、更新が回るかどうかで決めてください。

更新が止まるマトリクスを防ぐ記録のタイミングと担当者の決め方

RTMが形骸化する原因は、更新のタイミングを決めていないことに尽きます。「気づいた人が直す」は誰も直しません。記録の時点を成果物の完了条件に組み込むのが唯一の対策です。設計書のレビュー完了時に設計項目列を埋める、プルリクエストのマージ条件に課題キーの記述を含める、テストケース作成のレビューで要件リンクの有無を確認する。作業の完了判定に混ぜてしまえば、別途の更新作業が発生しません。

担当は、要件を書いた人ではなく各成果物を作った人に持たせます。設計者が設計リンクを、実装者がコミットの紐付けを、テスト担当がテストリンクを埋める。プロジェクトマネージャーが一人で全部を埋める体制は、規模が大きくなった瞬間に崩れます。週次で空欄の件数だけを見る担当を1人決めておくと、崩れかけた時点で気づけます。

変更要求が来たときに影響範囲を特定する追跡手順と回帰試験の選定

トレーサビリティが最も効くのが、変更要求への対応です。ここで手順を持っているかどうかが、見積もりの精度と手戻りの量を分けます。

変更対象の要件から関連するテストケースを引き当てる調査の順序

調査は要件IDを起点に、次の順で広げます。まず変更対象の要件を特定し、その要件に紐付く設計項目と実装課題を引く。次に、同じ設計項目を共有する別の要件がないかを見ます。ここは影響範囲が広がる典型的な経路です。共通部品や共有マスタに触れる変更ほど、直接の要件以外に波及します。最後に、洗い出した要件群に紐付くテストケースを合算して、再実施の候補一覧を作ります。

逆向きの確認も1回入れてください。変更で削除される要件があるなら、その要件だけを検証していたテストケースは廃止対象です。追加と削除の両方を出さないと、使われないテスト資産が溜まっていきます。工程全体でテストがどう積み上がるかはテスト工程の種類と流れ・V字モデルを扱った記事の構造が前提になります。

回帰テストの範囲をリンク情報で絞る判断基準と追跡だけでは足りない点

引き当てたテストケース一覧をそのまま全部流すなら、追跡を張った意味が半分になります。実務では優先度を付けて絞ります。変更した要件を直接検証するケースは必須、共有部品を経由して波及した要件のケースは業務影響の大きさで選別、そこから遠い領域は自動化済みのものだけ流す。この3段階で十分に回ります。範囲選定の考え方と自動化の判断はリグレッションテストの範囲選定と実施判断を扱った記事に整理しています。

ただし、リンク情報で絞れるのは「要件として認識されている影響」だけです。設定ファイルの共有、データベースの同一テーブルへの書き込み、非同期処理のタイミング依存といった、要件レベルに現れない結合は追跡表に出てきません。静的解析による呼び出し関係の確認や、結合テストの共通シナリオを一定量固定で流す運用を併用してください。RTMを万能な影響分析ツールとみなすと、ここで漏れます。

受託開発と監査対応でトレーサビリティを整える範囲と見送る場面

どこまで作り込むかの判断です。結論から言えば、規格監査が絡む案件は全件、通常の業務システム開発は部分適用で足ります。

受託開発の検収と責任分界で証跡が効く具体的な場面と残す記録の粒度

受託開発でトレーサビリティが金銭に直結するのは、検収と追加費用の交渉の場面です。要件定義書の各項目にIDが振られ、テストケースと結果が紐付いていれば、「合意した範囲は全て実装・検証済み」を一覧で示せます。逆に、後から出てきた要望が当初要件のどれにも紐付かないことも同じ表で示せるため、仕様変更として扱う根拠です。この一枚があるかないかで、検収時の押し問答の長さが変わります。

残す粒度は、要件ID・合意日・変更履歴・テスト結果の4点で足ります。設計の中間成果物まで全て証跡化すると保守が重くなるだけで、契約上の争点にはほとんど登場しません。当社では基幹システムの受託開発で要件定義の段階からこの対応表を作り、変更要求のたびに追加費用の有無を同じ表の上で判定する進め方を採っています。発注側で内製する場合も、この4点だけは先に決めておくと後が楽になります。

医療機器や車載の規格が求める双方向の証跡と監査での確認の観点

規格が絡む領域では、追跡は選択肢ではなく要求事項です。医療機器ソフトウェアの IEC 62304 は、ソフトウェア要求・アーキテクチャ・リスクコントロール手段・検証の間をたどれる状態を求めます。ISO 14971 のハザード分析から始まり、リスクコントロール手段がソフトウェア要求として実装され、その検証結果まで一本の線でつながることが審査の確認対象です。航空機搭載ソフトウェアの DO-178C、車載の ISO 26262 も同じ構造で、要求から検証までの対応付けを証跡として求めます。

監査で見られるのは、表が存在するかではなく、表と実体が一致しているかです。抜き取られた要件IDから設計書・コード・テスト結果を実際に開いて突き合わせる形が一般的で、後追いで作った表はここで露見します。開発と並行して記録が積み上がる仕組みになっていることが、事実上の合格条件になります。

全要件の追跡を見送るべき条件と部分適用で足りる小規模案件の見極め

ここでの判断は明確です。社内向け業務システムの改修や、要件が数十件規模の小さな案件で、規格監査も第三者検収も無いなら、全要件のRTMは作らないでください。作れば工数が増え、更新が止まり、実体とずれた表だけが残ります。投資として回収できません。

その場合の代替は、課題管理ツールの標準機能で拾える範囲に留めることです。要件を課題として登録し、コミットに課題キーを書く。これだけで後方向の追跡は成立し、コストはほぼゼロで済みます。部分適用に切り替える境界は次の条件で判定できます。

規格認証・第三者監査・官公庁案件のいずれかに該当する：全件で作る
要件が数百件規模、または多数の部門から要求が集まる：主要機能に限って作る
障害が事業停止や金銭賠償に直結する領域を含む：その領域だけ作る
上記のいずれにも当たらない：作らず、課題キーの記述ルールだけを徹底する

迷ったときは、その表を誰が読むのかを問うてください。読む人がいない表は、更新されないまま残る負債になります。

よくある質問

IT開発のトレーサビリティについて、要件管理やテストの担当者から寄せられることの多い質問をまとめました。

ITにおけるトレーサビリティとは何を指しますか？

要件・設計・ソースコード・テストケースといった開発の成果物どうしを識別子で結び、どちらの向きからも相手をたどれる状態を指します。要件から実装・テストへ下る前方向と、コードや不具合から要件へ遡る後方向の両方が成立していると、双方向トレーサビリティと呼ばれます。目的は、仕様の抜けを検出することと、変更が発生したときに影響範囲を引き当てることの2つです。製品の製造履歴を追う製造業のトレーサビリティとは、追う対象が異なります。

トレーサビリティマトリクスは何で作ればよいですか？

要件が数十件規模で更新者が少ないなら表計算ソフトで足ります。要件が3桁に乗る、更新者が3人以上、変更要求が頻繁に届く、のうち2つ以上が当てはまるなら、JiraやBacklogなどの課題管理ツールに要件専用の課題種別を作り、リンク機能で持たせる方が保守しやすい選択です。テスト結果まで一体で管理したい場合は、Azure DevOpsやPolarion ALM、codebeamer、Jama Connectといった要件管理向けの製品が候補になります。ツール選定より先に、要件IDの採番規則を決めてください。

アジャイル開発でも要件トレーサビリティは必要ですか？

必要な範囲は変わりますが、考え方は同じです。ユーザーストーリーを要件の単位と見なし、ストーリーに紐付くプルリクエストと受け入れテストをリンクさせれば、追跡としては成立します。スプリントごとに要件が変わる前提のため、固定的なRTMを別ファイルで維持するのは向きません。バックログのアイテムをそのまま追跡の主キーにして、コミットとテストを課題キーで結ぶ運用が現実的です。規格監査が絡む場合のみ、スプリント終了時に一覧を書き出して証跡として残します。

双方向トレーサビリティはどこまで維持すればよいですか？

維持の範囲は、変更の頻度と障害時の損害で決めます。規格認証や第三者監査がある領域は全要件が前提で、そうでない場合は主要機能や事業停止に直結する領域に絞って構いません。維持を続けるコツは、リンクの記録を成果物の完了条件に組み込むことです。設計レビューの完了条件、プルリクエストのマージ条件、テストケースのレビュー項目に含めれば、別作業としての更新が発生しません。全件を目指して更新が止まるより、範囲を絞って生きた状態を保つ方が価値があります。

製造業のトレーサビリティとITのトレーサビリティは同じ意味ですか？

語の意味は同じ「追跡可能性」ですが、対象が違います。製造業では原材料のロットや製品のシリアルという物理的なモノを追い、リコール時の回収範囲の特定や法令上の記録義務への対応が目的です。IT開発では要件と成果物の対応関係を追い、仕様の抜け検出と変更時の影響範囲特定が目的になります。製造業向けシステムを開発する案件では、モノの追跡機能そのものが要件になるため両方が同時に登場しますが、システムの機能と開発プロセスの管理として分けて扱います。