要件トレーサビリティとは｜変更の影響を追える5つの整理ポイント

はじめに

承認金額の上限を変更したい。画面の入力チェックは直したが、APIと夜間バッチには古い上限が残っていた。受け入れテストも、元の金額だけで実施していた。これは説明用の例だが、要件変更が複数の成果物に広がる状況は珍しくない。

要件を変更するとき、どの設計とテストを直すべきか追える状態が重要だ。要件トレーサビリティは、要求の根拠、要件、設計、実装、テストなどの対応をたどれるようにする考え方である。

本記事では、PMや業務担当者が開発担当者と共有しやすい5つの整理ポイントを紹介する。すべてを大きな管理表に詰め込むのではなく、変更を受け付けたときに必要な確認先を見つけられることを目標にする。

リンクを増やすより、双方向にたどれること

要件から設計とテストをたどると、実現方法と確認方法が分かる。逆に、ある設計やテストから要件へ戻れると、その作業が何のために必要なのかを確認できる。これが双方向の対応を持つ意味だ。

NASAのソフトウェアエンジニアリングハンドブックは、双方向トレーサビリティを扱い、小規模なプロジェクトでは表計算や文書でも管理できる一方、対応情報を最新に保つ必要があると説明している。NASAの個別要件を一般の業務システムにそのまま適用するのではなく、更新を続ける運用の重要性を参考にしたい。

リンクがあるだけでは十分ではない。古い設計や失効したテストを指していれば、変更の影響を誤って判断する。対応先の版、確認状態、更新担当まで含めて管理する。

変更の影響を追える5つの整理ポイント

以下は、承認ワークフローを例にした整理案である。IDや状態名は説明用であり、プロジェクトの管理方法に合わせて調整する。

1. 要件IDと根拠を固定する

要件ごとに安定したIDを付け、表の行番号や文書のページ番号だけで識別しない。並べ替えや文章の追加で番号が変わると、別資料の参照先がずれてしまう。

たとえばREQ-014を「申請金額に応じて承認者を決める」とし、業務ルールの根拠、合意した担当者、適用範囲を記録する。本文を変更しても、同じ要件の改訂ならIDを維持し、版や変更履歴で区別する。

一つの要件に複数の独立した条件を詰め込むと、どの条件が実装済みか分からなくなる。承認金額、代理承認、緊急時の例外などは、確認単位に合わせて分ける。ただし、細分化すること自体を目的にせず、レビューできる粒度を選ぶ。

2. 設計との対応を関係の種類で書く

要件に設計書のURLを一つ貼るだけでは、どの画面・API・バッチが対象か分かりにくい。成果物のIDと対象箇所を記録し、「実現する」「制約を受ける」などの関係も区別する。

承認金額の要件なら、入力画面、承認者判定API、夜間再判定バッチが関係するかもしれない。一つの要件に複数の設計が対応することも、複数の要件を一つの共通処理が実現することもある。一対一と決めつけない。

画面から設計書を開く場合にも、元の要件IDへ戻れるようにする。設計に対応する要件が見つからない場合は、不要な機能なのか、要件の記録漏れなのかを確認する。

3. テストと受け入れ条件を対応させる

テストIDを付けるだけでなく、どの要件のどの条件を確認するかを書く。「承認画面のテスト」といった大きな単位では、変更した上限金額を確認できたか判断しにくい。

金額条件なら、境界の直前、境界と同じ値、直後の値を例にして、期待する承認者を決める。画面だけでなくAPIからの登録も確認するのか、既存データに新しいルールを適用するのかも受け入れ条件に含める。

テストケースが存在することと、その版の実装で合格したことは別だ。実施結果、対象の版、実施日、未実施や失敗の状態を記録する。要件が変わった場合、過去の合格をそのまま最新の確認結果と扱わない。

4. 変更履歴と判断の根拠を残す

変更には、理由、変更前後、承認者、適用予定の版を記録する。「金額を修正」とだけ書くと、なぜ変えたのか、既存データに影響するのかを後から判断できない。

対応表から関連する設計とテストを抽出した後、通知、権限、外部連携、運用手順にも影響がないかを確認する。リンクのない箇所は検索候補から漏れるため、表だけで影響分析が完全になるとは考えない。

仕様変更のレビューでは、対応先の修正が必要か、不要ならその理由は何かを残す。APIの入力や応答が変わる場合は、OpenAPIの変更レビューの確認事項も対応付けるとよい。

5. 未対応・古い対応をレビューで見つける

一覧には「要確認」「対応中」「確認済み」などの状態と担当者を持たせる。未対応の要件、要件のない設計、テストのない条件、古い版へのリンクを定期的に確認する。

すべての要件に同じ量の記録を求めると更新が続かなくなることもある。まず影響の大きい業務、権限、金額、外部連携から対応を整え、対象外の範囲と理由を明示する。ただし、契約や開発標準で全件の対応が求められる場合は、その条件を優先する。

更新のタイミングも決める。変更依頼の受付、設計レビュー、テスト計画、リリース判断の各段階で、どの担当者が何を確認するかを書いておく。

対応表の記入例

次の表は、単一要件について確認先を整理する例だ。実際には一つのセルへすべて詰めず、複数の関係を別行やリンクで管理してもよい。

変更依頼を受けたときの確認手順

1. 対象の要件IDと、変更理由・範囲を確認する。
2. 対応する設計・実装・テスト・運用を洗い出す。
3. リンクがない周辺処理にも影響がないか確認する。
4. 修正する箇所と、修正不要の理由を記録する。
5. 対象版のテスト結果と未完了項目を確認し、リリースを判断する。

対応表は判断を助ける道具であり、確認そのものを代替しない。AIが影響候補を抽出する場合も、候補の根拠と未確認の範囲を残し、人が業務上の受け入れ条件を確認する。

まとめ

要件トレーサビリティで目指すのは、変更時に確認先を探し直さず、根拠まで戻れる状態だ。要件ID、設計、テスト、変更履歴、未対応箇所をつなぎ、対応情報を最新に保つ。

Kakusillなどの仕様書づくりの道具を選ぶ前にも、何を一つの要件とするか、どの成果物と結び付けるか、誰が更新するかを整理しておきたい。形式よりも、変更のたびに使える運用を作ることが重要である。