プロジェクト・マネジメント-プロジェクトの指揮 | 治事 / PRINCE2 / 注疏

プロジェクトの指揮

プロジェクトの指揮プロセス(DP)の目的は、プロジェクト委員会が主要な意思決定と全体的なコントロールを行い、プロジェクトの成功に対する説明責任を果たすこと。一方、日々のマネジメント業務はプロジェクト・マネージャー(PM)に委任される。

達成目標

以下の点を確認・確立することを目指す。

立ち上げの認可: プロジェクトの立ち上げが認可されていること
成果物提供の認可: プロジェクト成果物の提供が認可されていること
ガバナンスの維持: ライフサイクル全体で適切な指揮とコントロールが行われていること
正当性の継続確認: プロジェクトが継続して実行可能であること
戦略的整合: ビジネス・レイヤーとの関連性が維持されていること
クローズの認可: プロジェクトのクローズが認可されていること
価値の実現: 終了後のベネフィット実現計画が適切に管理・レビューされていること

位置付け

トリガー

プロジェクトの始動プロセス(SU)が完了し、PMからプロジェクト立ち上げ要求が出された時点で開始される。

実施のポイント

運用の特徴
- 例外によるマネジメント: プロジェクト委員会は日々の活動には関与せず、報告書を通じたモニタリングと重要な意思決定に専念する
- 権限の委任: PMやチーム・マネージャーに適切な権限を与え、意思決定プロセスを明確に定義することが重要
主要な役割
- 外部との連携: ビジネス・レイヤーの戦略とプロジェクトを整合させ、コミュニケーション・チャネルとしての役割を担う
- 統一された指揮: PMに対して矛盾のない一貫したガイダンスを提供する(委員会内で意見が分かれた場合はプロジェクト・エグゼクティブが最終決定を下す)
助言とガイダンス
- 双方向のやり取り: 委員会からPMへ非公式な助言を与え、PMからも必要に応じて助言を求めるなど、双方向のコミュニケーションが重要

活動

インプット	活動	アウトプット
プロジェクト立ち上げの要求(トリガー) ビジネス・ケース概要(レビュー) プロジェクト要約書(レビュー) プロジェクト成果物記述書(レビュー) ステージ計画書・立ち上げ用(レビュー)	立ち上げの認可	ビジネス・ケース概要(承認済み) プロジェクト要約書(承認済み) プロジェクト成果物記述書(承認済み) ステージ計画書・立ち上げ用(承認済み) 立ち上げ通知プロジェクト立ち上げの認可(立ち上げプロセスをトリガー)
プロジェクト認可の要求(トリガー) プロジェクト立ち上げ文書(レビュー) ビジネス・ケース(レビュー)	プロジェクトの認可	プロジェクト立ち上げ文書(承認済み) ビジネス・ケース(承認済み) プロジェクト認可の通知
次のステージの要求(トリガー) 例外計画書の承認の要求(トリガー) ステージ終了報告書(レビュー) ステージ計画書・次のステージ用(レビュー) プロジェクト計画書(確認) ビジネス・ケース(確認)	ステージまたは例外計画書の認可	ステージ終了報告書(承認済み) ステージ計画書・次のステージ用(承認済み) プロジェクト計画書(必要に応じて更新・承認済み) ビジネス・ケース(必要に応じて更新・承認済み) 認可されたステージまたは例外(CSプロセスをトリガー) プロジェクト立ち上げ文書(必要に応じて更新・承認済み)
助言の要求(トリガー) 例外の提起(トリガー) 教訓報告書(レビュー) ハイライト報告書(レビュー) 課題報告書(レビュー) 例外報告書(レビュー) ビジネス・ケース(確認)	継続的な指揮	例外計画書の要求(SBプロセスをトリガー) プロジェクト委員会の助言と決定(CSプロセスをトリガー) 早期クローズの通知(CPプロセスをトリガー)
プロジェクトのクローズの要求(トリガー) プロジェクト終了報告書(レビュー) ビジネス・ケース(確認)	プロジェクトのクローズの認可	プロジェクトのクローズの通知

各活動の詳細

立ち上げの認可

プロジェクトの立ち上げには相応の時間・コスト・リソースの投資が必要となる。この活動の目的は、プロジェクト委員会がその投資に価値があるかを厳密に判断し、正式なゴーサインを出すこと。

プロジェクト委員会に推奨される処置

整合性と妥当性の確認
- プロジェクト・アプローチがビジネスの方針に整合していることを確認する
- ビジネス・ケース概要が実行可能であり、戦略的な目標に貢献するかを確認する
主要文書の承認
- プロジェクト要約書およびプロジェクト成果物記述書をレビューし、承認する
計画とリソースの確定
- 立ち上げステージのためのステージ計画書を承認し、許容度(トレランス) を設定する
- 必要な人員・設備・プロジェクト支援などのロジスティック面の確保を指示する
通知と認可
- 利害関係者や関連部門に対し、プロジェクトが立ち上げステージに入ったことを通知する
- PMに対し、立ち上げステージの開始を正式に認可する

