・統合マネジメントとは、プロジェクト全体を通しての大きな考え方をまとめたもの
・すべての章を勉強し終わったら、もう１度ここに戻ってくるとよい
・ この章にPMBOKの色々なイズムが詰まっている
＜プロジェクトとは＞
・ 独自性と有期性を持つもの＝定常業務とは異なる
・ プロジェクトを包含するのがプロダクト、プロダクトを包含するのがポートフォリオ
＜プロジェクトの流れ＞
・5つのプロセスからなる（立上→計画→実行→監視コントロール→終結）
・立上げ＝「プロジェクト憲章の作成」「ステークホルダーの特定」だけ
・計画=どんなルールでやっていくかという全体計画と、ベースラインを作るプロセス
・実行と監視コントロール＝グルグル回す。問題が生じれば変更要求を出して対策を打つ。
・終結＝「プロジェクトの終結」だけ
＜全体を通して共通しているPMBOKの重要な考え方＞
・ 行き当たりばったりに進めるのではなく、計画を立ててから実行するということ
・ 計画はベースライン（=比較基準）という形で可視化する
・ 計画フェーズではリスクも洗い出し、万一それが発生した場合はどうするかまで事前に作戦を決めておく
・ プロジェクト実行中は、常に進捗やパフォーマンスを監視。現状とベースラインの間に差異が出たらイレギュラーな事態が起きたと判断する
・ イレギュラーな事態が起きた場合、まずはどう対処するルールに決めていたか、ドキュメントを確認する
・ ドキュメントに記載がある想定内のイレギュラーに対しては、事前に建てた戦略通りに対策を打つ
・よほどのことがなければベースライン自体を変更してはならない
（つまり、間に合わないから納期を遅らせる、ユーザから要望があったから要件を追加する、できそうにないから計画の方を動かす、などの安易な変更は禁忌。）
・ どうしてもルールや計画自体を変更しなければならない場合は、変更要求という正式なプロセスを通じて計画を変更する
・ お上に状況をエスカレーションし、ルールや計画のアップグレードを行うことの承認を得る
・ 重要なことは、プロジェクトというのは事前に建てた緻密な「想定」と「作戦」に従って遂行していくものであり、無計画のまま始めて行き当たりばったりで対応していくものではないんだということ。これがPMIイズム。
・ 変更はあって当然のものとして受け入れている。しかし十分に精査し、慎重に行おうという姿勢がPMIイズム。
ー－－－－－－－－－－
＜立上げプロセス＞
① プロジェクト憲章の作成
・ プロジェクトを正式に立ち上げるプロセス。PMはこのプロセス内で任命される。
・ビジネスケース、ベネフィットマネジメント計画書を用いて、プロジェクトへの投資価値をスポンサーに対して説明する
・ スポンサーに認可されることでプロジェクトが正式に立ち上がる
・ 正式に承認されたことを示すものとして、プロジェクト憲章が発行される
・ プロジェクト憲章には、ビジネスニーズ、前提条件、制約条件、ハイレベルな要求事項が書かれる
・ ハイレベル＝高次元レベルでのというニュアンス。具体的な要求事項は別プロセスで定義することになる。
＜計画プロセス＞
② プロジェクトマネジメント計画書の作成
・ 各種ドメインの計画書、ベースライン、コンフィギュレーションマネジメント計画書を作る
・ ベースライン＝スケージュールベースライン＋コストベースライン＋スコープベースライン
・ ベースラインは監視コントロールプロセスにおける比較基準となる。EVMなどで活用される
・ 変更要求が生じたとき、どういうフローで変更を認可するのかもここで決めておく
＜実行＞
③ プロジェクト作業の指揮・マネジメント
・ 成果物を作る
・ 同時に、ベースラインと比較するための実測値(生データ)もアウトプットする（作業パフォーマンスデータ）
④ プロジェクト知識のマネジメント
・教訓登録簿を作る。こいつはプロジェクト実行中に随時更新されるし、終結時にも更新される。
＜監視コントロール＞
⑤ プロジェクト作業の監視・コントロール
・ 計画と実績を比較し、異常事態が起きていないかを監視する
・ 異常や異常の予兆があれば手を打つ
・ 新たなリスクがないか発生していないか監視する
⑥ 統合変更管理
・ 変更要求をインプットとし、要求内容を精査し、変更を承認する
・ すべての変更要求はここに投げられる
＜終結プロセス＞
⑦ プロジェクトの終結
・ 「スコープの妥当性確認」の終了を受けて発動する
・ プロジェクトそのものを完結させるプロセス
・ 終了のための公式文書の作成、最終成果物の移管、教訓登録簿の更新を行う(振り返りと教訓のデータベース化)