プロジェクト中に発生する「変更」をどう扱うかを学ぶよ！
変更管理プロセスは流れを順番ごと覚えるのがコツだよ。
概要
変更管理とは、プロジェクトの計画や成果物に対する変更を適切に管理し、影響を最小限に抑えながら実施するプロセスです。 変更はプロジェクトの進行中に避けられないため、組織的に扱うことが重要です。
変更管理の重要性
-
変更が無計画に行われると、コスト超過や納期遅延、品質低下につながる
-
変更の影響を評価し、承認されたものだけを反映することで、リスクを軽減
-
全関係者の合意を得て、透明性を確保
変更管理に関わる主な役割
| 役割 | 主な責任 |
|---|---|
| プロジェクトマネージャー | 変更評価の主導、承認プロセスの管理 |
| 変更管理委員会（Change Control Board：CCB） | 重要変更の承認・却下を行う場合がある |
| 変更要求者 | 変更の理由と詳細を提出 |
| チームメンバー | 変更内容の実施および影響分析への協力 |
重要な変更管理の用語
-
スコープクリープ（Scope Creep）: 制御されていない、意図しないプロジェクト範囲（スコープ）の拡大や変更。プロジェクトの遅延やコスト超過の主原因になります。
-
スコープチェンジ（Scope Change）: 計画的かつ公式に承認されたスコープの変更。
-
変更の3つのタイプ（ITIL 3大変更タイプ）:
- プロジェクト運用やサービス維持管理において、変更のリスク、緊急度、手続きの手軽さに応じて分類した3つの枠組みです。
変更タイプ (英語) 特徴と概要 ITプロジェクトでの具体例 承認ルート（CCB / CAB） 標準変更
(Standard)リスクが低く手順が完全に確立された定常作業 パスワードリセット、PCの定期入替、定期的なウイルス定義更新 不要（事前承認済み / Pre-authorized）。毎回CCBを通さず現場の判断で即実行可能。 通常変更
(Normal)計画的に行う、事前評価が必要な標準外の変更 サーバーのOSアップデート、新機能の追加、インフラ構成の変更 必要。影響評価の実施後、CCB/CABの審査・承認を経てから実施。 緊急変更
(Emergency)重大なシステムダウン等に最速で対処する変更 セキュリティ脆弱性の緊急修正、重大な本番システム障害からの復旧 超特急ルート。緊急CCB（またはECAB）等で即時承認し、詳細な記録は事後報告。 -
変更ログ（Change Log）: プロジェクト中に発生した重大な問題や、計画からの逸脱（重大なスコープ変更や新機能リクエストなど）を公式に記録・評価・追跡するための最適な文書です。
変更管理プロセス（時系列ステップ）
変更要求が発生した場合、プロジェクトマネージャーは以下の 時系列ステップ に従ってプロセスを進めます。
- 変更要求の受領・起票: 変更を求める人（スポンサー、顧客、チームメンバー等）が公式に変更要求書を提出します。
- 変更ログへの記録: 受領した変更要求を 変更ログ に未承認（Pending）ステータスで即座に記録し、追跡可能にします。
- 影響評価の実施: プロジェクトマネージャーとチームは、変更がスコープ、スケジュール、コスト、品質、リソース、リスクに与える影響を分析します。
- 承認・却下の意思決定: 影響評価結果をもとに、意思決定権者（通常は 変更管理委員会（CCB） またはプロジェクトスポンサー）が承認・却下・保留を決定します。
- プロジェクト計画書の更新: 変更が承認された場合、プロジェクト管理計画書やスコープ/スケジュール/コストのベースラインを修正します。
- 変更の実施と検証: 変更を実際の作業に適用し、計画通りに実装されたかをテストなどで検証します。
- ステータス更新と関係者への通知: 変更ログ のステータスを「完了」に更新し、結果を要求元およびステークホルダーに通知します。
- 変更はプロジェクト成功のために必須だが、管理が重要であることを理解する。
- 変更管理プロセスのステップを順序立てて説明できること。
- 関係者の役割分担（CCBの役割など）を押さえること。
関連模擬問題
【問1】
質問: 変更管理委員会によって、変更要求が認められました。次に行うことはどれですか。
選択肢:
- A. 変更管理台帳を更新する
- B. コストベースラインを変更する
- C. スコープ・クリープに対応する
- D. スケジュールベースラインを更新する
回答と解説を見る
正解は A です。
解説: 変更管理委員会（CCB）によって変更要求が認められたら、承認内容によって変更管理台帳を更新します。 変更が正しく管理されていれば、スコープ・クリープは発生しません。 また、変更が発生してもスケジュールベースラインやコストベースラインが変更になるとは限りません。
【問2】
質問: システム開発プロジェクトの実行時において、ステークホルダーの一部から何度も変更要求が出されています。変更要求は公式ルートで承認され、スケジュール変更を繰り返している状況です。このとき、プロジェクトマネージャーの次のアクションとして、最もふさわしいものは、次のうちどれですか。
選択肢:
- A. 変更管理委員会に参加し、影響の大きな変更要求は却下できるようにする
- B. 変更要求について上限を設定し、上限を超える変更要求がある場合にはプロジェクトの中断を提案する
- C. 変更要求を障害管理として開発の後半にまとめて対応するようにスケジュールを変更する
- D. ステークホルダーとミーティングを行い、今後も変更要求の発生する可能性の高い機能を確認し、その機能の開発の順番を後方にすることなどでスケジュールへの影響が小さくなるようにする
回答と解説を見る
正解は D です。
解説: プロジェクトマネージャーは公式ルートで承認された変更要求については、影響をなるべく小さくして受け入れることが求められます。そのため、影響の大きな開発が発生しても、開発する機能の順序を入れ替えるなどの対策を行います。 勝手に障害管理にしてまとめたり唐突にプロジェクト中断を求めることは不適切です。また、自ら変更管理委員会に参加することはできません。