5つのプロセス群 プロジェクトマネジメントのプロセスとは

プロジェクトマネジメントは、どのようなプロセスで実行されるものでしょうか。

プロジェクトとは、以前の記事(プロジェクトとは ポイントは「独自の」と「有期性」)でも紹介しましたが、独自性・新規性のあるものです。そのため、今までと同じ、ということは通用しません。

PMBOKでは、このプロセスを5つのプロセス群として定義しています。

今回は、この5つのプロセス群を紹介したいと思います。

5つのプロセス群とは

PMBOKガイドでは、プロジェクトマネジメントのプロセスとして以下の5つに定義されています。

No 定義 内容
立上げ プロジェクトの開始を認可するプロセス
計画 プロジェクトの目標を達成するために必要な作業を規定するプロセス
実行 計画に従い、規定された作業を実行するプロセス
監視・コントロール 実行と計画の差異等を分析・監視し必要な対策をするプロセス
終結 成果物を受け入れ、プロジェクトを公式に終了するプロセス

プロジェクトを成功させるための各プロセスをどのようにしていくか、がプロジェクトマネージャーとしての腕の見せ所ですね。

各プロセスの概要を簡単に解説します。なお、私が一番、重要だと思っているのは「立上げ」のプロセスです。

そのため、ほかのプロセスの内容よりも長く記載しています。

立上げの概要

「立上げ」のプロセスでは、そもそもプロジェクトの目的や目標を明確に設定し、ステークホルダーを特定します。何でこのプロジェクトをやるんだっけ?、という点を明確にします。

プロジェクトは、誰もやったことがない独自性・新規性があるものです。そのため、過去にやったことがあって、それと同じ、ということはありません。

類似のプロジェクトがあったとしても、その時と今では目的や目標が異なるはずです。

もし、「立上げ」のプロセスでプロジェクトの目的や目標を曖昧にしてしまうと、のちのプロセスに大きな影響が出てしまいます。

このプロジェクトが「品質」を最重要においているのであれば、品質に特化した計画を、「納期」を最重要においているのであれば、納期に特化した計画を立てる必要があります。

「立上げ」のプロセスでこれが記載されていないと、どのような計画を立ててよいのか分からない、又は計画を立てても見当違いの計画になってしまうかもしれません。

そのため、ちゃんとプロジェクトの目的・目標を明確にしておく必要があります。

計画の概要

「計画」のプロセスでは、プロジェクトの実行の基準になるプロジェクトマネジメント計画書を作成します。

5つのプロセス群の中でも一番、多くのプロセスが定義されています。

具体的には、「計画」のプロセスでWBSの作成やスケジュールの作成、リスク対応計画などを作成していきます。

実行の概要

「実行」のプロセスは、上記の内容の通りです。「計画」のプロセスで作成したプロジェクト計画書に沿って作業を実施していきます。

監視・コントロール

「監視・コントロール」のプロセスでは、その時点の作業実績とプロジェクト計画書との差異を監視します。もし、監視の結果、必要な対応があればそれを実行します

例えば、スケジュールの進捗に遅延がみられるのであれば、後れを取り戻すためにクラッシングやファスト・トラッキングなどの措置を提案・実行します。

クラッシングやファスト・トラッキングは、IPAの試験でもよく出題されますのでしっかりと覚えておきましょう。

また、計画とずれて実行する場合は変更要求を行い承認を得る必要があります。

終結の概要

「終結」のプロセスでは、所定のプロセスが完了していることを検証し、公式にプロジェクトの終了を公式に確定することです

また、ただ終了するだけでなく、プロジェクトの振り返りを行い、失敗や教訓があればそれを記録し次のプロジェクトに生かします

番外編「フェーズとは」

規模が大きくなるとプロジェクトをマネジメントしやすいように「フェーズ」という区分にプロジェクトを分割します。

システム開発の現場でも、企画フェーズ、要件定義フェーズ、設計フェーズ、などと分割されると思います。

各フェーズともに、システム開発に必要なことですが、「計画」「実行」「監視・コントロール」の内容は異なります。

例えば、「企画フェーズ」と「設計フェーズ」では品質計画も異なりますよね。

そのため、プロジェクトの内容によっては、フェーズに分割し各プロセスを回していくことが大切です。

最後に

いかがでしたでしょうか。

プロジェクトマネジメントのプロセスはPMBOKによって5つのプロセス群に分類されています。

実際に私が、実務を実施している際に「今、私は監視・コントロールをしている!」なんて考えて実務をしているわけではありません。

ただ、実際にやっていることはこのプロセス群の内容です。

私の場合は、システムを発注する側の担当者なので受注したベンダが私の要求した事項を満たしているか、目的や目標を見失わずに実行しているか、を監視・コントロールしています。

当然、ベンダだけでなく社内の調整なども実施します。昔はよくシステムテストやっているのに平気で変更要求されて調整が面倒でした・・・。

しかも変更要求に必要な書類や規定された手続を踏んでくれないから大変です。

こんなことにならないように、「立上げ」のプロセスで目的・目標を明確にしステークホルダーとの意識合わせは重要なのだと感じます。

以下、関連記事です。

関連記事

以前の記事でそもそも「プロジェクト」とは何か、を紹介しました。その「プロジェクト」を「マネジメント」することとはどのようなことでしょうか。 えっ、プロジェクトが失敗しないようにマネジメント(管理・運営)することでしょ?、っと思うかもし[…]

最新情報をチェックしよう!