トレーサビリティマトリクスとは？要件トレーサビリティの表の作り方と活用を解説

トレーサビリティマトリクスとは：要件から設計・実装・テストまでを1行でたどる表

トレーサビリティマトリクスは、要件を行に、その要件を受けて作られる成果物を列に並べ、対応関係を一覧にした表です。IPA/SEC（ソフトウェア・エンジニアリング・センター）の「トレーサビリティ確保におけるソフト開発データからの効果検証 実施報告書」（2013年2月）は、用語の定義で、プロジェクトが「要件のすべてを正しく設計し、実装し、評価し、納入した」と保証するための仕組みであり、上位要件と下位要件、要件と下流の作業成果物との追跡可能性を「格子表（マトリクス）」に整理したものと説明しています。

IPAの資料は「マトリクス」と表記しているため、本記事もこの表記で統一し、「マトリックス」と書かれたものも同じものとして扱います。

同報告書は、ソフトウェアのトレーサビリティを二つに分けています。一つは、ソフトウェアの部品が製品にどう組み込まれているかを追う「製品に関するトレーサビリティ」、もう一つは、ソフトウェアの要件が製品のどの部分で実現されているかを追い、逆に構成部品がどの要件のためにあるかを追う「文書及びデータに関するトレーサビリティ」です。本記事で扱うトレーサビリティマトリクスは、後者に当たります。

同報告書は、ソフトウェアの品質保証で担保が求められる要素として、システム設計が要求仕様を満たしていること、実装がシステム設計に合っていること、要求仕様がシステムテストで確認されることなどを挙げ、これを開発工程のV字モデルの図で示しています。V字の左側で要求仕様から詳細設計、ソースコードへと書き下ろした内容が、右側の単体・結合・システム・受入の各検査で確かめられているかを、横につないで確認する考え方です。

トレーサビリティマトリクスは、このV字の左右と上下のつながりを一枚の表に写したものと言えます。同報告書によると、ソフトウェア開発では開発途中の仕様変更が多く、成果物どうしがどう影響し合っているかを把握しておくことで、一部を修正したときに影響を受ける箇所を特定でき、修正漏れを防げます。

上から下へ、下から上へ、両方向にたどれることが要になる

IPA社会基盤センターの「ユーザのための要件定義ガイド 第2版」（2019年12月）は、要件定義の成果物どうしの関係を管理する取り組みの例を紹介し、その効果を二つの方向で説明しています。上位の要求から下位の要求へたどって、要件定義した内容が抜け漏れなくシステム化要求に展開されているかを確かめるのが「フォワードトレーサビリティ管理」です。

逆に、下位の要求や実装された機能から上位へたどり、目的と結びついていないものを見つけて開発や維持の対象から外すのが「バックワードトレーサビリティ管理」です。

トレーサビリティマトリクスは、この両方向の確認を一つの表で行うための道具です。左から右へ読めば「この要件は実装されテストされたか」が分かり、右から左へ読めば「このテストやこの機能は何のためにあるのか」が分かります。どちらか一方だけでは、作り漏れか作りすぎのどちらかを見逃します。

製品の多機能化と派生開発で、追えないことのリスクが大きくなる

トレーサビリティマトリクスは、製造業の製品開発にも関わる手法です。前述のIPA/SECの報告書は、組込み製品の多機能化・多様化に伴ってソフトウェアが肥大化・複雑化していることを挙げています。派生開発で一つの機能が複数の製品に展開されることも多く、ある機能で不具合が起きると、類似製品にも影響が広がる可能性があるとしています。

そのうえで同報告書は、ソフトウェアへの要求を的確に定義して製品に確実に作り込むこと、とくに欠陥の作り込みを予防することが重要で、そこにトレーサビリティが深く関わると述べています。どの要件がどの製品のどのモジュールに入っているかを追えなければ、不具合の影響範囲を絞り込めません。要件と成果物の対応を表で持っておくことは、この確認の出発点になります。

表に並べる項目：行に要件、列に各工程の成果物を置く

トレーサビリティマトリクスの基本の形は、行に要件、列に工程ごとの成果物を置く表です。IPA/SECの報告書は、表計算ソフトなどのオフィスソフトの機能でトレーサビリティを確保する例として、左端に基となる要件を書き、その右側に、要求仕様からシステム設計書、基本設計書、詳細設計書、ソースコード、各検査仕様書までの工程ごとに、要件に対応する内容を書き込む表を示しています。

