これは何か
変更要求書は、一度決まった要件や範囲を変えたいときに、何を、なぜ、どう変えたいか、その影響は何かを書いて申請する成果物です（04-06 途中で要件が変わったらどうするのか）。
なぜ作るか
- 変更を口頭で済ませず、判断の材料をそろえる
- 影響（作業・費用・期間・他システム）を、判断の前に調べる
- 誰が、いつ、どの理由で変更を認めたかを残す
誰が使うか・いつ作るか
- 書く人：変更を求める人（業務部門・開発の担当・ベンダーなど）
- 影響を調べる人：要件・設計・テスト・移行の担当
- 判断する人：変更を承認する権限を持つ人
- 変更の必要が生じたときに作ります
- アステリア案件の変更の件数や、承認の手順は、正本に記載がありません。未確定
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 変更要求書の項目
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
| 項目 | 何を書くか | 書き方の例（教材上の例） |
|---|---|---|
| 変更番号 | 変更を追いかけるための番号 | CHG-EX-001 |
| 対象 | 変える要件・範囲 | REQ-FUNC-0123 |
| 変更の内容 | 変更前と変更後 | 対象の取引の条件を変える |
| 理由 | なぜ変える必要があるか | 業務ルールの見直し |
| 変えない場合の影響 | 変えないと何が困るか | 手作業での補正が必要 |
| 影響の範囲 | 設計・連携・プログラム・テスト・移行・運用 | 設計と連携とテストに影響 |
| 必要な作業・費用・期間 | 見積もり | 影響の調査結果を記入 |
| 判断 | 承認・却下・保留、判断した人、日付 | 記入欄 |
| 反映の確認 | どの成果物に反映したか | 反映先と確認日 |
番号・内容はすべて教材上の例です。
何を書いてはいけないか
- 影響を調べる前に「影響なし」と書く
- 理由を「要望があったため」だけにする
- 判断した人と日付を空けたまま、作業を始める
どこを見るか
- 変更前と変更後が、はっきり書かれているか
- 変えない場合の影響が書かれているか（判断の比較に必要）
- 影響の範囲が、設計・連携・テスト・移行・運用まで調べられているか
- 他の会社の担当範囲への影響が、確かめられているか
- 判断と反映の確認が、記録されているか
赤信号
- 影響の範囲が「軽微」とだけ書かれている
- 承認の前に、作業が始まっている
- 同じ変更が、別々の番号で何件も出ている
- 反映の確認欄が、ずっと空欄
関係するUnit・成果物・危機演習
- Unit：04-06 途中で要件が変わったらどうするのか、04-05 要件はどこからどこまで追跡するのか、01-05 どこまでを今回の対象にするか
- 成果物：PRG-008 変更管理台帳、REQ-004 要件追跡表
- 危機演習：CR01 要件定義が終わらない（学習上の接続です。正式な対応関係ではありません）
AI WORKFLOW
「この変更要求書を読み、①変更前後が不明確な箇所、②影響の範囲で調べられていない領域（設計・連携・テスト・移行・運用）、③判断に必要なのに書かれていない情報、を挙げてください。承認・却下の提案はしないでください。」
REVIEW
- AIが挙げた影響の範囲に、根拠があるか
- 「影響なし」の領域を、人が確かめたか
- 見積もりの数字を、AIが推測で書き足していないか
人間が判断すること
- 変更を承認するか、却下するか、保留するか
- 増える費用と期間を受け入れるか
- 反映の時期（今回か、次期か）
いつ使うか
この教材では STAGE 04｜1,500件の要件を管理する の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
この変更要求書だけで、承認する人は「受け入れるか」を決められますか？