【第4回】プロジェクトの統合マネジメント、7つのプロセス

本連載ではプロジェクトマネジメントの全体像とプロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。

みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。

第4回となる今回のテーマは「統合マネジメント」です。

＜プロジェクトマネジメント成功の技術連載一覧＞※クリックで開きます

【第1回】プロジェクトマネジメントとは何か？［全文公開中］
【第2回】プロジェクトマネージャーの役割とは？
【第3回】ステークホルダーマネジメントの重要性と進め方
 【第4回】プロジェクトの統合マネジメント、7つのプロセス
 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ
 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］
【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］
【第8回】コストをプロジェクトの武器にする！
【第9回】目に見えにくいプロセス管理こそ品質達成の鍵
 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す
 【第11回】プロジェクトのリスクマネジメント［後編］リスク分析とコンティンジェンシープラン
 【第12回】人がプロジェクトの源泉！チームは育てて強くする［前編］
【第13回】人がプロジェクトの源泉！チームは育てて強くする［後編］
【第14回】コミュニケーションの本質を知り、使いこなそう！
【第15回】笑顔で終わるプロジェクトはここが違う！プロジェクトクロージングのTODO ［全文公開中］

統合マネジメント
統合マネジメント7つのプロセス
さいごに
＜参考・引用＞

統合マネジメント

統合マネジメントという言葉は、あまり聞き慣れないかもしれませんね。
私も時折「統合マネジメントってなんですか？」「具体的に何を行えばいいのか？」といった質問を受けます。

統合マネジメントは簡潔に言うと「プロジェクトのすべての要素を調整」する活動を指します。
PMBOKでは「プロジェクトマネジメント・プロセス群内の各種プロセスとプロジェクトマネジメント活動の特定、定義、結合、統一、調整等を行うために必要なプロセスおよび活動」と定義されています。^※1
プロジェクトは有期的で独自性のある活動＝ひとつとして同じプロジェクトはありません。リソース、コスト、納期、関わる人々、目的などのすべての要素を総合的に管理・調整することではじめて、プロジェクトマネジメントが実現します。そしてプロジェクトは固有であり、複数の利害か関与するダイナミックで複雑なものです。プロジェクトの目的を達成する為に、今どのような状態にあって何をすべきかを考える際、プロジェクト統合マネジメントが不可欠です。そして統合マネジメントはプロジェクトマネージャー固有の領域として、PM自身がその活動を担当・指揮していきます。

統合マネジメント7つのプロセス

PMBOKでは以下7つのステップ（プロセス）でプロジェクト活動の効果的なマネジメントを行うものとしています。^※2

(1) プロジェクト憲章の作成

プロジェクトの羅針盤とも言える「プロジェクト憲章」、みなさんの組織やプロジェクトでは書いていますか？
プロジェクト憲章はプロジェクトと組織の戦略目標とを結びつけて、プロジェクトへの組織のコミットメントを示すものとされ、通常はプロジェクト初期に1度だけ作成される、プロジェクトの基礎となるドキュメントです。

1）プロジェクト憲章を作り前に行うこと（準備）

プロジェクト憲章を作成するもととなる情報が必要です、それはなんでしょうか？主には前段階で作成された（されているであろう）プロジェクト作業範囲記述書（SOW：Statement of Work）やビジネスケース、外部発注の場合には契約書やSLAなどをもとに作成します。

プロジェクト憲章より前に作成された、適当なプロジェクト関連文書類を入手する
文書間の整合性や実現可能性が低い内容がないか確認する
必要に応じて、不明点等を関係者に確認したり交渉を行う

必要になる文書・情報は業種業態、企業文化、そもそもプロジェクトが発注側か受注側か、組織内プロジェクトなのかといったものによっても変わります。自身のプロジェクト憲章作成に対してどのような情報が必要かというイメージやリストを事前に持っておきましょう。

2）プロジェクト憲章に何を記載するか