列の数や名前はプロジェクトによって変わりますが、「要件を一意に指せる番号」と「それを受けた成果物の該当箇所」が並んでいれば、表として機能します。

下の表は、本記事で整理した列の構成例です。「上位の要求ID」の列は、下から上へたどって要件の根拠を確かめるために置きます。「テストの結果」の列があれば、表がそのままテストの進み具合の一覧になり、「変更の記録」の列があれば、いつ何が変わったために表を直したのかを後から確かめられます。最初からすべての列をそろえる必要はなく、要件ID、要件の内容、設計書、テストケースの4列から始めて、運用しながら足していく方法もあります。

発注する側と開発する側で、同じ表を見る

トレーサビリティマトリクスは、開発会社の中だけで使う表ではありません。IPAの「ユーザのための要件定義ガイド 第2版」は、システムを発注・利用する側の視点で要件定義の勘どころをまとめたもので、要求を台帳で管理し、ビジネス要求とシステム化要求の関係を後から追えるようにしておくことを、その一つとして挙げています。

同ガイドは、モデリング言語などで関係を図にすると、言葉だけで書くよりも利用する側と認識を合わせやすく、認識のずれが出にくいとしています。

社内の業務部門が出した要求がどの機能になり、どのテストで確かめられたかを、発注する側も同じ表で確かめられれば、受け入れのテストで何を見ればよいかがはっきりします。製品に組み込むソフトウェアを外部に委託する場合も、要求の番号と表の形式を契約の前にそろえておくと、納品物の確認がしやすくなります。

要求ごとに番号を振り、上位と下位を番号で結ぶ

表を成り立たせる前提は、要求一つひとつに番号があることです。IPAの「ユーザのための要件定義ガイド 第2版」は、トレーサビリティの節で、業務上の要求である「ビジネス要求」とシステムに求める「システム化要求」をそれぞれ台帳で管理し、要求ごとに項番（ID）を割り振ることが望ましいとしています。そのうえで、システム化要求の台帳の各行に、もとになったビジネス要求の番号を書き込んでいく方法を示しています。

同ガイドは、システム化しない要求についても、そのことが分かる情報をビジネス要求の台帳に残しておくよう勧めています。表の空欄が「まだ対応していない」のか「対応しないと決めた」のかを区別できるようにしておくと、後で見直す人が判断に迷わずに済みます。

性能や信頼性などの非機能要求も、同じ形の表で追える

画面や帳票の機能だけでなく、性能、信頼性、セキュリティといった非機能要求も表で追う対象になります。IPA/SECの「高信頼化ソフトウェアのための開発手法ガイドブック」（2011年3月）は、事例編で非機能要求のトレーサビリティマトリクスの様式を紹介しています。縦軸に非機能要求の項目、横軸に開発の工程を並べ、どのような非機能要求が求められているか、その達成をどう確かめるか、確かめた結果どうだったかを対応づける形です。

同ガイドブックは、この事例を、システムに組み込む他社のソフトウェアやハードウェアの製品に起因する重大な障害を予防することを狙いとした取り組みとして紹介しています。

同ガイドブックは、開発が進むと、採用した製品の制約から新しい非機能要求が見えてくる場合があり、そのときは表に項目を追加することを想定しているとしています。非機能要求は工程の途中で具体化しやすいため、最初から完成した表を作ろうとせず、行が増える前提で運用するのが現実的です。

作り方：設計書を書くのと同時に、1列ずつ埋めていく

トレーサビリティマトリクスは、設計が終わってからまとめて作るものではありません。IPA/SECの報告書は、表の作成は各設計書の作成と同時並行で行うことに意味があるとし、設計書の完成後に改めて作ろうとすると、設計書をもう一度見直すことになり、設計書の作成と同程度の工数がかかると考えられると述べています。

同報告書の例では、基本設計書を書き進めながら、参照したシステム設計書の項目の隣に対応する内容を埋めていき、基本設計書が完成した時点で、要求仕様から基本設計書までの対応が確保された状態になります。これを工程ごとに繰り返すことで、要求仕様からシステム検査仕様書までがつながります。以下は、IPAの資料に書かれた考え方をもとに、作業の順に並べた手順です。

手順1から5：要件定義からテストの結果まで

