このユニットの結論
要件は、プロジェクトの途中でも変わります。変わること自体は悪くありません。
問題になるのは、影響を調べずに変えること、決める人を通さずに変えること、変えたことを関係者に伝えないことです。
変更は、「受け付ける → 影響を調べる → 決める → 伝える → 反映を確かめる」という決まった流れで扱います。
1. 何の話か
このユニットは、変更管理の話です。
一度決まった要件でも、
- 法律や会社のルールが変わった
- 業務のやり方を見直した
- 他のシステムの事情が変わった
- テストで考え漏れが見つかった
といった理由で、変更が必要になります。
2. なぜ必要か
変更を口頭やメールだけで受けると、
- 変更を知らない人が、古い要件のまま作り続ける
- 1行の変更のつもりが、設計・連携・テスト・移行にまで影響する
- 費用や期間が、いつの間にか増えている
ということが起きます。
3. このユニットで分かること
- 変更を扱う流れ
- 影響を調べるときに見る範囲
- 変更の判断で、AIに任せてよいことと人間が決めること
4. 変更を扱う流れ
- 変更の申請
- 影響の調査
- 判断（承認・却下・保留）
- 関係者への連絡
- 成果物への反映
- 反映の確認
一般的には、変更ごとに番号を付け、申請から反映の確認までを一つの記録で追いかけます。
5. 影響を調べる範囲
要件が変わると、04-05 要件はどこからどこまで追跡するのか で学んだつながりの先が、すべて影響を受ける可能性があります。
- 設計
- 他システムとの連携（IF）
- プログラム
- テストケース
- データ移行
- 運用手順・利用者への説明
- 費用・スケジュール
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件に関係する記載
- 約1,500件の要件、約36本のシステム連携
- マルチベンダー（Vendor A〜D）
- 成果物に REQ-005 変更要求書、PRG-008 変更管理台帳、PRG-007 意思決定記録がある
アステリア案件で、どの変更をいつ、誰の判断で受け入れたかは、正本に記載がありません。未確定
6. THINK — 「1項目足すだけ」
業務部門から、「請求データに1項目足すだけなので、すぐ対応してほしい」と頼まれました。
問題
開発担当に、そのまま作業を頼んでよいでしょうか。
判断例を開く
判断
まず変更として受け付け、影響を調べます。
確認すること:
- その項目は、どのシステムが正しい値を持っているか（データの正本）
- 他のシステムへの連携に、その項目を足す必要があるか
- 相手のシステムの担当（別のベンダーかもしれない）の作業が必要か
- 既存のデータにも、その項目を移す必要があるか
- テストのやり直しがどこまで必要か
「1項目」でも、連携の先まで影響することがあります。
7. よくある失敗
- 変更を記録せず、会議や口頭で済ませる
- 影響を調べる前に、承認してしまう
- 変更を承認した人と日付が残っていない
- 変更の結果を、関係する他社・他部門に伝えない
- 成果物のどこに反映したかを確かめない
8. 成果物との接続
- REQ-005 変更要求書：変更の中身・理由・影響を書いて申請する
- PRG-008 変更管理台帳：変更を番号で追いかけ、状態を管理する
- REQ-004 要件追跡表：影響の範囲を調べる手がかり
- PRG-007 意思決定記録：変更を受け入れた判断を残す
危機演習 CR01 要件定義が終わらない も、要件の変化と向き合う題材です（学習上の接続です。正式な対応関係ではありません）。
9. AI WORKFLOW — 影響の候補を洗い出させる
指示例:
「次の変更要求について、要件追跡表・連携一覧・テスト一覧から、影響を受ける可能性のある箇所を候補として挙げてください。関係が書かれていない箇所は推測で確定せず、『確認が必要』として分けてください。」
AIは、変更の説明文を分かりやすく整える下書きにも使えます。
10. REVIEW — AIの影響候補を確認する
- 最新の版の一覧を渡したか
- 挙がった候補が、本当に影響を受けるか
- 他社が担当する部分の影響が、抜けていないか
- AIが「影響なし」と書いた箇所の根拠は何か
ADVANCED深掘り — 実務者向けに一段深く
深掘り — 変更の分類と、変更率、凍結の時期
変更を 3 つに分ける
すべての変更を同じ手続きで扱うと、軽微な直しに重い手続きがかかり、手続きを飛ばす人が出ます。変更を分類します（教材上の例）。
- 軽微：文言の修正、表示の順番など。影響が 1 つの成果物に閉じる。担当のリーダーが決める
- 標準：設計・テスト・他システムに影響する。影響を調べ、決める場に回す
- 緊急：法令や業務の停止に関わり、待てない。決める人が直接判断し、手続きは事後に整える
分類の基準と、分類ごとの決める人を前もって決めます。世界で共有されている考え方では、標準の変更を決める場を変更管理委員会（CCB）と呼びます。
変更率を測る
一定の期間に、確定した要件のうち何件が変わったかを、変更率と呼びます。月ごとに並べると、変更が落ち着いていく時期と、落ち着かない領域が見えます。設計が進んでも変更率が下がらない領域は、要件がまだ固まっていない印で、そこに人を足しても手戻りが増えるだけです。
凍結の時期を決める
ある時点から先は、緊急以外の変更を受け付けず、次の機会に回す、という区切りを凍結と呼びます。凍結の時期は、テストや移行の準備が変更に耐えられなくなる時点から逆算して決め、全員に伝えます。凍結のあとに受けた変更は、数と理由を記録し、稼働後の最初の改修の候補にします。
測り方の例
- 分類ごとの変更の件数と、申請から決定までの日数
- 月ごとの変更率（領域ごと）
- 凍結のあとに受けた緊急の変更の数
現場で確かめる問い
- 変更は分類されているか。分類ごとに決める人は決まっているか
- 変更率を月ごとに見ているか。下がっていない領域はどこか
- 凍結の時期は決まっているか。誰が、いつ、全員に伝えたか
- 凍結のあとに受けた変更を、数と理由で記録しているか
アステリア案件の変更の分類、変更率、凍結の時期は、正本に記録がありません。記録なし
11. 人間が判断すること
- 変更を受け入れるか、却下するか、保留するか
- 増える費用と期間を受け入れるか
- どの時点で反映するか（今回・次期）
- 誰に、どう伝えるか
12. 判断演習
本番稼働の3週間前に、要件の変更要求が届きました。業務上は重要ですが、影響の範囲はまだ分かっていません。
あなたなら、判断する人に何を示しますか。
- 変更しない場合の業務への影響
- 変更する場合の作業とテストのやり直し
- 本番稼働後に反映する案
- 判断の期限
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
要件の変更は、決まった流れで受け付け、影響を調べてから決めるものです。
決めたことは、関係者に伝え、反映されたことを確かめて、初めて終わります。