プロジェクト憲章に何を記載するかは、「何を明確にしておかなければならないか」「どのような事項において共通理解を持っておかなければならないか」とイメージするとよいでしょう。プロジェクト憲章に明確なフォーマットはなく、プロジェクトの規模や複雑さ、組織内のルールなどによってその記載ボリュームは増減します。プロジェクト憲章はハイレベルな記述によりプロジェクトないの共通理解とその視座をあわせていきましょう。

※ここでいうハイレベルは「高度な」という意味ではなく「概要」や「大局的視点」という意味で使用しています。

＜プロジェクト憲章に記載したい基本的な項目：例＞

ビジネスニーズ
プロジェクトの概要・目的/目標、終了基準
ビジネスケース（メリット）
成果物
納期とマイルストーン
条件（前提条件・制約条件）
予算（承認された財源）
主要なリスク
プロジェクト組織体制
役割や権限
変更管理方法
承認者

3）プロジェクト憲章は誰が作るか問題

ドキュメントの性質からプロジェクトのイニシエーターやスポンサーが発行（作成）します。しかし組織によってはプロジェクトマネージャーが作成し、その確認/承認をスポンサーから得るという手続きが多いようです。著者の感覚としても後者の割合が高いと感じます。プロジェクト憲章の存在は前述したようにプロジェクトとPMの活動を助けるものですから、組織内の慣習を理解しながら早めはやめの作成を心がけたいものです。

(2) プロジェクトマネジメント計画書の作成

ハイレベルなプロジェクトアウトラインがプロジェクト憲章で整理されたら、次のステップとしてプロジェクトマネジメント計画書を作成し、詳細な計画作成に入ります。主にプロジェクトの実行、監視コントロール、終結についての方法を規定しますが、要約レベルでも詳細レベルでも大丈夫で、憲章と同じようにプロジェクトの特性に応じた詳細さで記述しましょう。

計画書作成の基本的なステップ

(3) プロジェクトへの指揮とマネジメント

前のステップまでに整理された計画を実行に移し、その活動を指揮（リード）して成果物を作成、必要に応じて修正を加えるプロセスです。PMはプロジェクトチームへ指示を与え、会議開催や日々その進捗状況をウォッチして、プロジェクトの計画に沿って効果的に活動がなされているかを確認します。このフェーズで得られる（＝プロジェクトとして残さなければならない）以下のアウトプットを意識して進めましょう。

成果物
成果物はPMBOKでは「固有で検証可能なプロダクト、所産、またはサービスを提供する能力で、プロセス、フェーズ、またはプロジェクトを完了するために生成する必要があるもの」と定義されます。^※3　要するにプロジェクトの成果であり、PMは常に注意深く監視とコントロールを続けなければなりません。
作業パフォーマンス・データ
プロジェクトマネージャーは、プロジェクト実行時に得られた観測値や測定値を管理、収集し、これらはプロジェクトの資産としてこれからのプロジェクトに生かされます。
例えば）
- アクティビティの予実→ XXタスクはX日で実施できると思っていたが、実際はその倍を要した。
- 変更要求の数→ 当該A_PJ規模での変更要求数から鑑みて、類似プロジェクトBも同等の予測ができるだろう。
課題ログ
プロジェクトで挙がった課題は対応経過が追跡されると同時に、記録として残しましょう。
変更要求ログ
プロジェクト実行中に挙がった変更要求もその対応経過と共に記録します。
(!) プロジェクトにおいて必要な「変更」は悪ではなく、必要に応じて速やかに検討し変更を取り込まなければなりません。だからと言って闇雲に変更を許容したり「合意のない変更」「勝手な変更」を許容するものでもありません。そしてステークホルダは「誰でも変更を要求すること」ができます。例えば「XXは変更した方がXXに効果的だと思うけれど、なんだか言いにくい、、」というようなことがあれば、プロジェクトの為にもしっかり変更を要求（提案）してみましょう。

(4) プロジェクトに関する知識のマネジメント

プロジェクトに関する知識のマネジメントとは、過去に得られた情報やツールを利用したり、プロジェクトの目標達成に必要な知識を得て活用するプロセスを指します。またプロジェクト活動で新たに得られたナレッジは、その後のプロジェクトや組織に再活用され、これらを繰り返していくことが大切です。

