要件・設計・実装・テストをつなぐ

このレッスンの到達目標

変更の目的から、確認結果までをたどれるようにする。

音声とインタラクティブ図解で学ぶ音声を再生すると、下のインタラクティブ図解と本文の段落ハイライトが連動して動きます。

TRACEABILITY & IMPACT MAP · AUDIO & INTERACTIVE

要件変更の波及ルートとトレーサビリティ検証シミュレーター

「画面だけ直して夜間バッチや請求帳票が旧計算のまま」になる事故を防ぐため、変更シナリオごとの影響範囲と回帰テスト対象を可視化します。

変更内容と成果物の追跡⚠️ 画面だけ変更（不整合）

受注画面の値引き率だけを変更し、夜間バッチ・請求帳票・期待値テストの更新を忘れた状態です。

検証結果・影響診断画面表示は2,703円ですが、夜間バッチ再計算で3,003円に戻り、請求書と食い違います。

要件IDと設計・画面・バッチ・テストを対応づけることで、仕様変更時にどこまで再確認すべきかを漏れなく特定できます。

要件では利用者の課題と必要な条件を明らかにし、設計では実現方法を決め、実装では動く仕組みを作り、テストでは定めた条件を満たすか確認します。資料の枚数ではなく、判断ができる内容かを見ます。

「取引先別に値引きしたい」という要件は、適用条件、計算式、入力、保存、帳票への反映、テストの期待値へつながります。どこかだけを変更すると、別の成果物と食い違います。

作業を始める前に、何ができれば完了かを決めます。コードの存在だけでなく、レビュー、異常系テスト、関連資料の更新などを必要に応じて含めます。

要件IDと設計・コード・テストの対応を記録すると、変更時に調べる対象を探せます。これをトレーサビリティと呼びます。対応があることに加え、内容の整合も確認します。

要件R01「対象取引先を値引きする」に対し、設計D01「共通計算」、実装の対象箇所、テストT01「対象・非対象の確認」を対応させてみます。対象期間が変わったら、どこを調べる必要があるかを挙げてください。

対応は一対一とは限りません。一つの要件を画面・バッチ・帳票で実現する場合や、一つの共通部品が複数要件に関係する場合もあります。

読了記録と習熟度の確認は別です。