プロジェクト・マネジメント-プロセス概要 | 治事 / PRINCE2 / 注疏

プロセス概要

プロセスとは、特定の達成目標を達成するための一連の処置およびそのインプットとアウトプットを定義する構造化された一連の活動。プロジェクトを正しく指揮・管理・提供するために必要な活動を含む。

7つのプロセス

PRINCE2 には7つのプロセスがある。

プロセス	略称	主なアクター	目的
プロジェクトの始動(Starting up a Project)	SU	プロジェクト・マネージャー・ビジネス	実行可能性の確認
プロジェクトの指揮(Directing a Project)	DP	プロジェクト委員会	プロジェクト委員会による意思決定
プロジェクトの立ち上げ(Initiating a Project)	IP	プロジェクト・マネージャー	詳細計画とベースライン策定
ステージのコントロール(Controlling a Stage)	CS	プロジェクト・マネージャー	プロジェクト・マネージャーによる日々の管理
成果物デリバリーのマネジメント(Managing Product Delivery)	MP	チーム・マネージャー	チームによる制作と報告
ステージ境界のマネジメント(Managing a Stage Boundary)	SB	プロジェクト・マネージャー	次のステージへの準備
プロジェクトのクローズ(Closing a Project)	CP	プロジェクト・マネージャー	正式な終了手続き

最小ステージ構成: プロジェクトの規模に関わらず、時間軸においては少なくとも立ち上げステージと最終ステージの2つが必ず存在する。プロジェクトの規模や必要性に応じて、これら2つのステージの間に複数の中間ステージを設けることもできる。

プロセス全体像

プロジェクト・ライフサイクル

プロジェクト開始前

プロジェクトが正式に動き出す前には、アイデアやニーズを具体化し、その妥当性を検証する「準備段階」が必要である。

プロジェクト権限委任(トリガー): プロジェクトが始まるきっかけ。ビジネス(プロジェクトを委託する組織)から提供される。形態は口頭による指示から、詳細に定義された正式な文書まで多岐にわたる。
プロジェクトの始動(SU)プロセス: プロジェクトを正式に開始する前に、そのプロジェクトに価値があり、かつ実行可能であるかを評価・確認する。

主な活動: プロジェクト・マネージャーおよびプロジェクト委員会の任命、プロジェクト要約書の作成、ステージ計画書(立ち上げステージ用)の作成。

プロジェクトの指揮(DP)プロセス: プロジェクト委員会がプロジェクト要約書とステージ計画書を精査し、プロジェクトの開始を承認するかどうかを決定する。

立ち上げステージ

プロジェクトの始動が承認された後、詳細な計画を策定し、管理体制を構築するステージである。

プロジェクトの立ち上げ(IP)プロセス: プロジェクトを成功させるために以下の重要な要素を確立する。

詳細計画の立案: スケジュールやリソースの明確化。
ガバナンスの構築: プロジェクト・マネジメント・アプローチとコントロールの定義。
ビジネス・ケースの精査: 投資対効果や正当性を裏付ける堅固なビジネス・ケースの開発。
ベネフィット・マネジメント: 成果がもたらす利益をどのようにレビューするかを決定。

次のステージの準備: 立ち上げステージの後半で、**ステージ境界のマネジメント(SB)**プロセスを使用して、次のステージに関する詳細な計画を作成する。
ステージの終了と認可: プロジェクト委員会はプロジェクトの指揮(DP)プロセスを用い、プロジェクト全体および次ステージを認可するかどうかを決定する。承認されたPID(プロジェクト立ち上げ文書)は、今後の進捗を評価するためのベースラインとして保存される。

後続ステージ

立ち上げステージ以降、プロジェクトは一つまたは複数の実行ステージ(後続ステージ)を経て進行する。日々の管理・成果物の作成・ステージの切り替えが中心となる。

ステージのコントロール(CS)プロセス: プロジェクト委員会は、ステージごとの日々の管理をプロジェクト・マネージャーに委任する。

プロジェクト・マネージャーの責務: 承認された計画に沿って進捗しているか、予測が**許容度(トレランス)**の範囲内に収まっているかを常に確認する。
委員会への報告: プロジェクト・マネージャーはハイライト報告書を定期的に提出し、プロジェクト委員会に進捗状況を通知する。

成果物デリバリーのマネジメント(MP)プロセス: プロジェクト・マネージャーとチーム・マネージャー(またはチーム・メンバー)間のやり取りを管理するプロセスである。

作業の割当: プロジェクト・マネージャーは実行すべき作業を**WP(ワーク・パッケージ)**としてアサインする。
チームからの報告: チーム側は、チェックポイント報告書を通じて作業の進捗状況をプロジェクト・マネージャーに報告する。

ステージ境界のマネジメント(SB)プロセス: 各ステージの終盤に行われる、ステージの締めと次への準備のためのプロセスである。

実績報告と許可依頼: プロジェクト・マネージャーは現在のステージの実施状況を報告し、次のステージへ進むための許可を依頼する。
計画と更新: 次のステージの詳細計画を作成すると同時に、ビジネス・ケースを最新の状況に基づいて更新する。
委員会の意思決定: プロジェクト委員会は、プロジェクトがビジネス戦略と整合しており実行可能性があるかを評価し、次ステージの開始を認可するか決定する。

最終ステージ

プロジェクトは一時的な組織体であるため、最終ステージの終盤で正式に終了させる手続きが必要となる。

プロジェクトのクローズ(CP)プロセス: 以下の活動を行う。

成果物の移転とオーナーシップの確定: 成果物の受領者が所有し継続して使用できる状態にあることを確認する。
パフォーマンス評価: プロジェクトの最終的な実績を、当初の計画書と比較して評価する。
リソースのリリース: プロジェクトにアサインされていた人員やリソースを解放する。
文書の保管: 後の参照や監査に備え、プロジェクト関連文書を適切にアーカイブする。
ベネフィット・レビュー計画の確認: プロジェクト完了後に現れるベネフィットを評価する計画を確認または修正する。

プロジェクト終了後

プロジェクトが正式にクローズした後も、価値の実現を確認するための活動は継続される。

ベネフィットの実現: 大半のベネフィットはプロジェクト完了後の運用フェーズで実現される。
ベネフィット・マネジメント・アプローチの役割: ベネフィット・レビューをいつどのように実施するか、誰が実行責任と説明責任を負うかを文書化しておく必要がある。

プロセス記述の構成要素

各プロセスは以下の構成と形式で説明される。

項目	内容
目的	プロセスを実行する理由
達成目標	プロセスで達成すべき固有の目標
位置づけ	他のプロセスとの関係、成果物のインプット/アウトプット
活動	推奨される処置の一連の流れ
責任	RACI 図による役割分担の定義

他フレームワーク補足

概念	PRINCE2	PMBOK	PgMP
プロセスの総数	7つのプロセス	5つのプロセス群(49プロセス)	(今後追記)
日々の管理プロセス	ステージのコントロール(CS)・成果物デリバリーのマネジメント(MP)	実行プロセス群・監視・コントロール・プロセス群	(今後追記)
プロジェクト終了プロセス	プロジェクトのクローズ(CP)	プロジェクト終了	(今後追記)