企業AIプロジェクトWiki · スコープ・変更
変更要求
別名Change request · CR · 変更申請 · 変更リクエスト
変更要求とは、識別された文書、成果物、またはベースラインの修正を提案する正式な記録です。現状と提案状態、理由、影響、選択肢、判断権限、実施・検証条件を結び、約束や管理対象システムを変える前に必要性、価値、安全性を判断し、決定後に関係するベースラインを整合させます。
変更要求は提案であり、承認結果ではない
実行開始後も新しい情報は生じます。業務優先度が変わり、前提が崩れ、利用者から新しい需要が出て、リスクが課題になり、テストによって元の設計を見直す場合があります。変更要求は、会議、チャット、コード変更だけで案件が無断に変わらないよう、これらを共通の可視・判断可能な経路へ載せます。
要求の提出は、変更案が正式に出されたことだけを示します。費用、日付、実施を約束するものではありません。評価者は情報追加を求め、権限者は承認、条件付き承認、延期、却下、取下げ受理を選べます。必要な承認が得られるまで、提案状態は新しいベースラインではありません。
変更統制は計画を固定する制度ではなく、判断品質と約束の整合性を守る制度です。必要な変更を可能にしつつ、何と置き換わり、何が後回しになり、どのリスクが増え、承認しないと何が起こるかを見えるようにします。
正式な変更要求が必要になる場面
作業量の大小ではなく、すでに合意・統制されている対象を変えるかで判断します。どのベースライン、金額、リスク等級、システム変更を手続対象にするかを組織が事前に定めます。
スコープまたは納品結果の変更
利用者、業務場面、機能、インターフェース、データ、環境、文書、研修、運用責任、明示的対象外を追加、削除、置換します。
完了条件または品質ゲートの変更
検収基準、テストサンプル、性能目標、セキュリティ要件、本番移行条件、許容差、強制停止条件を変えます。
計画・資源ベースラインの変更
約束済みマイルストーン、納品順序、予算、要員、外部調達、継続費用、顧客側の投入条件を変えます。
統制対象の技術構成の変更
承認済みアーキテクチャ、API契約、DB構造、本番設定、権限、ネットワーク経路、外部サービス、復旧方針を変えます。
リスク対応によるベースライン変更
現在の境界内ではリスク・課題を解消できず、追加統制、異なる残余リスクの受容、機能停止、運用方式変更が必要です。
承認済み内容の中止・再配置
ベースライン上の作業を止める、後続段階へ移す、他の内容と交換する場合、元の約束がどう置換されるかを明示します。
評価可能な変更要求に必要な内容
- 要求を一意に識別できるか
番号を付け、申請者、申請日、業務責任者、緊急度、判断希望日を記録します。
記録：要求ID、所有者、状態、時刻。
- 現在のベースラインが明確か
有効なスコープ、要件、設計、計画、予算、構成、版を参照し、「前の案を変える」だけにしません。
記録：対象名、版、格納場所、関連項目。
- 提案状態を検証できるか
追加、削除、置換、中止する内容と観察可能な完了結果を記し、必要に応じてルール、API差分、試作を添付します。
記録：目標状態、対象内外、完了条件。
- 理由と変更しない結果が揃っているか
発端、業務価値、法令・リスク上の必要性と、現状維持による費用、遅延、危険、機会損失を説明します。
記録：根拠、緊急性、非実施の結果。
- 影響範囲を追跡できるか
利用者、業務、成果物、要件、システム、データ、供給者、環境、テスト、文書、運用チームを洗い出します。
記録：関連対象、依存関係、初期影響一覧。
- 実施・検証の初期案があるか
実施方法、移行・停止の有無、テスト、復旧、完了確認者を少なくとも示します。
記録：実施選択肢、検証方法、復旧方針、責任者。
影響評価は開発工数の見積だけではない
承認、不承認、実行可能な代替案を比較します。小さなコード修正でもデータ、セキュリティ、契約、運用境界を越えることがあります。大きな案も単純な可否ではなく、縮小、優先度交換、段階導入を選べます。
業務価値と目標
支援する目標、解決する問題、受益者、価値の測定方法、より優先度の高い作業を圧迫しないかを確認します。
スコープ、日程、費用、要員
分析、設計、開発、データ、テスト、デプロイ、研修、引き継ぎ、継続運用まで含め、日程、予算、要員、調達への影響を示します。
ソリューションと依存関係
構成、API、データモデル、移行、設定、基盤、供給者、関連成果物への連鎖を調べ、要素間の追跡性を保ちます。
品質、検収、既存証拠
更新・再実行が必要な基準、テスト、合格済み結果を特定し、旧証拠が新状態にも適用できるかを明記します。
セキュリティ、プライバシー、法令、契約
権限、データ目的・流れ、脅威面、記録保持、規制、ライセンス、調達、価格・責任の変更を評価します。
リリース、運用、復旧
停止、容量、監視、支援、通知、バックアップ、ロールバック、継続性、長期保守を検討し、デプロイ可能性だけで終えません。
不承認と代替案
現状維持の結果と、範囲縮小、優先度交換、延期、試行、別技術経路を並べて判断者へ示します。
提出から完了までの一連の処理
登録して関連付ける
IDを付け、原提案を保存し、発端となった要件、欠陥、リスク、課題、決定、顧客連絡を関連付けます。
仕分けと完全性確認
統制ベースラインを変えるか、重複か、緊急経路かを判断し、不足情報は補足依頼します。仕分けは承認ではありません。
部門横断で影響評価する
実際の影響に応じて業務、進行、技術、データ、セキュリティ、テスト、運用、財務、調達、供給者が参加し、見積、リスク、選択肢を作ります。
適切な権限者へ判断を求める
金額、範囲、期間、リスク、契約約束の委任基準に従い、案件・製品責任者、変更管理委員会、顧客など指定役割が決定します。
決定を記録・通知する
決定者、日付、状態、理由、条件、適用範囲、後続責任を残し、口頭合意だけでなく全関係者へ通知します。
承認後にベースラインを更新する
実施前または承認条件に従い、スコープ、要件、設計、予算、計画、構成、検収資料、契約別紙、版記録を同期し、旧状態を保存します。
統制された計画で実施する
承認内容を実行作業へ分解し、指定版、環境、権限、デプロイ経路を使います。新しい重大影響は無断拡大せず再評価します。
検証・引き継ぎ・完了
承認条件に照らして確認し、運用・引き継ぎ資料を更新し、関連記録の整合と暫定措置の除去を確認して、指定役割が完了にします。
状態、判断権限、緊急変更の設計
| 状態・決定 | 正確な意味 |
|---|---|
| 提出済み / 情報不足 | 要求が登録済み、または評価情報が不足しています。どちらも実施を許可しません。 |
| 評価中 | 関係者が影響と選択肢を分析中です。承認見込みや先行着手の権限を示しません。 |
| 承認 | 権限者が記録された範囲、条件、予算、時期で実施を許可します。重大な逸脱は再判断が必要です。 |
| 条件付き承認 | 指定の前提、上限、テスト、審査、期限を満たした場合のみ権限が有効です。条件は検証可能にします。 |
| 延期 / 却下 | 延期は要求を残して判断・実施を後ろへ送り、却下は現行ベースラインを維持します。理由と再提案条件を残します。 |
| 実施済み / 完了 | 実施済みは変更作業が行われた状態です。検証、ベースライン・資料更新、責任移管後に初めて完了にします。 |
企業AIの変更要求では動作ベースライン全体を識別する
モデル・サービス変更
提供者、モデルID、固定版または可動エイリアス、地域、パラメータ、廃止時期を記録します。アプリコードが同じでも、管理型モデル更新で品質、遅延、費用、安全性が変わります。
プロンプト、ガードレール、人の規則
システムプロンプト、出力スキーマ、フィルタ、拒否、人の承認、エスカレーションは動作を決めます。過剰拒否と統制漏れの両方を評価します。
ナレッジ・検索経路
資料源、権限、洗浄、分割、埋込み、索引、検索、再順位付けは回答根拠を変えます。データ権限、失効・削除、再構築範囲、復旧先を定めます。
ツール、実行、権限
書込、送信、注文、チケット、承認を加えると現実の影響が増えます。最小権限、引数確認、冪等性、上限、監査、失敗補償、人への引き継ぎを評価します。
評価ベースラインと再検証
正常、異常、情報不足、攻撃入力、機密情報、高影響アクションの影響サンプルを特定します。評価集合・尺度の版を残し、旧平均点から合格を自動継承しません。
第三者変更と継続監視
提供者のモデル、API、方針は案件外で変わります。通知条件、版固定、ドリフト監視、再評価トリガー、代替策を影響・運用計画へ含めます。
停止、復旧、事故連携
権限外開示、不可逆操作、根拠のない重要事実、人承認の迂回、監査不能などの停止条件と、アプリ、モデル、プロンプト、索引、ツール設定の復旧先を定めます。
変更要求を完了する前に残す証拠
- 決定記録が完全である
承認、条件付き承認、延期、却下、取下げ、置換について、決定者、委任根拠、日付、理由、適用範囲を残します。
- 新旧ベースラインを比較できる
スコープ、要件、設計、計画、予算、構成、契約資料を更新し、旧版、差分、発効日も追跡可能にします。
- 実施対象を識別できる
成果物、設定、DB移行、モデル、プロンプト、ナレッジ索引、ツール権限、導入環境を記録し、「完了」だけにしません。
- 検証結果を再確認できる
基準、テスト、再テスト、回帰、安全確認、運用観察、例外を実施版に結び、確認者を明記します。
- 運用・引き継ぎが同期している
監視、通知、復旧、支援、研修、利用者説明、資産台帳、継続費用に責任者がいます。
- 未完了事項に行き先がある
残余リスク、延期内容、暫定統制、観察期間、撤去日に責任者と別記録を与え、完了処理で隠しません。
変更要求と混同しやすい記録
| 関連記録 | 変更要求との違い |
|---|---|
| 要件 | 要件は関係者の需要・制約を表します。変更要求は統制済み要件または他のベースラインの修正を提案し、影響と判断を運びます。 |
| 欠陥票 | 欠陥は既存要件を満たさない事実です。元の基準へ直すだけなら通常スコープ変更ではありませんが、解決策、費用、約束が変わるなら要求を関連付けます。 |
| リスク | リスクは不確実性と影響です。対策がベースラインを変える場合、変更要求で権限を得て、リスク記録では残余リスクを追跡します。 |
| 課題・事故 | 課題はすでに発生し、事故対応は封じ込めと復旧を優先します。恒久的な統制状態の変更は通常または緊急変更要求で扱います。 |
| タスク・バックログ | タスクは実行すると決めた作業です。変更要求はその判断より前に、変更すべきかと全影響を説明します。 |
| 決定記録 | 決定記録は選択と理由を保存します。変更要求は対象、影響評価、権限、実施、検証、完了まで扱います。 |
| 契約変更書 | 契約変更書には固有の法的・商業的効果があります。案件の変更要求が契機にはなっても、必要な署名、価格、責任調整を代替しません。 |
| 変更統制 | 変更統制は修正を識別、記録、評価、承認・却下、追跡する制度全体です。変更要求はその中で一件の提案を運ぶ記録です。 |
出典と適用範囲
本項目は、プロジェクトまたはシステムのベースラインを変更する提案に使う正式な変更要求を説明します。口頭の意見、通常タスク、欠陥票、リスク・課題記録ではなく、変更が承認済み、実施済み、または契約に反映済みであることも意味しません。組織によってプロジェクト管理、チケット、構成管理、契約手続で異なる名称や様式を使います。しかし、合意済みのスコープ、成果物、要件、設計、計画、予算、構成、運用ベースラインを変える提案には、変更対象の識別、影響評価、権限者の判断、提出から完了までの追跡が必要です。