このユニットの結論
要件に番号を付ける理由は、一覧をきれいにするためではありません。
後から「この要件はどこで設計され、どこで実装され、どこでテストされたか」を追えるようにするためです。
要件IDは、要件の住所です。
1. 何の話か
アステリア刷新プロジェクトには約1,500件の要件があります。
これを、
- 請求処理
- 承認機能
- 会計連携
- 検索改善
のような名前だけで管理すると、同じような要件を区別できなくなります。
そこで各要件に一意なIDを付けます。
2. 名前だけでは何が困るのか
会議で、
「会計連携の要件を変更します」
と言われても、どの要件なのか分かりません。
さらに、
- どの設計書
- どの連携仕様
- どのプログラム
- どのテスト
が影響するのかも追いにくくなります。
3. 要件IDは「住所」
たとえば、
REQ-FUNC-0123
というIDがあるとします（教材上の例です。アステリア案件の要件ではありません）。
内容は、
承認済み取引をFIN-COREへ仕訳データとして連携する
です。
要件名が少し変更されても、IDが同じなら、
同じ要件の変更履歴
として追跡できます。
4. 要件は後工程へつながる
要件IDは、次のようにつながります。
- 要件
- 設計
- API・インターフェース
- 実装
- テスト
- 障害・変更
このつながりを追える状態を、
追跡可能性（Traceability）
と呼びます。
5. THINK — 要件が1行変わっただけ？
REQ-FUNC-0123
承認済み取引をFIN-COREへ仕訳データとして連携する
という要件が、
国内取引の承認済み取引のみをFIN-COREへ仕訳データとして連携する
へ変更されました。
問題
要件一覧の1行だけ直せばよいでしょうか。
判断例を開く
判断
いいえ。
確認候補には、
- 対象判定の設計
- データ項目
- 連携仕様
- プログラム
- テストケース
- 海外取引の処理
- エラー処理
- 運用手順
などがあります。
要件IDがあると、関連する成果物をたどりやすくなります。
6. IDがないと起こること
要件IDがないと、
- 古い設計を修正してしまう
- テスト対象から漏れる
- 変更影響を見落とす
- 同じ要件を別名で二重登録する
- 障害時に元要件まで戻れない
といった問題が起きます。
7. 成果物との接続
このユニットでは、
との接続を意識します。
正式な列名や詳細定義は、FROZEN正本に従います。
教材側で正本にない正式項目を勝手に増やしません。
8. IDを付ければ終わりではない
IDがあっても、
- 関連設計が登録されていない
- テストケースとの関係がない
- 変更履歴が更新されていない
なら、追跡できません。
つまり大切なのは、
番号そのものではなく、番号を使って関係を維持すること
です。
9. AI WORKFLOW — AIで影響箇所を探す
AIに、
- 変更対象の要件
- 要件一覧
- 設計一覧
- API・IF仕様
- テスト一覧
- 変更履歴
を渡すと、関連候補を整理できます。
指示例:
「REQ-FUNC-0123の変更影響候補を、設計、データ、連携、実装、テスト、運用に分けて整理してください。記載がない関係を確定事実として補完せず、推測は推測として分離してください。」
10. REVIEW — AIの関連候補を確認する
AIが関連ファイルを10件挙げたとしても、それだけでは確定しません。
確認すること:
- 正しい要件IDを見ているか
- 古い版ではないか
- 本当に依存関係があるか
- 逆に漏れている成果物はないか
- 推測を確定扱いしていないか
AIは検索を速くできます。
しかし、関係の正しさを最終確認するのは人間です。
ADVANCED深掘り — 実務者向けに一段深く
深掘り — ID の設計と、版の管理
ID には意味を持たせすぎない
ID に分類（機能・画面・連携）を含めると読みやすくなりますが、分類が変わったときに ID を変えたくなります。ID は一度付けたら変えない、が原則です。分類は ID とは別の欄で持ち、ID には変わらない部分（種類の区分と連番）だけを含めます。変えない ID があって初めて、変更の履歴がつながります。
ID と版を分ける
要件の内容が変わっても、ID は同じです。変わったのは「版」です。ID と版の番号を分けて持ち、「この設計は、この要件のどの版を見て作ったか」を残します。版を持たないと、設計が古い内容を見て作られていても気づけません。世界で共有されている考え方では、ID・版・状態をそろえて管理することを構成管理と呼び、ある時点の版の組を固定したものを基準線（ベースライン）と呼びます。
状態を持つ
要件には、草案・確認中・確定・変更中・廃止、のような状態があります。状態がないと、一覧のどれが合意済みでどれが途中かが分かりません。確定に移す操作は、決める権限のある人だけが行い、日付と人を残します。
分ける・まとめる・やめる
大きすぎる要件を分けるとき、元の ID に枝番を振るか（04-05）、新しい ID を振って元の ID を「分割済み、分割先はこれ」として廃止するか、どちらかに決めます。やめた要件は削除せず、廃止の状態と理由を残します。削除すると、その要件を見ていた設計やテストが行き先を失います。
測り方の例
- 版の番号を持たない要件の数
- 状態が「確定」の要件の割合と、確定した日と人が残っている割合
- 廃止の理由が残っていない要件の数
現場で確かめる問い
- ID に、変わりうる分類が含まれていないか。分類が変わったとき ID を変えたことはないか
- 要件の版の番号を持っているか。設計やテストが、どの版を見て作られたかが分かるか
- 要件の状態（草案・確定・廃止など）を持っているか。確定の操作は誰が行うか
- やめた要件を削除していないか。分割した要件の元と先がたどれるか
アステリア案件の要件 ID の体系、版の管理、状態の種類は、正本に記録がありません。記録なし
11. 人間が判断すること
人間が決めるのは、
- この変更を承認するか
- 影響範囲をどこまでとするか
- どのテストが必要か
- リリースに含めるか
- 関係部門へどう説明するか
です。
12. 判断演習
要件一覧に、
REQ-FUNC-0034 請求処理を高速化する
とだけ書かれていました。
※ REQ-FUNC-0034 は、REQ-FUNC-0123 と同じく教材上の架空の要件IDの例です。プロジェクト成果物のID（REQ-001〜REQ-006など）ではありません。
あなたなら、
- 何を「高速」と呼ぶのか
- 現在何秒なのか
- 何秒を目標にするのか
- 誰が困っているのか
- どの画面・処理が対象なのか
- どうテストするのか
を確認します。
IDがあっても、要件内容が曖昧なら良い要件にはなりません。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
要件IDの目的は、
要件を後工程まで追うこと。
変更が起きたとき、
「どこを直せばよいか」
を探せる状態を作ることです。