トレーサビリティ

定義

トレーサビリティとは、ソフトウェア開発の成果物間の対応関係を追跡可能にする仕組み。「要件 → 設計 → 実装 → テスト」の各工程で生まれる成果物が、どの要件を実現しているかを双方向に辿れる状態を指す。

代表的なツールはトレーサビリティマトリクス：

要件ID | 設計書章 | 実装クラス | テストケースID
  R-01  |  §3.2   | OrderService | TC-045, TC-046
  R-02  |  §3.4   | PaymentGateway | TC-089

なぜ重要か

要件とテストが対応していないと、「実装したが検証されていない機能」や「テストしているが要件に存在しない機能」が発生する。トレーサビリティがなければ要件の網羅性と変更影響範囲が把握できない。

V字モデルの構造を理解することで、トレーサビリティの確保が「いつ」「何と何の間で」必要かが明確になる。

V字モデルとトレーサビリティ

要件定義 ────────────────── システムテスト
    └─ 外部設計 ────────── 結合テスト
           └─ 内部設計 ── 単体テスト
                  └─ 実装

V字の左辺（定義・設計）と右辺（テスト）が対応している。トレーサビリティ確保の実践として「V字の両端から始める」：

1. まず要件定義とシステムテスト要件を対応付ける
2. 次に詳細設計と単体テストを対応付ける
3. 中間の工程は優先度に応じて段階的に整備する

この順序は「最も影響が大きい両端」を先に確保し、部分的な整備でも価値を生み出せるという実用的なアドバイス。

適用場面

• テスト計画時：要件一覧とテストケース一覧のマッピングを作成し、テスト漏れの要件を可視化する
• 変更管理時：要件変更が発生したとき、影響を受ける設計・実装・テストの範囲を即座に特定する（→構成管理）
• 工程完了判定時：「全要件がテストされているか」の確認をトレーサビリティマトリクスで行う
• 大規模プロジェクト：コンポーネント数が多いほどトレーサビリティの価値が増大する（品質マップとの組み合わせ）

注意点

トレーサビリティマトリクスは整備・維持コストがある。「まずV字の両端から始める」のは、全工程を一度に網羅しようとして挫折するリスクを避けるため。要件数・プロジェクト規模に応じて段階的に整備範囲を広げる。

出典

ソフトウェア品質保証の極意 — 第3章 3.4「構成管理」（極意22）、Column「W字モデル」