前回の記事についてはこちら
PMP PMBoK 第6版を理解する 2.ビジネスケースや組織構造について
学習目標
・統合マネジメントの全体について説明できる
・プロジェクト憲章について説明できる
・プロジェクトマネジメント計画書について説明できる
・プロジェクト文書について説明できる
・プロジェクト作業の指揮マネジメントの働きについてを説明できる
・プロジェクト知識のマネジメントの働きについてを説明できる
・プロジェクト作業の監視コントロールの働きについて説明できる
・統合変更管理の働きと変更管理の手順について説明できる
・プロジェクトやフェーズの終結プロセスの働きについて説明できる
4.統合マネジメント
| 4.統合マネジメント | インプット | ツールと技法 | アウトレット |
| 4.1プロジェクト憲章の作成 | ・ビジネス文書 ・合意書 ・組織のプロセス資産(教訓レポジトリ) | ・専門家の判断 ・データ収集 ・会議 | ・プロジェクト憲章 |
| 4.2プロジェクトマネジメント計画書の作成 | ・プロジェクト憲章 ・他プロセスからのアウトプット ・組織のプロセス資産 | ・専門家の判断 ・データ収集 ・会議(kick off mtg) | ・プロジェクトマネジメント計画書 ・ベースライン ・補助計画書 |
| 4.3プロジェクトの指揮マネジメント | ・プロジェクトマネジメント計画書 | ・PMIS ・会議 | ・成果物 ・課題ログ ・変更要求 ・作業パフォーマンスデータ |
| 4.4プロジェクトの知識マネジメント | ・プロジェクトマネジメント計画書 ・組織のプロセス資産 | ・知識マネジメント ・情報マネジメント | ・教訓登録簿 ・組織のプロセス資産更新版 |
| 4.5プロジェクトの監視・コントロール | ・プロジェクトマネジメント計画書 ・作業パフォーマンス情報 ・プロジェクト文書 | ・データ分析 ・会議 | ・変更要求 ・作業パフォーマンス報告書 |
| 4.6統合変更管理 | ・変更要求 | ・会議(変更管理会議) | ・承認済み変更要求 |
| 4.7プロジェクトやフェーズの集結 | ・プロジェクト憲章 ・プロジェクトマネジメント計画書 ・受け入れ済み成果物 ・ビジネス文書 | ・会議 | ・最終プロダクト、サービス、所産の移管 ・最終報告書 |
49プロセスのうち最初のプロセスが「4.1プロジェクト憲章の作成」になります。
PMが作成して、スポンサー、イニシエーターが承認することでプロジェクトが正式に認可されます。PMに権限を与えるための文章を作成します。
PMBOK®Guidep.70
先行割り当てを受けたメンバーが「4.2プロジェクトマネジメント計画書の作成」をして、PMが承認します。全ての計画書、ベースラインなどの情報が計画書の一部となります。
プロジェクトアプローチ、プロジェクトコントロールの方法などを記述したものがプロジェクトマネジメント計画書になります。
先行割り当て PMBOK®Guidep.333
「4.3プロジェクト作業の指揮マネジメント」
・計画書通りの作業をリードする。(計画通りに作業を進める)
・承認済み変更を実施する。(課題への対処)
「4.4プロジェクト知識のマネジメント」
・既存の知識を利用して、新しい知識を創造する
・教訓登録簿が作成される
「4.5プロジェクト作業の監視・コントロール」
・プロジェクト全体の進捗状況を分析(追跡)してレビューする
・報告書を作成する
※プロジェクト作業が予定通りに進んでいない場合、その原因を追究して原因を打開するためのアクションプラン(変更要求)を出します。
「4.6統合変更管理」
・全ての変更要求をレビューして、承認する
・計画書などの変更をマネジメントして、変更を伝達する。
PM、スポンサーが承認権限があるが、億単位のお金が動く場合、PMの独断では決められない場合があるため、会議を行います。
例えば、メンバーからこう変更したいと上がってきたものをPMの独断で
OKとしているのは、変更要求の承認を行っています。
またベースラインに影響がある変更の場合、クライアントやスポンサーから予算の承認がおりることで、追加の変更や改修を行うケースもあるかと思います。
「4.7プロジェクトやフェーズの終結」
全ての契約上の活動を終結します。
4.1プロジェクト憲章
PMになる人がプロジェクトの進め方(教訓リポジトリ)を参照し、全員の意見をファシリテーションし、会議などを行って、プロジェクト憲章を作成します。
インプット
（ビジネスケース、評価指標、ベネフィットマネジメント計画書）
・合意書
・組織のプロセス資産(教訓レポジトリ)
ツールと技法
・人間関係とチームに関するスキル：ファシリテーション、会議のマネジメント
・会議
アウトプット
・プロジェクトの目的
・測定可能なプロジェクトの目標と関連する成功基準
・ハイレベルの要求事項
・ハイレベルのプロジェクト記述、境界、および主要成果物
・プロジェクトの全体リスク
・要約マイルストーンスケジュール
・事前承認された財源
・主要ステークホルダーリスト
・プロジェクト承認要求事項
(プロジェクトの成功を判断する事項、成否を判断する人、受け入れ承認する人)
・プロジェクト終了基準
・任命されたPMとその責任と権限レベル
・プロジェクト憲章を認可するスポンサー等の名前と地位
4.2プロジェクトマネジメント計画書
プロジェクトマネジメント計画書は先行割り当てを受けたメンバーが作成し、PMが承認します。
立ち上げプロセス群 情報（主にプロジェクト憲章）をベースに計画書を作成します。
各知識エリアの補助計画書・ベースライン（スコープ・スケジュール・コスト）をまとめています。
どのようなもの（スコープ）をいつまで（スケジュール）に、いくら（コスト）で作るのか？を明記にし、PMにより承認された計画の事です。
インプット
・プロジェクト憲章
・他のプロセスからのアウトプット(ベースライン、補助計画書)
・組織のプロセス資産
過去の情報やテンプレートを確認して、計画書を作ることが多い
ツールと技法
・会議
計画プロセス群の最後でキックオフミーティングを行います。
目的：プロジェクト目標を伝達し、プロジェクトへのチームのコミットメントを得る。各ステークホルダーの役割と責任を説明することにある。
アウトプット
★プロジェクトマネジメント計画書に含まれるもの
・補助計画書(計画プロセス群のアウトプット)
・ベースライン
・変更マネジメント計画書
変更の手順を示しているもので、いくら以下ならPMの単独で決められる、いくら以上ならCCBを通す必要があるなどを記載。またどういった手順で伝達するのかなど。
・コンフィグレーションマネジメント計画書
成果物の構成項目を特定して、どの部分が変わったのかを明確に管理する方針を文書化したものです。ベースラインやプロジェクト内で発生した文書の版数管理もコンフィグレーションの対象となります。
スコープクリープが発生しないようにします。
※スコープクリープ・・・誰もバージョン管理をしていない状態かつそれが肥大化
・プロジェクト文書
作業を進めていくとドキュメントができてきます。
→リスク登録簿、テスト・評価文書など
これらのデータの格納先がプロジェクト文書
※PMBoKに記載されている内容も一部であり、全部ではない。
PMBOK®Guidep.89
4.3プロジェクト作業の指揮マネジメントの働き
２つの働き
・計画書に従い、作業を進める。
・承認済み変更要求の実行する。（課題の対処）
インプット
・プロジェクトマネジメント計画書
・プロジェクト文書
・承認済み変更要求
ツールと技法
・PMIS
スケジューリングツールに作業データを入力する
例）redmine、excel、MSproject
【このシステムの一部としてKPIの自動収集や自動報告を行うこともできる】
・会議
情報交換
デイリースタンドアップミーティング（毎日の15分以内の進捗確認）など
アウトプット
・成果物(中間成果物を含む)
・作業パフォーマンスデータ(生データ：全ての種類の作業実績データ)
【アクティビティの実施中に把握した生の観測値や測定値のことである。】
完了した作業（成果物 5.6）、実際に発生した費用（コスト 7.4）、実際の期間（タイム 6.6）など
→これらの情報を元に各コントロールプロセスにて評価を行います。
PMBOK®Guidep.95
・課題ログ
課題ログの作成は、プロジェクトの実行中に行われます。
13.3 は 4.3の1作業になります。
・変更要求（是正処置、予防処置、欠陥修正、更新）
作業の実行中に問題が発生した場合は、変更要求が提案されます。
更新は4.3のみ。・・・追加の依頼が発生する場合
・予防処置：今後、実績値がずれないように対応する方法(ベースラインを変えない)
・欠陥修正：要求事項を満たしていないため、成果物を修正する方法
(ベースラインを変える可能性がある)
・更新：ステークホルダーからの追加のアイディア
(ベースラインを変える可能性がある)
★成果物を生成した後の流れについて
成果物(4.3 アウトプット)
⇓
検証済み成果物(8.3 アウトプット)
成果物の監査を行います。
品質基準を満たしていることを確認した成果物(内部評価完了)
⇓
受け入れ済み成果物(5.5 アウトプット)
ユーザーテストなどで成果物に対する受け入れを得るプロセス
顧客やスポンサーから受け入れを得た結果(検収済み成果物)
⇓
最終プロダクト、サービス、所産の移管(4.7 アウトプット)
成果物の納品
4.4プロジェクト知識のマネジメントの働き
・既存の知識を利用して新しい知識を創造する
・過去のプロジェクト文書（教訓登録簿）から知識マネジメントにより、教訓登録簿を作成する
常に行っていることが前提となっているため、実行プロセスにある。
監視コントロールは定期的に行っていることが前提。
インプット
・プロジェクトマネジメント計画書
・プロジェクト文書
教訓登録簿, プロジェクト・チームの任命, ステークホルダー登録簿,
資源ブレイクダウンストラクチャー(チームの構成情報)
・成果物
ツールと技法
・知識マネジメント(ナレッジマネジメント)
個人のもつ暗黙知を形式知に変換することにより、知識の共有化、明確化を図り、作業の効率化や新発見を容易にしようとする企業マネジメント上の手法
SECIモデル(野中郁次郎が提唱)
2.表出化(Externalization)：各個人、小グループが有する暗黙知を形式知として洗い出す。
3.結合化(Combination)：洗い出された形式知を組み合わせ、それを基に新たな知識を創造する。
4.内面化(Internalization)：新たに創造された知識を組織に広め、新たな暗黙知として習得すること。
こちらの記事の方がSECIモデルを理解しやすいかもしれません。
アウトプット
・教訓登録簿
最終的にはプロジェクトやフェーズの終了時に、教訓リポジトリとして組織のプロセス資産に含まれます。
4.5プロジェクト作業の監視コントロールの働き
２つの働き
・プロジェクト全体の計画と実績を比較して変更要求を提案する
・報告書（作業パフォーマンス報告書）を作成する
インプット
・プロジェクトマネジメント計画書(計画値)
・9つのプロセスからの集約された作業パフォーマンス情報(実績値)
・プロジェクト文書
スケジュール予測（6.6）,コスト予測（7.4）
ツールと技法
・根本原因分析：問題の主な原因に注力して分析
・アーンドバリュー分析(Earned Value)：コスト換算上で作業進捗を測る分析方法
・差異分析：計画値と実績値の差異から原因を調べる分析方法
アウトプット
・変更要求(更新は含まない)
計画値と実績値の差異から、是正処置、予防処置、欠陥修正が提案されます。
・作業パフォーマンス報告書
状況報告、進捗報告、またアーンドバリュー・グラフ、傾向線とグラフ、予備バーンダウン図表やリスクの要約などが含まれます。
4.6統合変更管理の働きと変更管理の手順
全ての変更要求をレビューし、変更を承認して、成果物、プロジェクト文書、プロジェクトマネジメント計画書などへの変更をマネジメントし、決定事項を伝達するプロセスです。
【ベースラインが確立されるまでは変更が統合変更管理プロセスによって正式にコントロールされる要求されることはない。】
【変更は口頭で発案でも構わないが、必ず書面に記録し変更管理システムやコンフィグレーションマネジメントシステムに入力しなければならない。】
【統合変更管理プロセスは、必要に応じて変更管理委員会(CCB)を含む。CCBがプロジェクトの変更をレビューし、評価し、承認し、保留または却下するとともに、そうした決定を記録し伝達することに責任を有する認可された正式なグループである。】
PMBOK®Guidep.115
インプット
・変更要求
・プロジェクトマネジメント計画書
・作業パフォーマンス報告書
・プロジェクト文書
ツールと技法
・変更管理ツール
・会議(変更管理会議)
アウトプット
・承認済み変更要求
・プロジェクト文書更新版
変更ログはプロジェクト期間中に発生した変更を文書化するために使用します。
★作業手順
原因分析→変更要求→会議→承認済み変更要求→変更ログ→更新版
変更要求とその手順に関する問題は多く出題されます！
4.7プロジェクトやフェーズの終結プロセスの働き
主な働き
・成果物の配布（delivery）と顧客による正式な受け入れを確認する【納品】
・すべてのコストがプロジェクトに請求されていることを確認する
・プロジェクトの会計を閉じる
・人員の配置転換（資源をリリースする、資源の再分配）
・納入者の仕事の正式な受け入れを確認する（調達終結を完了する）
・納入者との間にある未解決のクレームを最終処理する
・プロジェクトの成功と失敗を監査する
・教訓を特定し、教訓をまとめる（知識の共有と移転）→教訓レポジトリの作成
・プロジェクトに関してクライアントからフィードバックを得る（ステークホルダーの満足度の測定）
インプット
・プロジェクト憲章
・プロジェクトマネジメント計画書
・プロジェクト文書(教訓登録簿)
・ビジネス文書(ビジネスケース、ベネフィットマネジメント計画書)
・受け入れ済み成果物
【フェーズ分けされた、または中止されたプロジェクトでは、部分的または仕掛り中の成果物がプロジェクトの受け入れ済み成果物となることがある。】
PMBOK®Guidep.125
ツールと技法
・会議
【会議は、成果物が受け入れられ終了基準を満たしていることの確認を行い、契約の完了を正式化し、ステークホルダーの満足度を評価し、教訓を集め、プロジェクトから知識と情報を移転し、成功を祝うために使用される。】
アウトプット
・最終プロダクト、サービス、所産の移管
・最終報告書
・組織のプロセス資産更新版(教訓リポジトリ)
PMBOK®Guidep.127,128
プロジェクトやフェーズの終結プロセスについては、細かくPMBoKを確認することをおすすめ致します。これは立ち上げプロセスと同様、終結プロセスが1つしかないのに、出題率としては約12%ほどになっているためです。
10.まとめ
- 統合マネジメントはプロジェクト全体のマネジメントプロセスである
- PMがプロジェクト憲章を作成して、スポンサー、イニシエーターが承認する
- プロジェクト憲章には、プロジェクトの目的やリスク、要約マイルストーンなどが含まれる
- 先行割り当てを受けたメンバーがプロジェクトマネジメント計画書を作成して、PMが承認する
- キックオフミーティング後、計画書に従い、作業を進める
- 課題の対処方法(変更要求)が提案される
- 全ての変更要求が、統合変更管理プロセスでレビューされる
- 監視コントロールからは是正処置、予防処置、欠陥修正の３つが提案される
- 変更要求が承認された後、変更ログを通じて、内容が伝達される
- 会議を通して、教訓をまとめ、成果物を納品して、最終報告書を作成し、プロジェクトを終結する
今回は4章の統合マネジメントについてまとめてみました。
立ち上げプロセスの「プロジェクト憲章の作成」と終結プロセスの「プロジェクトやフェーズの終結」についてはPMBoKを細かく見て頂くことをおすすめ致します。
以上になります。お疲れ様でした！
