前回の基本編に続き、PMPについてまとめていきます。今回は、プロジェクト統合マネジメントについてです。
ここからは、各知識エリアのプロセスについて確認していきますが、それぞれのプロセスの「インプット・ツールと技法・アウトプット」が重要になります。
“どのアウトプットがどのインプットになるのか？” や”どの技法がどの知識エリアでよく使われるか？” を常に意識してまとめていこうと思います。
※統合編は長編のためPart 1とPart 2に分けました。
what you learn
プロジェクト統合マネジメントとは、その他の知識エリア「スコープ、スケジュール、コスト、品質、資源、コミュニケーション、リスク、調達、ステークホルダー」を取りまとめるエリアで、PMBOKガイドでは「プロジェクトマネジメント・プロセス群内の各種プロセスと、プロジェクトマネジメント活動の特定、定義、統合、統一、調整などを行うために必要なプロセスおよび活動」と定義されています。
プロジェクト統合マネジメントでは簡単にまとめると以下のようなことが行われます。
それでは、プロジェクト統合マネジメントの以下７つプロセスを確認していきます。
※ () 内はプロセス群の名前を記載。
プロジェクトを正式に認可するために必要なプロジェクト検証を作成するプロセスです。組織の戦略とプロジェクトを紐づけ、プロジェクトへの組織のコミットメントを取り付けます。
ここでのインプット・ツールと技法・アウトプットは以下の通りです。
| インプット | ■ ビジネス文書：ビジネスケース（ニーズ、費用便益分析） や ベネフィットマネジメント計画書（戦略の整合性）によりプロジェクトに投資価値があるかを定量的に判断 ■ 合意書（契約書） ■ EEF（業界標準など） ■ OPA（組織標準の方針） |
|---|---|
| ツールと技法 | ■ 専門家の判断（SME） ■ データ収集（ブレーンストーミング、フォーカスグループインタビュー） ■ 人間関係とチームに関するスキル（コンフリクトマネジメント、ファシリテーション、会議のマネジメント） ■ 会議 |
| アウトプット | ■ プロジェクト憲章 ■ 前提条件ログ |
※ EEF – Enterprise Environment Factors
※ OPA – Organizational Process Assets
インプットのビジネス文書である、ベネフィットマネジメント計画書でプロジェクトによるベネフィット（スポンサーや受益者へ提供する価値）をどう生み出し継続するかを明確にします。
そして、ビジネスケースに記述されているビジネスニーズで投資価値、費用便益分析で効果と価値を数値化して評価します。その結果プロジェクトを開始するかどうか（Go or No Go）を判断します。
専門家の判断は、SME（Subject Matter Experts）- 当該分野専門家と呼ばれ、特定の専門知識を持った個人やグループによる判断になります。必要な専門知識として、組織戦略、ベネフィットマネジメント、業界の技術知識とプロジェクトの注力店、所要期間と予算の見積もり、リスクの特定などがあります。
プロジェクト憲章の作成はスポンサー（イニシエーター）が発行しますが、PMはドラフト作成をすることがあります。
プロジェクト憲章の記載事項は以下の通り
ここでは詳細ではなく、概要レベルのスコープやスケジュールが記載されています。
前提条件ログは、プロジェクトの前提条件・制約条件が記載されており、リスクとしてマネジメントする必要があります。また、以下のプロセスのインプットになります。
プロジェクトマネジメント計画書は以下のような計画書が含まれています。
これらは他の知識エリアの 「〇〇の計画」や「XXの見積もり」などの計画のプロセス群でのアウトプットです。その他、開発アプローチやライフサイクルに関する記述書、マネジメントレビューも含まれています。
プロジェクトマネジメント計画書作成時の全体的な位置はこの図がわかりやすかったので引用します。下図よりプロジェクトマネジメント計画書は計画プロセス群のその他の知識エリアのアウトプットが集約したドキュメントだとわかります。
出典：図解入門よくわかる 最新PMBOK第6版の基本 (p.g.122)
ここでのインプット・ツールと技法・アウトプットは以下の通りです。
| インプット | ■ プロジェクト憲章 ■ 他のプロセスからのアウトプット ■ EEF ■ OPA |
|---|---|
| ツールと技法 | ■ 専門家の判断（テーラリング、コンフィグレーションマネージメントのレベル定義、プロジェクト作業の優先順位付け、など） ■ データ収集（ブレーンストーミング、フォーカスグループインタビュー） ■ 人間関係とチームに関するスキル（コンフリクトマネジメント、ファシリテーション、会議のマネジメント） ■ 会議 |
| アウトプット | ■ プロジェクトマネジメント計画書 |
ここではこれ以上詳細に確認する箇所はないので割愛。
プロジェクトの目標を達成するために、計画されたプロジェクトのアクティビティを実行して成果物をアウトプットします。また、成果物とともに課題や変更要求、作業パフォーマンスデータなどがアウトプットされ、これらが後続の監視コントロールプロセスにおける重要なインプットになります。
プロジェクト作業の指揮・マネジメントと後述のプロジェクト知識のマネジメントは実行エリアのプロセスになります。その他の知識エリア実行プロセス群との関係性は下図がわかりやすいので引用します。
出典：図解入門よくわかる 最新PMBOK第6版の基本 (p.g.123)
プロジェクト作業の指揮・マネジメントでのインプット・ツールと技法・アウトプットは以下の通りです。
| インプット | ■ プロジェクトマネジメント計画書 ■ プロジェクト文書(※) ■ 承認済み変更要求 ■ EEF ■ OPA |
|---|---|
| ツールと技法 | ■ 専門家の判断 ■ プロジェクトマネジメント情報システム（PMIS） ■ 会議 |
| アウトプット | ■ 成果物 ■ 作業パフォーマンスデータ ■ 課題ログ ■ 変更要求 < 以下更新版 > ■ プロジェクトマネジメント計画書 ■ プロジェクト文書 ■ OPA |
プロジェクト文書は以下の文書が主にインプットとして利用されます。
変更済み変更要求は、後続の統合変更管理プロセスで承認された変更要求で、アクティビティ実行時に起こる変更を変更管理委員会（CCB）がレビュー・承認した結果になります。変更作業は主に 是正処置、予防措置、欠陥修正 が含まれます。
プロジェクトマネジメント情報システム(PMIS) とは、プロセス効率化のために使用される以下のようなシステム（仕組み）です。
成果物とは、プロセス・フェーズまたはプロジェクトを完了して生成された固有で検証可能なプロダクト、所産、サービスになります。
作業パフォーマンスデータとは、アクティビティ実施に伴い、現場から提出された生データで、完了した作業、KPI、技術的パフォーマンス測定値、スケジュールアクティビティの実際の開始日と終了日、成果物の状況、スケジュール進捗、欠陥数、実際の費用などが含まれます。
この作業パフォーマンスデータと変更要求は、その他のプロセスのインプットとして使用され、最終的に承認済み変更要求としてこのプロセスのインプットとして戻ってきます。
この流れを簡単に表したのが下図です。
その他の監視・コントロールでは以下のプロセスが作業パフォーマンスデータをインプットとして使用します。
プロジェクト知識のマネジメント以降については Part 2 にまとめています。
今回はここまで！