1.2統合マネジメントと変更管理

統合マネジメントは「プロジェクト憲章とは何か」を暗記する分野ではなく、プロジェクトの実行中に変更要求（仕様変更・追加要望・前提条件の変化）が発生したとき、PMがどの手順で受理・評価・承認・反映すべきかを判断する力が問われます。プロジェクトは計画どおりに進まないことの方が普通であり、変更そのものを禁止するのではなく、変更を統制されたプロセスで管理することが統合マネジメントの本質です。無秩序に変更を受け入れるとスコープクリープや品質低下を招き、逆に変更を一切受け付けなければ顧客満足やビジネス価値を損ないます。

1.2.1プロジェクト憲章と全体計画

• プロジェクト憲章＝プロジェクトの存在を正式に認可し、PMに資源を使用する権限を付与する文書。プロジェクトの目的・概要・主要な制約・スポンサーなどを定める、プロジェクト立上げ時の最初の合意点。憲章がなければPMは正式な権限を持たないまま活動することになる。
• プロジェクト全体計画（マネジメント計画）＝スコープ・スケジュール・コスト・品質・資源・リスク等、各知識エリアの計画を統合した、プロジェクトをどう実行・監視・終結するかの基準となる文書。実行中の判断や変更の要否は、この計画（ベースライン）との差異を基準に評価される。

1.2.2統合変更管理と構成管理

• 統合変更管理＝発生した変更要求を、（1）変更要求として正式に記録する→（2）スコープ・スケジュール・コスト・品質・リスクへの影響を評価する→（3）変更管理委員会（CCB）等で承認/却下/保留を決定する→（4）承認された変更のみをベースラインへ反映する、という一連の統制されたプロセス。口頭合意や非公式な対応で計画を変更しないことが原則。
• 構成管理＝成果物やドキュメントのバージョン・状態を管理し、承認された変更だけが正式な構成（ベースライン）に反映されるようにする活動。統合変更管理と対をなし、「今、何が正式な最新版か」を常に一意に特定できる状態を維持する。

あなたはあるシステム開発プロジェクトのPMで、開発リーダーから「顧客の現場担当者から直接、"この画面にもう一項目追加してほしい"と口頭で依頼され、大した工数でもなさそうだったのでその場で対応してしまった」と報告を受けたとします。この時点で一見問題なく見えても、統合変更管理の観点では複数のリスクが潜んでいます。第一に、この変更が正式な変更要求として記録されていないため、スコープ記述書やWBSとの整合が取れず、後で「言った/言わない」の対立や、他のステークホルダへの説明責任が果たせなくなるリスクがあります。第二に、「大した工数でもなさそうだから」という現場の主観的な判断だけで、スケジュールや他機能への影響、テスト範囲の見直しの要否が評価されていないため、小さな変更の積み重ねが後になってスコープクリープとして顕在化し、リリース直前にまとめて遅延や品質問題が表面化する典型的なパターンに陥りかねません。PMとして取るべき対応は、まず今回の対応を正式な変更要求として遡って記録し、影響評価を行った上で、軽微な変更であっても必ず統合変更管理のプロセス（記録→評価→承認→反映）を通す運用ルールをチームに再周知することです。同時に、緊急性が高く現場対応がやむを得ない場合に備えて、軽微な変更を迅速に承認できる簡易な承認フロー（あらかじめ定めた影響度の閾値以下は担当リーダー権限で即日承認できる、等）をCCBと事前に合意しておく設計も有効です。「変更を全て禁止する」のでも「非公式に何でも受け入れる」のでもなく、統制されたプロセスの中で変更を扱うことが統合マネジメントの核心です。

1.2.3この節のまとめ

• プロジェクト憲章はPMへの権限付与、プロジェクト全体計画は実行・監視・変更判断の基準となる文書
• 統合変更管理は記録→影響評価→承認→ベースライン反映の統制プロセスで、軽微な変更でも省略しない
• 構成管理で承認済みの変更のみを正式な構成に反映し、非公式な対応の積み重ねがスコープクリープを招くことを防ぐ