プロジェクトの認可

立ち上げステージの最後に、PMからプロジェクト実行の認可要求を受けることで開始される。プロジェクト委員会は資金やリソースを投入する前に、以下が確保されているかを厳格に判断する。

ビジネス正当性: 堅固なビジネス・ケースが存在し、プロジェクトが実行可能かつ有益であるか
実現可能性: プロジェクト計画書とベネフィット・マネジメント・アプローチが、期待される価値を確実に提供できるか
管理体制: マネジメント・アプローチとコントロールが、計画の達成を適切に支援できるか

プロジェクト委員会がプロジェクトを認可しなかった場合、プロジェクトはその時点で早期クローズしなければならない。

プロジェクト委員会に推奨される処置

文書と基準の承認
- プロジェクト立ち上げ文書(PID) をレビューし、承認する
- プロジェクト全体の許容度(トレランス) を確認し、合意する
妥当性のチェック
- 過去の類似プロジェクトからの教訓が計画に反映されているかを確認する
- リスク(脅威と機会)に対する対応策が適切に計画されているかを確認する
リソースの確保と通知
- プロジェクト完遂に必要な人員とリソースを確保・コミットする(ステージごとにPMへ提供される)
- プロジェクトが認可されたことをビジネスや利害関係者に公式に通知する
最終指示
- PMに対し、プロジェクトの実行を認可する(または不認可の場合は早期クローズを指示する)

継続的な指揮

プロジェクト委員会は、認可のタイミングだけでなく、プロジェクトの全期間を通じてPMを支援し、進捗をコントロールする。

継続的な指揮がトリガーされる主な場面：

一般的な助言: ビジネスの持続可能性目標(ESG 要件など)の明確化
要求対応: 対立の解消や複雑な選択肢の絞り込み
報告書対応: ハイライト報告書・例外報告書・課題報告書の受領
外部変化: ビジネス優先度の変更や外部要因によるプロジェクトへの影響
懸念事項: プロジェクト委員会メンバーの個別の懸念事項
体制変更: 委員会の構成員の変更

ステージ内で許容度を超える事態(例外)が発生した場合：

例外計画の認可: ステージの許容度を超える例外が発生した場合、委員会は例外計画書を審査し承認する。承認された計画は新たなベースラインとなる
プロジェクト権限委任の変更: ビジネス側から方針変更やクローズの指示があった場合、委員会は以下のいずれかを選択する
- 変更要求として扱う: PMにステージまたはプロジェクトの再計画を求める
- 早期クローズと再開始: 現在のプロジェクトを停止し、新しい権限委任に基づいて開始する

プロジェクト委員会に推奨される処置

助言と支援: PMからの非公式な要求に対し、必要なリサーチや助言を行い支援する
エスカレーション対応
- 課題: 意思決定を下す。仕様外項目の場合、拒否(修正要求) または条件付き承認(現状受け入れ) を判断する
- 例外報告書: 内容を精査し、続行の可否を決定する
進捗の監視: ハイライト報告書を確認し、必要に応じて是正措置を講じる
情報の伝達: ビジネスからの決定や方針変更を速やかにPMに通知する

ステージまたは例外計画書の認可

プロジェクト委員会による正式な承認なしに、次のステージを開始してはならない。この活動により、現在の実績を確認し、次の活動への投資を正当化する。

全ステージでの必須プロセス: すべてのステージを開始する前に、必ずこの承認プロセスを経る
レビューの焦点: 現在のステージのパフォーマンス(実績)を確認した上で、次のステージ計画書(または例外計画書)が妥当であるかを判断する

プロジェクト委員会に推奨される処置

実績の評価: ステージ終了報告書をレビューし、承認する
計画の審査: PMが承認を求めているステージ計画書または例外計画書を精査する
意思決定の実行
1. 計画を承認し、次へ進める
2. 計画を却下し、PMに再考・修正を依頼する
3. プロジェクトの正当性が失われたと判断し、早期クローズを指示する
ステータスの伝達: コミュニケーション・マネジメント・アプローチに基づき、最新状況をビジネスや利害関係者に通知する

プロジェクトのクローズの認可

プロジェクトを制御された状態で終了させることは、開始時と同等に重要。プロジェクト委員会は、当初の計画(PID)と最終的な実績を比較評価し、プロジェクトがその役割を全うしたことを確認する。

コントロールされた方法でクローズが行われない場合のリスク：

運用側への移管が不完全になり、ベネフィットが実現されない
プロジェクトチームが解放されず、次の業務に支障をきたす
プロジェクトの最終的な成否や逸脱の度合いが曖昧になる