1. 要求を洗い出し、番号を振る。要件定義書や仕様書から要求を抜き出し、一つずつ番号を付けます。IPAの要件定義ガイドが勧めるように、業務上の要求とシステムに求める要求を分けて台帳にしておくと、後の対応づけがしやすくなります。
2. 上位の要求と下位の要求を結ぶ。システム化要求の行ごとに、もとになった業務上の要求の番号を書きます。どの要求にも結びつかない行と、どの行からも参照されない要求が、最初の確認の対象です。
3. 設計の段階で、設計書の該当箇所を書き込む。基本設計、詳細設計と進むたびに、要件を受けた章や項目の番号を対応する列に書き足します。
4. 実装とテストを結ぶ。要件を実現したモジュールや機能の名前と、要件を確かめるテストケースの番号を書きます。テストケースの番号が空いている要件は、テストの設計がまだ追いついていないということです。
5. テストの結果と変更を反映する。テストの合否と実施日を記録し、要件が変わったときは変更の記録を残したうえで、影響する列を更新します。

要件を変える申し出は、表で影響を見積もってから判断する

IPAの要件定義ガイドが紹介する事例では、承認された要求と要件にはベースライン（合意した基準の版）を設定し、以降の変更は変更要求の管理の手順を通してのみ行うルールにしています。この事例の流れでは、変更につながる項目を「変更要求リスト」で一覧にし、システムを作る目的に合っているか、効果にどれだけ役立つか、品質・費用・納期（QCD）にどれだけ影響するか、いつ実施するのが適切かを評価します。

QCDへの影響を評価する際には、変更が既存のシステムに及ぶ範囲を特定して見積もることが挙げられています。そのうえで、プロジェクトの管理者以上の責任者が実施するかどうかを承認し、承認した変更は関連する文書を更新して関係者に知らせ、ベースラインに取り込みます。

同ガイドは、修正が大規模になりそうな変更は担当者どうしで決めず、変更管理委員会（CCB）のようなプロジェクト全体の意思決定の場で採否を決めることや、変更管理は要件定義にとどまらず、開発や運用の段階でも続けるべきだということも述べています。影響範囲を特定する作業で使うのが、トレーサビリティマトリクスです。

変わる要件の行から、直すべき設計書の箇所とやり直すテストの数を数えて見積もりに添えれば、採否を判断する人が影響の大きさをつかみやすくなります。

表計算ソフトで始めるか、専用のツールを使うか

IPA/SECの報告書は、設計書どうしのトレーサビリティを確保する方法として、要件管理ツールの導入は選択肢の一つで早期の効果が期待できるとする一方、費用や習熟にかかる時間、扱えるファイル形式の制限といった問題がある場合もあると述べています。そのうえで、表計算ソフトで表を作る方法と、文書作成ソフトのコメント機能を使って上位の設計書の番号を各行に書き込み、表を別に作らずに対応を追う方法を例として示しています。

IPAの要件定義ガイドは、トレーサビリティの情報を手作業で作ろうとすると、どうしても漏れが起きる可能性が高くなるため、なるべく機械的に確かめられるようにすると精度が上がり時間も短くなるとしています。同ガイドは、UMLやSysMLといったモデリング言語を使い、ツールの機能でモデルどうしの関係をトレーサビリティマトリクスとして表示する例も紹介しています。

小さなプロジェクトは表計算ソフトで始め、要件の数や関係する文書が増えてきたらツールを検討する、という順に考えると判断しやすくなります。ツールを比べるときは、自社の要件の書き方や設計書の形式のまま取り込めるか、変更したときに関係する行をたどれるかを、実際の画面で確かめるのが確実です。2026年12月9日（水）・10日（木）に東京国際フォーラムで開催する「イプロスAI - 産業World 2026」では、設計や製品データを扱う企業も出展しており、出展企業情報から事前に確かめられます。

設計や製品開発のデータを扱う企業の講演も行われます。12月10日（木）10:45〜11:05には伊藤忠テクノソリューションズ株式会社による講演「『つくってから気づく』をなくす！ AI設計×デジタルツインで設計から生産準備までの手戻りを減らす！」、12月9日（水）14:15〜14:35にはPTCジャパン株式会社による講演「AIで、製品開発・製造・サービスはどこまで変わる？ ～製造業の『AI活用』を最新事例で解説～」があります。

使い方：抜け漏れ、変更の影響、テストの網羅を確かめる

トレーサビリティマトリクスは、作ること自体に価値があるわけではありません。表を見て判断する場面で使われてはじめて役に立ちます。ここでは、IPAの資料が挙げる効果をもとに、代表的な三つの使い方を説明します。