1）プロジェクトは一から作らない

筆者の経験からも、プロジェクトを１から建てつけることはほとんどありません。プロジェクトに必要な知識や情報は社内（外）に豊富に存在します。例えばBプロジェクトの前身であるAプロジェクトに関わったXXさんであれば、Aプロジェクトのドキュメント一式にアクセスでき、教訓登録簿等などを現在のプロジェクトに活かすことができるでしょう。プロジェクトを任されたら「よし作ろう」ではなく「よし、情報収集しよう」という意識で社内の情報を集めることから始めましょう。

残念ながらそのような情報がない、蓄積されていない、という場合は自組織のプロジェクト高度化のために、知識の蓄積や管理を自組織に対して提案してみましょう。

2）暗黙知を形式知化する

暗黙知とは経験やノウハウといった、明確に表現することが難しい知識を指します。この知識を共有するには会話や相互作用が必要です。いかに暗黙知を形式知（文書化できる知識）にして生かしていくか、を意識しましょう。

3）ナレッジの源泉を引き出す

プロジェクト中に起こった問題や課題、或いはこれは上手くいった、というプラスの情報も、その時期が過ぎると忘れてしまうものです。また特に不満や要求などネガティブな部分は表立って声にならないことも少なくありませんが、会社全体の成長・高度化、知識体系に貢献し、将来のプロジェクトをより良くするためにはそれらの「声」を収集することが必要です。そのためにPMはプロジェクト内で信頼関係を築くこと、つまり「発言しやすい、発言できる」雰囲気を作って、「さあ、どうぞあなたが感じたことを教えてください、もっと良くしていきましょう、よくなるはず！」という態度を示すことが重要です。例えばプロジェクト終了後のアンケートでそのような意見を収集する際などに「どのような意見であっても人事評価に影響しない、上長に記名で共有しない」などと付け加えるなども有効です。

(5) プロジェクト実行の監視とコントロール

プロジェクトにおける監視とは、プロジェクトは順調か？計画通りに進んでいるか？を見る活動です。そのために活動進捗や途中結果の収集を行い、必要に応じて改善活動（予防・是正・欠陥修正）を適用していきます。

1）どのようにプロジェクトの状態を測定するか

一般的な手法として以下のような分析を行いますが、特に利用されるのが「アーンド・バリュー分析」です。今はさまざまなプロジェクト管理ツールで自動的に測定されることが多いですね。

データ分析方法例）

アーンド・バリュー分析（EVM）
費用便益分析
根本原因分析
傾向分析、差異分析

プロジェクトは常に動いています。その動きをモニタリングするだけでなく、目に見える形（データ）にすることで今の自分たちの状況と打つべき対策を検討する手助けになります。なるべく自分たちのプロジェクト規模で扱いやすい分析を採用して活用してみましょう。また、データ分析だけでなく、経験のあるステークホルダーや有識者に相談したり、プロジェクト内でのミーティングやレビューも積極的に行っていきましょう。

EVM：1960年代にアメリカで生まれたプロジェクト管理技法で、プロジェクトの計画予算と実際に発生した費用、およびそれまでに完了した作業量を対比し、コストとスケジュール実績が計画とどの程度の乖離があるのかを明確化。最終的な推定コスト・完了時期を予測する。現状から将来プロジェクトを予測する際に活用される手法です。
(!) ここではEVM作成方法や分析結果の見方（パターン）などは割愛しますが、馴染みのない方はぜひ調べてみてください。

(6) 統合変更管理の実行

変更が起こらないプロジェクトはありませんが、変更に伴う活動が適切でないとストレスや予期しない負担となります。知らないうちに追加要求をチームが受け取ってしまった、追加要求が捩じ込まれたが納期が遅れてしまう、どうしよう…といった苦い経験は想像に易いでしょう。統合変更管理の管理主眼は、それら必ず起こる変更の「ルールを決めて適切に管理すること」です。

