プロジェクト・マネジメント-プロジェクトの指揮 | 项目管理

プロジェクトの指揮

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

達成目標

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

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

位置付け

トリガー

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

実施のポイント

運用
- 例外によるマネジメント: プロジェクト委員会は日々の活動には関与せず、報告書を通じたモニタリングと重要な意思決定に専念する。これにより、委員会メンバーが過度な業務負担を負うことなく、効果的なガバナンスを維持できる仕組みとなっている。
- 権限の委任: PMやチーム・マネージャーに適切な権限を与え、意思決定プロセスを明確に定義することが重要である。
主要な役割委員会はプロジェクトと**ビジネス・レイヤー(組織の戦略層)**をつなぐ架け橋として機能する。
- 外部との連携: ビジネス・レイヤーの戦略とプロジェクトを整合させ、コミュニケーション・チャネルとしての役割を担う。
- 統一された指揮: PMに対して矛盾のない、一貫したガイダンスを提供する。 ※委員会内で意見が分かれた場合は、プロジェクト・エグゼクティブが最終決定を下す。一貫性のない指示は、プロジェクトを停滞させる大きなリスクとなる。＊このプロセスはあくまでプロジェクト委員会の活動に焦点を当てたものであり、PMの実務を細かく管理(マイクロマネジメント)するためのものではない。PMに適切な権限を与え、自律的なチーム運営を促すことが、プロジェクト成功の鍵となる。
助言とガイダンス公式な決定(指揮)だけでなく、非公式なサポートも重要である。
- 双方向のやり取り:
  - 委員会からPMへ: プロジェクト外の状況変化を伝え、非公式な助言を与える。
  - PMから委員会へ: 必要に応じて専門的な知見や助言を求める。

活動

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

立ち上げの認可

プロジェクトの立ち上げ(Initiation)には相応の時間、コスト、リソースの投資が必要となる。

＊この活動の目的は、プロジェクト委員会がその投資に価値があるかを厳密に判断し、正式なゴーサインを出す。

意思決定のプロセス プロジェクトの始動プロセスの最終ステップとして、プロジェクト・マネージャー(PM)から立ち上げ要求を受けた際に行われる。
- 形式: 公式な会議を開く場合もあれば、持ち回りでの承認となる場合もある。
- 必須条件:
  - 委員会の全メンバーが決定に合意していること。
  - プロジェクト・エグゼクティブからPMに対し、文書による立ち上げ指示が出されていること。
- プロジェクト保証の活用: 委員会のメンバーが多忙な場合、立ち上げステージ計画書の妥当性確認をプロジェクト保証(個人またはグループ)に委任することができる。ただし、最終的な説明責任が負う。
プロジェクト委員会に推奨される処置委員会は、立ち上げを認可するにあたり、以下のチェックとアクションを実行する。
- 整合性と妥当性の確認
  - プロジェクト・アプローチが組織(ビジネス)の方針と一致しているか。
  - ビジネス・ケース概要が実行可能であり、戦略的な目標に貢献するか。
- 主要文書の承認
  - プロジェクト要約書およびプロジェクト成果物記述書をレビューし、承認する。
- 計画とリソースの確定
  - 立ち上げステージのためのステージ計画書を承認し、ステージに対する許容度(トレランス) を設定する。
  - 必要な人員、設備(通信設備、備品)、プロジェクト支援などのロジスティック面の確保を指示する。
- 通知と認可
  - 利害関係者や関連部門に対し、プロジェクトが立ち上げステージに入ったことを公式に通知する。
  - PMに対し、立ち上げステージの開始を正式に認可する。

プロジェクトの認可

立ち上げステージの最後に、PMからプロジェクト実行の認可要求を受けることで開始される。

目的と達成目標プロジェクト委員会は資金やリソースを投入する前に、以下のことが確保されているかを厳格に判断する。
- ビジネス正当性: 堅固なビジネス・ケースが存在し、プロジェクトが実行可能でかつ有益であるか。
- 実現可能性: プロジェクト計画書とベネフィット・マネジメント・アプローチが、期待される価値を確実に提供できるか。
- 管理体制: マネジメント・アプローチ(品質、リスク、課題など)とコントロールが、計画の達成を適切に支援できるか。＊プロジェクト委員会がプロジェクトを認可しなかった(正当性がないと判断した)場合、プロジェクトはその時点で早期クローズしなければならない。
プロジェクト保証の活用委員会は、詳細なレビュー(例: コミュニケーション・マネジメント・アプローチが適切か等の検査)をプロジェクト保証(個人またはグループ)に委任することができる。ただし、最終的な説明責任が負う。
プロジェクト委員会に推奨される処置認可を下す際、委員会は以下の具体的なアクションを実行する。
- 文書と基準の承認
  - プロジェクト立ち上げ文書(PID) をレビューし、承認する。
  - プロジェクト全体の許容度(トレランス) を確認し、合意する。
