このユニットの結論
要件は、「どの業務の困りごとから生まれ、どの設計・連携・プログラム・テストで実現され、本番でどう確かめられたか」まで追跡できる必要があります。
要件一覧だけでは足りません。前後のつながりを残すことで、変更や障害が起きたときに、影響する場所を探せるようになります。
1. 何の話か
04-04 要件に番号を付ける理由 では、要件IDは「要件の住所」だと学びました。
このユニットでは、その住所を使って、要件をどこからどこまでたどるかを考えます。
2. なぜ必要か
約1,500件の要件がある大きなプロジェクトでは、次のような質問に答えられないと困ります。
- この要件は、なぜ必要になったのか（元の業務の困りごとは何か）
- この要件は、どの設計とプログラムで実現されたのか
- この要件は、どのテストで確かめたのか
- この要件を変えたら、どこに影響するのか
追跡できないと、テストの漏れ、変更の影響の見落とし、障害時の原因の探しにくさにつながります。
3. このユニットで分かること
- 要件を追跡する範囲（前方向と後方向）
- 追跡の表に何を残すか
- 追跡の確認で、AIが支援できることと人間が決めること
4. 前にたどる・後ろにたどる
- 業務の困りごと・要望
- 要件
- 設計
- 連携（IF）
- プログラム
- テスト
- 本番での確認
- 後ろ向きの追跡：要件から、元の業務の困りごとや要望にさかのぼる。「この要件は本当に必要か」を確かめるために使います。
- 前向きの追跡：要件から、設計・連携・プログラム・テストへ進む。「この要件は作られ、確かめられたか」を確かめるために使います。
両方向にたどれる状態を、一般的に双方向の追跡可能性と呼びます。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件の規模と関連する成果物
- 約1,500件の要件
- 約36本のシステム連携（正本で個別に定義されているのは IF-01〜IF-12 の12本）
- 成果物に REQ-002 要件一覧、REQ-004 要件追跡表、REQ-005 変更要求書、REQ-006 要件確定記録がある
アステリア案件の要件追跡表の実際の列や、どの粒度で追跡したかは、正本に記載がありません。未確定
5. 追跡の表に残すもの（一般的な例）
| 列 | 何を書くか |
|---|---|
| 要件ID | 要件の住所 |
| 出どころ | 元の要望、業務、決めた会議 |
| 設計 | 関係する設計書の該当箇所 |
| 連携 | 関係する連携（IF） |
| テスト | 要件を確かめるテストケース |
| 結果 | テストの合否と日付 |
| 変更履歴 | 変更要求の番号と内容 |
列の名前や細かさは、プロジェクトで決めます。大切なのは、空欄を放置しないことです。空欄は「まだつながっていない」ことを示すサインです。
6. THINK — テストの欄が空いている
要件追跡表を見ると、要件の2割で「テスト」の欄が空欄でした。テスト工程は来週終わる予定です。
問題
予定どおりテストを終えてよいでしょうか。
判断例を開く
判断
そのまま終えるのは危険です。
確認すること:
- 空欄の要件は、本当にテストされていないのか、記入漏れなのか
- 空欄の要件に、業務上重要なものが含まれていないか
- 対象外になった要件が、表に残っているだけではないか
空欄の理由を確かめてから、テストを終えてよいかを判断します。
7. よくある失敗
- 要件一覧と追跡表を別々に更新し、内容がずれる
- 要件が変わっても、追跡表の設計・テストの欄を更新しない
- 追跡の粒度が粗すぎて、どのテストがどの要件を確かめたか分からない
- 表を作ることが目的になり、確認に使われない
8. 成果物との接続
- REQ-004 要件追跡表：要件と設計・テストなどのつながりを残す
- REQ-002 要件一覧：追跡の起点になる
- REQ-005 変更要求書：要件が変わったときの記録
危機演習 CR01 要件定義が終わらない も、要件の管理を考える題材です（学習上の接続です。正式な対応関係ではありません）。
9. AI WORKFLOW — つながりの抜けを探させる
指示例:
「次の要件追跡表を確認し、①テスト欄が空欄の要件、②設計欄が空欄の要件、③変更履歴があるのにテスト結果の日付が変更より古い要件、を挙げてください。空欄の理由は推測せず、確認が必要な項目として示してください。」
AIは、大量の行から抜けを探す作業を速くできます。
10. REVIEW — AIの結果を確認する
- AIが挙げた抜けが、本当に抜けなのか（別の表で管理されていないか）
- AIが関係を推測で埋めていないか
- 古い版の表を見ていないか
ADVANCED深掘り — 実務者向けに一段深く
深掘り — 双方向の追跡と、カバレッジ率
前向きと後ろ向き
追跡には 2 つの向きがあります。要件から設計・テストへたどる前向きと、テストから要件へ戻る後ろ向きです。前向きで「テストのない要件」が見つかり、後ろ向きで「どの要件にも結びつかないテスト」が見つかります。どちらも、どこかで抜けが起きている印です。
カバレッジ率の読み方
テストに結びついた要件の数を、全要件の数で割ったものをカバレッジ率と呼びます。便利な数字ですが、「結びつきがあるか」しか見ていません。1 つの弱いテストが結びついていれば、その要件は数えられます。率が 100% でも、確かめ方が十分とは限りません。率と合わせて、重要な要件については「どのテストで、何を確かめるか」を個別に見ます。
粒度をそろえる
要件の 1 件とテストの 1 件の大きさがそろっていないと、追跡表は役に立ちません。大きすぎる要件（「請求業務を支援する」）は、追跡されていても確かめられません。要件を確かめられる大きさに分け、番号を振り直すのではなく、枝番で分けます（04-04）。
変わったときに印を付ける
要件が変わったら、結びついている設計・テストに「要確認」の印が自動で付く仕組みにします。人の記憶で追うと、約1,500件の要件の規模では必ず抜けます。
現場で確かめる問い
- テストに結びつかない要件と、要件に結びつかないテストを、最後に数えたのはいつか
- カバレッジ率の高い領域で、重要な要件のテストの中身を個別に見たことがあるか
- 追跡表の 1 行の大きさはそろっているか。確かめられないほど大きい要件はないか
- 要件が変わったとき、結びついた設計・テストに印が付く仕組みがあるか。人の記憶に頼っていないか
アステリア案件の追跡表の形式、カバレッジ率、更新の仕組みは、正本に記録がありません。記録なし
11. 人間が判断すること
- どの粒度で追跡するか
- 空欄の要件を、テスト対象に追加するか、対象外とするか
- 追跡の抜けがある状態で、次の工程へ進むか
12. 判断演習
本番で障害が起き、ある画面の処理が原因だと分かりました。
要件追跡表を使って、次のことを調べる手順を書いてください。
- その処理は、どの要件から作られたか
- その要件は、どのテストで確かめたか
- 同じ要件から作られた、ほかの処理はどこか
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
要件の追跡は、要件の前と後ろのつながりを残すことです。
空欄は「まだつながっていない」サインです。放置せずに理由を確かめます。