空欄から、作り漏れとテスト漏れを見つける

IPA/SECの報告書は、トレーサビリティマトリクスの利点として、表中の空欄が仕様や検査項目の漏れを表すため、仕様の網羅状況を簡単に確かめられることを挙げています。また、各設計書の記述をひと目で見比べられるので、不適切な記述や矛盾を見つけやすいとしています。

具体的には、要件の行で設計書やテストケースの列が空いていれば、作り漏れかテスト漏れの候補です。逆に、どの要件の行にも出てこない機能やテストがあれば、要件にない作り込みか、要件の書き漏れの候補になります。リリース判定の前にこの二つを確かめるだけでも、表を作った意味があります。下の表は、確認の結果を書き込んだ例です。

要件が変わったとき、直すべき文書とテストを洗い出す

IPAの要件定義ガイドは、要件定義の成果物は互いに関係していて、上位の成果物が変われば下位の成果物それぞれへの影響を見極めて正しく直す必要があり、その関係を何らかの方法で管理しておくことが、修正の作業漏れを防ぐ有効な手段になると述べています。同ガイドは別の節で、成果物の修正に抜け漏れがあると、高い確率で後の工程での障害の混入につながるとも指摘しています。

トレーサビリティマトリクスがあれば、変わった要件の行を右へたどるだけで、直すべき設計書の箇所と、やり直すべきテストケースが分かります。仕様変更の打ち合わせでその場で影響範囲を示せれば、変更を受け入れるかどうか、いつまでに対応できるかの判断も早くなります。

レビューの確認を短くし、品質を説明する根拠にする

IPA/SECの報告書は、工程ごとの成果物の対応が確保されると内容の確認が容易になり、レビューの時間を短くできると予測できるとしています。同報告書は、組込みソフトウェアの4件のプロジェクトの不具合データをもとに、トレーサビリティを確保するための工数（従来の作業工数の30%と仮定）と、設計が原因の不具合への対応にかかった工数を比べる試算も行っています。

4件とも合計では不具合への対応工数のほうが多く、たとえばあるプロジェクトでは、不具合への対応が922.45時間だったのに対し、トレーサビリティを確保する工数は516.50時間と見積もられました。ただし、別のプロジェクトでは、範囲を最も広げた段階でトレーサビリティを確保する工数のほうが多くなり、差が逆転しています。

同報告書は、トレーサビリティに要する工数によってはコスト増になることを示しているとしており、どこまで追うかによって効果は変わります。

同報告書の試算は検査仕様書とのつながりを対象にしていませんが、テストケースと結果の列まで持った表は、発注者や品質保証の担当者に「すべての要件がテストで確かめられている」ことを示す材料としても使えます。要件の数のうちテスト済みのものがいくつあるかを表から数えれば、進み具合を数字で伝えられます。

運用の注意点：更新が止まった表は、かえって判断を誤らせる

トレーサビリティマトリクスの弱点は、作ったあとに更新されなくなることです。IPA/SECの報告書は欠点として、表が各工程の設計書の内容を写して作るものであるため、元の設計書に変更があれば表も必ず直す必要があること、そして設計書どうしの関係が1対1なら分かりやすい一方、1対多になると関係が分かりにくくなることを挙げています。実態とずれた表は、空欄がないのに漏れがある、という誤った安心を生みます。

1対多の関係は、一つの要件が複数の設計箇所やテストに分かれる場合や、一つの機能が複数の要件を満たす場合に起きます。一つのセルに番号を並べて書くと、どの組み合わせが対応しているのかが読み取りにくくなります。要件を細かく分けて1行に一つの対応が来るようにするか、表計算ソフトのフィルター機能で特定の番号を含む行だけを抜き出せるよう番号を区切り文字で書くか、といった書き方のルールを、作り始める前に決めておくと読みやすさを保てます。

「文書どうしの整合がいつの間にか失われる」は、要件定義の現場から挙がった問題

IPAの「ユーザのための要件定義ガイド 第2版」は、作成にあたって、作業部会に参加したユーザ企業とベンダ企業の双方の委員から要件定義の問題をあらためて出してもらい、分類しています。その中には、「ドキュメント間の整合性がいつの間にか失われる」という「トレーサビリティ管理の問題」が挙がっています。同じ一覧には、成果物の抜け・漏れ・あいまいさや、要求調整・規模調整のコントロールができないといった問題も並んでいます。