- 妥当性のチェック
  - 過去の類似プロジェクトからの教訓が計画に反映されているかを確認する。
  - レビューが実施済みであるリスク(脅威と機会)に対する対応策が適切に計画されているかを確認する。
- リソースの確保と通知
  - プロジェクト完遂に必要な人員とリソースを確保、または提供を約束(コミット)する(これらは、各ステージの承認ごとに順次 PMへ提供される)。
  - プロジェクトが認可されたことをビジネスや利害関係者に公式に通知する。
- 最終指示
  - PMに対し、プロジェクトの実行を認可する。または、不認可の場合は早期クローズを指示する。

継続的な指揮

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

指導とガイダンスの提供プロジェクト委員会のメンバーは、PMからの助言要求に対し、随時(特に立ち上げ時やステージ境界付近で)非公式なガイダンスや助言を提供する。
- 継続的な指揮がトリガーされる主な場面:
  - 一般的な助言: ビジネスの持続可能性目標(ESG 要件など)の明確化。
  - 要求対応: 対立の解消や、複雑な選択肢の絞り込み。
  - 報告書対応: ハイライト報告書、例外報告書、課題報告書の受領。
  - 外部変化: ビジネス優先度の変更や、外部要因によるプロジェクトへの影響。
  - 懸念事項: プロジェクト委員会メンバーの個別の懸念事項。
  - 体制変更: 委員会の構成員の変更。
例外と変更への対応ステージ内で許容度を超える事態(例外)が発生した場合、委員会は以下の原則に従って意思決定を行う。
- 例外計画の認可: ステージの許容度を超える例外が発生した場合、委員会は例外計画書を審査し、承認する。承認された計画は新たなベースラインとなる。 ※ワーク・パッケージ(WP)レベルの例外はPMが処理し、プロジェクトレベルの例外はビジネスの承認が必要となる。
- プロジェクト権限委任の変更: ビジネス側から方針変更やクローズの指示があった場合、委員会は以下のいずれかを選択する。
  1. 変更要求として扱う: PMにステージまたはプロジェクトの再計画を求める。
  2. 早期クローズと再開始: 現在のプロジェクトを停止し、新しい権限委任に基づいてゼロから開始する(追加コストがかかる可能性がある)。
プロジェクト保証の委任委員会は、変更要求のインパクト評価が適切かどうかの検査など、実務的な評価措置をプロジェクト保証(個人またはグループ)に委任することができる。ただし、最終的な説明責任が負う。
プロジェクト委員会に推奨される処置委員会は、PMを適切にコントロールするために以下の実務を行う。
- 助言と支援: PMからの非公式な要求に対し、必要なリサーチや助言を行い支援する。
- エスカレーション対応:
  - 課題: 意思決定を下す。仕様外項目の場合、拒否(修正要求) または条件付き承認(現状受け入れ) を判断する。
  - 例外報告書: 内容を精査し、続行の可否を決定する。
- 進捗の監視: ハイライト報告書を確認し、必要に応じて是正措置を講じる。
- 情報の伝達: ビジネスからの決定や方針変更を速やかにPMに通知する。

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

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

認可の基本原則 * 全ステージでの必須プロセス: すべてのステージを開始する前に、必ずこの承認プロセスを経る。なんとなく次の作業に入るといった曖昧な進行を排除するためである。 * レビューの焦点: 現在のステージのパフォーマンス(実績)を確認した上で、次のステージ計画書(または立て直しのための例外計画書)が妥当であるかを判断する。
プロジェクト保証の委任委員会は、計画書の詳細な検査(実行可能性の確認など)をプロジェクト保証(個人またはグループ)に委任することができる。ただし、最終的な説明責任が負う。
プロジェクト委員会に推奨される処置委員会は、以下のステップを通じてガバナンスを効かせ、次のステップへのゴーサインを出す。
- 実績の評価: ステージ終了報告書をレビューし、承認する。
- 計画の審査: PMが承認を求めているステージ計画書または例外計画書を精査する。
- 意思決定の実行: 委員会の判断は、状況に応じて以下の3つのいずれかとなる。
  1. 計画を承認し、次へ進める。
  2. 計画を却下し、PMに再考・修正を依頼する。
  3. プロジェクトの正当性が失われたと判断し、早期クローズを指示する。
