これは何か
変更管理台帳は、プロジェクトの途中で出てきた変更の依頼を1件ずつ登録し、影響の見積もり・判断・反映までの状態を追いかける一覧です。
1件ずつの変更の中身は、変更要求書（REQ-005）に書きます。変更管理台帳は、それらをまとめて、全体として何件の変更がどの状態にあるかを見るためのものです。
なぜ作るか
- 変更の依頼が、決まった手続き（影響の確認 → 判断 → 反映）を通っているかを確かめる
- 認められていない変更が、こっそり作業に入り込むのを防ぐ
- 変更が積み重なったとき、費用・期間への影響の合計を見られる
- 認められた変更が、関係する成果物（要件・設計・テストなど）に反映されたかを確かめる
誰が使うか・いつ作るか
- 管理する人：PMO など、変更の手続きを回す担当
- 使う人：変更を判断する人、プロジェクトの責任者、各チームの担当
- 一般的には、プロジェクトの初めに変更の手続きと一緒に用意し、変更の依頼が出るたびに登録します
- アステリア案件の変更の手続き・変更の件数・判断した人は、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
変更に関係する記載
- 約120人規模のプロジェクト、約1,500件の要件、マルチベンダー
- P-004 田辺 彩 — PMOリーダー
- 成果物に REQ-005 変更要求書、PRG-008 変更管理台帳がある
PMOリーダーが変更管理台帳を管理するという記載は、正本にありません。未確定
主な項目（列）
一般的には、1行に次の列を持ちます。
- 変更番号：変更要求書と同じ番号
- 依頼日・依頼した人
- 変更の概要：何を変えたいか（1〜2行）
- 理由
- 影響の見積もり：範囲・費用・期間・品質への影響
- 判断：認める／認めない／保留
- 判断した人・日付
- 反映先：直す必要のある成果物（要件一覧・設計・テストなど）
- 状態：受付／影響確認中／判断待ち／反映中／反映済み（確認済み）
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 台帳の数行
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
次の表は、台帳の読み方を学ぶための例です。番号・内容・状態は、すべて教材上の架空の例で、アステリア案件の変更ではありません。
| 変更番号 | 概要 | 影響の見積もり | 判断 | 反映先 | 状態 |
|---|---|---|---|---|---|
| CHG-EX-01 | 案件の一覧に、担当部署で絞り込む機能を足す | 小（画面1つ） | 認める | 要件一覧、画面設計、テスト | 反映済み（確認済み） |
| CHG-EX-02 | 承認の段数を2段から3段にする | 中（画面・権限・テスト） | 保留（組織の規程の改定を待つ） | ― | 判断待ち |
| CHG-EX-03 | 帳票の出力形式を1つ追加する | 中（帳票・テスト） | 認める | 要件一覧、帳票設計、テスト | 反映中 |
| CHG-EX-04 | 稼働の直前に、画面の並びを大きく変える | 大（画面・教育・手順書） | 認めない（稼働後に再検討） | ― | 完了（不採用） |
読み方
- 状態が「判断待ち」のまま長く止まっているものはないか
- 「認める」の行に、反映先と、反映の確認があるか
- 影響の見積もりの合計が、予算・期間の余裕を超えていないか
- 判断した人が、その変更を判断してよい立場の人か
- 台帳に載っていない変更が、作業に入り込んでいないか
書き方
- 変更の依頼を受けたら、番号を取って台帳に登録する（作業を始める前に）
- 影響を見積もる担当と期限を決める
- 判断の場に上げ、結果と判断した人を書く
- 認めた変更は、反映先ごとに直す担当を決める
- 反映が終わったら、直した成果物を確かめてから「反映済み」にする
- 定期的に、止まっている行と、影響の合計を報告する
何を書いてはいけないか
- 判断していない変更を「反映中」にする
- 影響の見積もりのない「認める」
- 反映の確認をしないままの「反映済み」
どこを見るか
- 状態ごとの件数と、長く止まっている行
- 認めた変更の影響の合計
- 判断した人と日付
- 反映先と、反映の確認
- 認めなかった変更の理由
赤信号
- 判断した人の欄が空欄
- 「認める」なのに、反映先が空欄
- 稼働の直前に、大きな変更が続けて認められている
- 台帳の件数と、実際に進んでいる変更の作業が合わない
よくある失敗
- 小さな変更だからと台帳に載せず、積み重なって大きな遅れになる
- 変更の依頼が口頭や個別の連絡だけで伝えられ、台帳に載らないまま作業が始まる
- 認めなかった変更の理由を残さず、同じ依頼が何度も出る
関係するUnit・成果物・危機演習
- Unit：04-06 途中で要件が変わったらどうするのか、03-02 PMOとは何をする組織なのか、03-01 誰が最終責任を持つのか
- 成果物：REQ-005 変更要求書、REQ-004 要件追跡表、PRG-007 意思決定記録
- 危機演習：この成果物を直接の題材にする危機演習はありません
AI WORKFLOW
AIは、台帳の点検の下書きに役立ちます。
「この変更管理台帳から、①状態が長く変わっていない行、②『認める』なのに反映先が空欄の行、③影響の見積もりがない行、を挙げ、認めた変更の影響の見積もりを区分ごとに集計してください。変更を認めるかどうかは判断しないでください。」
REVIEW
- AIが挙げた行と集計が、台帳の元の内容と合っているか
- AIが影響の大きさを付け直したり、判断を書き換えたりしていないか
- 止まっている行の担当に、人が確かめたか
人間が判断すること
- 変更を認めるか、認めないか、保留にするか
- 影響の合計が大きいとき、どの変更を後回しにするか
- 反映が終わったと判断してよいか
いつ使うか
この教材では STAGE 04｜1,500件の要件を管理する の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
この台帳を見た人は、「今、どんな変更が依頼され、どれが認められ、どれが反映まで終わったか」を答えられますか？