要求トレーサビリティマトリクス（RTM）とは：定義、テンプレート、事例

要求トレーサビリティマトリクス（RTM）とは、すべてのステークホルダー要求が、失われることも、重複することも、いつの間にか抜け落ちることもなく設計、開発、テストの各工程を通過したことを証明する唯一の文書です。誰も頼んでいない機能を出荷してしまったり、全員が期待していた機能を見落としたりした経験があるなら、きちんと維持されたRTMがその解決策です。

要求トレーサビリティマトリクスとは何ですか

要求トレーサビリティマトリクス（RTM）とは、通常は表形式の構造化された文書で、各ビジネス要求またはシステム要求を対応する設計仕様、コードモジュール、テストケースに結びつけるものです。「トレース」という言葉が鍵です。どの要求からもそのテスト結果までを前方に追跡でき、どのテストケースからも元のビジネスニーズまで後方に遡ることができ、その結びつきが途切れていないことを確認できます。

これは、プロジェクトスコープ記述書の元帳のようなものだと考えてください。スコープ記述書は何が範囲内で何が範囲外かを定義します。RTMは、スコープ内のすべての項目が実際に構築され検証されたかどうかを追跡します。

押さえておくべき主要用語：

• 要求ID： 各要求に割り当てられる一意の識別子（例：REQ-001）。
• ソース： その要求を生み出したステークホルダー、文書、または規制。
• トレーサビリティ： プロジェクトのライフサイクル全体を通じて、要求のライフサイクルを双方向に追跡できる能力。
• カバレッジ： 少なくとも1つのテストケースがリンクされている要求の割合。

重要な事実

• Standish GroupのCHAOSレポートは一貫して、要求が不明確または不完全であることがITプロジェクト失敗の主要因トップ3の一つであり、問題を抱えたプロジェクトの50%以上でコスト超過の一因になっていると指摘しています（Standish Group、2023年）。
• PMIのPulse of the Professionによると、成熟した実践を用いていない組織のうち37%で、不十分な要求管理がプロジェクト失敗の一因になっています（PMI、2022年）。
• IIBAのBABOKガイド（第3版）はトレーサビリティをビジネスアナリシスの中核タスクと位置づけ、それがプロジェクトライフサイクル全体を通じて影響分析、テスト計画、変更管理を支えると述べています（IIBA、2015年）。

要求トレーサビリティの種類

一般的に使われるトレーサビリティのアプローチは3種類あります。ほとんどのプロジェクトでは、この3つを同時に運用することで恩恵を受けられます。

多くのアジャイルチームは前方トレーサビリティから始め、テストスイートの拡大とともに後方カバレッジを追加します。規制対象の業界（医療機器、航空、金融ソフトウェア）では通常、最初から双方向トレーサビリティが義務付けられています。

RTMに含まれる項目

RTMの列はプロジェクトの種類によって異なりますが、次の項目セットはほとんどのソフトウェアやシステム導入プロジェクトをカバーします。

小規模プロジェクトでは列を絞り、複雑なプログラムでは列を増やして構いません。目標は、RTMを手にした誰もが、誰にも尋ねることなく「この要求はテストされたか」「どのテストがそれをカバーしているか」という2つの問いに答えられることです。

RTMが重要な理由

スコープクリープを防ぐ

すべての機能が文書化された要求に紐づいていれば、新しい作業が気づかれないまま紛れ込むことがはるかに難しくなります。スコープクリープについての議論は、「これを作るべきか」から「これはどの要求に対応するのか」へと変わります。この問いだけでも、中途半端な依頼の驚くほど多くを消し去ります。

変更管理を簡素化する

ステークホルダーが変更を依頼したとき、RTMはどのテストケース、設計仕様、コードモジュールが影響を受けるかを正確に示します。かつては1日がかりの会議を要した影響分析が、きちんと維持されたマトリクスがあれば20分で済むこともあります。

テストと承認を支える

開発からユーザー受け入れテストへと移行するチームは、書かれてはいるが一度もテストされていない要求というギャップにしばしば気づきます。RTMは、UATが始まる前に、その途中ではなく、こうしたギャップを表面化させます。

監査証跡を提供する

規制対象の業界では、監査人は承認済み仕様書のすべての要求に対応するテスト結果があることを確認したいと考えます。RTMがその証拠です。それがなければ、記憶を頼りに経緯を再構築することになり、それがうまくいくことはめったにありません。

要求トレーサビリティマトリクスの作り方

ステップ1：すべての要求を集める

プロジェクトスコープ記述書、ステークホルダーインタビュー、規制文書、承認済みのユーザーストーリーなど、あらゆる情報源から要求を集めます。他の何よりも先に、それぞれに一意のIDを割り当てましょう。IDの付与を省略すると、マトリクスの維持が不可能になります。

ステップ2：列構成を定義する

チームが実際に記入できる列を選びましょう。まずは絞り込むことです。全員が維持する6列のRTMは、誰も更新しない15列のバージョンよりもはるかに有用です。要求ID、説明、ソース、テストケースID、テストステータスがあれば、ほとんどのプロジェクトの基本をカバーできます。

ステップ3：要求を設計成果物にリンクする

各要求について、それに対応する設計文書のセクション、アーキテクチャ図の参照先、または技術仕様を記録します。まだ設計成果物が存在しない場合は、その行を「設計待ち」としてフラグを立てましょう。このフラグ自体が有用です。それは、何かがまだ開発に着手できる状態にないことをプロジェクトマネージャーに伝えます。

ステップ4：開発の作業項目にリンクする