- ステータスの伝達: コミュニケーション・マネジメント・アプローチに基づき、プロジェクトの最新の進捗状況をビジネスや利害関係者にを通知する。

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

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

目的と重要性プロジェクト委員会は、解散前の最後の活動として、当初の計画(ベースライン)と実績を比較評価する。
- 達成度の評価: 当初のプロジェクト立ち上げ文書(PID)やプロジェクト計画書に掲げた目標が達成されたかを確認する。
- 逸脱の把握: 計画からどの程度の乖離が生じたか、またはこれ以上プロジェクトを継続しても追加の貢献が見込めない状態(＝完了)であるかを判断する。
クローズが不適切な場合のリスクコントロールされた方法でクローズが行われない場合、以下のリスクが生じる。
- 運用側への移管が不完全になり、ベネフィットが実現されない。
- プロジェクトチームが解放されず、次の業務に支障をきたす。
- プロジェクトの最終的な成否や逸脱の度合いが曖昧になる。
プロジェクト委員会に推奨される処置委員会は、責任を持ってプロジェクトを終了させるために以下の実務を行う。
- 達成状況の評価
  - プロジェクト立ち上げ文書(PID) の初期版と最終版を比較し、目標の達成度や計画からの逸脱を評価する。
  - プロジェクト終了報告書をレビューし、承認する。
- ベネフィット管理の移管
  - 更新されたベネフィット・マネジメント・アプローチを承認する。
  - プロジェクト終了後にしか確認できないベネフィットの評価責任を、ビジネス(運用側)へ正式に移管する。
  - 運用時の成果物のパフォーマンスや、予期せぬ副作用(有益・有害双方)を特定できる体制を確認する。
- ビジネス・ケースの最終確認
  - 実績値(コスト、リスク、期間)をビジネス・ケース概要と比較し、最終的な正当性を評価する。
- 通知とリソースの解放
  - コミュニケーション・マネジメント・アプローチに従い、関係各所へクローズを正式通知する。
  - 支援インフラやリソースの撤去・返却を指示し、コスト計算を止めるための終了日を明記する。
  - チームメンバーのオフボーディング(解任手続き) が正しく行われていることを確認する。

適用

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

プロジェクト・エグゼクティブの責務プロジェクトの指揮におけるすべての活動は、最終的にプロジェクト・エグゼクティブが責任(実行責任および説明責任)を負う。
- 作業の委任: プロジェクト・エグゼクティブは、プロセス内の実務的な作業を他の担当者に任せることができる。
- 意思決定の保持: 作業を委任したとしても、主要な決定や認可を行う権限はエグゼクティブ自身に留まる。
実務上のポイント
- 自律性とガバナンスの両立: PMには日々の管理権限が委任されるが、それはあくまで合意された許容度の範囲内である。その範囲を超える、またはプロジェクトの前提に関わる判断は、必ずプロジェクト・エグゼクティブ(およびプロジェクト委員会)が担う。＊PMは、プロジェクト・エグゼクティブの責任範囲にある事項(プロジェクトの認可、資金の最終承認、戦略的判断など)について、自ら決定を下したり、承認したり、指揮を執ったりすることはできない。
- 一貫した指揮: 役割を分離することで、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³: サプライヤー関連

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

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

＊プロジェクト委員会の役割は作業ではなくガードレールの設定と通過許可に集約されている。

認可 (Authorize): 計画書やアプローチが適切か判断し、GOサインを出す。
合意 (Agree): ビジネス側(経営層)とプロジェクト・レベルの限界値(許容度)を合意する。
確約 (Commit): 計画達成に必要なリソースを、口先だけでなく実際に確保する。
対応 (Respond): 例外や課題が発生した際、PMが動けなくなる前に迅速に指揮を執る。