プロジェクト委員会に推奨される処置

達成状況の評価
- プロジェクト立ち上げ文書(PID) の初期版と最終版を比較し、目標の達成度や計画からの逸脱を評価する
- プロジェクト終了報告書をレビューし、承認する
ベネフィット管理の移管
- 更新されたベネフィット・マネジメント・アプローチを承認する
- プロジェクト終了後にしか確認できないベネフィットの評価責任を、ビジネス(運用側)へ正式に移管する
ビジネス・ケースの最終確認
- 実績値(コスト・リスク・期間)をビジネス・ケース概要と比較し、最終的な正当性を評価する
通知とリソースの解放
- コミュニケーション・マネジメント・アプローチに従い、関係各所へクローズを正式通知する
- 支援インフラやリソースの撤去・返却を指示し、コスト計算を止めるための終了日を明記する
- チームメンバーのオフボーディング(解任手続き) が正しく行われていることを確認する

適用

一般的な考慮事項

このプロセスを実務に適用する際は、指揮と管理の境界線を明確にすることが最も重要である。

プロジェクト・エグゼクティブの責務: このプロセスのすべての活動は、最終的にプロジェクト・エグゼクティブが責任を負う
作業の委任: プロジェクト・エグゼクティブは実務的な作業を他の担当者に任せることができるが、主要な決定や認可を行う権限はエグゼクティブ自身に留まる
PMは、プロジェクト・エグゼクティブの責任範囲にある事項(プロジェクトの認可・資金の最終承認・戦略的判断など)について、自ら決定を下したり承認したりすることはできない

役割のテーラリング

プロジェクト保証を委任できる場面：

立ち上げの認可: 立ち上げステージ計画書の妥当性確認をプロジェクト保証に委任できる
プロジェクトの認可: コミュニケーション・マネジメント・アプローチの検査などを委任できる
継続的な指揮: 変更要求のインパクト評価の検査などを委任できる

いずれの場合も、最終的な説明責任はプロジェクト委員会が負う。

責任

活動	ビジネス・レイヤー	プロジェクト・エグゼクティブ	シニア・ユーザー	シニア・サプライヤー	プロジェクト・マネージャー	チーム・マネージャー	プロジェクト保証	プロジェクト支援
立ち上げの認可	I	A/R	—	—	—	—	—	—
プロジェクトの認可	I	A/R	C	C	I	I	C	I
継続的な指揮	C	A/R¹	R²	R³	C/I	I	C	I
ステージまたは例外計画書の認可	I	A/R	C	C	I	I	C	I
プロジェクトのクローズの認可	I	A/R	C	C	I	I	C	I

R = 実行責任、A = 説明責任、C = 協議先、I = 情報先

R¹: ビジネス関連
R²: ユーザー関連
R³: サプライヤー関連

プロセスへのプラクティスの適用

プラクティス	プロジェクトの指揮プロセスへの適用
ビジネス・ケース	戦略との整合性・実行可能性を確認し、ビジネス・ケースの各バージョンを承認する。ベネフィットおよび持続可能性の許容度をビジネス側と合意し、ステージごとの許容度を設定する
組織化	ビジネス・ユーザー・サプライヤーの3つの利益を代表する適切な権限者が委員会を構成する。PMチーム組織・各マネジメント・アプローチ(商業・コミュニケーション・変更)・デリバリー・モデルを承認する
計画	計画や手法が戦略や主要マイルストーンと整合しているかをレビューする。プロジェクト計画書・各ステージ計画書・例外計画書を承認し、必要な資金・人員・リソースをコミット(確約)する
品質	シニア・ユーザーが期待品質と受け入れ基準を定義する。プロジェクト保証の実行責任を負い、各マネジメント・アプローチや成果物記述書を承認する。品質許容度を合意・設定する
リスク	立ち上げ前や各ステージ承認前に高レベルのリスクを検討する。リスク・マネジメント・アプローチを承認し、全体のリスクレベルが許容範囲内であることを継続的に確認する
課題	課題マネジメント・アプローチを承認し、提起された課題にタイムリーに対応する。必要に応じて変更許可委員を委任し、変更予算の設定を決定する
進捗	デジタルおよびデータ管理アプローチを承認する。時間・コスト・スコープの許容度をビジネスと合意し、ハイライト報告書や例外報告書を通じて計画どおりの進行を監督する

他フレームワーク補足

概念	PRINCE2	PMBOK	PgMP
ガバナンス主体	プロジェクト委員会(DP)	スポンサー/ステアリング委員会	プログラム・ガバナンス委員会
例外によるマネジメント	許容度内はPMに委任、超過時にエスカレーション	変更要求管理・エスカレーションプロセス	(今後追記)
認可のタイミング	各ステージ前に必須	フェーズゲートレビュー	(今後追記)