本連載ではプロジェクトマネジメントの全体像とプロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。
みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。
第4回となる今回のテーマは「統合マネジメント」です。
＜プロジェクトマネジメント成功の技術 連載一覧＞※クリックで開きます
【第1回】プロジェクトマネジメントとは何か？ ［全文公開中］
【第2回】プロジェクトマネージャーの役割とは？
【第3回】ステークホルダーマネジメントの重要性と進め方
【第4回】プロジェクトの統合マネジメント、7つのプロセス
【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ
【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］
【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］
【第8回】コストをプロジェクトの武器にする！
【第9回】目に見えにくいプロセス管理こそ品質達成の鍵
【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す
【第11回】プロジェクトのリスクマネジメント［後編］リスク分析とコンティンジェンシープラン
【第12回】人がプロジェクトの源泉！チームは育てて強くする［前編］
【第13回】人がプロジェクトの源泉！チームは育てて強くする［後編］
【第14回】コミュニケーションの本質を知り、使いこなそう！
【第15回】笑顔で終わるプロジェクトはここが違う！プロジェクトクロージングのTODO ［全文公開中］
統合マネジメント
統合マネジメントという言葉は、あまり聞き慣れないかもしれませんね。
私も時折「統合マネジメントってなんですか？」「具体的に何を行えばいいのか？」といった質問を受けます。
統合マネジメントは簡潔に言うと「プロジェクトのすべての要素を調整」する活動を指します。
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）プロジェクトは一から作らない
続きを読むにはログインが必要です。
ご利用は無料ですので、ぜひご登録ください。