1）その変更要求は受けるべきか、受けざるべきか？

「XXをこう変えたい」と変更要求がなされたのには理由があるはずです。しかし、例えばその変更要求がプロジェクトスコープの範囲内か、そのプロジェクトフェーズ内で行うべきか（後続対応でよいのではないか）など評価することも同じように重要です。ある要求を受けつけるためには、別のタスクや物事に影響する場合がありますし、その影響によっては適切に「変更しない」という判断になる場合があることも忘れないでください。

また統合変更管理の活動ではそれらの変更ログを必ず文書化して、どのようにして変更要求が承認されたか、その全体的な影響、影響先を把握し、プロジェクト活動にスムーズに統合＝適応させていきましょう。

2）変更管理委員会とは？

要求された変更（希望）内容によってはPMの権限で判断するものもあれば、プロジェクトスポンサー（オーナー）が判断するものなど様々です。事前に「XXの変更はPM承認、それ以外はPO、XXXレベルは変更管理委員会で決裁する」など事前に定義しておくとよいでしょう。変更管理委員会（CCB：Change Control Board）のメンバも事前にアサインしておきましょう。必要時に招集（MTG）し、プロジェクトからでた変更要求をレビュー、評価し、承認または却下します。

(7) プロジェクトクローズ

全てのプロジェクト作業が終了し、その活動を終えるために必要なマネジメントを指します。プロジェクトは成果物ができたら終わり、ではありません。最終的に必ずプロジェクト憲章に沿って「プロジェクトオーナーらからクローズ承認」を受けることができて初めてプロジェクトをクローズ（終結）することができます。

1）具体的なステップ

プロジェクトオーナー等への活動報告
プロジェクトクローズMTG（振り返り会など）
プロジェクト活動報告と終了報告書等の提出
プロジェクトナレッジの整理と保管

2）実施するクローズ活動と終結基準：例 ^※4

プロジェクトクローズ活動をしっかりできるプロジェクトでありたいですね。形式的な活動も含まれますが、以下の活動例を終結基準として意識してみてください。また、終結時に「何を終えておかなければならないだろう」と考えはじめては遅いので、あらかじめチェック項目として整理しておきましょう。またPMは活動途中からこれらの終結基準や準備しなければならない報告・ドキュメントを少しずつ作成しておくことをお勧めします！

全ての文書と成果物が最新状態であることを確認する
全ての課題が解決されていることを確認する（または適切に申し送り事項として管理されていることを確認する）
成果物の検収完了を確認する
プロジェクトの会計を終えている（未払い等がない状態を指す）
人的資源（人員）を返却する（プロジェクトから定常業務へ配置転換する）
プロジェクトで利用した各種資源の返却や再分配を行う
プロジェクト報告など必要なドキュメントを作成し報告を完了する
プロジェクトの知識や教訓を特定、整理し、将来活用できるよう情報保管する
ステークホルダーの満足度特定（アンケートやヒアリングの実施）

さいごに

プロジェクト統合マネジメントは、プロジェクトの土台となる整理（プロジェクト憲章）と計画（プロジェクトマネジメント計画書）、それらの実行（実行・知識の活用、監視コントロール）と変更調整（統合変更管理）を行いながら、その目的目標を達成してプロジェクトの役割を終える（プロジェクトクローズ）に至る、一連の大きな活動サイクルです。ボリュームがありますが、一連の流れと共にプロジェクトではこういう活動が必要なんだ、というポイントを先ずは掴んでいきましょう。

次回のテーマは「スコープマネジメント」です。明確な目標設定と共有方法のコツを学んでいきましょう。

＜参考・引用＞

※1：PMBOKガイド第6版.P69.プロジェクト統合マネジメント
※2：PMBOKガイド第6版.P70.プロジェクト統合マネジメント・プロセス
※3：PMBOKガイド第6版.P95.プロジェクト作業の指揮·マネジメント：アウトプット_成果物
※4：PMBOKガイド第6版.P123.プロジェクトまたはフェーズの事務終了のための活動