要件定義書、設計書、テスト仕様書を、それぞれ別の担当者が別の時期に書く場合、一つずつは正しく書かれていても、要件の変更が一部の文書にしか反映されなければ、文書どうしの内容は少しずつずれていきます。トレーサビリティマトリクスは、このずれを個々の文書の中ではなく、文書と文書のあいだで見つけるための表です。

どこまで追うかを段階で考える

IPA/SECの報告書は、成果物どうしのトレーサビリティを取る範囲を5段階の「適用レベル」に分けて、試算を行っています。範囲が広がるほど成果物を作る工数は増えると推測される一方、成果物の品質が上がって検証工程での不具合が減ると考え、その差を評価の尺度にしています。同報告書は、品質向上の観点からはトレーサビリティはできるだけ広い範囲で確保するべきだが、プロジェクトで求められる品質と開発コストのバランスで範囲は変わるとしています。

粒度と範囲を決め、保守の手間を最初に見込む

同報告書は、トレーサビリティを確保していても、その精度や粒度といった質が設計の品質に影響するため、トレーサビリティの質にも配慮が必要だとしています。また、継続して開発されるソフトウェアではトレーサビリティの情報の保守が重要になり、開発の規模や管理の方法によっては専任の管理者が必要になる場合もあるため、そのコストもあらかじめ考えておく必要があると述べています。

すべての要件を細かな粒度で追おうとすると、更新の手間が膨らみ、いずれ続かなくなります。安全や法令に関わる要件、変更が多い要件、不具合が起きたときの影響が大きい要件から始め、どの粒度で追うかをプロジェクトの最初に決めておくと、続けやすくなります。前述の試算でも、追う範囲によって効果が変わっていました。

なお、同報告書の試算は設計が原因の不具合を対象にしたため、検査仕様書とのつながりは範囲から外しています。そのうえで同報告書は、一般に設計書とテストの仕様書のあいだのトレーサビリティもソフトウェアの品質の評価では重要だとしています。表を設計の列だけで止めず、テストケースと結果の列まで持つことで、リリースの判断に使える表になります。

番号の書き方をそろえ、更新を作業の手順に組み込む

IPAの要件定義ガイドが紹介する取り組みの例では、上位の文書に付けた番号を下位の文書に書き込んで結びつけ、番号をどの文書のどの位置に書くか、番号の付け方をどうするかといった規約を決めて、すべてのプロジェクトで標準化しています。ツールで関係を管理する場合も、文書からキーワードを読み取る部分の書式を定型にしておくことが必要だとしています。

表の更新は「気づいた人が直す」では続きません。要件の変更を承認したとき、設計書を改訂したとき、テストを実施したときに、誰が表のどの列を更新するかを、作業の手順の中に書いておくことが大切です。

製品や部品をたどる「トレーサビリティ」とは対象が違う

製造業で「トレーサビリティ」と言うと、部品や材料のロットから製品の出荷先までをたどる仕組みを指すことが多くあります。これは、要件と文書の対応を追うトレーサビリティマトリクスとは対象が違います。ただし、どちらも「後からたどれるように、番号で結んで記録しておく」という点は共通しています。製品や部品の追跡については「トレーサビリティとは？製造業での意味とシステムの仕組み、リコール・欧州規制への備えと導入手順を解説」で詳しく解説しています。

まとめ

トレーサビリティマトリクスは、要件と設計・実装・テストの対応を一つの表で追えるようにし、抜け漏れと変更の影響を確かめるための手法です。最後に要点を整理します。

• 行に要件、列に成果物を並べる。要求ごとに番号を振り、上位の要求、設計書の該当箇所、実装、テストケース、結果を同じ行に書きます。
• 設計書を書くのと同時に埋める。完成後にまとめて作ると、設計書をもう一度見直す手間がかかります。
• 空欄と、どこにも結びつかない行を見る。上から下へたどれば作り漏れとテスト漏れ、下から上へたどれば要件にない作り込みが見つかります。
• 要件の変更を判断する材料にする。変わる要件の行をたどって、直す文書とやり直すテストを数え、見積もりに添えます。発注する側と同じ表を見ておけば、受け入れのテストで確かめる範囲もはっきりします。
• 続けられる範囲と更新の手順を先に決める。重要な要件から始め、誰がいつどの列を直すかを作業の手順に組み込みます。