各要求を、それが構築されているチケット、ユーザーストーリー、またはスプリントバックログ項目に結びつけます。Jira、Azure DevOps、あるいは共有スプレッドシートといったツールがこれらのリンクを保持できます。ワークブレークダウンストラクチャーは、このマッピングの自然な情報源です。

ステップ5：テストケースにリンクする

各要求について、それを検証するテストケースIDを記録します。ここで受け入れ基準を確認しましょう。テストケースは、受け入れ基準が満たされているかどうかを直接検証すべきです。要求にテストケースがなければ、それはカバレッジがないか、完全に見落とされているかのどちらかです。

ステップ6：テスト実行状況を追跡する

テストが進むにつれ、各行のテストステータス列を更新します。多くのチームは各テストサイクルの終わりにカバレッジレポートを実行します。合格ステータスの要求は何パーセントか、まだ不合格または未着手のものは何かを確認するのです。これがリリースの実行可否判断のインプットになります。

ステップ7：プロジェクト全体を通じて最新に保つ

最初に書かれただけで二度と手を加えられないRTMは、単なる飾りです。明確なオーナー（通常はビジネスアナリストまたはプロジェクトマネージャー）を割り当て、要求が変わったとき、テストケースが追加されたとき、設計上の決定がスコープに影響を与えたときに更新しましょう。一度きりの成果物ではなく、生きた登録簿として扱ってください。

RTMの例

顧客ログイン機能についての小さな実例を見てみましょう。

REQ-003が不合格ということは、メール配信の問題が解決されるか、要求が正式にスコープから外されるまで、リリースを進めるべきではないということです。RTMはその意思決定を可視化し、文書として残します。

ベストプラクティスとよくある間違い

ベストプラクティス：

• RTMを書く前に要求IDを割り当てる。後から番号を振ると、欠番や重複が発生します。
• ローカルのスプレッドシートではなく、共有ツールを使う。RTMが一人のデスクトップ上にしか存在しない場合、その人が休暇に入った瞬間に維持が止まります。
• すべてのスプリントレビューやプロジェクトのステージゲートでRTMを見直す。15分の確認で、ずれが積み重なる前に食い止められます。
• 非機能要求（パフォーマンス、セキュリティ、アクセシビリティ）を含める。これらは、本番インシデントを引き起こすまで忘れられがちな要求です。
• 各要求について受け入れ基準文書にリンクし、テスターが合格の基準を正確に把握できるようにする。

よくある間違い：

• テストできないほど曖昧な要求を書いてしまう。「システムは高速であるべきだ」はテストケースにトレースできません。「システムはリクエストの95%について2秒以内に検索結果を返さなければならない」ならトレースできます。
• RTMを一度きりの引き継ぎ文書として扱う。継続的に更新すべきであり、一度完成させて棚に上げるものではありません。
• 後方トレーサビリティを省略する。多くのチームは要求からテストへの前方追跡は行いますが、対応する要求のないテストが存在しないかを確認することはありません。この確認によって、スコープから外された機能のテストケースが取り除かれ、すべてのテストサイクルで時間を節約できます。
• テストステータスが実際のテスト状況に遅れる。テストがすでに実行され不合格になっているにもかかわらず「未着手」と表示されている行は、プロジェクトの健全性について誤った印象を与えます。

よくある質問

RTMと要求登録簿の違いは何ですか。

要求登録簿は、要求とその属性（ID、説明、オーナー、優先度）を一覧化し分類したものです。RTMはそのすべてに加えて、各要求を設計、開発、テストの各工程を通じてトレースします。RTMは、登録簿にトレーサビリティの層を加えたものです。

アジャイルプロジェクトにRTMは必要ですか。

アジャイルプロジェクトでもトレーサビリティは恩恵をもたらしますが、形式が異なることが多いです。正式なスプレッドシートの代わりに、多くのアジャイルチームはプロジェクトマネジメントツール（Jira、Azure DevOps）を使い、ユーザーストーリーをテストケースや受け入れ基準にリンクします。RTMの概念自体は同じで、成果物の見た目が異なるだけです。

RTMのオーナーは誰ですか。

通常はビジネスアナリストまたはプロジェクトマネージャーがRTMを所有し、開発者やテスターが貢献します。オーナーシップとは、すべての更新を一人で行うことではなく、最新の状態に保つ責任を負うことを意味します。規制対象の環境では、通常、RTM全体に対して名前の付いた承認者がいます。

RTMの構築はいつ始めるべきですか。

開発が始まった後ではなく、要求がベースライン化された時点ですぐに始めましょう。RTMの構築が遅れると、記憶を頼りにリンクを再構築することになり、時間がかかりミスも起きやすくなります。理想的には、要求の抽出段階で要求IDを割り当て、設計作業が始まる前にマトリクスへの記入を開始します。

RTMはソフトウェア以外のプロジェクトにも使えますか。

はい。建設、製造、製品開発のプロジェクトはいずれも、仕様をテストや検査結果に結びつけるためにトレーサビリティマトリクスを使います。列の内容は変わります（コードモジュールの代わりに設計図番号、自動テストケースの代わりに検査記録など）が、ロジックは同じです。

きちんと維持された要求トレーサビリティマトリクスは、納品中もローンチ後も時間を節約してくれる数少ないプロジェクト文書の一つです。要求が構築され検証されたかどうかについて、チームの全員に単一の信頼できる情報源を与え、プロジェクトのリーダーシップには十分な根拠に基づいてリリースの意思決定を下すための証拠を与えます。シンプルに始め、常に最新に保てば、その労力は何倍にもなって返ってきます。