湖心の静寂、心安らぐ場所https://blog.issyuu.comzh-CNhttps://blog.issyuu.com/zh/post/pm-processes-close-dzh:pm-processes-close-d生きている限り、学び続けるWed, 22 Apr 2026 04:12:12 GMT<h2>プロジェクトのクローズ<a href="#プロジェクトのクローズ"><span></span></a></h2> <blockquote> <p>プロジェクトのクローズの目的は、プロジェクト成果物の受け入れが確認される<strong>終止符</strong>を打ち。PIDで定めた目標が達成されたことを認識し、漫然とした運用の継続を防ぐ。</p> </blockquote> <h3>達成目標<a href="#達成目標"><span></span></a></h3> <blockquote> <p>単なる作業の停止ではなく、以下の事項を確実に完了させる。</p> </blockquote> <ul> <li><strong>ユーザー受け入れの確認</strong>: プロジェクト成果物がユーザーに承認されたことを確認する。</li> <li><strong>運用体制の確立</strong>: クローズ後もビジネス側で成果物を支援・維持できる体制を整える。</li> <li><strong>実績評価</strong>: パフォーマンスをベースラインと比較・レビューする。</li> <li><strong>ベネフィットの評価</strong>: 実現済みのベネフィットを確認し、プロジェクト後のレビュー計画(ベネフィット・マネジメント・アプローチ)を更新する。</li> <li><strong>未解決事項への対処</strong>: 未解決の課題やリスクを<strong>継続対応勧告</strong>としてまとめ、適切な担当者へ引き継ぐ。</li> <li><strong>整然とした終了</strong>: 早期クローズであっても、単にプロジェクトを放置(放棄)せず、手続きに従って終了させる。</li> </ul> <h3>位置付け<a href="#位置付け"><span></span></a></h3> <h4>明確な終了がもたらすメリット<a href="#明確な終了がもたらすメリット"><span></span></a></h4> <blockquote> <p>プロジェクトを正式に閉じることで、組織に以下の効果をもたらす。</p> </blockquote> <ul> <li><strong>成功の認識</strong>: 達成目標が満たされたことを全関係者が認識できる。</li> <li><strong>責任の移転</strong>: プロジェクト成果物のオーナーシップが運用側へ正式に移転し、プロジェクト・マネジメント・チームは責任から解放され、解散が可能になる。</li> <li><strong>コストの遮断</strong>: 以降、プロジェクトとしてのコストが停止できる。</li> <li><strong>学習の機会</strong>: 未達成のゴールを特定し、将来の取り組み課題として整理できる。</li> </ul> <h4>実施のポイント<a href="#実施のポイント"><span></span></a></h4> <ul> <li><strong>有限性の確保</strong>: プロジェクトが<strong>始まりと終わりのある活動</strong>としての特性を維持するために不可欠なフェーズである。</li> <li><strong>早期クローズへの対応</strong>: ビジネス・ケースの失効などで途中で打ち切る場合も、投げ出さずに<strong>整然とした終了</strong>を行うための枠組みを提供する。</li> <li><strong>計画的なクローズ</strong>: クローズ活動は、<strong>最終マネジメント・ステージの計画書</strong>の一部としてあらかじめ組み込んでおく。</li> <li><strong>継続対応勧告</strong>: 終了後に実施すべき特定の処置を文書化する。対象者のニーズに合わせ、報告書形式やミーティングなど、最適な形式で提供する。</li> <li><strong>通知</strong>: プロジェクト・エグゼクティブは、ビジネス・レイヤー(組織の上層部)に対してプロジェクトの終了を正式に通知する。</li> </ul> <h3>活動<a href="#活動"><span></span></a></h3> <table><thead><tr><th>インプット</th><th>活動</th><th>アウトプット</th></tr></thead><tbody><tr><td>プロジェクト終了が近づく(このプロセスをトリガー)<br />プロジェクト・ログ(レビュー)<br />プロジェクト立ち上げ文書(確認)<br />ビジネス・ケース(確認)<br />プロジェクト計画書(レビュー)</td><td>計画されたクローズの準備</td><td>プロジェクト・ログ(更新)<br />プロジェクト計画書(必要に応じて更新)<br />ベネフィット・マネジメント・アプローチ(必要に応じて更新)<br />教訓報告書(作成)<br />プロジェクト終了報告書(作成)</td></tr><tr><td>プロジェクト終了が近づく(このプロセスをトリガー)<br />プロジェクト・ログ(レビュー)<br />プロジェクト立ち上げ文書(確認)<br />ビジネス・ケース(確認)<br />プロジェクト計画書(レビュー)</td><td>プロジェクトの受け入れの確認</td><td>プロジェクト・ログ(更新)<br />プロジェクト計画書(必要に応じて更新)<br />ベネフィット・マネジメント・アプローチ(必要に応じて更新)<br />教訓報告書(作成)<br />プロジェクト終了報告書(作成)</td></tr><tr><td>プロジェクト終了が近づく(このプロセスをトリガー)<br />プロジェクト・ログ(レビュー)<br />プロジェクト立ち上げ文書(確認)<br />ビジネス・ケース(確認)<br />プロジェクト計画書(レビュー)</td><td>プロジェクトの評価</td><td>プロジェクト・ログ(更新)<br />プロジェクト計画書(必要に応じて更新)<br />ベネフィット・マネジメント・アプローチ(必要に応じて更新)<br />教訓報告書(作成)<br />プロジェクト終了報告書(作成)</td></tr><tr><td>プロジェクト終了が近づく(このプロセスをトリガー)<br />プロジェクト・ログ(レビュー)<br />プロジェクト立ち上げ文書(確認)<br />ビジネス・ケース(確認)<br />プロジェクト計画書(レビュー)</td><td>プロジェクトのクローズの要求</td><td>プロジェクト・ログ(更新)<br />プロジェクト計画書(必要に応じて更新)<br />ベネフィット・マネジメント・アプローチ(必要に応じて更新)<br />教訓報告書(作成)<br />プロジェクト終了報告書(作成)</td></tr><tr><td>早期クローズの要求(このプロセスをトリガー)<br />プロジェクト・ログ(レビュー)<br />プロジェクト立ち上げ文書(確認)<br />ビジネス・ケース(確認)<br />プロジェクト計画書(レビュー)</td><td>早期クローズの準備</td><td>プロジェクト・ログ(更新)<br />プロジェクト計画書(必要に応じて更新)<br />ベネフィット・マネジメント・アプローチ(必要に応じて更新)<br />教訓報告書(作成)<br />プロジェクト終了報告書(作成)</td></tr><tr><td>早期クローズの要求(このプロセスをトリガー)<br />プロジェクト・ログ(レビュー)<br />プロジェクト立ち上げ文書(確認)<br />ビジネス・ケース(確認)<br />プロジェクト計画書(レビュー)</td><td>プロジェクトの受け入れの確認</td><td>プロジェクト・ログ(更新)<br />プロジェクト計画書(必要に応じて更新)<br />ベネフィット・マネジメント・アプローチ(必要に応じて更新)<br />教訓報告書(作成)<br />プロジェクト終了報告書(作成)</td></tr><tr><td>早期クローズの要求(このプロセスをトリガー)<br />プロジェクト・ログ(レビュー)<br />プロジェクト立ち上げ文書(確認)<br />ビジネス・ケース(確認)<br />プロジェクト計画書(レビュー)</td><td>プロジェクトの評価</td><td>プロジェクト・ログ(更新)<br />プロジェクト計画書(必要に応じて更新)<br />ベネフィット・マネジメント・アプローチ(必要に応じて更新)<br />教訓報告書(作成)<br />プロジェクト終了報告書(作成)</td></tr><tr><td>早期クローズの要求(このプロセスをトリガー)<br />プロジェクト・ログ(レビュー)<br />プロジェクト立ち上げ文書(確認)<br />ビジネス・ケース(確認)<br />プロジェクト計画書(レビュー)</td><td>プロジェクトのクローズの要求</td><td>プロジェクト・ログ(更新)<br />プロジェクト計画書(必要に応じて更新)<br />ベネフィット・マネジメント・アプローチ(必要に応じて更新)<br />教訓報告書(作成)<br />プロジェクト終了報告書(作成)</td></tr></tbody></table> <h4>計画されたクローズの準備<a href="#計画されたクローズの準備"><span></span></a></h4> <blockquote> <p>プロジェクトが完了条件を満たし、クローズ可能な状態にあることを確認した上で、プロジェクト委員会に対して<strong>クローズ勧告</strong>を行うための準備を整える活動である。</p> </blockquote> <ol> <li>PMに推奨される処置 <ul> <li>関係者への周知と広報 <ul> <li><strong>通知対象の特定</strong>: コミュニケーション・マネジメント・アプローチに基づき、終了を知らせるべき組織や利害関係者を特定する。 ＊<strong>価値の最大化</strong>: 単なる終了通知だけでなく、広報(PR)やマーケティングの機会として活用できるコミュニケーション活動についても検討する。</li> </ul> </li> <li>記録の整理と保管 <ul> <li><strong>ログの閉鎖</strong>: 運用中だった各種プロジェクト・ログを正式にクローズする。</li> <li><strong>アーカイブの確保</strong>: 将来の監査や教訓の参照に備え、デジタルおよびデータ・マネジメント・アプローチに従ってプロジェクト情報を安全に保管する。 ＊チームの意思決定やパフォーマンスの正当性を証明可能にする。</li> </ul> </li> <li>最終手続きの起案 <ul> <li><strong>通知案の作成</strong>: プロジェクト委員会がレビュー・承認するための<strong>プロジェクトのクローズ通知(案)</strong> を準備する。</li> </ul> </li> </ul> </li> </ol> <h4>早期クローズの準備<a href="#早期クローズの準備"><span></span></a></h4> <blockquote> <p>ビジネス・ケースの失効などにより、プロジェクト委員会から早期終了の指示があった際に実施する活動である。</p> </blockquote> <ol> <li>実施のポイント <ul> <li><strong>価値の回収</strong>: 進行中の作業を単に放棄するのではなく、それまでに生み出された価値(成果物)を可能な限り回収する。</li> <li><strong>透明性の確保</strong>: プロジェクトの中止によって生じたビジネス上の損失を明確に示す。</li> </ul> </li> <li>PMに推奨される処置 PMは、混乱を最小限に抑え、組織の資産を守るために以下の処置を講じる。 <ul> <li>現状の記録と評価 <ul> <li><strong>要求の記録</strong>: 早期クローズの要求をプロジェクト・ログや課題報告書に記録し、プロジェクト計画書を最終実績に基づいて更新する。</li> <li><strong>成果物の仕分け</strong>: プロジェクト支援と連携し、各成果物のステータスを以下の観点で評価・分類する。 <ul> <li>承認済み / 開発中 / 条件付き承認済み / 未着手</li> <li>安全確保(養生やデータ保護)が必要なもの</li> <li>他のプロジェクトで転用・再利用できる可能性があるもの</li> </ul> </li> </ul> </li> <li>価値の回収と追加作業 <ul> <li><strong>回収手段の合意</strong>: 作成中の成果物をどう扱うか(完成させるか、現状で保存するか、廃棄するか)、プロジェクト委員会と協議して決定する。</li> <li><strong>追加作業の実施</strong>: 他プロジェクトに役立つ成果物の完成や、未完成状態での安全確保(例: 建設途中の建物の耐候処理など)が必要な場合、その作業を計画する。状況によっては、これらの対応のために<strong>例外計画書</strong>の作成が必要になる。</li> </ul> </li> <li>リソースの管理 <ul> <li><strong>リソースの解放</strong>: 人員や資材を予定より早くリリース(解散)できる見込み、またはその準備が整ったことをビジネス側に通知し、承認を得る。</li> </ul> </li> </ul> </li> </ol> <h4>プロジェクトの受け入れの確認<a href="#プロジェクトの受け入れの確認"><span></span></a></h4> <blockquote> <p>プロジェクト成果物のオーナーシップを、プロジェクト・マネジメント・チームから運用および保守環境(ユーザー側)へ正式に移管することを確認する活動である。</p> </blockquote> <ol> <li>実施のポイント <ul> <li><strong>移管の柔軟性</strong>: 移管はプロジェクト終了時の単一リリースだけでなく、フェーズごとの段階的なデリバリーも含まれる。</li> <li><strong>早期クローズ</strong>: プロジェクトが途中で終了する場合でも、承認済みの成果物については、プロジェクト委員会の指示に従ってオーナーシップをユーザーに移管する。</li> <li><strong>ベネフィット・マネジメント・アプローチの更新</strong>: 成果物の提供に伴い、アプローチを更新する必要がある。これには、プロジェクト終了後のベネフィット・レビューや運用時のパフォーマンス・レビューの計画を含める。これにより、予期せぬ副産物(有益なものも有害なものも含む)や教訓を特定することが可能になる。</li> <li><strong>プロジェクト外の活動</strong>: プロジェクト完了後の実際のベネフィット・レビュー自体はプロジェクト活動ではない。プロジェクトの責務は、あくまで<strong>レビューが確実に実施されるように計画を立てること</strong>である。</li> </ul> </li> <li>PMに推奨される処置 <ul> <li>継続対応勧告の作成 <ul> <li><strong>未解決事項の引き継ぎ</strong>: 未完了の作業、残存する課題、リスクに対処するための<strong>継続対応勧告</strong>を準備する。</li> <li><strong>対象者別の最適化</strong>: 人事・財務・業務など、成果物を利用する特定のユーザーグループごとに個別のアクションプランを作成する場合もある。</li> </ul> </li> <li>計画の最終確認 <ul> <li><strong>評価活動の記載</strong>: ベネフィット・マネジメント・アプローチに、運用開始後のベネフィット測定活動が正しく記載されているかを確認する。 ＊この活動は、プロジェクト成果物がしばらく運用された後で初めて測定できるベネフィット(信頼性パフォーマンスなど)を確認する目的で実施する。</li> <li><strong>移管方法の遵守</strong>: PIDを調査し、運用担当者への適切な成果物提供手順(トレーニングやマニュアル提供など)を確認・実行する。</li> </ul> </li> </ul> </li> </ol> <h4>プロジェクトの評価<a href="#プロジェクトの評価"><span></span></a></h4> <blockquote> <p>プロジェクトの全工程を振り返り、当初の計画に対してどれほど成功したかを客観的に評価する活動である。</p> </blockquote> <ol> <li>実施のポイント <ul> <li><strong>組織学習の促進</strong>: プロジェクトの経験を組織の資産として活用する。成功要因だけでなく、早期クローズに至った理由も分析し、将来のプロジェクトの成功率を高める。</li> <li><strong>見積精度の上昇</strong>: 今回のプロジェクトにおける<strong>見積もり</strong>と<strong>実際の実績(測定基準)</strong> を比較・分析することで、今後のプロジェクトにおける計画立案の精度を改善できる。</li> </ul> </li> <li>PMに推奨される処置 <ul> <li>ベースラインと現状の比較 <ul> <li><strong>当初意図の確認</strong>: プロジェクトの立ち上げ・ステージで合意・ベースライン化された初期の<strong>PID</strong>をレビューし、プロジェクトの<strong>原点</strong>を確認する。</li> <li><strong>承認済み変更の確認</strong>: プロジェクト期間中に承認された変更を反映した最新バージョンのPIDをレビューし、最終的な達成目標がどのように変化したかを把握する。</li> </ul> </li> <li>報告書の作成 <ul> <li><strong>プロジェクト終了報告書の作成</strong>: プロジェクト・マネジメント・チームと協議し、パフォーマンスの総括や目標達成度を記した<strong>プロジェクト終了報告書</strong>を準備する。</li> <li><strong>教訓の形式知化</strong>: プロジェクト・ログを精査し、将来のプロジェクトに適用可能な知見を特定する。チームと協議の上で、<strong>プロジェクト教訓報告書</strong>に記載する。</li> </ul> </li> </ul> </li> </ol> <h4>プロジェクトのクローズの要求<a href="#プロジェクトのクローズの要求"><span></span></a></h4> <blockquote> <p>PMがプロジェクト委員会に対し、最終ステージの終了とプロジェクト全体のクローズを正式に要求する活動である。</p> </blockquote> <ol> <li>実施のポイント <ul> <li><strong>正当性の提示</strong>: 意思決定の根拠として、プロジェクトの全期間を総括した<strong><strong>プロジェクト終了報告書</strong></strong>を提出する。</li> <li><strong>成功の祝賀と承認</strong>: 完了を公式に認め、貢献した関係者への感謝を表明することで、組織にポジティブな影響を与える。</li> </ul> </li> <li>プロジェクト・マネージャーに推奨される処置 <ul> <li>パフォーマンスの総括と報告 <ul> <li><strong>概要の説明</strong>: プロジェクト全体のパフォーマンスを要約してプロジェクト委員会に報告し、クローズの準備が整っていることを確認する。</li> <li><strong>例外事項の強調</strong>: 仕様外項目(オフスペック)のうち、完全な修正ではなく<strong><strong>条件付き承認</strong></strong>となった箇所を明確に伝え、委員会の認識を合わせる。</li> </ul> </li> <li>正式な要求 <ul> <li><strong>クローズの要求</strong>: 必要なすべての成果物が引き渡され、管理業務が完了したことを踏まえ、プロジェクトの正式なクローズを委員会に求める。</li> <li><strong>感謝の提案</strong>: プロジェクトの成功を祝い、関係者の労をねぎらうための感謝の表明(正式メッセージやイベントなど)を委員会に提案する。</li> </ul> </li> </ul> </li> </ol> <h3>適用<a href="#適用"><span></span></a></h3> <h4>一般的な考慮事項<a href="#一般的な考慮事項"><span></span></a></h4> <ul> <li><strong>活動の柔軟性</strong>: プロジェクトの状況に応じて、活動の結合、分割、同時に実行できる。</li> <li><strong>プロセスの接続</strong>: <strong>プロジェクトの指揮(DP)<strong>および</strong>ステージのコントロール(CS)</strong> とのインターフェースの完全性を確保しなければならない。</li> <li><strong>移管の確認</strong>: 成果物の移管(ハンドオーバー)は、必ずしも最終ステージで行われるとは限らない。過去のステージで既に移管が完了している場合、本プロセスでは<strong>すべての移管作業が漏れなく完了しているか</strong>の最終確認に専念する。</li> </ul> <h4>役割のテーラリング<a href="#役割のテーラリング"><span></span></a></h4> <blockquote> <p>責任の所在を明確にしつつ、実務面では組織に応じた柔軟な分担が可能である。</p> </blockquote> <ul> <li><strong>PMの実行責任と委任</strong>: PMは、本プロセスで作成されるマネジメント成果物の作成に実行責任を負う。ただし、全体的な責任を保持したままであれば、具体的な作業を他者に委任できる。</li> <li><strong>シニア・ユーザーの関与</strong>: <strong>プロジェクトの受け入れ確認</strong>活動において、プロジェクト終了後のベネフィット・レビューが確実に計画されているかの確認を、シニア・ユーザーが主導して行う場合がある。</li> </ul> <h3>責任<a href="#責任"><span></span></a></h3> <table><thead><tr><th>活動</th><th>ビジネス・レイヤー</th><th>プロジェクト・エグゼクティブ</th><th>シニア・ユーザー</th><th>シニア・サプライヤー</th><th>プロジェクト・マネージャー</th><th>チーム・マネージャー</th><th>プロジェクト保証</th><th>プロジェクト支援</th></tr></thead><tbody><tr><td>計画されたクローズの準備</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>早期クローズの準備</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>プロジェクトの受け入れの確認</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>I</td><td>I</td><td>I</td></tr><tr><td>プロジェクトの評価</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>プロジェクトのクローズの要求</td><td>I</td><td>A</td><td>C</td><td>C</td><td>R</td><td>I</td><td>C</td><td>I</td></tr></tbody></table> <p>R = 実行責任、A = 説明責任、C = 協議先、I = 情報先</p> <h3>プロセスへのプラクティスの適用<a href="#プロセスへのプラクティスの適用"><span></span></a></h3> <table><thead><tr><th>プラクティス</th><th>プロジェクトのクローズ・プロセスへの適用</th></tr></thead><tbody><tr><td><strong>ビジネス・ケース</strong></td><td>実績(コスト・ベネフィット)を反映して最新化し、未実現のベネフィット予測を更新する。プロジェクト終了後の責任の所在を明確にするため、ベネフィットおよび持続可能性アプローチをレビュー・更新する</td></tr><tr><td><strong>組織化</strong></td><td>チームのパフォーマンスとウェルビーイングを評価し、教訓として記録する。クローズに伴う各種管理アプローチ(コミュニケーション・変更・商業)の要件を確認し、<strong>プロジェクト・マネジメント・チームを解散</strong>してオフボーディングを完了させる</td></tr><tr><td><strong>計画</strong></td><td>計画と実績を比較・分析し、プロジェクト全体のパフォーマンスを分析し、教訓ログやプロジェクト終了報告書の重要な根拠となる</td></tr><tr><td><strong>品質</strong></td><td>最終ステージまでの品質活動がすべて完了したことを品質登録簿で確認する。クローズに関連する品質要件をレビューし、<strong>品質登録簿をクローズ</strong>する</td></tr><tr><td><strong>リスク</strong></td><td>最終ステージのリスクを整理し、解決しなかった<strong>残存リスクをビジネス側(運用等)へ移転</strong>する。リスク・マネジメント・アプローチを確認後、<strong>リスク登録簿をクローズ</strong>する</td></tr><tr><td><strong>課題</strong></td><td>未解決の課題を整理し、ビジネス側が引き継ぐべき<strong>継続対応勧告</strong>を特定する。課題マネジメント・アプローチを確認後、<strong>課題登録簿をクローズ</strong>する</td></tr><tr><td><strong>進捗</strong></td><td>成果物登録簿により全成果物の提供を確認し、登録簿を閉鎖する。データのアーカイブ方法(場所・手順等)を確認し、<strong>プロジェクト終了報告書</strong>を発行。最後にデイリー・ログと教訓ログをクローズする</td></tr></tbody></table>category:项目管理tag:プロジェクトtag:マネジメントtag:プロセスtag:プロジェクトのクローズhttps://blog.issyuu.com/zh/post/pm-processes-closezh:pm-processes-close生きている限り、学び続けるWed, 22 Apr 2026 04:12:12 GMT<h2>プロジェクトのクローズ<a href="#プロジェクトのクローズ"><span></span></a></h2> <p>プロジェクトのクローズ・プロセスの目的は、プロジェクト成果物の受け入れが確認される時点を提供する。 また、プロジェクト立ち上げ文書で確立されたとおりに、達成目標または達成目標に対する承認された変更が達成されたことを認識するためのポイントも提供します。 早期クローズの原因がある場合、このプロセスにより、プロジェクトを整然とした方法でクローズすることを確保します。</p> <p>プロジェクトのクローズ・プロセスの達成目標は、以下を行うことです。 * プロジェクト成果物のユーザー受け入れを確認する * プロジェクトのクローズ後、ビジネスが成果物を支援できることを確保する * プロジェクトのパフォーマンスをベースラインと比較してレビューする * すでに実現されているベネフィットを評価して、プロジェクト後のベネフィット・レビューを含めるようベネフィット・マネジメント・アプローチを更新する * 継続対応勧告によって、未解決の課題やリスクに対処への提供ができることを確保する * プロジェクトのクローズが整然とした方法で行われるよう保証し、単に放棄されていないようにする(早期クローズの場合)</p> <p>プロジェクトの決定的な特徴の 1 つはプロジェクトが有限であること、つまり始まりと終わりがあるということです。(プロジェクトがこの特徴を失うと、運用上のマネジメント・アプローチに対する利点の一部を失うことになります。) プロジェクトの明確な終了により、以下のことが実現されます。 * 次のことを全関係者が認識することになるため、漫然と運用に移行する場合よりも、成功率が高まります。 * 当初の達成目標が満たされていること(承認のうえ、変更される場合がある) * 現在のプロジェクトが予定の工程を満了したこと * 成果物の継続的な運用と保守に対する責任が、合意されたオーナーによって確認されていること * 一時的なプロジェクト組織、特にプロジェクト・マネジメント・チームを解散できること * 今後プロジェクトのコストは発生しないこと * 未達成のゴールや達成目標が特定され、今後それらに取り組む機会が確保されること * 合意されたオーナーに成果物のオーナーシップが移転され、プロジェクト・マネジメント・チームは責任から解放されること</p> <p>クローズ活動は、最終ステージのためのステージ計画書の一部として計画されます。プロジェクトをクローズする際は、プロジェクトのクローズの認可を得るためにプロジェクト委員会に提供する情報を準備する作業が必要になります。その後、プロジェクト・エグゼクティブはビジネス・レイヤーにプロジェクトの終了を通知します。 状況によっては(ビジネス・ケースが有効でなくなった場合など)、プロジェクト委員会がプロジェクトの早期クローズのトリガーを望むこともあります。プロジェクトが早期クローズに至った場合でも、プロジェクトのクローズ・プロセスを実施する必要があります。 プロジェクト終了後に、プロジェクト成果物に特有の処置をいくつか実施しなければならない場合があります。これらの処置は継続対応勧告として文書化され計画されます。処置の対象者はさまざまであるため、個別に作成する必要がある場合もあります。勧告の形式と内容は対象者のニーズによって判断されます。正式な報告書を希望する対象者もいれば、システムへのログインプットやミーティングを希望する対象者もいます。</p> <h3>活動<a href="#活動"><span></span></a></h3> <table><thead><tr><th>インプット</th><th>活動</th><th>アウトプット</th></tr></thead><tbody><tr><td>プロジェクト終了が近づく(このプロセスをトリガー)<br />プロジェクト・ログ(レビュー)<br />プロジェクト立ち上げ文書(確認)<br />ビジネス・ケース(確認)<br />プロジェクト計画書(レビュー)</td><td>計画されたクローズの準備</td><td>プロジェクト・ログ(更新)<br />プロジェクト計画書(必要に応じて更新)<br />ベネフィット・マネジメント・アプローチ(必要に応じて更新)<br />教訓報告書(作成)<br />プロジェクト終了報告書(作成)</td></tr><tr><td>プロジェクト終了が近づく(このプロセスをトリガー)<br />プロジェクト・ログ(レビュー)<br />プロジェクト立ち上げ文書(確認)<br />ビジネス・ケース(確認)<br />プロジェクト計画書(レビュー)</td><td>プロジェクトの受け入れの確認</td><td>プロジェクト・ログ(更新)<br />プロジェクト計画書(必要に応じて更新)<br />ベネフィット・マネジメント・アプローチ(必要に応じて更新)<br />教訓報告書(作成)<br />プロジェクト終了報告書(作成)</td></tr><tr><td>プロジェクト終了が近づく(このプロセスをトリガー)<br />プロジェクト・ログ(レビュー)<br />プロジェクト立ち上げ文書(確認)<br />ビジネス・ケース(確認)<br />プロジェクト計画書(レビュー)</td><td>プロジェクトの評価</td><td>プロジェクト・ログ(更新)<br />プロジェクト計画書(必要に応じて更新)<br />ベネフィット・マネジメント・アプローチ(必要に応じて更新)<br />教訓報告書(作成)<br />プロジェクト終了報告書(作成)</td></tr><tr><td>プロジェクト終了が近づく(このプロセスをトリガー)<br />プロジェクト・ログ(レビュー)<br />プロジェクト立ち上げ文書(確認)<br />ビジネス・ケース(確認)<br />プロジェクト計画書(レビュー)</td><td>プロジェクトのクローズの要求</td><td>プロジェクト・ログ(更新)<br />プロジェクト計画書(必要に応じて更新)<br />ベネフィット・マネジメント・アプローチ(必要に応じて更新)<br />教訓報告書(作成)<br />プロジェクト終了報告書(作成)</td></tr><tr><td>早期クローズの要求(このプロセスをトリガー)<br />プロジェクト・ログ(レビュー)<br />プロジェクト立ち上げ文書(確認)<br />ビジネス・ケース(確認)<br />プロジェクト計画書(レビュー)</td><td>早期クローズの準備</td><td>プロジェクト・ログ(更新)<br />プロジェクト計画書(必要に応じて更新)<br />ベネフィット・マネジメント・アプローチ(必要に応じて更新)<br />教訓報告書(作成)<br />プロジェクト終了報告書(作成)</td></tr><tr><td>早期クローズの要求(このプロセスをトリガー)<br />プロジェクト・ログ(レビュー)<br />プロジェクト立ち上げ文書(確認)<br />ビジネス・ケース(確認)<br />プロジェクト計画書(レビュー)</td><td>プロジェクトの受け入れの確認</td><td>プロジェクト・ログ(更新)<br />プロジェクト計画書(必要に応じて更新)<br />ベネフィット・マネジメント・アプローチ(必要に応じて更新)<br />教訓報告書(作成)<br />プロジェクト終了報告書(作成)</td></tr><tr><td>早期クローズの要求(このプロセスをトリガー)<br />プロジェクト・ログ(レビュー)<br />プロジェクト立ち上げ文書(確認)<br />ビジネス・ケース(確認)<br />プロジェクト計画書(レビュー)</td><td>プロジェクトの評価</td><td>プロジェクト・ログ(更新)<br />プロジェクト計画書(必要に応じて更新)<br />ベネフィット・マネジメント・アプローチ(必要に応じて更新)<br />教訓報告書(作成)<br />プロジェクト終了報告書(作成)</td></tr><tr><td>早期クローズの要求(このプロセスをトリガー)<br />プロジェクト・ログ(レビュー)<br />プロジェクト立ち上げ文書(確認)<br />ビジネス・ケース(確認)<br />プロジェクト計画書(レビュー)</td><td>プロジェクトのクローズの要求</td><td>プロジェクト・ログ(更新)<br />プロジェクト計画書(必要に応じて更新)<br />ベネフィット・マネジメント・アプローチ(必要に応じて更新)<br />教訓報告書(作成)<br />プロジェクト終了報告書(作成)</td></tr></tbody></table> <h4>計画されたクローズの準備<a href="#計画されたクローズの準備"><span></span></a></h4> <p>プロジェクトがクローズできる状態にあることをプロジェクト・マネージャーが確認したら、プロジェクト委員会にクローズ勧告を出すことができます。</p> <p>プロジェクト・マネージャーに推奨される処置 * コミュニケーション・マネジメント・アプローチを使って、プロジェクトがクローズする旨を知らせる必要のある組織や関係者を特定する(広報活動やマーケティング機会のためのコミュニケーション活動について、この時点で検討する)。 * プロジェクト・ログをクローズする。 * プロジェクト・マネジメント・チームの決定、処置、パフォーマンスについて将来監査を行えるようにするため、プロジェクトの情報が(デジタルおよびデータ・マネジメント・アプローチに従って)安全に保管されることを確保する。 * プロジェクト委員会によるレビューを受けるため、プロジェクトのクローズ通知案を準備する。</p> <h4>早期クローズの準備<a href="#早期クローズの準備"><span></span></a></h4> <p>状況によっては、プロジェクト委員会がプロジェクト・マネージャーに対しプロジェクトを早期に終了するよう指示する場合があります。(そのような場合、プロジェクト・マネージャーは、進行中の作業を単に放棄するのではなく、プロジェクトでそれまでに生み出された価値が回収され、プロジェクトの中止によって生じた損失がビジネスに示されたことを確認する必要があります。)</p> <p>プロジェクト・マネージャーに推奨される処置 * プロジェクト・ログ(および必要に応じて課題報告書)を更新して早期クローズの要求を記録する。 * プロジェクト計画書を更新して最終ステージでの実績を反映させる。 * プロジェクト支援に成果物のステータスを要求する。ここから、プロジェクト成果物のどのコンポーネントが以下に該当するかを判断する。 * 成果物記述書に記載されている承認部門の承認を受けている * 完成する必要があるが、現在開発中である * 条件付き承認として承認されている * まだ開始されていない * 安全を確保する必要がある * 他のプロジェクトに役立つ可能性がある * 該当する場合、完成済みまたは作成中の成果物を回収するための手段に合意する。これにはプロジェクト委員会の協議を要します。また、他のプロジェクトに役立つ可能性のある成果物の作成、安全性確保、完成といった追加作業(未完成の建物の安全性と耐候性の確保など)が含まれる場合があります。場合によっては、追加作業には例外計画書の作成が必要となる。 * リソースと人員が早期にリリースされる可能性があること、またはリリースされようとしていることをビジネスに通知するための承認を求める。</p> <h4>プロジェクトの受け入れの確認<a href="#プロジェクトの受け入れの確認"><span></span></a></h4> <p>プロジェクト成果物は、プロジェクトのクローズに先立ち、運用および保守環境に移管する必要があります。移管はプロジェクトの終わりに 1 回のリリースとして実施されることもありますが、プロジェクト・アプローチによっては、フェーズごとのデリバリーによっていくつかのリリースに分けて成果物がデリバリーされることもあります。早期クローズが実施される場合、承認は済んでいるものの提供が済んでいない成果物があることがあります。プロジェクト委員会のガイダンス次第では、このような成果物の一部または全部のオーナーシップをユーザーに移転する必要がある場合があります。 成果物を提供する際には、ベネフィット・マネジメント・アプローチの更新が必要になる場合があります。(これは、プロジェクト終了後のベネフィット・レビュー、または運用使用時のプロジェクト成果物のパフォーマンスのレビューをベネフィット・マネジメント・アプローチに含めるためです。このようなベネフィット・レビューを実施することで、他のプロジェクトに役立つ教訓を提供するような(有益または有害な)副産物がなかったかどうかを特定できることがあります。) プロジェクト・ライフサイクル中に移管が複数回行われる場合もあります。(プロジェクト完了後のベネフィット・レビューはプロジェクト活動ではありません。プロジェクト活動に含まれるのは、そのようなベネフィット・レビューが実施されるように計画することです。プロジェクトがプログラムの一部として実施される場合、プロジェクト終了後のベネフィット・レビューは、プログラムのベネフィット・マネジメント活動の一環として実施する必要があります。)</p> <p>プロジェクト・マネージャーに推奨される処置 * プロジェクト・マネジメント・チームと協議のうえ、プロジェクト成果物の未完了作業、課題、リスクに関する継続対応勧告を準備する。各プロジェクト成果物またはそのコンポーネントや、特定のユーザー・グループ(人事部、財務部、業務部など)のための個別の継続対応勧告を作成する場合もあります。 * ベネフィット・マネジメント・アプローチにプロジェクト終了後の活動が記載されていることを確認する。この活動は、プロジェクト成果物がしばらく運用された後で初めて測定できるベネフィット(信頼性パフォーマンスなど)を確認する目的で実施します。 * プロジェクト立ち上げ文書を調査し、成果物の運用期間中に成果物を管理する者に成果物を提供する方法を確認する。</p> <h4>プロジェクトの評価<a href="#プロジェクトの評価"><span></span></a></h4> <p>成功する組織は、プロジェクトの経験からの学習を活用します。プロジェクトを評価する際の達成目標は、プロジェクトがどれほど成功したかを評価することです。または早期クローズの場合は、プロジェクトと早期クローズの理由を評価することです。今回のプロジェクトの見積もりと実際の進捗の測定基準を分析することによって、今後のプロジェクトの見積もりを改善することも可能かもしれません。</p> <p>プロジェクト・マネージャーに推奨される処置 * 立ち上げステージで合意し、その時点でベースライン化されたプロジェクト立ち上げ文書に定義されている、プロジェクトの当初の意図をレビューする。 * プロジェクト立ち上げ文書のコンポーネントの最新バージョンに定義されている承認済みの変更をレビューする。 * プロジェクト・マネジメント・チームと協議のうえ、プロジェクト終了報告書を準備する。 * プロジェクト・ログをレビューし、今後プロジェクトに適用できる教訓を特定し、プロジェクト・マネジメント・チームと協議のうえでプロジェクト教訓報告書に記載する。</p> <h4>プロジェクトのクローズの要求<a href="#プロジェクトのクローズの要求"><span></span></a></h4> <p>現在のステージを終了してプロジェクトをクローズするには、プロジェクト・マネージャーはプロジェクト委員会に連絡してプロジェクトのクローズを要求します。プロジェクト・マネージャーは、プロジェクトの成功を祝うことの重要性を強調し、プロジェクト委員会が関係者全員に何らかの形で感謝の意を表することを提案します。プロジェクトのクローズの正式な正当性は、プロジェクト終了報告書に記載されています。</p> <p>プロジェクト・マネージャーに推奨される処置 * プロジェクト委員会にプロジェクトのパフォーマンスの概要を説明し、クローズする準備ができていることを確認する。このとき、仕様外項目の条件付き承認がある部分を強調します。 * プロジェクト委員会にプロジェクトのクローズを要求する。</p> <h3>適用<a href="#適用"><span></span></a></h3> <h4>一般的な考慮事項<a href="#一般的な考慮事項"><span></span></a></h4> <p>このプロセスの活動は、状況に応じて結合、分割、同時に実行できます。ただし、プロジェクトの指揮のプロセスとステージのコントロールのプロセスとのインターフェースとの関連の完全性が確保されるよう注意を払います。 成果物の移管活動は、プロジェクトのクローズの一環としてプロジェクトの最終ステージでは行われない場合がありますが、その前のいくつかのステージで行われた可能性があります。その場合、プロジェクトのクローズのプロセスとして、すべての移管作業が完了していることの確認のみが必要となります。</p> <h4>役割のテーラリング<a href="#役割のテーラリング"><span></span></a></h4> <p>プロジェクト・マネージャーはこのプロセスにおけるあらゆる新しいマネジメント成果物の作成の実行責任を負いますが、引き続き全体的な責任を負う場合は、作業を他の人に委任できます。プロジェクト終了後のベネフィット・レビューの実施が予定されていることの確認は、「プロジェクトの受け入れの確認」活動でシニア・ユーザーが行う場合もあります。</p> <h3>責任<a href="#責任"><span></span></a></h3> <table><thead><tr><th>活動</th><th>ビジネス・レイヤー</th><th>プロジェクト・エグゼクティブ</th><th>シニア・ユーザー</th><th>シニア・サプライヤー</th><th>プロジェクト・マネージャー</th><th>チーム・マネージャー</th><th>プロジェクト保証</th><th>プロジェクト支援</th></tr></thead><tbody><tr><td>計画されたクローズの準備</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>早期クローズの準備</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>プロジェクトの受け入れの確認</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>I</td><td>I</td><td>I</td></tr><tr><td>プロジェクトの評価</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>プロジェクトのクローズの要求</td><td>I</td><td>A</td><td>C</td><td>C</td><td>R</td><td>I</td><td>C</td><td>I</td></tr></tbody></table> <p>R = 実行責任、A = 説明責任、C = 協議先、I = 情報先</p> <h3>プロセスへのプラクティスの適用<a href="#プロセスへのプラクティスの適用"><span></span></a></h3> <table><thead><tr><th>プラクティス</th><th>プロジェクトのクローズ・プロセスへの適用</th></tr></thead><tbody><tr><td>ビジネス・ケース</td><td>プロジェクト終了時のプロジェクトのパフォーマンスが評価され、ビジネス・ケースが更新されて、実際のコストとベネフィット、およびまだ実現されていないベネフィットの予測が反映されます。ベネフィット・マネジメント・アプローチと持続可能性マネジメント・アプローチは、必要に応じてプロジェクト終了後の責任のためにレビューおよび更新されます。</td></tr><tr><td>組織化</td><td>プロジェクト・チーム・パフォーマンスとウェルビーイングは、学んだ教訓とプロジェクト終了報告書へのインプットの為にレビューされます。<br />コミュニケーション・マネジメント・アプローチ、変更マネジメント・アプローチ、商業マネジメント・アプローチは、プロジェクトのクローズに関連する要件(通知など)の為にレビューされます。<br />プロジェクト・マネジメント・チームは解散し、オフボーディング活動が完了します。</td></tr><tr><td>計画</td><td>計画は、プロジェクトの実際のパフォーマンスを、学んだ教訓やプロジェクト終了報告書へのインプットを提供するために計画されたものと比較するためにレビューされます。</td></tr><tr><td>品質</td><td>品質登録簿は、最終ステージに必要な品質活動が実施されたことを確認し、終了報告書にインプットを提供するために確認されます。<br />品質マネジメント・アプローチは、プロジェクトのクローズに関連する要件についてレビューされます。<br />品質登録簿がクローズされます。</td></tr><tr><td>リスク</td><td>リスク登録簿は、最終ステージのリスクを排除し、残存リスクをビジネスに移転し、学んだ教訓とプロジェクト終了報告書へのインプットを提供するためにレビューされます。<br />リスク・マネジメント・アプローチは、プロジェクトのクローズに関連する要件についてレビューされます。<br />リスク登録簿がクローズされます。</td></tr><tr><td>課題</td><td>課題登録簿は、最終ステージの課題を排除し、ビジネスの継続対応を把握し、学んだ教訓とプロジェクト終了報告書へのインプットを提供するためにレビューされます。<br />課題マネジメント・アプローチは、プロジェクトのクローズに関連する要件についてレビューされます。<br />課題登録簿がクローズされます。</td></tr><tr><td>進捗</td><td>成果物登録簿は、最終ステージに必要な成果物が提供されたことを確認し、学んだ教訓とプロジェクト終了報告書へのインプットを提供するために確認されます。成果物登録簿がクローズされます。<br />デイリー・ログと教訓ログは、プロジェクト終了報告書へのインプットを提供するためにレビューされます。<br />デジタルおよびデータ・マネジメント・アプローチは、プロジェクト・データのアーカイブまたは使用の方法や場所など、プロジェクトのクローズに関連する要件についてレビューされます。<br />プロジェクト終了報告書が作成および発行されます。<br />デイリー・ログと教訓ログがクローズされます。</td></tr></tbody></table>category:项目管理tag:プロジェクトtag:マネジメントtag:プロセスtag:プロジェクトのクローズhttps://blog.issyuu.com/zh/post/pm-processes-stage-boundary-dzh:pm-processes-stage-boundary-d生きている限り、学び続けるTue, 21 Apr 2026 04:12:12 GMT<h2>ステージ境界<a href="#ステージ境界"><span></span></a></h2> <blockquote> <p>現在のステージの成果を振り返り、プロジェクトの<strong>ビジネス正当性</strong>と<strong>リスク</strong>を再評価した上で、プロジェクト委員会が次の方針(継続か中止か)を判断するための十分な情報を提供する。</p> </blockquote> <h3>達成目標<a href="#達成目標"><span></span></a></h3> <blockquote> <p>PMは、プロジェクト委員会が情報に基づいた確実な意思決定を行えるように、以下の事項を確実する。</p> </blockquote> <ul> <li><strong>成果の保証</strong>: 現在のステージの全成果物が完了し、承認されていることを保証する。</li> <li><strong>計画の策定</strong>: 次のステージの<strong>ステージ計画書</strong>、または必要に応じて<strong>例外計画書</strong>を準備する。</li> <li><strong>PIDの更新</strong>: ビジネス・ケース、プロジェクト計画書、役割記述書、アプローチなど、最新状況に合わせて<strong>PID</strong>をレビュー・更新する。</li> <li><strong>正当性の確認</strong>: プロジェクトの継続的な実行可能性を評価するための情報を提供する。</li> <li><strong>知見の記録</strong>: 後続ステージや他のプロジェクトで役立つ<strong>教訓</strong>を記録する。</li> <li><strong>認可の要求</strong>: 次のステージを開始するための正式な承認を求める。</li> </ul> <h3>位置付け<a href="#位置付け"><span></span></a></h3> <h4>トリガー<a href="#トリガー"><span></span></a></h4> <ul> <li><strong>実施時期</strong>: 各マネジメント・ステージの終了時、または終了間際に実施する。</li> <li><strong>例外への対応</strong>: ステージやプロジェクトが許容度を逸脱すると予測された場合、プロジェクト委員会からの指示により、現行計画を置き換えるための<strong>例外計画書</strong>を作成する時。</li> </ul> <h4>実施の重要性<a href="#実施の重要性"><span></span></a></h4> <ul> <li><strong>ステージ制のメリット</strong>: プロジェクトをステージに分けることで、定期的に<strong>このまま進めて良いか</strong>を確認できる。これにより、時間と資金の浪費を防ぐ。</li> <li><strong>前向きな中止の判断</strong>: 十分な情報に基づき、正当性がなくなったプロジェクトを<strong>中止</strong>と決定することは失敗ではなく、<strong>マネジメント上の成功</strong>(適切な判断)と見なされる。</li> <li><strong>情報不足の回避</strong>: 逆に、十分な情報を提供できず、プロジェクト委員会が誤った判断をしたり意思決定が遅れたりすることは、マネジメント側の失敗といえる。</li> <li><strong>コントロールの回復</strong>: 計画から大幅に逸脱しそうな場合でも、このプロセスを通じて<strong>例外計画書</strong>を作成することで、プロジェクトを再び適切なコントロール下に置くことができる。</li> </ul> <h3>活動<a href="#活動"><span></span></a></h3> <table><thead><tr><th>インプット</th><th>活動</th><th>アウトプット</th></tr></thead><tbody><tr><td>ステージ境界が近づく(このプロセスをトリガー)<br />プロジェクト立ち上げ文書(レビュー)<br />プロジェクト計画書(レビュー)<br />プロジェクト・ログ(確認)</td><td>次のステージ計画書の準備</td><td>プロジェクト・ログ(更新)<br />ステージ計画書(次のステージ用に作成)<br />成果物記述書(次のステージ用に作成)<br />プロジェクト立ち上げ文書(必要に応じて更新)</td></tr><tr><td>例外計画書の要求(このプロセスをトリガー)<br />例外報告書(レビュー)<br />プロジェクト立ち上げ文書(レビュー)<br />プロジェクト計画書(レビュー)<br />プロジェクト・ログ(確認)</td><td>例外計画書の準備(必要な場合)</td><td>プロジェクト・ログ(更新)<br />例外計画書(作成)<br />成果物記述書(改訂されたステージの作成/更新)<br />例外計画書の承認の要求(プロジェクトの指揮のプロセスをトリガー)</td></tr><tr><td>プロジェクト・ログ(確認)<br />ステージ計画書(確認)<br />プロジェクト計画書(レビュー)</td><td>プロジェクト計画書の更新</td><td>プロジェクト計画書(必要に応じて更新)</td></tr><tr><td>プロジェクト計画書(確認)<br />プロジェクト・ログ(確認)<br />ビジネス・ケース(レビュー)</td><td>ビジネス・ケースの更新</td><td>ベネフィット・マネジメント・アプローチ(必要に応じて更新)<br />ビジネス・ケース(必要に応じて更新)</td></tr><tr><td>プロジェクト・ログ(確認)<br />コミュニケーション・マネジメント・アプローチ(確認)</td><td>ステージの評価</td><td>ステージ終了報告書(作成)</td></tr><tr><td>ステージ終了報告書<br />ステージ計画書または例外計画書(次のステージ用)</td><td>次のステージの要求</td><td>次のステージの要求(プロジェクトの指揮のプロセスをトリガー)</td></tr></tbody></table> <h4>次のステージ計画書の準備<a href="#次のステージ計画書の準備"><span></span></a></h4> <blockquote> <p>現在のステージの終了が近づいた際、次ステージを円滑に進めるための具体的な<strong>ステージ計画書</strong>を作成する活動である。</p> </blockquote> <ol> <li>実施のポイント <ul> <li><strong>共同作業</strong>: 計画立案はPM 一人の仕事ではない。実行可能で堅固な計画にするために、プロジェクト委員会、プロジェクト保証、TM、適切な利害関係者と十分に協議しながら進める。</li> </ul> </li> <li>PMに推奨される処置 <ul> <li>情報のレビューと更新 <ul> <li><strong>PIDの再確認</strong>: PIDをレビューし、マネジメント・アプローチを最新化する。大きな変更がある場合は、プロジェクト委員会と協議する。</li> <li><strong>教訓の活用</strong>: 教訓ログを確認し、次のステージで活かせる知見を計画に反映させる。</li> <li><strong>マイルストーンの整合</strong>: プロジェクト計画書を確認し、次のステージに該当するマイルストーンと整合性を取る。</li> </ul> </li> <li>計画と成果物の定義 <ul> <li><strong>計画書の作成</strong>: 次のステージの<strong>ステージ計画書</strong>を作成する。</li> <li><strong>成果物の定義</strong>: 次のステージで納品される成果物の<strong>成果物記述書</strong>を作成し、<strong>成果物登録簿</strong>にレコードを追加・更新する。</li> </ul> </li> <li>管理ログの最新化 <ul> <li><strong>リスクと課題の反映</strong>: 新たに特定された、または修正が必要な課題やリスクをプロジェクト・ログに記録する。</li> <li><strong>品質活動の予定化</strong>: 次のステージにおける品質レビューのターゲット日や承認予定日を決定し、<strong>品質登録簿</strong>を更新する。</li> </ul> </li> </ul> </li> </ol> <h4>例外計画書の準備(必要な場合)<a href="#例外計画書の準備必要な場合"><span></span></a></h4> <blockquote> <p>ステージまたはプロジェクトが、合意された許容度(トレランス)を逸脱することが予測され、プロジェクト委員会から要求された際に実施する活動である。</p> </blockquote> <ol> <li>トリガー <ul> <li><strong>計画の置換</strong>: 承認された例外計画書は、現在のステージ計画書(またはプロジェクト計画書)に取って代わり、新たなベースラインとなる。</li> <li><strong>コントロールの回復</strong>: 逸脱した状態を解消し、プロジェクトを再び委員会の認可下に戻すための重要なステップである。</li> </ul> </li> <li>PMに推奨される処置 <ul> <li>情報の整理と分析 <ul> <li><strong>要求の記録</strong>: プロジェクト・ログを更新し、プロジェクト委員会から例外計画書の作成要求を記録する。</li> <li><strong>PIDのレビュー</strong>: プロジェクト立ち上げ文書(PID)をレビューし、マネジメント・アプローチや計画立案要件を最新化する。必要に応じて変更要求について委員会と協議する。</li> <li><strong>知見の活用</strong>: 教訓ログを確認し、今回の例外対応や計画策定に活かせる教訓を取り入れる。</li> </ul> </li> <li>計画の策定と定義 <ul> <li><strong>例外計画書の作成</strong>: プロジェクト計画書のマイルストーンを参照しつつ、現行の計画を修正・再構築した例外計画書を策定する。</li> <li><strong>成果物の定義</strong>: 例外計画の範囲に含まれる成果物の記述書を作成または更新し、成果物登録簿に反映する。</li> </ul> </li> <li>ログと登録簿の最新化 <ul> <li><strong>リスクと課題の管理</strong>: 例外状況に伴う新たなリスクや課題を特定し、プロジェクト・ログを更新する。</li> <li><strong>品質活動の予定化</strong>: 計画された品質マネジメント活動(レビュー日、承認日など)を品質登録簿に記録し、管理体制を整える。</li> </ul> </li> </ul> </li> </ol> <h4>プロジェクト計画書の更新<a href="#プロジェクト計画書の更新"><span></span></a></h4> <blockquote> <p>プロジェクト委員会がプロジェクト全体の進捗を正確に把握・測定するための基準(ベースライン)を最新化する活動である。</p> </blockquote> <ol> <li>目的 <ul> <li><strong>進捗の統合</strong>: 終了するステージの実際の実績を反映させる。</li> <li><strong>将来予測の反映</strong>: 次に開始するステージ計画書(または例外計画書)で定義された期間とコストの予測値を、全体計画に組み込む。</li> <li><strong>ビジネス・ケースへの連動</strong>: 修正されたコストや終了日の情報は、プロジェクトの正当性を再評価する<strong>ビジネス・ケースの更新</strong>において不可欠なインプットとなる。</li> </ul> </li> <li>PMに推奨される処置 <ul> <li>実績と予測の精査 <ul> <li><strong>ステージ実績の確定</strong>: 終了間際のステージ計画書が、実際の実績を正しく反映した最新の状態であることを確認し、必要に応じて更新する。</li> <li><strong>全体計画の修正</strong>: ステージの実績と次ステージの予測に基づき、プロジェクト計画書を修正する。</li> </ul> </li> <li>ログの最新化 <ul> <li><strong>リスクと課題の更新</strong>: 計画の修正に伴い、新たに特定された課題やリスク、または既存情報の変更内容をプロジェクト・ログに反映させる。</li> </ul> </li> </ul> </li> </ol> <h4>ビジネス・ケースの更新<a href="#ビジネスケースの更新"><span></span></a></h4> <blockquote> <p>プロジェクトが依然として投資に見合う価値を持ち、<strong>実行可能</strong>であることを確認する活動である。</p> </blockquote> <p>＊プロジェクトは常に変化する外部環境の影響を受けるため、最新の状況を反映したビジネス・ケースを維持しなければならない。</p> <ol> <li>目的 <ul> <li><strong>継続的な正当性の検証</strong>: 合意された期間、コスト、品質、スコープ、リスク、持続可能性の範囲内でベネフィットが実現できるかを再評価する。</li> <li><strong>意思決定の根拠</strong>: プロジェクト委員会が続行を認可するための不可欠な判断材料となる。</li> </ul> </li> <li>責任の所在 <ul> <li><strong>プロジェクト・エグゼクティブ</strong>: ビジネス・ケースに対して最終的な説明責任を負う。</li> <li><strong>PM</strong>: 更新の実務を担当するが、内容の修正やレビューにあたっては必ずプロジェクト・エグゼクティブと協議しなければならない。</li> </ul> </li> <li>PMに推奨される処置 <ul> <li>リスクと許容度の評価 <ul> <li><strong>リスク選好度の確認</strong>: 組織のリスク選好度やリスク・キャパシティに変化がないか、許容度の再定義が必要かを確認する。</li> <li><strong>集約されたリスクの分析</strong>: プロジェクト・ログを基に、個別のリスクが積み重なった<strong>集約されたリスク影響度</strong>を確定する。それが組織の許容度内に収まっているかを評価し、ビジネス・ケースを脅かす主要リスクを特定する。</li> </ul> </li> <li>ベネフィットの精査 <ul> <li><strong>実績の反映</strong>: ステージ内で実施されたベネフィット・マネジメント活動の結果に基づき、<strong>ベネフィット・マネジメント・アプローチ</strong>を更新する。</li> <li><strong>スケジュールの影響評価</strong>: プロジェクト計画書を調査し、終了日の前倒しや遅延がベネフィットの実現(量や時期)にどう影響するかをレビューする。</li> </ul> </li> <li><strong>文書の修正</strong>: 評価結果に基づき、ビジネス・ケースおよびベネフィット・マネジメント・アプローチを修正し、プロジェクト委員会の承認を得られる状態に整える。</li> <li><strong>ログの更新</strong>: 必要に応じてプロジェクト・ログを確認、更新する。</li> </ul> </li> </ol> <h4>ステージの評価<a href="#ステージの評価"><span></span></a></h4> <blockquote> <p>ステージの結果をプロジェクト委員会に報告し、プロジェクト・マネジメント・チームが進捗を明確に把握できるようにする活動である。</p> </blockquote> <ol> <li>トリガー <ul> <li>実際のステージ終了にできるだけ近い時。</li> </ul> </li> <li>実施のポイント <ul> <li><strong>PMの役割</strong>: 単なる実績の報告にとどまらず、プロジェクトが今後も計画やビジネス・ケースを達成できるかについて、<strong>PMとしての見解</strong>を述べ、全体的なリスク状況を評価しなければならない。</li> </ul> </li> <li>PMに推奨される処置 <ul> <li>報告書の作成 <ul> <li><strong>ステージ終了報告書の準備</strong>: 最新のビジネス・ケース、プロジェクト計画、プロジェクト・ログ、マネジメント・アプローチに基づき、現在のステージのパフォーマンスを総括した<strong>ステージ終了報告書</strong>を作成する。</li> <li><strong>教訓(Lessons)の統合</strong>: これまでに記録された教訓をレビューし、報告書に反映させる。 ＊特に長期プロジェクトにおいては、これらの中間レビューがビジネスに大きなベネフィットをもたらす鍵となる。</li> </ul> </li> <li>ステークホルダーへの配慮 <ul> <li><strong>コミュニケーションの最適化</strong>: コミュニケーション・マネジメント・アプローチを確認し、外部関係者に対して報告書(または教訓報告書)のコピーを送付する義務や必要性があるかを確認する。</li> </ul> </li> </ul> </li> </ol> <h4>次のステージの要求<a href="#次のステージの要求"><span></span></a></h4> <blockquote> <p>現在のステージを正式に終了させ、次のステージへ進むための認可をプロジェクト委員会に要求する活動である。</p> </blockquote> <ol> <li>実施のポイント <ul> <li><strong>正当性の提示</strong>: 意思決定の根拠として、<strong>ステージ終了報告書</strong>および<strong>次のステージ計画書(または例外計画書)</strong> を提出する。</li> <li><strong>権限の委譲</strong>: プロジェクト委員会から次ステージの実行権限を得ることで、プロジェクトを継続させる。</li> </ul> </li> <li>PMに推奨される処置 <ul> <li>状況の説明と準備の確認 <ul> <li><strong>ステータスの総括</strong>: 現在のステージのパフォーマンス、次ステージの概要、必要なリソース(人員・設備等)を説明し、準備が整っていることを確認する。</li> <li><strong>仕様外項目の確認</strong>: ステージ進行中に<strong>条件付き承認</strong>となった仕様外項目(オフスペック)があれば、その状況を再確認する。</li> </ul> </li> <li>権限の取得 <ul> <li><strong>マネジメント成果物の承認要求</strong>: 以下の文書について、プロジェクト委員会の正式な承認を求める。 <ul> <li>次のステージ計画書(または例外計画書) ＊例外計画書が承認されない場合、改訂版が承認されるまで、現在のステージは委員会の指揮の下で続行されることになる。</li> <li>改訂されたPID</li> <li>改訂されたビジネス・ケースおよびベネフィット・マネジメント・アプローチ</li> </ul> </li> <li><strong>権限の要求</strong>: 次のステージを開始するための正式な権限を要求する。</li> </ul> </li> <li>教訓のレビュー: 適切なタイミングであれば、この時点で教訓をレビューする。 ＊特に長期プロジェクトにおいて、中間レビューによる知見の活用はビジネス上の大きなベネフィットに繋がる。</li> </ul> </li> </ol> <h3>適用<a href="#適用"><span></span></a></h3> <h4>一般的な考慮事項<a href="#一般的な考慮事項"><span></span></a></h4> <blockquote> <p>このプロセスの活動は固定的なものではなく、プロジェクトの規模や複雑さに応じて柔軟に運用することが可能である。</p> </blockquote> <ul> <li><strong>活動の柔軟性</strong>: このプロセスの活動は、プロジェクトの状況に応じて結合、分割、または同時に実行できる。</li> <li><strong>整合性の維持</strong>: 柔軟に運用する場合でも、以下のプロセスとの接続における完全性を損なわないよう、細心の注意を払わなければならない。 <ul> <li><strong>プロジェクトの立ち上げ(IP)</strong>: 初期計画との整合。</li> <li><strong>ステージのコントロール(CS)</strong>: 現場の進捗情報の吸い上げ。</li> <li><strong>プロジェクトの指揮(DP)</strong>: プロジェクト委員会への意思決定の要請。</li> </ul> </li> </ul> <h4>役割のテーラリング<a href="#役割のテーラリング"><span></span></a></h4> <blockquote> <p>成果物の作成責任と、実際の作業の委任についての考え方は以下の通りである。</p> </blockquote> <ul> <li><strong>PMの実行責任</strong>: このプロセスで発生する新しいマネジメント成果物(次ステージ計画書、ステージ終了報告書など)の作成に関する最終的な実行責任は、プロジェクト・マネージャー(PM)が負う。</li> <li><strong>作業の委任</strong>: PMが全体的な責任を維持することを前提として、実際の作成作業をプロジェクト支援やチーム・マネージャーなど、必要なスキルを持つ他の者に委任することができる。</li> <li><strong>専門性の活用</strong>: 技術的な詳細が必要な計画策定において、チーム・マネージャーの専門知識を借りることは、より堅固な計画を作成するために有効な手段となる。</li> </ul> <h3>責任<a href="#責任"><span></span></a></h3> <table><thead><tr><th>活動</th><th>ビジネス・レイヤー</th><th>プロジェクト・エグゼクティブ</th><th>シニア・ユーザー</th><th>シニア・サプライヤー</th><th>プロジェクト・マネージャー</th><th>チーム・マネージャー</th><th>プロジェクト保証</th><th>プロジェクト支援</th></tr></thead><tbody><tr><td>次のステージ計画書の準備</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>例外計画書の準備<br />(必要な場合)</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>プロジェクト計画書の更新</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>ビジネス・ケースの更新</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>ステージの評価</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>次のステージの要求</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>I</td><td>C</td><td>I</td></tr></tbody></table> <p>R = 実行責任、A = 説明責任、C = 協議先、I = 情報先</p> <h3>プロセスへのプラクティスの適用<a href="#プロセスへのプラクティスの適用"><span></span></a></h3> <table><thead><tr><th>プラクティス</th><th>ステージ境界のマネジメント・プロセスへの適用</th></tr></thead><tbody><tr><td><strong>ビジネス・ケース</strong></td><td>実績に基づきコスト・リスク・ベネフィットの予測を最新化する。外部環境の変化も反映し、<strong>正当性を再検証</strong>する。ベネフィットおよび持続可能性アプローチも必要に応じて更新する</td></tr><tr><td><strong>組織化</strong></td><td>チームのパフォーマンスと<strong>ウェルビーイング</strong>をレビューし、教訓として記録する。次ステージに向け、マネジメント組織や役割記述書を最適化する</td></tr><tr><td><strong>計画</strong></td><td>実際の実績を反映してプロジェクト計画書(期間・スコープ)を更新する。次のステージ計画書または例外計画書を作成する</td></tr><tr><td><strong>品質</strong></td><td>ステージ内の品質活動の完了を品質登録簿で確認し、ステージ終了報告書へ反映する。次計画で使用する成果物記述書を準備し、品質アプローチを更新する</td></tr><tr><td><strong>リスク</strong></td><td>現在のリスクを整理し、次ステージ特有のリスクを特定・更新する。リスク・マネジメント・アプローチは、必要に応じてレビューおよび更新する</td></tr><tr><td><strong>課題</strong></td><td>課題登録簿をレビューし、未解決の課題に対する次の一手を決定する。次ステージに向けた課題を追加・更新し、アプローチの妥当性を再確認する</td></tr><tr><td><strong>進捗</strong></td><td>成果物登録簿により納品状況を最終確認する。デイリー・ログや教訓ログを整理し、これらすべての情報を集約して<strong>ステージ終了報告書</strong>を発行する</td></tr></tbody></table>category:项目管理tag:プロジェクトtag:マネジメントtag:プロセスtag:ステージ境界https://blog.issyuu.com/zh/post/pm-processes-stage-boundaryzh:pm-processes-stage-boundary生きている限り、学び続けるTue, 21 Apr 2026 04:12:12 GMT<h2>ステージ境界<a href="#ステージ境界"><span></span></a></h2> <p>ステージ境界のマネジメントのプロセスの目的は、プロジェクト・マネージャーがプロジェクト委員会に以下を行えるだけの十分な情報を提供できるようにする。 * 現在のステージの成功の確認 * 次のステージ計画書の準備 * 更新したプロジェクト計画書のレビュー * ビジネス正当性の継続とリスクの許容可能性の確認 このプロセスは各ステージの終了時か終了間際に実行します。</p> <p>(プロジェクトは必ずしも計画どおりには運びません。(ステージまたはプロジェクトがその許容度を超えることが予測された場合)プロジェクト委員会は例外報告書への対応として、現ステージの再計画や、場合によってはプロジェクトの再計画を要求する場合があります。再計画のアウトプットは例外計画書です。例外計画書は、ステージ計画書がプロジェクト委員会の承認を得るために提出されるのと同様に、プロジェクト委員会に提出されます。例外も、このプロセスのトリガーとなる可能性があります。)</p> <p>ステージ境界のマネジメントのプロセスの達成目標は以下のとおりです。 * 現在のステージ計画書のすべての成果物が完了し承認されていることを、プロジェクト委員会に保証する * 次のステージのステージ計画書または例外計画書を準備する * プロジェクト立ち上げ文書をレビューし、必要に応じて更新する(特にビジネス・ケース、プロジェクト計画書、ユーザーの期待品質、マネジメント・アプローチ、プロジェクト・マネジメント・チーム組織、役割記述書) * プロジェクト委員会がプロジェクトの継続的な実行可能性を評価するために必要な情報を提供する * プロジェクトの後続のステージやその他のプロジェクトで役立つ情報や教訓を記録する * 次のステージを開始する認可を要求する 例外については、ステージ境界のマネジメントのプロセスの達成目標は上記と同様ですが、例外計画書の準備と、プロジェクトまたは現在のステージ計画書を例外計画書に置き換えるための承認を求めることが含まれます。</p> <p>ステージ境界のマネジメントのプロセスは、プロジェクトをステージに分けることを前提としています。 (プロジェクトは、その規模にかかわらず、プロジェクトで作成する成果物に約束されたベネフィットを、それ自体、あるいはプログラムまたはポートフォリオの一部として提供する必要があります。各ステージの終わりには、プロジェクトのビジネス正当性を再確認します。時間と資金を浪費しないように、必要に応じてプロジェクトを変更したり、中止したりすることがあります。) プロジェクトは計画どおりに進まなくなったり、ビジネス正当性を阻害するような外部要因の影響を受けたりする場合があることを認識することが重要です。プロジェクトやステージが許容度を超える可能性が高いとプロジェクト・マネージャーが予測した場合、これは今後プロジェクトが失敗する可能性があることを示唆しています。このような場合、プロジェクトを正しい指揮とコントロール下に置くための是正処置のメカニズムを用意することが重要です。 中止を前向きに決定することは、障害ではありません。しかし、十分な情報を提供しなければ、プロジェクト委員会が情報に基づいた決定を下せず、誤った決定につながったり、意思決定が不必要に遅れたりする場合があります。そのため、プロジェクト委員会に十分な情報を提供しないことは失敗といえます。 ステージ境界のマネジメントのプロセスは、例外手順を実施する手段を提供します。</p> <h3>活動<a href="#活動"><span></span></a></h3> <table><thead><tr><th>インプット</th><th>活動</th><th>アウトプット</th></tr></thead><tbody><tr><td>ステージ境界が近づく(このプロセスをトリガー)<br />プロジェクト立ち上げ文書(レビュー)<br />プロジェクト計画書(レビュー)<br />プロジェクト・ログ(確認)</td><td>次のステージ計画書の準備</td><td>プロジェクト・ログ(更新)<br />ステージ計画書(次のステージ用に作成)<br />成果物記述書(次のステージ用に作成)<br />プロジェクト立ち上げ文書(必要に応じて更新)</td></tr><tr><td>例外計画書の要求(このプロセスをトリガー)<br />例外報告書(レビュー)<br />プロジェクト立ち上げ文書(レビュー)<br />プロジェクト計画書(レビュー)<br />プロジェクト・ログ(確認)</td><td>例外計画書の準備(必要な場合)</td><td>プロジェクト・ログ(更新)<br />例外計画書(作成)<br />成果物記述書(改訂されたステージの作成/更新)<br />例外計画書の承認の要求(プロジェクトの指揮のプロセスをトリガー)</td></tr><tr><td>プロジェクト・ログ(確認)<br />ステージ計画書(確認)<br />プロジェクト計画書(レビュー)</td><td>プロジェクト計画書の更新</td><td>プロジェクト計画書(必要に応じて更新)</td></tr><tr><td>プロジェクト計画書(確認)<br />プロジェクト・ログ(確認)<br />ビジネス・ケース(レビュー)</td><td>ビジネス・ケースの更新</td><td>ベネフィット・マネジメント・アプローチ(必要に応じて更新)<br />ビジネス・ケース(必要に応じて更新)</td></tr><tr><td>プロジェクト・ログ(確認)<br />コミュニケーション・マネジメント・アプローチ(確認)</td><td>ステージの評価</td><td>ステージ終了報告書(作成)</td></tr><tr><td>ステージ終了報告書<br />ステージ計画書または例外計画書(次のステージ用)</td><td>次のステージの要求</td><td>次のステージの要求(プロジェクトの指揮のプロセスをトリガー)</td></tr></tbody></table> <h4>次のステージ計画書の準備<a href="#次のステージ計画書の準備"><span></span></a></h4> <p>現在のステージの終わりが近づいたら、次のステージのステージ計画書を作成します。(クローズ活動は、最終ステージのためのステージ計画書の一部として計画されます。) 計画立案は単独で行う活動ではありません。プロジェクト・マネージャーは実行可能な計画を作成するために、プロジェクト委員会、プロジェクト保証、チーム・マネージャー、その他の利害関係者などと協議する必要があります。計画立案に関与する人の数が多いほど、計画な堅固なものとなります(適切な人が関与している場合に限る)。</p> <p>プロジェクト・マネージャーに推奨される処置 * プロジェクト立ち上げ文書のコンポーネントをレビューし、必要に応じて更新する。例えば、マネジメント・アプローチから計画立案要件を確認する。変更要求に関しては、プロジェクト委員会と協議する必要がある場合があります。 * 次のステージに適用する教訓の教訓ログを確認する。 * ステージに適用可能なマイルストーンのプロジェクト計画書を確認する。 * 次のステージのステージ計画書を作成する。 * 次のステージで納品される成果物の成果物記述書を作成する。 * 次のステージで作成する予定の成果物の成果物登録簿のレコードを作成または更新する。 * 新しく課題やリスクが特定された場合(または既成のものに修正が必要な場合)、プロジェクト・ログを更新する。 * 計画された品質マネジメント活動の品質登録簿を更新する。これには成果物のターゲット・レビュー日と承認日を記載します。</p> <h4>例外計画書の準備(必要な場合)<a href="#例外計画書の準備必要な場合"><span></span></a></h4> <p>ステージやプロジェクトについて、合意された許容度を超えて偏差が発生することが予測される場合、プロジェクト委員会の承認は効力を失います。 プロジェクト委員会は例外報告書を受け取ると、例外計画書を要求します。(例外計画書は、計画されたステージ境界の前に作成されますが、プロジェクト委員会による承認が、修正されたステージのステージ境界となります。) プロジェクト・マネージャーに推奨される処置 * プロジェクト・ログを更新して、例外計画書に対するプロジェクト委員会の要求を記録する。 * プロジェクト立ち上げ文書をレビュー(必要に応じて更新)する。例えば、マネジメント・アプローチから計画立案要件を確認します。変更要求に関しては、プロジェクト委員会と協議する必要がある場合があります。 * 例外計画書に適用する教訓の教訓ログを確認する。 * 例外計画書に適用可能なマイルストーンについて、プロジェクト計画書をレビューする。 * 例外計画書を作成する。 * 次のステージで納品される成果物の成果物記述書を作成または更新する。 * 例外計画書によって作成される成果物の成果物登録簿のレコードを作成または更新する。 * 新しく課題やリスクが特定された場合や既成のものに修正が必要な場合、プロジェクト・ログを更新する。 * 計画された品質マネジメント活動のプロジェクト・ログを更新する。これには成果物のターゲット・レビュー日と承認日を記載します。</p> <h4>プロジェクト計画書の更新<a href="#プロジェクト計画書の更新"><span></span></a></h4> <p>プロジェクト委員会はプロジェクト全体を通じ、プロジェクト計画書を基に進捗を測定します。 プロジェクト計画書は、終了しようとしているステージの進捗を含めて更新し、開始しようとしているステージのステージ計画書や例外計画書にある期間とコストを予測します。コストや終了日の修正に関する詳細は、ビジネス・ケースを更新するときに使用します。</p> <p>プロジェクト・マネージャーに推奨される処置 * 現在のステージ計画書が、実際の進捗を反映した最新のものであることを確認し、必要に応じて更新する。 * プロジェクト計画書を修正する。 * 新しく課題やリスクが特定された場合や既成のものに修正が必要な場合、プロジェクト・ログを更新する。</p> <h4>ビジネス・ケースの更新<a href="#ビジネスケースの更新"><span></span></a></h4> <p>(通常、プロジェクトが依然として実行可能な場合のみ、プロジェクト委員会はプロジェクトの続行を認可されます。ベネフィットは、現在合意されているビジネス・ケースで確立されている期間、コスト、品質、スコープ、リスク、持続可能性のパラメーターの範囲内で実現されます。) (プロジェクトは、平穏な環境下で実施されるものではありません。プロジェクトの外部環境は変化し、それに伴い、プロジェクト成果物の開発も変化します。したがって、ビジネス・ケースにはこれらの変更を反映する必要があり、プロジェクトとの関連性を保つためにレビューし、修正する必要があります。) プロジェクト・エグゼクティブはビジネス・ケースに対する説明責任を負っています。そのため、プロジェクト・マネージャーがプロジェクト委員会の承認を得る準備において、ビジネス・ケースをレビューしたり更新したりする際には、プロジェクト・エグゼクティブと協議しなければなりません。</p> <p>プロジェクト・マネージャーに推奨される処置 * 関係する組織のリスク選好度とリスク・キャパシティに変更がなかったか、またリスク許容度を再定義する必要がないかを確認する。 * プロジェクト・ログを使用してプロジェクト・リスクを評価し、プロジェクトの集約されたリスク影響度を確定して、ビジネス・ケースに影響を与える現在の主要リスクを特定する。これには、集約されたリスク影響度がリスク許容度内に収まっているかどうかの評価が含まれます。 * ベネフィット・マネジメント・アプローチを更新して、ステージで実行されたベネフィット・マネジメント処置の結果を反映する。 * プロジェクトの最終実施日が早い日程または遅い日程に変更されたかをプロジェクト計画書で調査、レビューする。これは予想されるベネフィットの一部または全部に影響を及ぼすことがあります。 * 必要に応じてプロジェクト・ログを確認、更新する。 * プロジェクト委員会の承認を得られるよう、ビジネス・ケースや、必要に応じてベネフィット・マネジメント・アプローチを修正する。</p> <h4>ステージの評価<a href="#ステージの評価"><span></span></a></h4> <p>ステージの結果はプロジェクト委員会に報告し、プロジェクト・マネジメント・チームが進捗をはっきりと確認できるようにします。 プロジェクト・マネージャーは、プロジェクトが今後もプロジェクト計画書やビジネス・ケースを満たしていけるかどうかの能力について意見を述べ、全体的なリスク状況を評価します。この活動は、実際のステージ終了にできるだけ近い時点で行います。 プロジェクト・マネージャーに推奨される処置 * ステージのパフォーマンスに基づいて、更新されたビジネス・ケース、更新されたプロジェクト計画書とプロジェクト・ログ、更新されたマネジメント・アプローチを使用して、現在のステージのステージ終了報告書を準備する。 * これまでに記録された教訓を確認し、ステージ終了報告書に含める。これは、教訓の中間レビュー(またはプロジェクト自体の中間レビュー)がビジネスにベネフィットをもたらす可能性のある長期プロジェクトでは特に重要です。 * コミュニケーション・マネジメント・アプローチをレビューし、ステージ終了報告書(および該当する場合には、教訓報告書)のコピーを、その時点で外部関係者に送付する要件があるかどうかを確認する。</p> <h4>次のステージの要求<a href="#次のステージの要求"><span></span></a></h4> <p>プロジェクト・マネージャーはプロジェクト委員会に連絡して、現在のステージを終了して次のステージに進めるよう要求します。(正式な正当性は、ステージ終了報告書と次のステージ計画書または例外計画書に記載されています。) プロジェクト・マネージャーに推奨される処置 * 現在のステージのパフォーマンス、次のステージの概要、必要な人員とリソースについてプロジェクト委員会に説明し、進める準備ができていることを確認する。プロジェクト・マネージャーは、ステージ中に仕様外項目の条件付き承認があった部分も確認する。 * 例外計画書やステージ計画書、および該当する場合には、改訂プロジェクト計画書、改訂ベネフィット・マネジメント・アプローチ、改訂ビジネス・ケース(第 14 章を参照)について、プロジェクト委員会の承認を求める。プロジェクト委員会が例外計画書を承認しない場合、改訂された例外計画書が承認されるまで、現在のステージはプロジェクト委員会の指揮に従って続行されます。 * 次のステージを提供できるよう、プロジェクト委員会に権限を要求する。 * 適切な場合は、この時点で教訓をレビューする。これは特に、中間の教訓レビュー(またはプロジェクト自体の中間レビュー)がビジネスにベネフィットをもたらす可能性のある長期のプロジェクトの場合に当てはまります。</p> <h3>適用<a href="#適用"><span></span></a></h3> <h4>一般的な考慮事項<a href="#一般的な考慮事項"><span></span></a></h4> <p>このプロセスの活動は、状況に応じて結合、分割、同時に実行できます。ただし、プロジェクトの立ち上げのプロセス、ステージのコントロールのプロセス、プロジェクトの指揮のプロセスとの関連の完全性が確保されるよう注意を払う。</p> <h4>役割のテーラリング<a href="#役割のテーラリング"><span></span></a></h4> <p>プロジェクト・マネージャーは、このプロセスにおけるあらゆる新しいマネジメント成果物の作成の実行責任を負いますが、プロジェクト・マネージャーが全体的な責任を負う場合は、プロジェクト支援やチーム・マネージャーなど必要なスキルを持つ他の者に作業を委任できます。</p> <h3>責任<a href="#責任"><span></span></a></h3> <table><thead><tr><th>活動</th><th>ビジネス・レイヤー</th><th>プロジェクト・エグゼクティブ</th><th>シニア・ユーザー</th><th>シニア・サプライヤー</th><th>プロジェクト・マネージャー</th><th>チーム・マネージャー</th><th>プロジェクト保証</th><th>プロジェクト支援</th></tr></thead><tbody><tr><td>次のステージ計画書の準備</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>例外計画書の準備<br />(必要な場合)</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>プロジェクト計画書の更新</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>ビジネス・ケースの更新</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>ステージの評価</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>次のステージの要求</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>I</td><td>C</td><td>I</td></tr></tbody></table> <p>R = 実行責任、A = 説明責任、C = 協議先、I = 情報先</p> <h3>プロセスへのプラクティスの適用<a href="#プロセスへのプラクティスの適用"><span></span></a></h3> <table><thead><tr><th>プラクティス</th><th>ステージ境界のマネジメント・プロセスへの適用</th></tr></thead><tbody><tr><td>ビジネス・ケース</td><td>ステージ終了時のプロジェクトのパフォーマンスが評価され、ビジネス・ケースが更新されて、予測コスト、リスク、ベネフィットに対する変更、およびビジネス・ケースに影響を与えるプロジェクト外部の変更が反映されます。ベネフィット・マネジメント・アプローチと持続可能性マネジメント・アプローチは、必要に応じてレビューおよび更新されます</td></tr><tr><td>組織化</td><td>プロジェクト・チーム・パフォーマンスとウェルビーイングおよび状況は、学んだ教訓とステージ終了報告書のレポートへのインプットの為にレビューされます。<br />コミュニケーション・マネジメント・アプローチ、変更マネジメント・アプローチ、商業マネジメント・アプローチは、必要に応じてレビューおよび更新されます。<br />プロジェクト・マネジメント・チーム組織と役割記述書がレビューおよび更新され、次のステージのために新しい役割記述書が作成されます</td></tr><tr><td>計画</td><td>ステージ終了時のプロジェクトのパフォーマンスが評価され、スコープと時期の変更を反映するようプロジェクト計画書が更新されます。<br />次のステージ計画書または例外計画書が作成されます</td></tr><tr><td>品質</td><td>品質登録簿が確認され、ステージに必要な品質活動が実施されたことを確認し、ステージ終了報告書にインプットが提供されます。<br />次のステージ計画書または例外計画書の成果物記述書が作成されます。<br />プロジェクト成果物記述書と品質マネジメント・アプローチは、必要に応じてレビューおよび更新されます</td></tr><tr><td>リスク</td><td>リスク登録簿は、現在のステージのリスクを排除し、次のステージのリスクを追加または更新し、ステージ終了報告書にインプットを提供するためにレビューされます。<br />リスク・マネジメント・アプローチは、必要に応じてレビューおよび更新されます</td></tr><tr><td>課題</td><td>課題登録簿は、現在のステージの課題を排除するか、次の処置を特定し、次のステージの課題を追加または更新し、ステージ終了報告書にインプットを提供するためにレビューされます。<br />課題マネジメント・アプローチは、必要に応じてレビューおよび更新されます</td></tr><tr><td>進捗</td><td>成果物登録簿は、ステージに必要な成果物が提供されたことを確認し、ステージ終了報告書にインプットを提供するために確認されます。<br />デイリー・ログと教訓ログは、現在のステージ処置を排除し、次のステージの処置を追加または更新し、ステージ終了報告書にインプットを提供するためにレビューされます。<br />デジタルおよびデータ・マネジメント・アプローチは、必要に応じてレビューおよび更新されます。<br />ステージ終了報告書が作成および発行されます</td></tr></tbody></table>category:项目管理tag:プロジェクトtag:マネジメントtag:プロセスtag:ステージ境界https://blog.issyuu.com/zh/post/pm-processes-product-delivery-dzh:pm-processes-product-delivery-d生きている限り、学び続けるMon, 20 Apr 2026 04:12:12 GMT<h2>成果物のデリバリー<a href="#成果物のデリバリー"><span></span></a></h2> <blockquote> <p>成果物デリバリーの目的は、PMとTMの間のコミュニケーションと作業の受け渡しをコントロールする。スペシャリスト成果物の受け入れ、実行、報告、デリバリーに関する要件を合意し、確実な成果物提供を実現する。</p> </blockquote> <h3>達成目標<a href="#達成目標"><span></span></a></h3> <blockquote> <p>以下の事項を確実に行うことで、品質と計画を遵守したデリバリーを実現する。</p> </blockquote> <ul> <li><strong>合意の確立</strong>: チームに割り当てられた成果物に関する作業が、認可され、合意される。</li> <li><strong>明確な理解</strong>: 作成すべきもの、必要な労力、コスト、期間をチーム側が把握している。</li> <li><strong>品質と許容度の遵守</strong>: 成果物が期待品質を満たし、設定された許容度内で提供される。</li> <li><strong>期待の管理</strong>: PMが期待値を適切に管理できるよう、正確な進捗情報を合意された頻度に提供する。</li> </ul> <h3>位置付け<a href="#位置付け"><span></span></a></h3> <h4>TMの動き<a href="#tmの動き"><span></span></a></h4> <blockquote> <p>TMはチームの代表として、以下のステップで成果物の作成を管理する。</p> </blockquote> <ul> <li>準備と計画 <ul> <li><strong>WPの受け入れ</strong>: PMから認可されたワーク・パッケージを内容合意の上で受け入れる。</li> <li><strong>チーム計画書の作成</strong>: WPに基づき、具体的なチーム計画書を作成する(ステージ計画書作成と並行して実施可能)。</li> <li><strong>関係の維持</strong>: WP 記述書で定義された開発・運用・保守間の連携を維持する。</li> </ul> </li> <li>開発と品質管理 <ul> <li><strong>手法の遵守</strong>: 指定された開発手法に従い、成果物を開発する。</li> <li><strong>品質の立証</strong>: 品質記述書に定められた品質手法を用い、各成果物が仕様を満たしていることを証明する。</li> </ul> </li> <li>提供 <ul> <li><strong>承認の取得</strong>: 完成した成果物に対し、指定された承認権限者から正式な承認を得る。</li> <li><strong>成果物の納品</strong>: WP 記述書で指定された手順に従い、承認済み成果物をPMへ提供する。</li> </ul> </li> </ul> <h4>実施のポイント<a href="#実施のポイント"><span></span></a></h4> <ul> <li>自律性とマイクロマネジメントの回避 <ul> <li><strong>権限の委任</strong>: PMは、ワーク・パッケージ(WP)記述書で確立された許容度と信頼に基づき、TMに十分な自律性を与える。</li> <li><strong>副作用の防止</strong>: PMによるマイクロマネジメントは、チームのフラストレーションや作業の遅延を招くため、これを回避して<strong>求められている成果</strong>の提供に集中させる。</li> </ul> </li> <li>PM 視点とTM 視点 <ul> <li><strong>PM(ステージのコントロール)</strong>: <strong>ステージ全体がうまく回っているか</strong> を俯瞰する。</li> <li><strong>TM(成果物デリバリーのマネジメント)</strong>: <strong>割り当てられた成果物を、品質通りに期間内に作れるか</strong> に集中する。</li> </ul> </li> <li>チーム計画書の柔軟性 チーム計画書の形式は、状況に応じて柔軟に変えて良い。 <ul> <li><strong>シンプルな場合</strong>: WP 記述書にスケジュールを付け加えた程度。</li> <li><strong>複雑な場合</strong>: ステージ計画書に近い、詳細な構成。</li> <li><strong>契約が絡む場合</strong>: WP 自体が契約書の一部として機能することもある。</li> </ul> </li> </ul> <h3>活動<a href="#活動"><span></span></a></h3> <table><thead><tr><th>インプット</th><th>活動</th><th>アウトプット</th></tr></thead><tbody><tr><td>ワーク・パッケージの認可(このプロセスをトリガー)<br />ワーク・パッケージ記述書(レビュー)</td><td>ワーク・パッケージの受け入れ</td><td>チーム計画書 (作成、更新)</td></tr><tr><td>チーム計画書 (レビュー)<br />ワーク・パッケージ記述書(レビュー)</td><td>ワーク・パッケージの実行</td><td>プロジェクト・ログ (更新)<br />スペシャリスト成果物 (作成)</td></tr><tr><td>チーム計画書 (レビュー)<br />ワーク・パッケージ記述書(レビュー)<br />プロジェクト・ログ (レビュー)</td><td>ワーク・パッケージの評価</td><td>チェックポイント報告書 (期間ごとに作成)<br />プロジェクト・ログ (更新)</td></tr><tr><td>チーム計画書 (確認)<br />ワーク・パッケージ記述書 (確認)<br />プロジェクト・ログ (レビュー)</td><td>ワーク・パッケージの完了の通知</td><td>チーム計画書 (更新)<br />ワーク・パッケージ (完了)<br />完了したワーク・パッケージの通知(ステージのコントロール・プロセスをトリガー)</td></tr></tbody></table> <h4>ワーク・パッケージの受け入れ<a href="#ワークパッケージの受け入れ"><span></span></a></h4> <blockquote> <p>作業が開始される前に、PMとTMの間で、提供内容、制約、手順、および計画の妥当性について完全な合意を形成する活動である。</p> </blockquote> <ol> <li>TMに推奨される処置 <ul> <li>内容の理解と計画の策定 <ul> <li><strong>内容の理解</strong>: WP 記述書をレビューし、成果物の内容と納期を正確に把握する。</li> <li><strong>チーム計画書の作成</strong>: 制約条件を遵守し、具体的な<strong>チーム計画書</strong>を作成する。</li> <li><strong>標準への準拠確認</strong>: チーム計画書が実行可能か、またサプライヤー側の標準に準拠しているかについて、<strong>プロジェクト保証(サプライヤー)</strong> と協議する。</li> </ul> </li> <li>品質とログの管理 <ul> <li><strong>品質体制の確認</strong>: 追加の品質レビュー担当者が必要かどうかをプロジェクト保証と協議し、プロジェクト・ログ(品質登録簿等)を最新化する。</li> <li><strong>手順の確認</strong>: プロジェクト・ログを更新する際の手順をWP 記述書で確認する。</li> </ul> </li> <li>承認とリスク評価 <ul> <li><strong>計画の承認取得</strong>: チーム計画書について必要な承認を得る。 ※顧客・サプライヤー間の商業的関係において、PMによる承認が不適切な場合は、<strong>シニア・サプライヤー</strong>がレビューと承認を行う。</li> <li><strong>リスクのレビュー</strong>: チーム計画書に基づき、リスクのレビューを実施する。新たなリスクを特定した場合はPMに通知し、許可されている場合は直接プロジェクト・ログを更新する。</li> <li><strong>最終合意</strong>: すべての条件が整った段階で、WPの提供に正式に合意する。</li> </ul> </li> </ul> </li> </ol> <h4>ワーク・パッケージの実行<a href="#ワークパッケージの実行"><span></span></a></h4> <blockquote> <p>認可されたWPの要件に従い、実際にスペシャリスト成果物を開発・モニタリングする活動である。</p> </blockquote> <ol> <li>実施のポイント <ul> <li><strong>自律的な管理</strong>: TMは、設定された許容度の範囲内であれば、自律的に作業の実施や是正処置を行うことができる。 <ul> <li><strong>予測に基づく行動</strong>: TMは、WPが許容度内で完了できると予測される限り、自らコントロールを継続する。</li> <li><strong>逸脱の報告</strong>: もしWPの許容度を超えることが予測された場合、TMは独断で処置せず、<strong>速やかにPMに課題を提起</strong>しなければならない。その後の処置はPMが決定する。</li> </ul> </li> <li><strong>心理的安全性の確保</strong>: チーム内で課題やリスクを隠さず、迅速かつ適切に対処できる環境を維持することが、デリバリー成功の鍵となる。</li> </ul> </li> <li>TMに推奨される処置 TMは開発の現場監督として、以下の管理業務を遂行する。 <ul> <li>開発の管理と進捗報告 <ul> <li><strong>要件の遵守</strong>: WP 記述書とチーム計画書に基づき、成果物が正しく作られるよう現場をリードする。</li> <li><strong>情報のフィードバック</strong>: 新たな課題、リスク、教訓を特定した場合は、PMに通知し、PMが必要と判断した処置を確実に実行する。</li> </ul> </li> <li>品質管理と記録の更新 <ul> <li><strong>品質活動の完了報告</strong>: 計画された品質活動が完了するたびに、PMへ通知し、<strong>品質登録簿</strong>を最新の状態に更新する。</li> <li><strong>承認と登録</strong>: 完成した成果物に対して、成果物記述書で定められた承認権限者から正式な承認を取得する。承認後は<strong>成果物登録簿</strong>のステータスを更新し、完了を記録する。</li> </ul> </li> </ul> </li> </ol> <h4>ワーク・パッケージの評価<a href="#ワークパッケージの評価"><span></span></a></h4> <blockquote> <p>TMが、WP 記述書で定められた期間ごとの進捗を自らレビューし、その状況をPMへ報告する活動である。</p> </blockquote> <ol> <li>運用のポイント <ul> <li><strong>多角的なレビュー</strong>: 単なるスケジュールの進捗だけでなく、品質・リスク・課題・教訓など、WPに関連するあらゆる側面を確認し、情報の正確性を担保する。</li> <li>商業的環境と支援 サプライヤー(受注側)が外部組織である場合、管理方法には以下の柔軟性が認められる。 <ul> <li><strong>サプライヤー独自の管理</strong>: サプライヤーは、プロジェクト全体のログとは別に、自社固有の管理ツールや登録簿を使用して評価を行う場合がある。</li> <li><strong>プロジェクト支援の活用</strong>: プロジェクト支援の役割が、プロジェクト全体のログから当該 WPに関連する情報を抽出して提供し、TMの評価作業をサポートすることもある。</li> </ul> </li> </ul> </li> <li>推奨される処置 TMは、以下の各ドキュメントやログを網羅的に確認し、進捗の全体像を把握する。 <ul> <li>状況のレビュー 報告を行う前に、以下の情報を照合して現在のWPのステータスを正確に把握する。 <ul> <li><strong>計画との比較</strong>: WP 記述書とチーム計画書をレビューし、期待される進捗と実績を比較する。</li> <li><strong>ログの確認</strong>: 課題登録簿、リスク登録簿、教訓ログを確認し、WPに影響を与える事象を整理する。</li> <li><strong>品質と成果物の確認</strong>: 品質登録簿(活動ステータス)と成果物登録簿(承認レコードを含む完了状況)を確認する。</li> </ul> </li> <li>ステータスの報告 <ul> <li><strong>正式報告</strong>: 把握したステータスを<strong>チェックポイント報告書</strong>にまとめ、PMに提供する。 ＊プル・システム: アジャイルを採用している場合は、報告書を送る代わりに、PMが<strong>カンバン・ボード</strong>や<strong>バーンダウン・チャート</strong>などの進捗チャートを直接確認(プル)できる環境を維持する。</li> </ul> </li> </ul> </li> </ol> <h4>ワーク・パッケージの完了の通知<a href="#ワークパッケージの完了の通知"><span></span></a></h4> <blockquote> <p>WPに含まれる全作業が終了し、すべての成果物が承認されたことをPMへ正式に伝え、引き渡しを行う活動である。</p> </blockquote> <ol> <li>運用のポイント <ul> <li><strong>品質の保証</strong>: 単に<strong>作業が終わった</strong>という報告ではなく、定義された品質基準をクリアし、必要な承認を得ていることを裏付ける。</li> <li><strong>例外事項の共有</strong>: 完了時に残っているリスクや仕様外項目(オフスペック)を明確にし、PMが次の判断を下せるようにする。 ＊全てが完璧に終わるのが理想だけど、現実には<strong>一部の軽微な不備を承知で承認された</strong>というケースもある。そうした<strong>未解決の課題やリスクを隠さずに強調して伝える</strong>ことが、PMが次の判断を下すための重要なヒントになる。</li> </ul> </li> <li>TMに推奨される処置 <ul> <li>成果物の提供と確認 <ul> <li><strong>規定手順による提供</strong>: WP 記述書で合意された手順に従い、完成した成果物をPMに提供する。</li> <li><strong>承認の最終検証</strong>: 承認レコードをレビューし、WPによって提供されるすべての成果物が適切に承認済みであることを確認する。</li> </ul> </li> <li>記録の更新とレビュー</li> <li><strong>チーム計画書の完了</strong>: 計画書を最新化し、当該 WPが完了したことを記録する。</li> <li><strong>ログの総点検</strong>: プロジェクト・ログ(リスク登録簿、課題登録簿、教訓ログ)をレビューし、WPに関連する未解決事項や得られた知見を整理する。</li> <li>PMへの報告と最終通知 <ul> <li><strong>パフォーマンスの説明</strong>: WP 記述書での合意内容に対し、実際の作業パフォーマンス(期間、コスト、品質など)がどうであったかをPMに説明する。</li> <li><strong>残存事項の強調</strong>: 完成した成果物に関連する<strong>未解決の課題(仕様外項目など)</strong> や、依然として残っているリスクをPMに対して強調して伝える。</li> <li><strong>完了の正式通知</strong>: 上記の確認を経て、PMにWPの完了を正式に通知する。</li> </ul> </li> </ul> </li> </ol> <h3>適用<a href="#適用"><span></span></a></h3> <blockquote> <p>スペシャリスト作業の特性に応じた柔軟な運用が認められる一方、上位のマネジメント層(PM)との連携の完全性を維持することが重要である。</p> </blockquote> <h4>一般的な考慮事項<a href="#一般的な考慮事項"><span></span></a></h4> <blockquote> <p>専門的な知見を最大限に活かし、チームの自律性を重んじるコントロールが推奨される。</p> </blockquote> <ul> <li><strong>活動の柔軟な運用</strong>: 状況に合わせて活動を結合・分割・同時実行できるが、常に<strong>ステージのコントロール</strong>プロセスとの確実な接続を意識しなければならない。</li> <li><strong>専門手法に適した管理</strong>: 専門的な作業には、その種類に適したデリバリー手法(アジャイル等)や尺度が用いられる。PMとTMはこれに合意し、<strong>WP 記述書</strong>に反映させ、プロジェクト全体の管理アプローチと整合させる。</li> <li><strong>WPの階層化とガバナンス</strong>: WPは必ずしも小規模とは限らない。大規模なWPを扱う場合は、TMがさらに小さなWPへと階層化してチームメンバーに割り当て、適切なコントロール環境を構築する。</li> <li><strong>協調的な文化</strong>: TMとメンバーの関係は協調的であるべきである。TMは単に命令を下すのではなく、メンバーのオーナーシップを促す<strong>ファシリテーター</strong>として振る舞い、プロジェクト目標への貢献を支援する。</li> </ul> <h4>役割のテーラリング<a href="#役割のテーラリング"><span></span></a></h4> <blockquote> <p>組織の規模や複雑性に応じて、マネジメント体制を柔軟に構成できる。</p> </blockquote> <ul> <li><strong>TMの役割と代行</strong>: TMはプロセスの全活動に実行責任を負うが、PMがTMを兼任できる。</li> <li><strong>TMの階層化</strong>: 大規模プロジェクトでは、WPを分割して複数のTMを配置し、報告ラインを階層化できる。この場合、上位のTMが全体の実行責任を負い、PMへ報告を行う。</li> <li><strong>成果物記述書の柔軟性</strong>: WP 記述書の作成・更新・承認の担当者は、PMとTMが内容に合意していれば、プロジェクトの必要に応じて柔軟に変更(アサイン)できる。</li> </ul> <h3>責任<a href="#責任"><span></span></a></h3> <table><thead><tr><th>活動</th><th>ビジネス・レイヤー</th><th>プロジェクト・エグゼクティブ</th><th>シニア・ユーザー</th><th>シニア・サプライヤー</th><th>プロジェクト・マネージャー</th><th>チーム・マネージャー</th><th>プロジェクト保証</th><th>プロジェクト支援</th></tr></thead><tbody><tr><td>ワーク・パッケージの受け入れ</td><td></td><td></td><td></td><td></td><td>A</td><td>R</td><td></td><td>I</td></tr><tr><td>ワーク・パッケージの実行</td><td></td><td></td><td></td><td></td><td>A</td><td>R</td><td>C</td><td>C</td></tr><tr><td>ワーク・パッケージの評価</td><td></td><td></td><td></td><td></td><td>A</td><td>R</td><td>C</td><td>C</td></tr><tr><td>ワーク・パッケージの完了の通知</td><td></td><td></td><td></td><td></td><td>A</td><td>R</td><td>C</td><td>I</td></tr></tbody></table> <p>R = 実行責任、A = 説明責任、C = 協議先、I = 情報先</p> <h3>プロセスへのプラクティスの適用<a href="#プロセスへのプラクティスの適用"><span></span></a></h3> <table><thead><tr><th>プラクティス</th><th>成果物デリバリーのマネジメント・プロセスへの適用</th></tr></thead><tbody><tr><td><strong>ビジネス・ケース</strong></td><td>WP 記述書で定義された<strong>ベネフィットおよび持続可能性</strong>に関する要件を、実行プロセスの中で確実に充足させる</td></tr><tr><td><strong>組織化</strong></td><td>コミュニケーション、変更、商業の各管理要件を遵守する。チーム構造や作業スケジュールを記した<strong>チーム計画書</strong>を作成し、<strong>チームのウェルビーイング</strong>を継続的に監視する</td></tr><tr><td><strong>計画</strong></td><td>PMからの要求に基づき、WPを完遂するための具体的な<strong>チーム計画書</strong>を作成する</td></tr><tr><td><strong>品質</strong></td><td>スペシャリスト成果物を開発・提供し、WPの品質要件を満たす。<strong>品質登録簿</strong>を更新し、計画された活動と実績を記録する</td></tr><tr><td><strong>リスク</strong></td><td>チームレベルでリスクを管理し、<strong>リスク登録簿</strong>を最新化する。必要に応じてPMへエスカレーションする</td></tr><tr><td><strong>課題</strong></td><td>チームレベルで課題を管理し、<strong>課題登録簿</strong>に最新化する。必要に応じてPMへエスカレーションする</td></tr><tr><td><strong>進捗</strong></td><td>成果物のステータスに基づき<strong>成果物登録簿</strong>を更新する。合意された頻度で<strong>チェックポイント報告書</strong>を提出し、<strong>教訓ログ</strong>に知見を更新する</td></tr></tbody></table>category:项目管理tag:プロジェクトtag:マネジメントtag:プロセスtag:成果物のデリバリーhttps://blog.issyuu.com/zh/post/pm-processes-product-delivery-dzh:pm-processes-product-delivery-d生きている限り、学び続けるMon, 20 Apr 2026 04:12:12 GMT<h2>成果物のデリバリー<a href="#成果物のデリバリー"><span></span></a></h2> <p>成果物デリバリーのマネジメント・プロセスの目的は、プロジェクト・マネージャーとチーム・マネージャー間のつながりをコントロールする。これは、スペシャリスト成果物の受け入れ、実行、報告、デリバリーの要件に合意することで達成されます。チーム・マネージャーの役割は、ある作業領域をとりまとめ、プロジェクト成果物を形成する 1 つまたは複数のスペシャリスト成果物を提供することです。(チーム・マネージャーは、プロジェクトを実行している組織に属する人でも、組織外部の人でも構いません。)</p> <p>成果物デリバリーのマネジメント・プロセスの達成目標は、以下のことを確実に行うことです。 * チームに割り当てられた成果物に関する作業が、認可され、合意されること。 * チーム・マネージャーとそのチームが、作成されるものと期待されている労力、コスト、期間を明確に理解していること。 * 計画された成果物が期待品質どおりに、許容度内で提供されること。 * 期待が管理されるよう、合意された頻度で、正確な進捗情報がプロジェクト・マネージャーに提供されること。 チーム・マネージャーはプロジェクト・マネージャーから十分な自由を与えられて作業を行い、求められていることを提供します。これは、ワーク・パッケージ記述書で確立された許容度と、チーム・マネージャーに対するプロジェクト・マネージャーの信頼によって形式化します。プロジェクト・マネージャーのマイクロマネジメントはプロジェクトを改善しない代わりに、フラストレーションや遅延を引き起こす可能性が高くなります。</p> <p>成果物デリバリーのマネジメント・プロセスでは、チーム・マネージャーの観点からプロジェクトを捉えます。ステージのコントロール・プロセスでは、プロジェクト・マネージャーの観点からステージを捉えます。</p> <p>チーム・マネージャーは以下のことを行って、チームが確実にプロジェクト中に成果物を作成、提供できるようにします。 * プロジェクト・マネージャーから認可されたワーク・パッケージを受け入れる。 * ワーク・パッケージ記述書で特定される開発、運用、保守の関係が維持されるようにする。 * アサインされたワーク・パッケージに関するチーム計画書を作成する。これは、プロジェクト・マネージャーによるステージのステージ計画書作成と並行して行うことができます。 * ワーク・パッケージ記述書で特定されている開発手法に従って成果物が開発されることを確かなものとする。 * 成果物記述書で指定された品質手法を通じて、各成果物が品質仕様を満たしていることを示す。 * 成果物記述書で特定されている承認部門から、完成した成果物に対する承認を取得する。 * ワーク・パッケージ記述書に指定された手順に従って、プロジェクト・マネージャーに成果物を提供する。</p> <p>ワーク・パッケージは契約上の合意の一部を成す場合があります。このため、チーム計画書の書式には幅があり、ワーク・パッケージ記述書に単にスケジュールを付加しただけのものや、ステージ計画書に類似したスタイルで完全に作成された計画書もあります。</p> <h3>活動<a href="#活動"><span></span></a></h3> <table><thead><tr><th>インプット</th><th>活動</th><th>アウトプット</th></tr></thead><tbody><tr><td>ワーク・パッケージの認可(このプロセスをトリガー)<br />ワーク・パッケージ記述書(レビュー)</td><td>ワーク・パッケージの受け入れ</td><td>チーム計画書 (作成、更新)</td></tr><tr><td>チーム計画書 (レビュー)<br />ワーク・パッケージ記述書(レビュー)</td><td>ワーク・パッケージの実行</td><td>プロジェクト・ログ (更新)<br />スペシャリスト成果物 (作成)</td></tr><tr><td>チーム計画書 (レビュー)<br />ワーク・パッケージ記述書(レビュー)<br />プロジェクト・ログ (レビュー)</td><td>ワーク・パッケージの評価</td><td>チェックポイント報告書 (期間ごとに作成)<br />プロジェクト・ログ (更新)</td></tr><tr><td>チーム計画書 (確認)<br />ワーク・パッケージ記述書 (確認)<br />プロジェクト・ログ (レビュー)</td><td>ワーク・パッケージの完了の通知</td><td>チーム計画書 (更新)<br />ワーク・パッケージ (完了)<br />完了したワーク・パッケージの通知(ステージのコントロール・プロセスをトリガー)</td></tr></tbody></table> <h4>ワーク・パッケージの受け入れ<a href="#ワークパッケージの受け入れ"><span></span></a></h4> <p>ワーク・パッケージがチームに割り当てられる前に、プロジェクト・マネージャーとチーム・マネージャーとの間で、何を提供するかについて合意します。合意内容には、報告要件、適用される制約、適用される手順、ワーク・パッケージの要件が妥当で達成可能なものかどうかを含める必要があります。</p> <p>各チーム・マネージャーに推奨される処置 * ワーク・パッケージ記述書をレビューして、何をいつ提供するかを理解する。 * 所定の制約条件に準拠して成果物完了を示すチーム計画書を作成する。例えば、アジャイル・アプローチを使用する場合であればタイムボックス内になります。 * プロジェクト・ログを更新する手順については、ワーク・パッケージ記述書を確認する。 * 各成果物に追加のレビュー担当者が必要かどうかについてプロジェクト保証と協議し、それに応じてプロジェクト・ログが更新されていることを確認する。 * チーム計画書が実行可能であり、関連するサプライヤー標準に準拠しているかどうかをプロジェクト保証(サプライヤー)と協議する。 * チーム計画書に対する必要な承認を求める。商業的な顧客とサプライヤーの関係の場合、プロジェクト・マネージャーがチーム計画書をレビューして承認することが不適切である場合があります。この状況では、シニア・サプライヤーがチーム計画書をレビューして承認する場合もあります。 * チーム計画書を参照してリスクのレビューを実施し、リスクの追加や修正がある場合には、プロジェクト・マネージャーに通知する。チーム・マネージャーがリスクを直接記録することがワーク・パッケージ記述書で許可されている場合、チーム・マネージャーはプロジェクト・ログを更新する必要があります。 * ワーク・パッケージの提供に合意する。</p> <h4>ワーク・パッケージの実行<a href="#ワークパッケージの実行"><span></span></a></h4> <p>認可されたワーク・パッケージに定義されている要件に従って作業を実行、モニタリングする必要があります。 プロジェクト・マネージャーが設定した許容度内でワーク・パッケージを完了できると予測できる場合、チーム・マネージャーはワーク・パッケージに従って作業の実施や是正処置を実施することができます。ワーク・パッケージの許容度を超えることが予測された場合、チーム・マネージャーは速やかにプロジェクト・マネージャーに課題を提起します。その後、プロジェクト・マネージャーが処置を決定します。 さらに、チーム内の心理的安全性を確保することは非常に重要です。関連する課題とリスクは、迅速かつ適切に対処する必要があります。</p> <p>各チーム・マネージャーに推奨される処置 * ワーク・パッケージ記述書で定義された要件と、合意されたチーム計画書の特定の取り決めに従って、必要な成果物の開発を管理する。 * 新しい課題、リスク、教訓があればプロジェクト・マネージャーに通知し、プロジェクト・マネージャーが必要とする処置を講じる。 * 完了した品質活動をプロジェクト・マネージャーに通知し、品質登録簿を更新する。 * 完成した成果物の承認を取得し、成果物登録簿を更新する。</p> <h4>ワーク・パッケージの評価<a href="#ワークパッケージの評価"><span></span></a></h4> <p>チーム・マネージャーは、ワーク・パッケージ記述書で定義された各期間の進捗をレビューし、プロジェクト・マネージャーに報告する必要があります。</p> <p>推奨される処置 * ワーク・パッケージ記述書とチーム計画書をレビューして、その期間の期待される進捗を確認する。 * 課題登録簿をレビューして、ワーク・パッケージに関連する課題があるか確認する。 * リスク登録簿をレビューして、ワーク・パッケージに関連するリスクがあるか確認する。 * 品質登録簿をレビューして、ワーク・パッケージに関連する品質活動のステータスを確認する。 * 成果物登録簿をレビューして、承認レコードを含む、ワーク・パッケージに関連する成果物のステータスを確認する。 * 教訓ログをレビューして、ワーク・パッケージに関連する教訓があるか確認する。 * チェックポイント報告書を通じて、プロジェクト・マネージャーにワーク・パッケージのステータスを報告する。アジャイルなどの反復的かつ段階的なデリバリー手法を使用するプロジェクトの場合、チェックポイント報告書は「プル」システムに基づいている場合があります。プロジェクト・マネージャーはこのシステムでチーム・マネージャーと開発チームによって維持されているカンバン・ボードやバーンダウン・チャートなどの進捗チャートを確認します。 チーム・マネージャーがサプライヤー組織に所属している商業的な状況では、プロジェクト・ログとは異なる独自のログと登録簿を持ち、それを使ってワーク・パッケージを評価することもあります。(プロジェクト支援は、プロジェクト・ログに保持されているワーク・パッケージに関連する情報を提供してレビューすることにより、チーム・マネージャーを支援することもできます。)</p> <h4>ワーク・パッケージの完了の通知<a href="#ワークパッケージの完了の通知"><span></span></a></h4> <p>チーム・マネージャーがワーク・パッケージの認可をプロジェクト・マネージャーから受け入れたら、その完了をプロジェクト・マネージャーに伝達する必要があります。</p> <p>各チーム・マネージャーに推奨される処置 * ワーク・パッケージ記述書を確認して、手順に従って完了した成果物を提供する。 * 承認レコードをレビューして、ワーク・パッケージによって提供されるすべての成果物が承認されていることを確認する。 * チーム計画書を更新して、ワーク・パッケージが完了していることを示す。 * プロジェクト・ログをレビューして、ワーク・パッケージに関連する教訓や未解決の課題およびリスクがあるか確認する。 * 提供された成果物のステータスと、ワーク・パッケージ記述書での合意内容に対する作業のパフォーマンスについてプロジェクト・マネージャーに説明し、完成した成果物に関連する未解決の課題(仕様外項目など)またはリスクを強調する。 * プロジェクト・マネージャーにワーク・パッケージが完了したことを通知する。</p> <h3>適用<a href="#適用"><span></span></a></h3> <h4>一般的な考慮事項<a href="#一般的な考慮事項"><span></span></a></h4> <p>このプロセスの活動は、状況に合わせて結合、分割、または同時に実行できます。ただし、ステージのコントロール・プロセスへの接続の完全性を確保するよう注意しなければなりません。 このプロセスでは専門的な作業が行われるため、作業の種類に適したデリバリー手法と技法を使用して作業が完了されます。したがって、専門的な作業のモニタリングとコントロールは、使用されている方法と技法に適したコントロールと尺度を使用することが重要です。プロジェクト・マネージャーとチーム・マネージャーはそのようなコントロールに合意し、それらをワーク・パッケージ記述書に記載し、プロジェクトに対して確立されたマネジメント・アプローチと互換性があることを確認します。 ワーク・パッケージは必ずしも規模が小さいとは限りません。プロジェクトと同様にワーク・パッケージにも適用可能であり、その場合も適切なガバナンスとコントロールが必要です。また多くの場合、プロジェクト・マネジメント・スキルを有するチーム・マネージャーも必要です。 大規模なワーク・パッケージの場合、チーム・マネージャーは、階層化した小さなワーク・パッケージを作成しチーム・メンバーに割り当てることができます。この場合、成果物デリバリーのマネジメント・プロセスは、下位レベルのワーク・パッケージの作業が確実にコントロールされるようにテーラリングする必要があります。 成果物デリバリーのマネジメント・プロセス中のチーム・マネージャーとそのチーム・メンバーの関係は、協調的でなければなりません。チーム・マネージャーは、チーム・メンバーにタスクを委任したりアサインしたりするのではなく、オーナーシップを改善させるプロセスを促進し、ワーク・パッケージまたはチーム計画書、そして最終的にはプロジェクト目標とビジネス目標に貢献できるようにします</p> <h4>役割のテーラリング<a href="#役割のテーラリング"><span></span></a></h4> <p>チーム・マネージャーはすべての活動の実行責任を負いますが、チーム・メンバーから支援を受ける場合もあります。プロジェクト・マネージャーはチーム・マネージャーの役割を引き受けることができます。 ワーク・パッケージはさらにワーク・パッケージに分割することができます。これにより、独自の報告構造を持つチーム・マネージャーの階層を作成できます。上位レベルのチーム・マネージャーは、上位レベルのワーク・パッケージ内のすべての作業に実行責任があり、全体的な進捗をプロジェクト・マネージャーに報告します。 ワーク・パッケージ記述書の作成者、更新者、承認者を定義しますが、これらの責任は、チーム・マネージャーとプロジェクト・マネージャーの両者がワーク・パッケージ記述書の内容について合意している場合は変更できます。</p> <h3>責任<a href="#責任"><span></span></a></h3> <table><thead><tr><th>活動</th><th>ビジネス・レイヤー</th><th>プロジェクト・エグゼクティブ</th><th>シニア・ユーザー</th><th>シニア・サプライヤー</th><th>プロジェクト・マネージャー</th><th>チーム・マネージャー</th><th>プロジェクト保証</th><th>プロジェクト支援</th></tr></thead><tbody><tr><td>ワーク・パッケージの受け入れ</td><td></td><td></td><td></td><td></td><td>A</td><td>R</td><td></td><td>I</td></tr><tr><td>ワーク・パッケージの実行</td><td></td><td></td><td></td><td></td><td>A</td><td>R</td><td>C</td><td>C</td></tr><tr><td>ワーク・パッケージの評価</td><td></td><td></td><td></td><td></td><td>A</td><td>R</td><td>C</td><td>C</td></tr><tr><td>ワーク・パッケージの完了の通知</td><td></td><td></td><td></td><td></td><td>A</td><td>R</td><td>C</td><td>I</td></tr></tbody></table> <p>R = 実行責任、A = 説明責任、C = 協議先、I = 情報先</p> <h3>プロセスへのプラクティスの適用<a href="#プロセスへのプラクティスの適用"><span></span></a></h3> <table><thead><tr><th>プラクティス</th><th>成果物デリバリーのマネジメント・プロセスへの適用</th></tr></thead><tbody><tr><td>ビジネス・ケース</td><td>ワーク・パッケージ記述書で定義されたベネフィット・マネジメント要件と持続可能性マネジメント要件は、ワーク・パッケージの実行時に満たされます</td></tr><tr><td>組織化</td><td>ワーク・パッケージ記述書で定義されたコミュニケーション・マネジメント要件、変更マネジメント要件、商業マネジメント要件は、ワーク・パッケージの実行時に満たされます。<br />チーム構造、予定、作業の取り決めを記載したチーム計画書が作成されます。<br />チームのウェルビーイングと状況がモニタリングされます</td></tr><tr><td>計画</td><td>チーム・マネージャーは、プロジェクト・マネージャーから要求されたワーク・パッケージのチーム計画書を作成します。</td></tr><tr><td>品質</td><td>ワーク・パッケージ記述書で定義された品質マネジメント要件は、ワーク・パッケージの実行時に満たされます。<br />チーム計画書のスコープ内にある特別な成果物が作成され、提供されます。<br />チーム計画書のスコープ内にある成果物の品質登録簿は、計画された品質活動と実際の品質活動のレコードに合わせて更新されます</td></tr><tr><td>リスク</td><td>ワーク・パッケージ記述書で定義されたリスク・マネジメント要件は、ワーク・パッケージの実行時に満たされます。<br />チーム・レベルの課題のリスク登録簿は、新しいリスク、変化するリスク、リスク対応策のステータスのレコードに合わせて更新されます。<br />リスクは、該当する場合はプロジェクト・マネージャーにエスカレーションされます</td></tr><tr><td>課題</td><td>ワーク・パッケージ記述書で定義された課題マネジメント要件は、ワーク・パッケージの実行時に満たされます。<br />チーム・レベルの課題の課題登録簿は、新しい課題、変化する課題、処置のステータスのレコードに合わせて更新されます。<br />課題は、該当する場合はプロジェクト・マネージャーにエスカレーションされます</td></tr><tr><td>進捗</td><td>チーム計画書のスコープ内にある成果物の成果物登録簿は、成果物のステータスのレコードに合わせて更新されます。<br />ワーク・パッケージ記述書で定義されたデータ・マネジメント要件は、ワーク・パッケージの実行時に満たされます。<br />チェックポイント報告書は、ワーク・パッケージ記述書で合意された頻度でプロジェクト・マネージャーに提供されます。<br />チーム・レベルの教訓の教訓ログが更新されます</td></tr></tbody></table>category:项目管理tag:プロジェクトtag:マネジメントtag:プロセスtag:成果物のデリバリーhttps://blog.issyuu.com/zh/post/pm-processes-controlling-stage-dzh:pm-processes-controlling-stage-d生きている限り、学び続けるSun, 19 Apr 2026 04:12:12 GMT<h2>ステージのコントロール<a href="#ステージのコントロール"><span></span></a></h2> <blockquote> <p>ステージのコントロール・プロセスの目的は、作業を適切にアサインし、その状況をモニタリングして、課題に対処する。また、プロジェクト委員会への進捗報告を行い、ステージが設定された<strong>許容度(トレランス)</strong> 内に収まるよう是正処置を講じる。</p> </blockquote> <h3>達成目標<a href="#達成目標"><span></span></a></h3> <blockquote> <p>PMはファシリテーターとして、以下の事項を確実にする。</p> </blockquote> <ul> <li><strong>デリバリーの制御</strong>: ステージ開始時に合意した成果物からの逸脱をモニタリングし、コントロールされていない変更を回避する。</li> <li><strong>リスクと課題の管理</strong>: 常に最新の状況を把握し、コントロール下に置く。</li> <li><strong>正当性の維持</strong>: ビジネス・ケースを継続的にレビューする。</li> <li><strong>品質の確保</strong>: 成果物が期待品質を満たし、受け入れられることを確実にする。</li> <li><strong>許容度の遵守</strong>: 確立された許容度(時間・コスト等)の範囲内でのデリバリーに努める。</li> </ul> <h3>位置付け<a href="#位置付け"><span></span></a></h3> <h4>ステージのマネジメントサイクル<a href="#ステージのマネジメントサイクル"><span></span></a></h4> <blockquote> <p>ステージ全体を通して、以下の活動をサイクルとして実施する。</p> </blockquote> <ol> <li><strong>作業の認可</strong>: <strong>ワーク・パッケージ(WP)記述書</strong>を使用して作業を定義し、チームにアサインする。</li> <li><strong>モニタリング</strong>: ワーク・パッケージの進捗情報(要約報告等)を収集し、完了した成果物を受け入れる。</li> <li><strong>状況レビュー</strong>: 状況と品質を確認し、次のワーク・パッケージをトリガーする。</li> <li><strong>ハイライト報告</strong>: 合意された頻度でプロジェクト委員会へ進捗を報告する。</li> <li><strong>課題とリスクの捕捉・評価</strong>: 新たに発生したリスクや課題を観察し、適切に対応する。</li> <li><strong>是正処置の実施</strong>: 状況が許容度を逸脱しそうな場合、あるいは逸脱した場合に、コントロールを取り戻すための処置を講じる。</li> </ol> <h4>実施のポイント<a href="#実施のポイント"><span></span></a></h4> <ul> <li><strong>適用時期</strong>: 通常、プロジェクト認可後の最初の<strong>提供ステージ</strong>から始まるが、大規模・複雑なプロジェクトでは<strong>立ち上げステージ</strong>でも適用される。</li> <li><strong>ワーク・パッケージの活用</strong>: <ul> <li>作業の定義、アサイン、コントロールの最小単位として<strong>ワーク・パッケージ記述書</strong>を使用する。 ＊PMがチーム・マネージャーを兼務する場合でも、個々のメンバーへの指示とコントロールにはワーク・パッケージ記述書を使用し、責任と権限を明確にする。</li> </ul> </li> <li><strong>プロセスの遷移</strong>: <ul> <li>各ステージの終了が近づくと<strong>ステージ境界のマネジメント</strong>プロセスをトリガーする。</li> <li>最終ステージの終了間際では<strong>プロジェクトのクローズ</strong>プロセスがトリガーされる。</li> </ul> </li> </ul> <h3>活動<a href="#活動"><span></span></a></h3> <table><thead><tr><th>インプット</th><th>活動</th><th>アウトプット</th></tr></thead><tbody><tr><td>ステージの認可<br />(このプロセスをトリガー)<br />例外計画書の認可<br />(このプロセスをトリガー)<br />プロジェクト立ち上げ文書<br />(レビュー)<br />チーム計画書 (レビュー)<br />ステージ計画書 (レビュー)</td><td>ワーク・パッケージの認可</td><td>プロジェクト・ログ (更新)<br />ワーク・パッケージ記述書 (作成、修正、承認)<br />ワーク・パッケージの認可 (成果物デリバリーのマネジメント・プロセスをトリガー)</td></tr><tr><td>新しい課題またはリスク<br />(このプロセスをトリガー)<br />ワーク・パッケージ記述書<br />(レビュー)<br />チーム計画書 (レビュー)<br />チェックポイント報告書 (レビュー)</td><td>ワーク・パッケージのステータスの評価</td><td>プロジェクト・ログ (更新)<br />ステージ計画書 (更新)<br />課題報告書 (必要に応じて作成)<br />助言の要求 (プロジェクトの指揮プロセスをトリガー)</td></tr><tr><td>新しい課題またはリスク<br />(このプロセスをトリガー)<br />ワーク・パッケージ記述書<br />(レビュー)<br />チーム計画書 (レビュー)<br />チェックポイント報告書 (レビュー)</td><td>課題とリスクの把握</td><td>プロジェクト・ログ (更新)<br />ステージ計画書 (更新)<br />課題報告書 (必要に応じて作成)<br />助言の要求 (プロジェクトの指揮プロセスをトリガー)</td></tr><tr><td>新しい課題またはリスク<br />(このプロセスをトリガー)<br />ワーク・パッケージ記述書<br />(レビュー)<br />チーム計画書 (レビュー)<br />チェックポイント報告書 (レビュー)</td><td>是正処置の実施</td><td>プロジェクト・ログ (更新)<br />ステージ計画書 (更新)<br />課題報告書 (必要に応じて作成)<br />助言の要求 (プロジェクトの指揮プロセスをトリガー)</td></tr><tr><td>完了したワーク・パッケージの通知<br />(このプロセスをトリガー)<br />ワーク・パッケージ記述書<br />(レビュー)</td><td>完了したワーク・パッケージの受け取り</td><td>プロジェクト・ログ (更新)</td></tr><tr><td>プロジェクト委員会の助言<br />(このプロセスをトリガー)<br />ハイライト報告書 (前期)<br />(レビュー)<br />ステージ計画書 (レビュー)<br />チェックポイント報告書 (レビュー)<br />プロジェクト・ログ (レビュー)</td><td>ステージのステータスの評価</td><td>プロジェクト・ログ (更新)<br />ハイライト報告書 (期間ごとに作成)<br />ステージ終了が近づく (ステージ境界のマネジメント・プロセスをトリガー)<br />プロジェクト終了が近づく (プロジェクトの指揮プロセスをトリガー)</td></tr><tr><td>プロジェクト委員会の助言<br />(このプロセスをトリガー)<br />ハイライト報告書 (前期)<br />(レビュー)<br />ステージ計画書 (レビュー)<br />チェックポイント報告書 (レビュー)<br />プロジェクト・ログ (レビュー)</td><td>ハイライトの報告</td><td>プロジェクト・ログ (更新)<br />ハイライト報告書 (期間ごとに作成)<br />ステージ終了が近づく (ステージ境界のマネジメント・プロセスをトリガー)<br />プロジェクト終了が近づく (プロジェクトの指揮プロセスをトリガー)</td></tr><tr><td>ステージ計画書 (レビュー)<br />プロジェクト計画書 (レビュー)</td><td>課題とリスクのエスカレーション</td><td>例外報告書 (作成)<br />例外の提起 (プロジェクトの指揮プロセスをトリガー)</td></tr></tbody></table> <h4>ワーク・パッケージの認可<a href="#ワークパッケージの認可"><span></span></a></h4> <blockquote> <p>プロジェクト作業の自律性と、全体のスケジュール調整のバランスを取るための活動である。プロジェクト・マネージャー(PM)の同意なしに作業が開始されることによる混乱を防ぎ、計画に基づいた確実な実行を担保する。</p> </blockquote> <ul> <li><strong>ワーク・パッケージ(WP)の単位</strong>: 1つまたは複数の成果物を作成するための作業パッケージである。大規模な成果物の場合、サブ成果物に分割してWPを割り当てる。</li> </ul> <ol> <li>トリガー プロジェクト・マネージャー(PM)がWPを認可するきっかけには、主に以下の4つがある。 <ul> <li><strong>ステージの認可</strong>: プロジェクト委員会からステージ計画の実行権限が与えられたとき。</li> <li><strong>例外計画書の承認</strong>: 例外が発生し、新しい計画(例外計画)の実行が認められたとき。</li> <li><strong>新規ワーク・パッケージの必要</strong>: 現在の進捗評価から、次に着手すべき作業が特定されたとき。</li> <li><strong>是正処置</strong>: 特定された課題やリスクに対応するために、新しい作業が必要になったとき。</li> </ul> </li> <li>PMに推奨される処置 PMが現場を混乱させず、かつスムーズに作業を依頼するための具体的なアクションは以下の通り。 <ul> <li><strong>WPの特定と定義</strong>: <ul> <li>PID(プロジェクト立ち上げ文書)やステージ計画書を確認し、必要なWPを特定・定義する。</li> <li><strong>チーム・マネージャーと共創</strong>して、ワーク・パッケージ記述書をレビューし、内容の受け入れを確認した上で作業開始を認可する。 ＊TMとの良好な協力関係を築き、円滑なデリバリーの基盤を作る。</li> </ul> </li> <li><strong>計画の同期</strong>: <ul> <li>チーム・マネージャーが作成したチーム計画書をレビューし(商業的な制約がある場合は、主要マイルストーンのみを確認)、WPのスケジュールをステージ計画書に反映する。</li> </ul> </li> <li><strong>体制と品質の確保</strong>: <ul> <li>品質レビューの担当者が適切かどうかをプロジェクト保証と協議する。</li> <li>プロジェクト・ログを更新し、認可されたワーク・パッケージの内容・計画された品質管理活動を反映させる。</li> </ul> </li> <li><strong>情報の最新化</strong>: <ul> <li>マネジメント・アプローチに従って、WPの内容や進捗状況に基づき、関連する各種プロジェクト・ログやマネジメント成果物を最新の状態に更新する。</li> </ul> </li> </ul> </li> </ol> <h4>ワーク・パッケージのステータスの評価<a href="#ワークパッケージのステータスの評価"><span></span></a></h4> <blockquote> <p>実行中のワーク・パッケージ(WP)の進捗状況を定期的に把握し、計画との乖離がないかを評価するための活動である。これにより、問題が深刻化する前に予兆を捉え、適切なコントロールを維持することが可能になる。</p> </blockquote> <ul> <li><strong>頻度と手続き</strong>: 通常、ワーク・パッケージ記述書で合意された報告頻度(チェックポイント報告の間隔など)に基づき、現在のステージ計画書に従って実施される。</li> </ul> <ol> <li>PMに推奨される処置 <ul> <li>関係維持と情報の収集 <ul> <li><strong>非公式なコミュニケーション</strong>: チーム・マネージャーと日常的に対話し、良好な関係を維持する。これにより、公式な報告書に現れない潜在的な課題やリスクを早期に察知する。</li> <li><strong>チェックポイント報告書のレビュー</strong>: チーム・マネージャーから提出される報告書を確認し、実際の進捗、品質活動の結果、および今後の予測を正確に把握する。</li> </ul> </li> <li>記録と計画の更新 <ul> <li><strong>プロジェクト・ログの最新化</strong>: 収集した情報に基づき、リスク登録簿や課題登録簿などのプロジェクト・ログを必要に応じて更新する。</li> <li><strong>ステージ計画書の更新</strong>: これまでの実績値(実績コスト・時間)と将来の予測を反映させ、ステージ計画書を最新の状態に保つ。 ＊必要であれば、許容度内に収めるための軽微な調整もここで行う。</li> </ul> </li> </ul> </li> </ol> <h4>完了したワーク・パッケージの受け取り<a href="#完了したワークパッケージの受け取り"><span></span></a></h4> <blockquote> <p>個人またはチームに割り当てられた作業がすべて完了し、かつ公式に承認されたことを最終確認する活動である。単に作業が終わっただけでなく、品質基準を満たし、必要な承認手続きが完了していることを保証する。</p> </blockquote> <ol> <li>PMに推奨される処置 <ul> <li>完了と承認の検証 <ul> <li><strong>作業完了の確認</strong>: ワーク・パッケージ(WP)記述書で定義された全ての作業が完了しているか ＊アジャイル・アプローチの場合は、タイムボックス内で提供すると合意したフィーチャーが全て揃っているかを確認する。</li> <li><strong>品質活動のチェック</strong>: 品質登録簿を照合し、計画されていたすべての品質レビューや検査が完了しているか判断する。</li> <li><strong>公式な承認の確認</strong>: 各成果物が<strong>成果物記述書</strong>(品質および持続可能性の定義を含む)に従い、適切な権限者から正式な承認を得ていることを確実にする。</li> </ul> </li> <li>記録と計画の更新 <ul> <li><strong>成果物登録簿の最新化</strong>: 承認された成果物のステータスを<strong>成果物登録簿(成果物レコード)</strong> に反映し、最新の状態に更新する。</li> <li><strong>ステージ計画書の実績反映</strong>: ステージ計画書を更新し、当該ワーク・パッケージが正式に完了したことを記録する。これにより、ステージの全体進捗を正確に把握する。</li> </ul> </li> </ul> </li> </ol> <h4>ステージのステータスの評価<a href="#ステージのステータスの評価"><span></span></a></h4> <blockquote> <p><strong>実際に発生したこと(実績)</strong> と<strong>発生が予想されていたこと(計画)</strong> を比較し、次に何が起こり得るかを分析することで、ステージのコントロールを維持する活動である。</p> </blockquote> <p>＊ステージ計画書で定義された頻度で行われるが、プロジェクト委員会の助言や重大な課題・リスクの発生によって随時トリガーされる。</p> <ol> <li>達成目標 <ul> <li><strong>タイムリーな判断</strong>: 計画の推進と突発的なイベントへの対応のバランスを保つ。</li> <li><strong>情報の透明性</strong>: モニタリングを通じて、進捗とリソース状況に関する正確で最新の全体像を把握する。</li> </ul> </li> <li>評価の観点 論理的なコントロールを実行するため、以下の情報を照合・分析する。 <ul> <li><strong>実績 vs 計画</strong>: これまでに完了した作業と消費したリソース。</li> <li><strong>将来予測</strong>: ステージ終了時点での予測値と、許容度(トレランス)を逸脱する可能性の有無。</li> <li><strong>付随情報</strong>: 新たに特定されたリスク、課題、およびそれらがビジネス・ケースに与える影響。</li> </ul> </li> <li>PMに推奨される処置 <ul> <li>分析と更新 <ul> <li><strong>進捗レビュー</strong>: ステージの進捗をレビューし、是正処置が必要かどうかを判断する。</li> <li><strong>ログと計画の最新化</strong>: 必要に応じてプロジェクト・ログを修正し、総合評価により予測に変更がある場合は、ステージ計画書を更新する。</li> <li><strong>成果物の移管確認</strong>: 成果物が段階的にユーザーへ移管される計画の場合、その所有権(オーナーシップ)が適切に移行されているかを確認する。</li> </ul> </li> <li>次のステップへの備え <ul> <li><strong>教訓の振り返り</strong>: 教訓のレビューを<strong>今</strong>行うか、ステージ終了時まで待つかを検討し、有益な知見を逃さないようにする。</li> <li><strong>次フェーズの準備</strong>: ステージ計画書やマイルストーンに基づき、ステージの終了が近づいている場合は<strong>ステージ境界のマネジメント</strong>を、最終ステージの場合は<strong>プロジェクトのクローズ</strong>の準備を開始する。</li> </ul> </li> </ul> </li> </ol> <h4>課題とリスクの把握<a href="#課題とリスクの把握"><span></span></a></h4> <blockquote> <p>プロジェクトの進行中に非構造的(予測不能)に発生する課題やリスクを、一貫性のある信頼性の高い方法で特定・評価する活動である。</p> </blockquote> <ol> <li>運用のポイント <ul> <li><strong>包括的な把握</strong>: ビジネス、プロジェクト、利害関係者など、あらゆるルートから提起される情報を漏らさず吸い上げる。</li> <li><strong>心理的安全性の確保</strong>: チーム内で課題やリスクを隠さず、迅速に共有できる文化を醸成することが不可欠である。</li> <li><strong>迅速な対処</strong>: 特定された事象がプロジェクトに深刻な影響を及ぼす前に、適切かつ迅速な対応を可能にする。 具体的な処置(対応策)を決定する前に、必ず以下のステップを踏む。 <ol> <li><strong>登録</strong>: 発生した事象をプロジェクト・ログ(リスク登録簿または課題登録簿)に記録し、情報の所在を明確にする。</li> <li><strong>インパクト評価</strong>: その事象がプロジェクトの許容度やビジネス・ケースにどのような影響を与えるかを分析する。</li> </ol> </li> </ul> </li> <li>PMに推奨される処置 <ul> <li><strong>ルールの徹底</strong> <ul> <li><strong>リスクへの対応</strong>: 新たなリスクを特定した場合は、リスク・マネジメント・アプローチに従い、記録・管理する。</li> <li><strong>課題への対応</strong>: 課題が発生した場合は、課題マネジメント・アプローチに従い、記録・管理する。</li> </ul> </li> <li>判断とエスカレーション <ul> <li><strong>現状の再確認</strong>: 是正処置を検討する際は、まず<strong>ステージのステータスをレビュー</strong>し、プロジェクト全体の状況(全体像)を正しく把握する。</li> <li><strong>上位への相談</strong>: 自身の許容度(トレランス)を超える可能性がある場合、あるいは判断に迷う場合は、プロジェクト委員会に助言を求めるか、正式にエスカレーションを行う。</li> </ul> </li> </ul> </li> </ol> <h4>是正処置の実施<a href="#是正処置の実施"><span></span></a></h4> <blockquote> <p>計画からの偏差(ズレ)を解消するための処置を選択・実施し、プロジェクトを再び軌道に乗せる活動である。</p> </blockquote> <ol> <li>達成目標 <ul> <li><strong>許容度の遵守</strong>: 実施する処置は、あくまで<strong>ステージおよびプロジェクトの許容度(トレランス)の範囲内</strong>に収まらなければならない。</li> <li><strong>適切な解決策の選択</strong>: 偏差の原因を特定し、最も効果的な対応オプションを実行に移す。</li> </ul> </li> <li>トリガー 是正処置は、主に以下のタイミングや状況で検討・実施される。 <ul> <li><strong>ステータス評価時</strong>: ステージの進捗レビューにおいて偏差が確認された場合。</li> <li><strong>上位からの指示</strong>: プロジェクト委員会から受け取った助言やガイダンス。</li> <li><strong>下位からの報告</strong>: チーム・マネージャーから提起された課題への対応。</li> </ul> </li> <li>PMに推奨される処置 <ul> <li>分析とアクションの実行 <ul> <li><strong>情報収集とオプション特定</strong>: 偏差に関する詳細情報を集め、解決に向けた複数の選択肢を特定する。その中から最適なオプションを選択する。</li> <li><strong>作業の認可</strong>: 選択した是正処置を具体化し、ワーク・パッケージの認可(または修正認可)を通じて実行をトリガーする。</li> </ul> </li> <li>記録と計画の更新 <ul> <li><strong>成果物登録簿の更新</strong>: 変更が必要な成果物や新規成果物の情報を反映させる。</li> <li><strong>ステータスの追跡</strong>: 課題報告書を更新し、是正処置の進捗状況を明示する。</li> <li><strong>ログと計画の最新化</strong>: 是正処置による変更を各種プロジェクト・ログに記録し、最新の状況を反映するようにステージ計画書を修正する。</li> </ul> </li> </ul> </li> </ol> <h4>課題とリスクのエスカレーション<a href="#課題とリスクのエスカレーション"><span></span></a></h4> <blockquote> <p>PMの許容度の範囲内では解決できない課題やリスクに直面した際、上位のマネジメント層(プロジェクト委員会)へ判断を委ねる活動である。</p> </blockquote> <ol> <li>運用のポイント <ul> <li><strong>エスカレーションの基準</strong>: 是正処置を講じても、ステージが許容度を超えると予測される(＝例外状況になる)場合に適用する。</li> <li><strong>失敗ではない</strong>: 例外事態の予測が立った時点で、速やかにプロジェクト委員会に通知することが推奨される。エスカレーションは障害ではなく、適切な是正処置のための時間を確保するための前向きな行動である。</li> </ul> </li> <li>エスカレーションのステップ 例外報告書の作成に時間を要する場合、PMは以下の手順で機動的に対応する。 <ol> <li><strong>速報(通知)</strong>: 予測される例外状況をプロジェクト委員会に速やかに伝え、心の準備を促す。</li> <li><strong>裏付け(報告書)</strong>: その後、詳細なデータや分析を盛り込んだ<strong>例外報告書</strong>を提出し、正式な判断を仰ぐ。</li> </ol> </li> <li>PMに推奨される処置 <ul> <li>調査と影響評価 <ul> <li><strong>偏差の分析</strong>: <ul> <li>ステージ計画書を調査し、偏差の範囲や未完成の成果物を特定する。</li> <li><strong>何もしなかった場合に何が起きるか</strong>を判断する。</li> </ul> </li> <li><strong>全体への影響分析</strong>: 最新のプロジェクト立ち上げ文書(PID)とプロジェクト計画書を参照し、プロジェクト全体のステータスに対する偏差の影響を調査する。</li> <li><strong>心理的安全性の配慮</strong>: チーム内で事実が適切に共有されているか、心理的安全性を踏まえて処置の必要性を判断する。</li> </ul> </li> <li>オプションの検討と推奨 <ul> <li><strong>復旧オプションの策定</strong>: 回復のための選択肢を特定し、<strong>ビジネス・ケース</strong>に照らしてその正当性を評価する。</li> <li><strong>リソースの考慮</strong>: 各オプションを実行するためのスキルや経験を持つ要員の可用性を考慮し、現在のステージ計画へのインパクトを評価する。</li> <li><strong>例外報告書の作成</strong>: 状況、検討したオプション、およびPMとしての推奨事項を例外報告書にまとめ、プロジェクト委員会に提出する。</li> </ul> </li> </ul> </li> </ol> <h4>ハイライトの報告<a href="#ハイライトの報告"><span></span></a></h4> <blockquote> <p>PMがステージおよびプロジェクト全体のステータスに関する要約情報をプロジェクト委員会に提供する活動である。</p> </blockquote> <ol> <li>報告の目的 <ul> <li>プロジェクト委員会に対し、進捗が許容度(トレランス)の範囲内であることを保証する。</li> <li>委員会が現場に介入しすぎることなく、高い視点からガバナンスを効かせられるようにする。</li> <li>重要な課題やリスクを共有し、将来の予測を提示する。</li> </ul> </li> <li>プロジェクト・マネージャーに推奨される処置 <ul> <li>情報の集約 <ul> <li><strong>現状のサマリー</strong>: チェックポイント報告書、プロジェクト・ログ、成果物ステータス報告書、およびステージ計画書の修正内容をまとめる。</li> <li><strong>是正処置の記録</strong>: 報告期間中に実施した是正処置のリストを作成する。これにより、PMが自身の許容度内で適切に行動していることをプロジェクト委員会に対して実証する。</li> </ul> </li> <li>報告書の作成と配布 <ul> <li><strong>過去との比較</strong>: 前回のハイライト報告書をレビューし、継続性のある報告を行う。</li> <li><strong>報告書の作成</strong>: 最新の情報に基づき、現在の報告期間のハイライト報告書を作成する。</li> <li><strong>適切な配布</strong>: 定められた配布先に報告書を届ける。 ＊デリバリー手法(アジャイル等)における考慮事項 <ul> <li><strong>プルシステム</strong>: アジャイル手法を採用している場合、定期的な<strong>プッシュ</strong>型の報告ではなく、プロジェクト委員会が自ら進捗チャート(バーンダウンチャートやカンバンボードなど)を確認しにいく<strong>プル</strong>型の共有形式がとられることもある。</li> </ul> </li> </ul> </li> </ul> </li> </ol> <h3>適用<a href="#適用"><span></span></a></h3> <blockquote> <p>このプロセスを効果的に運用するためには、情報の効率化と、チーム間の協調的な信頼関係の構築が鍵となる。</p> </blockquote> <h4>一般的な考慮事項<a href="#一般的な考慮事項"><span></span></a></h4> <blockquote> <p>形式的な指示にとどまらず、メンバーのオーナーシップを促すファシリテーションが求められる。</p> </blockquote> <ul> <li><strong>情報のスリム化</strong>: ワーク・パッケージ(WP)記述書を作成する際、プロジェクト計画書やPIDなどの既存文書から内容を抜粋したり、相互参照(リンク)を活用したりするのが、情報の重複を減らし、管理の手間を最小限に抑えられます。</li> <li><strong>ビジネス・サプライヤー間の配慮</strong>: 外部サプライヤーが関わる場合、WPの詳細度は契約関係に応じて調整が必要です。</li> <li><strong>協調的な関係性</strong>: PM、プロジェクト支援、チーム・マネージャー(TM)の関係は、単なる<strong>命令と実行</strong>ではなく<strong>協調的</strong>であるべきである。</li> <li><strong>オーナーシップの向上</strong>: PMは単にタスクを割り当てるのではなく、各担当者がプロジェクトに貢献し、ビジネス目標を達成できるようプロセスを促進(ファシリテート)する。</li> </ul> <h4>役割のテーラリング<a href="#役割のテーラリング"><span></span></a></h4> <blockquote> <p>PMはガバナンスと整合性に責任を持ち、専門的な実務は適任者の知見を活用する。</p> </blockquote> <p>＊PMは全ての管理責任を負いますが、実務においては<strong>餅は餅屋</strong>の精神で柔軟に権限を委任する。</p> <ul> <li><strong>実行責任と委任</strong>: PMは本プロセスで作成されるマネジメント成果物に責任を負うが、責任を維持した上で実務タスクを他者に委任できる。</li> <li><strong>専門知見の活用</strong>: WP 記述書に含まれる専門的な手法や成果物の詳細は、<strong>チーム・マネージャーや専門家</strong>にコンテンツ作成を依頼する。PM 自身に専門スキルがない場合でも、専門家の力を借りることで正確性を担保する。</li> <li><strong>PMの本質的な役割</strong>: PMの重要な役割は、専門家が作成した内容が<strong>ステージ計画のニーズを満たしているか、適切に定義・レビュー・保証されているか</strong>を最終確認する。</li> </ul> <h3>責任<a href="#責任"><span></span></a></h3> <table><thead><tr><th>活動</th><th>ビジネス・レイヤー</th><th>プロジェクト・エグゼクティブ</th><th>シニア・ユーザー</th><th>シニア・サプライヤー</th><th>プロジェクト・マネージャー</th><th>チーム・マネージャー</th><th>プロジェクト保証</th><th>プロジェクト支援</th></tr></thead><tbody><tr><td>ワーク・パッケージの認可</td><td></td><td>A</td><td></td><td></td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>ワーク・パッケージのステータスの評価</td><td></td><td>A</td><td></td><td></td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>完了したワーク・パッケージの受け取り</td><td></td><td></td><td></td><td></td><td>A</td><td>R</td><td>C</td><td>I</td></tr><tr><td>ステージのステータスの評価</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>課題とリスクの把握</td><td></td><td>A</td><td></td><td></td><td>R¹</td><td>R²</td><td>C</td><td>C</td></tr><tr><td>是正処置の実施</td><td></td><td>A</td><td>C</td><td>C</td><td>A¹/R³</td><td>R⁴</td><td></td><td>I</td></tr><tr><td>課題とリスクのエスカレーション</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>I</td><td></td><td>I</td></tr><tr><td>ハイライトの報告</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr></tbody></table> <p>R = 実行責任、A = 説明責任、C = 協議先、I = 情報先</p> <ul> <li><strong>R¹</strong>: ステージ・レベルで課題とリスクを把握する実行責任がある</li> <li><strong>R²</strong>: チーム・レベルで課題とリスクを把握する実行責任がある</li> <li><strong>A¹</strong>: チーム・マネージャーが実施した是正処置に説明責任がある</li> <li><strong>R³</strong>: 自分のは正処置に実行責任がある</li> <li><strong>R⁴</strong>: チーム・レベルでのは正処置に実行責任がある</li> </ul> <h3>プロセスへのプラクティスの適用<a href="#プロセスへのプラクティスの適用"><span></span></a></h3> <table><thead><tr><th>プラクティス</th><th>ステージのコントロール・プロセスへの適用</th></tr></thead><tbody><tr><td><strong>ビジネス・ケース</strong></td><td>実行可能性を定期的に確認し、疑義があれば委員会へ通知する。<strong>ベネフィットおよび持続可能性マネジメント・アプローチ</strong>の要件をWPに反映する</td></tr><tr><td><strong>組織化</strong></td><td>コミュニケーション、変更、商業・マネジメント・アプローチをWPに適用する。<br />プロジェクト・チームの<strong>ウェルビーイング</strong>と状況を継続的にモニタリングする</td></tr><tr><td><strong>計画</strong></td><td>実施する作業に合わせて、ステージの<strong>WP</strong>を作成または更新する。<br />進捗や予測を反映し、ステージ計画書およびプロジェクト計画書を更新する</td></tr><tr><td><strong>品質</strong></td><td><strong>成果物登録簿</strong>と<strong>品質登録簿</strong>を最新化する。<br />品質マネジメント・アプローチをWPに適用し、必要に応じて成果物記述書を作成・更新する</td></tr><tr><td><strong>リスク</strong></td><td>リスク・マネジメント・アプローチをWP 記述書に適用。<br /><strong>リスク登録簿</strong>に新リスクを記録し、特定されたリスク対応策を確実に実行・完了させる</td></tr><tr><td><strong>課題</strong></td><td>課題マネジメント・アプローチをWP 記述書に適用。<br /><strong>課題登録簿</strong>を更新し、詳細分析やエスカレーションが必要な課題に対しては<strong>課題報告書</strong>を作成する</td></tr><tr><td><strong>進捗</strong></td><td>デジタルおよびデータ・マネジメント・アプローチをWPに適用。<br /><strong>デイリー・ログ</strong>や<strong>教訓ログ</strong>を更新し、<strong>ハイライト報告書</strong>や<strong>例外報告書</strong>を適切に発行・報告する</td></tr></tbody></table>category:项目管理tag:プロジェクトtag:マネジメントtag:プロセスtag:ステージのコントロールhttps://blog.issyuu.com/zh/post/pm-processes-controlling-stagezh:pm-processes-controlling-stage生きている限り、学び続けるSun, 19 Apr 2026 04:12:12 GMT<h2>ステージのコントロール<a href="#ステージのコントロール"><span></span></a></h2> <p>ステージのコントロール・プロセスの目的は、作業のアサイン、その作業のモニタリング、課題への対処、プロジェクト委員会への進捗報告、ステージをプロジェクト委員会が設定した許容度内に収めるための是正処置を実施する</p> <p>ステージのコントロール・プロセスの達成目標は、以下のことを確実に行う。 * ステージの成果物のデリバリー手法に注意を向けること。ステージの開始時に合意された成果物とデリバリーから逸脱する動きがある場合、コントロールされない変更を回避するためにモニタリングします。 * リスクと課題がコントロールされていること。 * ビジネス・ケースがレビューされていること。 * ステージで合意された成果物が合意された期待品質を満たし、受け入れられること。 * プロジェクト・マネジメント・チームは、確立された許容度内でのデリバリーに努めること。 エスカレーションを最小限に抑えることができるように、可能であれば許容度を使用してチーム・マネージャーに自由を与えます。同様にプロジェクト・マネージャーは、不必要なエスカレーションを回避して自由に行動と学習ができるよう、自身の許容度についてプロジェクト委員会と話し合います。したがって、プロジェクト・マネージャーはコントローラーではなくファシリテーターとして機能します。</p> <p>ステージのコントロール・プロセスは、プロジェクト・マネージャーによるステージの日常的なマネジメントを説明します。このプロセスは、プロジェクトの各ステージで使用されます。最終ステージを例外として、各マネジメント・ステージの終了が近づくと、ステージ境界のマネジメント・プロセスの活動が実施されます。 通常、ステージのコントロール・プロセスは、プロジェクト委員会がプロジェクトを認可した後に最初に使用されます。しかし、大規模なプロジェクトや複雑なプロジェクトでは、立ち上げステージで使用する場合もあります。 ワーク・パッケージ記述書は、実行する作業を定義、アサイン、コントロールしたり、チーム・マネージャーの許容度を設定したりするために使用されます。プロジェクト・マネージャーがチーム・マネージャーの役割を果たしている場合でも、個々のチーム・メンバーの作業を定義してコントロールするために、やはりワーク・パッケージ記述書を使用する必要があります。(この場合、ステージのコントロール・プロセスでチーム・マネージャーについて書かれている部分は、作業にアサインされた個々のチーム・メンバーについての記述と見なす必要があります。)</p> <p>実施中の作業を日々コントロールすることは、プロジェクトの最終的な成功を実現するために重要です。作業のコントロールは、ステージ全体を通して、以下のサイクルから成り立っています。 * 作業を認可する * 作業に関する進捗情報をモニタリングする(完了したワーク・パッケージの受け入れを含む) * 状況をレビューし(成果物の品質を含む)、新しいワーク・パッケージをトリガーする * 合意された頻度でプロジェクト委員会にハイライトを報告する * 課題とリスクを観察、評価し、対応する * 許容度内に収めるために必要な是正処置を実施する 最終ステージの終わりが近づくと、プロジェクトのクローズ・プロセスがトリガーされます。</p> <h3>活動<a href="#活動"><span></span></a></h3> <table><thead><tr><th>インプット</th><th>活動</th><th>アウトプット</th></tr></thead><tbody><tr><td>ステージの認可<br />(このプロセスをトリガー)<br />例外計画書の認可<br />(このプロセスをトリガー)<br />プロジェクト立ち上げ文書<br />(レビュー)<br />チーム計画書 (レビュー)<br />ステージ計画書 (レビュー)</td><td>ワーク・パッケージの認可</td><td>プロジェクト・ログ (更新)<br />ワーク・パッケージ記述書 (作成、修正、承認)<br />ワーク・パッケージの認可 (成果物デリバリーのマネジメント・プロセスをトリガー)</td></tr><tr><td>新しい課題またはリスク<br />(このプロセスをトリガー)<br />ワーク・パッケージ記述書<br />(レビュー)<br />チーム計画書 (レビュー)<br />チェックポイント報告書 (レビュー)</td><td>ワーク・パッケージのステータスの評価</td><td>プロジェクト・ログ (更新)<br />ステージ計画書 (更新)<br />課題報告書 (必要に応じて作成)<br />助言の要求 (プロジェクトの指揮プロセスをトリガー)</td></tr><tr><td>新しい課題またはリスク<br />(このプロセスをトリガー)<br />ワーク・パッケージ記述書<br />(レビュー)<br />チーム計画書 (レビュー)<br />チェックポイント報告書 (レビュー)</td><td>課題とリスクの把握</td><td>プロジェクト・ログ (更新)<br />ステージ計画書 (更新)<br />課題報告書 (必要に応じて作成)<br />助言の要求 (プロジェクトの指揮プロセスをトリガー)</td></tr><tr><td>新しい課題またはリスク<br />(このプロセスをトリガー)<br />ワーク・パッケージ記述書<br />(レビュー)<br />チーム計画書 (レビュー)<br />チェックポイント報告書 (レビュー)</td><td>是正処置の実施</td><td>プロジェクト・ログ (更新)<br />ステージ計画書 (更新)<br />課題報告書 (必要に応じて作成)<br />助言の要求 (プロジェクトの指揮プロセスをトリガー)</td></tr><tr><td>完了したワーク・パッケージの通知<br />(このプロセスをトリガー)<br />ワーク・パッケージ記述書<br />(レビュー)</td><td>完了したワーク・パッケージの受け取り</td><td>プロジェクト・ログ (更新)</td></tr><tr><td>プロジェクト委員会の助言<br />(このプロセスをトリガー)<br />ハイライト報告書 (前期)<br />(レビュー)<br />ステージ計画書 (レビュー)<br />チェックポイント報告書 (レビュー)<br />プロジェクト・ログ (レビュー)</td><td>ステージのステータスの評価</td><td>プロジェクト・ログ (更新)<br />ハイライト報告書 (期間ごとに作成)<br />ステージ終了が近づく (ステージ境界のマネジメント・プロセスをトリガー)<br />プロジェクト終了が近づく (プロジェクトの指揮プロセスをトリガー)</td></tr><tr><td>プロジェクト委員会の助言<br />(このプロセスをトリガー)<br />ハイライト報告書 (前期)<br />(レビュー)<br />ステージ計画書 (レビュー)<br />チェックポイント報告書 (レビュー)<br />プロジェクト・ログ (レビュー)</td><td>ハイライトの報告</td><td>プロジェクト・ログ (更新)<br />ハイライト報告書 (期間ごとに作成)<br />ステージ終了が近づく (ステージ境界のマネジメント・プロセスをトリガー)<br />プロジェクト終了が近づく (プロジェクトの指揮プロセスをトリガー)</td></tr><tr><td>ステージ計画書 (レビュー)<br />プロジェクト計画書 (レビュー)</td><td>課題とリスクのエスカレーション</td><td>例外報告書 (作成)<br />例外の提起 (プロジェクトの指揮プロセスをトリガー)</td></tr></tbody></table> <h4>ワーク・パッケージの認可<a href="#ワークパッケージの認可"><span></span></a></h4> <p>(プロジェクト作業を実施するために人々が必要とする自律性の度合いについては、作業の開始時期と作業完了時期を調整する必要性とのバランスを取る必要があります。)プロジェクト作業は、プロジェクト・マネージャーの同意を得て開始、継続する必要があります。そうしない場合、人々が自分の好きなときに活動を開始するので作業環境が混乱します。プロジェクト作業の調整された時期を確保するための手段は、ワーク・パッケージの認可、実行、デリバリーです。 ワーク・パッケージには 1 つまたは複数の成果物を作成するための作業が含まれます。1 つの成果物の作成に複数のワーク・パッケージが必要な場合、成果物をさらにサブ成果物に分け、成果物記述書も分割します。</p> <p>プロジェクト・マネージャーがワーク・パッケージの認可を行う際のトリガーとなるものには、以下の処置が挙げられます。 * ステージの認可: プロジェクト委員会はステージ計画書を実行する権限を付与する。 * 例外計画書の承認: プロジェクト委員会は例外計画書を実行する権限を付与する。 * 必要とされる新規のワーク・パッケージ: アウトプットはステージのステータスの評価から取得します。 * 是正処置課題またはリスクに対応する形で行う。 この活動は新しいワーク・パッケージの認可や既存パッケージの修正の認可に使用されます。</p> <p>プロジェクト・マネージャーに推奨される処置 * プロジェクト立ち上げ文書とステージ計画書を調査して、必要なワーク・パッケージを判断する。 * 認可する(または修正する)ワーク・パッケージを定義する。 * チーム・マネージャーとの仕事上の関係を構築する。 * ワーク・パッケージ記述書をチーム・マネージャーと共創してレビューし、受け入れを確認したら、チーム・マネージャーに作業開始を認可する。反復的かつ段階的なデリバリー手法を使用するプロジェクトの場合、ワーク・パッケージ記述書の共創は、チーム・マネージャー、開発チーム、プロダクト・オーナーとの共同作業である可能性があります。 * チーム・マネージャーの作成したチーム計画書をレビューし(プロジェクト・マネージャーがその内容を見ることが不適切であるような商業的環境の場合は、そこから引用されたマイルストーンを使用する)、認可されたワーク・パッケージの時期を反映するようにステージ計画書を更新する。 * プロジェクト・ログを更新して、認可されたワーク・パッケージの内容を反映する。 * 計画された品質マネジメント活動のプロジェクト・ログを更新する。 * 特定および選択された品質レビュー担当者が受け入れ可能かどうか、プロジェクト保証と協議する。 * 必要な場合は、マネジメント・アプローチに従ってプロジェクト・ログを更新する。</p> <h4>ワーク・パッケージのステータスの評価<a href="#ワークパッケージのステータスの評価"><span></span></a></h4> <p>この活動はワーク・パッケージのステータスを定期的に評価する手段を提供します。通常、この活動の頻度と手続きはワーク・パッケージ記述書に定義されている報告頻度と整合しており、現在のステージのステージ計画書に基づき実施されます。</p> <p>進行中の各ワーク・パッケージについてプロジェクト・マネージャーに推奨される処置 * チーム・マネージャーと非公式な話をして関係を維持し(第 3 章を参照)、ワーク・パッケージで発生する可能性のある課題やリスクを理解する。 * 実行中のワーク・パッケージのチェックポイント報告書から進捗情報を収集し、レビューする。 * 必要に応じてプロジェクト・ログを更新する。 * 現在のステージのステージ計画書を更新し、これまでの実績、予測、調整を反映させる。</p> <h4>完了したワーク・パッケージの受け取り<a href="#完了したワークパッケージの受け取り"><span></span></a></h4> <p>作業が個人またはチームに割り当てられている場合、作業が完了し、承認されたことを確認する必要があります。</p> <p>プロジェクト・マネージャーに推奨される処置 * チーム・マネージャーがワーク・パッケージ記述書で定義された作業を完了していること、またはアジャイル・アプローチが使用されている場合は、タイムボックスについて合意済みのフィーチャーが提供されていることを確認する。 * 成果物に関連する品質登録簿を確認して、必要な品質レビューが完了しているかどうかを判断する。 * ワーク・パッケージにある各成果物が、成果物記述書に記載された品質と持続可能性の責任の定義に従って、必要な承認を得ていることを確認する。 * 承認済み成果物の成果物登録簿のレコードが更新されていることを確認する。 * ステージ計画書を更新し、ワーク・パッケージを完了していることを示す。</p> <h4>ステージのステータスの評価<a href="#ステージのステータスの評価"><span></span></a></h4> <p>ステージをタイムリーに確認しなければ、ステージのコントロールが不能になるおそれがあります。計画立案を進めることと、イベントへ対応することのバランスを保つことが必要です。 情報に基づいた決定を下し、論理的なコントロールを実行するためには、実際に発生したことを、発生が予想されていたこと、および次に発生する可能性のあること(課題とリスクを含む)と比較する必要があります。 (このため、進捗の全体像を提供する一定の情報の流れと、その情報を供給する堅固なモニタリング・システムを備えることが不可欠です。) この活動の達成目標は、実施された作業の進捗状況、およびリソースのステータスに関する正確で最新の状況を保持することです。この活動は、ステージ計画書で定義されている頻度で実施されますが、プロジェクト委員会の助言によってトリガーされたり、新たな課題やリスクの分析の一部となったりする場合があります。</p> <p>プロジェクト・マネージャーに推奨される処置 * ステージの進捗をレビューし、処置が必要かどうかを判断する。 * 必要に応じてプロジェクト・ログを修正する。 * 総合評価により予測に変更がある場合、ステージ計画書を更新する。 * 成果物のフェーズごとの移転の一環として、成果物のオーナーシップがユーザーに移行されているかどうかを確認する(プロジェクト・ライフサイクル中に移管が複数回発生する場合もある)。 * 教訓のレビューを今実施するか、後でステージ・ステータスのレビューを実施する時期まで待つか、ステージの終わりに近づいたときに実施するかを検討する。 * 現在のステージの終わりが近づいている(ステージ計画書、プロジェクト・ログの内容、マイルストーンなどによって示唆される)場合、次のステージを準備する。 * 最後のステージの終わりに近づいている場合は、プロジェクトのクローズ準備を行う</p> <h4>課題とリスクの把握<a href="#課題とリスクの把握"><span></span></a></h4> <p>ほとんどの場合、プロジェクト・マネジメントの過程で課題が発生してリスクが特定されます。課題とリスクは構造化されていない方法で発生しており、一貫性のある信頼性の高い方法で把握しなければなりません。ビジネス、プロジェクト、またはその他の利害関係者のメンバーから、課題やリスクが提起されることもあります。さらに、プロジェクト・マネジメント・チーム内の心理的安全性を確保することは非常に重要です。関連する課題とリスクは、迅速かつ適切に対処する必要があります。 どのような処置を講じるかを決定する前に、プロジェクト・ログに各課題またはリスクを登録し、次にそのインパクトを評価します。</p> <p>プロジェクト・マネージャーに推奨される処置 * リスクが発生した場合は、リスク・マネジメント・アプローチに従ってリスクを記録、管理する * 課題が発生した場合は、課題マネジメント・アプローチに従って課題を記録、管理する * 是正処置の実施が必要な場合、プロジェクト委員会に助言を要求するか、課題やリスクをエスカレーションする。その後全体像を検討できるよう、まずステージのステータスをレビューする</p> <h4>是正処置の実施<a href="#是正処置の実施"><span></span></a></h4> <p>是正処置の実施の達成目標は、計画からの偏差を解決する処置を(ステージとプロジェクト許容度の限度内で)選択、実施することです。是正処置は、ステージ・ステータスの評価中にトリガーされ、一般にはプロジェクト委員会から受け取った助言とガイダンスや、チーム・マネージャーから提起された課題への対応が含まれます。</p> <p>プロジェクト・マネージャーに推奨される処置 * 偏差に関する関連情報を収集する。 * 偏差に対して可能な解決策を特定し、最も適切なオプションを選択する。 * ワーク・パッケージを認可することによって是正処置をトリガーする。 * 影響を受ける成果物の成果物登録簿のレコード(変更が必要かどうか、または新しい成果物が必要かどうかなど)を更新する。 * 課題報告書を更新し、必要に応じて是正処置のステータスを示す。 * 是正処置による変更を反映するようにプロジェクト・ログを更新する。 * 現在のステージのステージ計画書を更新する。</p> <h4>課題とリスクのエスカレーション<a href="#課題とリスクのエスカレーション"><span></span></a></h4> <p>ステージでは、プロジェクト委員会で合意された許容度を超えないようにする必要があります。プロジェクト・マネージャーは、プロジェクト委員会が設定した許容度内でステージ(またはプロジェクト)が完了すると予測される場合に限って、是正処置の実施または現状の維持ができます。プロジェクト・マネージャーがコントロールできる範囲内での是正処置によっては、ステージが合意された許容度を超えることを防げない場合に、この活動は適用されます。これは、プロジェクト委員会が設定した許容度内で解決できない、すべての種類の課題やリスク(またはそれらが集約されたもの)に適用されます。 例外報告書の作成向け情報の収集に時間を要する場合が予想される場合、できる限り早期にプロジェクト委員会に警告することを推奨します。したがってプロジェクト・マネージャーは、プロジェクト委員会が準備できるように、予測される例外状況をプロジェクト委員会に速やかに通知した後に例外報告書で情報の裏付けを行うという 2 ステップの手順で活動を実行するとよいでしょう。 プロジェクト・マネージャーはエスカレーションに対応するプロジェクト委員会の決定事項を実行します。課題とリスクをエスカレーションすることはグッド・プラクティスであり、障害と見なすべきではありません。課題を早期にエスカレーションするほど、是正処置の実施のための時間が得られることになります。</p> <p>プロジェクト・マネージャーに推奨される処置 * ステージ計画書を調査し、偏差の範囲および未完成の成果物を定義して、偏差を放置した場合に何が起こるかを判断する。 * プロジェクト・マネジメント・チーム内の心理的安全性を理解して、処置が必要かどうかを判断する。 * 最新ベースラインのプロジェクト立ち上げ文書を使用して、プロジェクトのステータスと偏差の全体的な影響に関してプロジェクト計画書を調査する。 * 復旧のためのオプションを判断し、ビジネス・ケースを参照して評価する。 * 現在のステージのステージ計画書を参照して、復旧のためのオプションのインパクトを評価する(インパクトの評価には、スキルや経験のある個人やグループの可用性を考慮します)。 * 状況、オプション、プロジェクト委員会への行動方針の推奨事項を例外報告書に記載する。その後、プロジェクト委員会は適切な行動方針を決定する(プロジェクト・マネージャーの勧告を支援または拒否する場合があります)。</p> <h4>ハイライトの報告<a href="#ハイライトの報告"><span></span></a></h4> <p>プロジェクト・マネージャーは、ステージとプロジェクトのステータスについての要約情報をプロジェクト委員会に提供し、コミュニケーション・マネジメント・アプローチに文書化されている頻度で、プロジェクト委員会による定義に従って利害関係者にその他の情報を配布する必要があります</p> <p>プロジェクト・マネージャーに推奨される処置 * 現在の報告期間のチェックポイント報告書、プロジェクト・ログ、成果物ステータス報告書からの情報とステージ計画書の重要な修正をまとめる。情報はステージ・ステータスのレビューから得られます。 * 報告期間中に実施された是正処置(プロジェクト・ログに記載または記録されている)のリストを組み立てる。これにより、プロジェクト・マネージャーが合意された許容度内で行動していることがプロジェクト委員会に保証されます(情報は是正処置を実施することで得られます。)。 * 過去の報告期間のハイライト報告書をレビューする。 * 現在の報告期間のハイライト報告書を作成する。 * ハイライト報告書を配布する。アジャイルなどの反復的かつ段階的なデリバリー手法を使用するプロジェクトの場合、ハイライト報告書は「プル」システムに基づいている場合があります。プロジェクト委員会はこのシステムでプロジェクト・マネージャーと開発チームによって維持されている進捗チャートを確認します。</p> <h3>適用<a href="#適用"><span></span></a></h3> <h4>一般的な考慮事項<a href="#一般的な考慮事項"><span></span></a></h4> <p>ワーク・パッケージ記述書は、ビジネスとサプライヤーの関係によって詳細が異なる場合があります。プロジェクト計画書、ステージ計画書、プロジェクト立ち上げ文書のいずれかからの抜粋を含めるか、単に要素への相互参照を行うことがグッド・プラクティスです。これにより、重複するコンテンツを減らすことができます。 ステージのコントロール・プロセス中のプロジェクト・マネージャー、プロジェクト支援、チーム・マネージャー間の関係は、協調的である必要があります。プロジェクト・マネージャーは、チーム・マネージャーやプロジェクト支援にタスクを委任したりアサインしたりするのではなく、オーナーシップを改善させ、チーム・マネージャーとプロジェクト支援がプロジェクトに貢献し、最終的にはビジネス目標を提供できるようにするプロセスを促進します</p> <h4>役割のテーラリング<a href="#役割のテーラリング"><span></span></a></h4> <p>プロジェクト・マネージャーは、このプロセスにおけるあらゆる新しいマネジメント成果物の作成の実行責任を負いますが、責任を維持したうえでタスクを他の人に委任できます。(プロジェクト・マネージャーはワーク・パッケージ記述書の作成に実行責任を負うとされています。ただし実際には、プロジェクト・マネージャーが、ワーク・パッケージ記述書でスペシャリスト成果物または手法に関する記述を定義するために必要なスキルを持っていない場合があります。したがって、プロジェクト・マネージャーはコンテンツを作成するためにチーム・マネージャーまたは他の専門家に頼り、プロジェクト・マネージャーの役割は、ステージ計画書のニーズを満たすためにそれらが十分に定義、レビュー、保証されていることを確認することです。)</p> <h3>責任<a href="#責任"><span></span></a></h3> <table><thead><tr><th>活動</th><th>ビジネス・レイヤー</th><th>プロジェクト・エグゼクティブ</th><th>シニア・ユーザー</th><th>シニア・サプライヤー</th><th>プロジェクト・マネージャー</th><th>チーム・マネージャー</th><th>プロジェクト保証</th><th>プロジェクト支援</th></tr></thead><tbody><tr><td>ワーク・パッケージの認可</td><td></td><td>A</td><td></td><td></td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>ワーク・パッケージのステータスの評価</td><td></td><td>A</td><td></td><td></td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>完了したワーク・パッケージの受け取り</td><td></td><td></td><td></td><td></td><td>A</td><td>R</td><td>C</td><td>I</td></tr><tr><td>ステージのステータスの評価</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>課題とリスクの把握</td><td></td><td>A</td><td></td><td></td><td>R¹</td><td>R²</td><td>C</td><td>C</td></tr><tr><td>是正処置の実施</td><td></td><td>A</td><td>C</td><td>C</td><td>A¹/R³</td><td>R⁴</td><td></td><td>I</td></tr><tr><td>課題とリスクのエスカレーション</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>I</td><td></td><td>I</td></tr><tr><td>ハイライトの報告</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr></tbody></table> <p>R = 実行責任、A = 説明責任、C = 協議先、I = 情報先</p> <ul> <li><strong>R¹</strong>: ステージ・レベルで課題とリスクを把握する実行責任がある</li> <li><strong>R²</strong>: チーム・レベルで課題とリスクを把握する実行責任がある</li> <li><strong>A¹</strong>: チーム・マネージャーが実施した是正処置に説明責任がある</li> <li><strong>R³</strong>: 自分のは正処置に実行責任がある</li> <li><strong>R⁴</strong>: チーム・レベルでのは正処置に実行責任がある</li> </ul> <h3>プロセスへのプラクティスの適用<a href="#プロセスへのプラクティスの適用"><span></span></a></h3> <table><thead><tr><th>プラクティス</th><th>ステージのコントロール・プロセスへの適用</th></tr></thead><tbody><tr><td>ビジネス・ケース</td><td>ビジネス・ケースは定期的に確認され、実行可能であることを確認します。それ以外の場合はプロジェクト委員会に通知する必要があります。ベネフィット・マネジメント・アプローチと持続可能性マネジメント・アプローチが適用され、それらの要件がステージのワーク・パッケージ記述書に含まれます</td></tr><tr><td>組織化</td><td>コミュニケーション・マネジメント、変更マネジメント・アプローチ、商業マネジメント・アプローチが適用され、それらの要件がステージのワーク・パッケージ記述書に含まれます。<br />プロジェクト・チームのウェルビーイングと状況がモニタリングされます</td></tr><tr><td>計画</td><td>ステージのワーク・パッケージ記述書が作成または更新されます。<br />ステージ計画書とプロジェクト計画書が更新されます</td></tr><tr><td>品質</td><td>成果物登録簿は、ステージの成果物のステータスで更新されます。<br />品質マネジメント・アプローチが適用され、その要件がステージのワーク・パッケージ記述書に含まれます。<br />ステージの成果物記述書が作成または更新されます。<br />品質登録簿は、計画済みの品質活動または実際の品質活動で更新されます</td></tr><tr><td>リスク</td><td>リスク・マネジメント・アプローチが適用され、その要件がステージのワーク・パッケージ記述書に含まれます。<br />リスク登録簿が新しいリスクの詳細で更新され、リスク対応策が実行または完了されます</td></tr><tr><td>課題</td><td>課題マネジメント・アプローチが適用され、その要件がステージのワーク・パッケージ記述書に含まれます。<br />課題登録簿は、新しい課題の詳細と、必要な処置または完了した処置で更新されます。<br />課題報告書は、エスカレーション、詳細な分析、処置が必要な課題に対して作成されます</td></tr><tr><td>進捗</td><td>デジタルおよびデータ・マネジメント・アプローチが適用され、その要件がステージのワーク・パッケージ記述書に含まれます。<br />デイリー・ログと教訓ログが新しいエントリで更新されます。<br />ハイライト報告書は、プロジェクト・コントロールに必要な頻度で作成、発行されます。<br />例外報告書は、合意された許容度内で解決できない課題について作成とエスカレーションが行われます</td></tr></tbody></table>category:项目管理tag:プロジェクトtag:マネジメントtag:プロセスtag:ステージのコントロールhttps://blog.issyuu.com/zh/post/pm-processes-initiating-dzh:pm-processes-initiating-d生きている限り、学び続けるSat, 18 Apr 2026 04:12:12 GMT<h2>プロジェクトの立ち上げ<a href="#プロジェクトの立ち上げ"><span></span></a></h2> <blockquote> <p>プロジェクトの立ち上げプロセスの目的は、プロジェクトの<strong>確固とした基盤</strong>を確立する。ビジネス側が本格的な支出やリソースの投入(コミットメント)を決定する前に、成果物提供のために必要な作業、コスト、リスクを十分に理解できる。</p> </blockquote> <h3>達成目標<a href="#達成目標"><span></span></a></h3> <blockquote> <p>関係者全員が以下の事項について共通の理解を持つことを目指す。</p> </blockquote> <ul> <li><strong>正当性と価値</strong>: 実施理由、期待されるベネフィット、および関連するリスク(<strong>ビジネス・ケース</strong>)。</li> <li><strong>スコープと成果物</strong>: 実施される作業範囲と、提供される具体的な成果物。</li> <li><strong>計画</strong>: 成果物を提供する方法、スケジュール、およびコスト(<strong>プロジェクト計画書</strong>)。</li> <li><strong>体制と責任</strong>: 意思決定に関与する人物とその責任。</li> <li><strong>品質</strong>: 求められる品質を定義し、達成する手段。</li> <li><strong>コントロール</strong>: ベースラインの確立方法、進捗のモニタリング、リスクや課題の管理手法。</li> <li><strong>コミュニケーション</strong>: 情報を必要とする人、書式、およびタイミング。</li> <li><strong>整合性</strong>: 組織のビジネス方針、手法、ガイダンスをプロジェクトに適用する方法。</li> </ul> <h3>位置付け<a href="#位置付け"><span></span></a></h3> <h4>実施のポイント<a href="#実施のポイント"><span></span></a></h4> <ul> <li>プロセスの重要性と役割 プロジェクトの成功を左右する<strong>合意とコミットメント</strong>を形成するフェーズである。 <ul> <li><strong>真のコミットメント</strong>: プロジェクトの目的、必要性、達成方法、責任について、関係者全員が明確なイメージを持ち、プロジェクトに対して真にコミットする。</li> <li><strong>意思決定の支援</strong>: このプロセスで作成された情報を基に、プロジェクト委員会は<strong>プロジェクトの指揮</strong>プロセスを通じて、プロジェクトの継続がビジネス目標に整合しているかを判断する。</li> <li><strong>マネジメント成果物の作成</strong>: PMは、委員会が求めるコントロール・レベルに応じた一連のマネジメント成果物を作成する。これらの成果物を<strong>誰がどのようにレビューし承認するか</strong>について、あらかじめ合意しておく必要がある。</li> </ul> </li> <li>商業的環境での考慮事項 ユーザー(顧客)とサプライヤーが商業的関係にある場合、本プロセスの活動には慎重な検討が求められる。 <ul> <li><strong>リスクと報酬の相違</strong>: 顧客側とサプライヤー側では、プロジェクトを引き受ける理由や、許容できるリスク、期待する報酬が異なる。</li> <li><strong>利害の調整</strong>: 双方の立場を考慮し、双方が納得できる形で基盤を構築する必要がある。</li> </ul> </li> </ul> <h3>活動<a href="#活動"><span></span></a></h3> <table><thead><tr><th>インプット</th><th>活動</th><th>アウトプット</th></tr></thead><tbody><tr><td><strong>プロジェクト立ち上げの認可</strong><br />(このプロセスをトリガー)<br /><br /><strong>プロジェクト要約書</strong> (レビュー)<br /><strong>プロジェクト・ログ</strong> (確認)<br /><strong>プロジェクト成果物記述書</strong> (レビュー)<br /><strong>ステージ計画書</strong> (立ち上げ)<br />(レビュー)</td><td>テーラリング要件への合意</td><td><strong>マネジメント・アプローチ</strong> (作成)<br /><strong>プロジェクト計画書</strong> (作成)</td></tr><tr><td><strong>プロジェクト立ち上げの認可</strong><br />(このプロセスをトリガー)<br /><br /><strong>プロジェクト要約書</strong> (レビュー)<br /><strong>プロジェクト・ログ</strong> (確認)<br /><strong>プロジェクト成果物記述書</strong> (レビュー)<br /><strong>ステージ計画書</strong> (立ち上げ)<br />(レビュー)</td><td>マネジメント・アプローチへの合意</td><td><strong>マネジメント・アプローチ</strong> (作成)<br /><strong>プロジェクト計画書</strong> (作成)</td></tr><tr><td><strong>プロジェクト立ち上げの認可</strong><br />(このプロセスをトリガー)<br /><br /><strong>プロジェクト要約書</strong> (レビュー)<br /><strong>プロジェクト・ログ</strong> (確認)<br /><strong>プロジェクト成果物記述書</strong> (レビュー)<br /><strong>ステージ計画書</strong> (立ち上げ)<br />(レビュー)</td><td>プロジェクト・コントロールの確立</td><td><strong>マネジメント・アプローチ</strong> (作成)<br /><strong>プロジェクト計画書</strong> (作成)</td></tr><tr><td><strong>プロジェクト立ち上げの認可</strong><br />(このプロセスをトリガー)<br /><br /><strong>プロジェクト要約書</strong> (レビュー)<br /><strong>プロジェクト・ログ</strong> (確認)<br /><strong>プロジェクト成果物記述書</strong> (レビュー)<br /><strong>ステージ計画書</strong> (立ち上げ)<br />(レビュー)</td><td>プロジェクト計画書の準備</td><td><strong>マネジメント・アプローチ</strong> (作成)<br /><strong>プロジェクト計画書</strong> (作成)</td></tr><tr><td><strong>ビジネス・ケース概要</strong></td><td>完全なビジネス・ケースの準備</td><td><strong>ビジネス・ケース</strong> (作成)</td></tr><tr><td><strong>ビジネス・ケース</strong><br /><strong>プロジェクト要約書</strong><br /><strong>プロジェクト成果物記述書</strong><br /><strong>プロジェクト計画書</strong><br /><strong>マネジメント・アプローチ</strong><br /><br /><strong>プロジェクト立ち上げ文書</strong></td><td>プロジェクト立ち上げ文書のとりまとめ</td><td><strong>プロジェクト立ち上げ文書</strong> (作成)<br /><strong>プロジェクト・ログ</strong> (更新)<br />ステージ終了が近づく(ステージ境界のマネジメント・プロセスをトリガー)</td></tr><tr><td><strong>プロジェクト立ち上げ文書</strong></td><td>プロジェクト認可の要求</td><td><strong>プロジェクト認可の要求</strong> (プロジェクトの指揮プロセスをトリガー)</td></tr></tbody></table> <h4>テーラリング要件への合意<a href="#テーラリング要件への合意"><span></span></a></h4> <blockquote> <p>すべてのプロジェクトに標準の手法をそのまま適用できるわけではない。プロジェクトの規模、複雑さ、リスク、重要度に応じて、管理の仕組みを最適化(テーラリング)する必要がある</p> </blockquote> <ol> <li>テーラリングの必要性 PMは、プロジェクトの遂行に影響を与える<strong>内部要因(組織文化、標準プロセスなど)<strong>や</strong>外部要因(法規制、市場環境など)</strong> を認識し、手法を最適化しなければならない。 <ul> <li><strong>組織標準の活用</strong>: ビジネス(組織)にすでに標準的なフレームワークが存在する場合は、それをベースに<strong>どのように適用し、どこを調整するか</strong>を明確にする。</li> <li><strong>合意の重要性</strong>: 調整した内容は文書化し、関係者間で合意を得る必要がある。 ＊管理の<strong>やりすぎ</strong>や<strong>不足</strong>を防ぐ。</li> </ul> </li> <li>PMに推奨される処置 PMは、以下のステップを通じてテーラリングの妥当性を確保する。 <ul> <li><strong>既存方針の確認</strong> <ul> <li>プロジェクト要約書をレビューし、すでに定義されているテーラリング・アプローチの概要を把握する。</li> </ul> </li> <li><strong>教訓の収集</strong> <ul> <li>過去の類似プロジェクトや外部組織の事例から、効果的なテーラリング方法についての教訓を収集する。</li> </ul> </li> <li><strong>要件の定義</strong> <ul> <li>関連するプロジェクト・コントロールを含め、**プロジェクト立ち上げ文書(PID)**の一部としてテーラリング要件を定義する。</li> </ul> </li> <li><strong>妥当性の確認</strong> <ul> <li>プロジェクト保証と協議し、提案したテーラリング内容がプロジェクト委員会や組織のニーズに合致しているかを確認する。</li> </ul> </li> <li><strong>承認の取得</strong> <ul> <li>テーラリング内容について委員会の承認を得る。 ※委員会がPID 全体の一部として後でまとめてレビューすることを希望する場合もある。</li> </ul> </li> </ul> </li> </ol> <h4>マネジメント・アプローチへの合意<a href="#マネジメントアプローチへの合意"><span></span></a></h4> <blockquote> <p>マネジメント・アプローチは、プロジェクトをどのように管理・運営していくかの<strong>ルールブック</strong>である。これらを定義することで、一貫性のあるコントロールが可能になり、詳細なプロジェクト計画の策定が進められるようになる。</p> </blockquote> <ol> <li>策定のポイント <ul> <li><strong>策定の順序</strong>: 各マネジメント・アプローチの策定活動は、複数を並行して進めることができるが、<strong>コミュニケーション・マネジメント・アプローチ</strong>は他すべてのアプローチの伝達要件を網羅する必要があるため、<strong>最後に完了させる</strong>ことが推奨される。</li> <li><strong>策定の根拠</strong>: ビジネス戦略、組織の標準、成果物記述書にある<strong>ユーザーの期待品質</strong>、および<strong>持続可能性</strong>などの要件に基づいて策定される。</li> </ul> </li> <li>定義すべき9つのマネジメント・アプローチ プロジェクトの特性に応じて、以下の領域における管理方針を定義する。 <ul> <li>変更マネジメント・アプローチ</li> <li>コミュニケーション・マネジメント・アプローチ</li> <li>持続可能性マネジメント・アプローチ</li> <li>ベネフィット・マネジメント・アプローチ</li> <li>商業マネジメント・アプローチ</li> <li>品質マネジメント・アプローチ</li> <li>リスク・マネジメント・アプローチ</li> <li>課題マネジメント・アプローチ</li> <li>デジタルおよびデータ・マネジメント・アプローチ</li> </ul> </li> <li>PMに推奨される処置 PMは、実効性のあるアプローチを策定するために以下の実務を行う。 <ul> <li><strong>影響の評価</strong> <ul> <li>決定済みのテーラリングが、各アプローチに与える影響をレビューする。</li> </ul> </li> <li><strong>要件の把握</strong> <ul> <li>プロジェクト要約書を確認し、適用すべきビジネス戦略やプラクティス、契約上の義務を特定する。</li> </ul> </li> <li><strong>知見の活用</strong> <ul> <li>過去の類似事例から教訓を収集し、アプローチに反映させる。</li> </ul> </li> <li><strong>リスクと課題の確認</strong> <ul> <li>プロジェクト・ログを精査し、アプローチ策定に関わるリスク(例: 特定の管理手法が複雑すぎるリスクなど)があるか確認し、必要に応じてログを更新する。</li> </ul> </li> <li><strong>妥当性の検証と承認</strong> <ul> <li><strong>プロジェクト保証</strong>と協議し、提案内容が委員会やビジネスのニーズを満たしているか確認する。</li> <li>プロジェクト委員会に承認を求める。 ※多くの場合、最終的な<strong>プロジェクト立ち上げ文書(PID)</strong> の一部として一括で承認される。</li> </ul> </li> </ul> </li> </ol> <h4>プロジェクト・コントロールの確立<a href="#プロジェクトコントロールの確立"><span></span></a></h4> <blockquote> <p>プロジェクト・コントロールの確立は、プロジェクトを規模、リスク、複雑性、重要度に応じて効果的かつ効率的に管理するためのメカニズムを構築する。</p> </blockquote> <ol> <li>重要性 <ul> <li><strong>合意の形成</strong>: プロジェクト委員会とPM 間、およびPMとチーム・マネージャー間での管理レベル(コントロール・レベル)について合意する。</li> <li><strong>効率的な管理</strong>: 適切なコントロールを確立することで、各マネジメント層が過度な負担を負わずに意思決定に関与できる環境を作る。</li> </ul> </li> <li>構成要素 効果的なコントロールを実現するために、以下の要素を具体的に定義し確立する。 <ul> <li><strong>コミュニケーション</strong>: 各レイヤー間における報告の頻度と形式。</li> <li><strong>ステージの設定</strong>: 適切な意思決定ポイントとしてのステージ数と境界。</li> <li><strong>課題管理</strong>: 課題を確実に把握し、分析するためのメカニズム。</li> <li><strong>許容度(トレランス)の設定</strong>: 委任された権限の範囲(時間、コスト、品質、スコープ、ベネフィット、リスク)。</li> <li><strong>モニタリング</strong>: 委任された権限が守られているかを監視する方法。</li> <li><strong>エスカレーション</strong>: 許容度を超える事態(例外)が発生した際の報告ルート。</li> </ul> </li> <li>PMと支援チームに推奨される処置 役割に応じて以下の処置を取る。 <ul> <li>手法と環境の評価 <ul> <li><strong>デリバリー手法の確認</strong>: ウォーターフォール、アジャイル、ハイブリッドなどの手法が、コントロールに与える影響を評価する。</li> <li><strong>テーラリングの反映</strong>: プロジェクト立ち上げ文書(PID)で定義された調整内容が、コントロールに与える影響を確認する。</li> </ul> </li> <li>知見とリスクの活用 <ul> <li><strong>教訓の反映</strong>: 過去のプロジェクトから、どの程度のコントロールが有効であったかの知見を集める。</li> <li><strong>リスクと課題のレビュー</strong>: ログを精査し、リスクの蓄積が管理の厳格さにどう影響するかを判断する(リスクが高いほど、コントロールを強める必要がある)。</li> </ul> </li> <li>体制と手順の構築 <ul> <li><strong>ステージ境界の確定</strong>: 適切なタイミングでコントロールを行うためのステージ区切りを決定し、文書化する。</li> <li><strong>意思決定手順の確立</strong>: 各レベルに最適な意思決定権限を割り当て、具体的な手順(品質システム等のテーラリング)を策定する。</li> <li><strong>役割の更新</strong>: 必要に応じてチーム組織を再編成し、役割記述書に決定権限と責任を反映させる。</li> <li><strong>エスカレーション・パスの確認</strong>: チーム -&gt; PM -&gt; 委員会 -&gt; ビジネスという報告ルートを確定させる。</li> </ul> </li> <li>最終確認と承認 <ul> <li><strong>整合性の確認</strong>: <strong>プロジェクト保証</strong>と協議し、提案したコントロールがプロジェクトの性質やビジネスのニーズと一致しているかを確認する。</li> <li><strong>承認依頼</strong>: 策定したコントロールについてプロジェクト委員会に承認を求める ※多くの場合、最終的な<strong>プロジェクト立ち上げ文書(PID)</strong> の一部として一括で承認される。</li> </ul> </li> </ul> </li> </ol> <h4>プロジェクト計画書の準備<a href="#プロジェクト計画書の準備"><span></span></a></h4> <blockquote> <p>プロジェクト計画書の準備は、本格的な支出やリソース投入を決定する前に、プロジェクトの期間、コスト、リソース、人員の要件を明確に定義し、ベネフィット実現の基盤となり、プロジェクト委員会が全体をコントロールするための基準を提供する。</p> </blockquote> <ol> <li>計画立案の基本姿勢 <ul> <li><strong>共創</strong>: 計画はPMが単独で作るものではない。ユーザーやサプライヤーと緊密に連携し、ワークショップなどを通じて成果物や依存関係の特定を促進する。</li> <li><strong>運用への配慮</strong>: 成果物の完成だけでなく、引き渡した後の保守体制やサービス合意(SLA)についても、必要に応じて計画に含める。</li> </ul> </li> <li>PMに推奨される処置 <ul> <li><strong>前提条件と手法の確認</strong>: <ul> <li>デリバリー手法(アジャイル、ウォーターフォール、ハイブリッド)、テーラリング要件をレビューし、計画立案に与える影響を評価する。</li> <li>過去の教訓や現在のプロジェクト・ログを精査し、計画上のリスクを特定・評価する。</li> </ul> </li> <li><strong>成果物の定義と構造化</strong>: <ul> <li><strong>成果物ブレークダウン・ストラクチャー (PBS)</strong>、<strong>成果物記述書</strong>、<strong>成果物流れ図</strong>を作成し、何を作るのかを構造的に定義する。</li> <li>立ち上げ中の理解の変化に基づき、必要に応じてプロジェクト成果物記述書を更新する。</li> </ul> </li> <li><strong>見積もりとリソースの確保</strong>: <ul> <li>見積もり手法を選択し、ツールやコントロール手法を特定する。</li> <li>必要な人員・リソースを特定し、関係者の可用性やコミットメントを確保する。</li> </ul> </li> <li><strong>管理活動の組み込み</strong>: <ul> <li>品質管理やプロジェクト・コントロールのための活動、リソース、時期を計画に反映する。</li> <li>各成果物の情報を<strong>成果物登録簿</strong>に記録する。</li> </ul> </li> <li><strong>プレゼンテーションと承認</strong>: <ul> <li>対象者(プロジェクト委員会など)に合わせて、最も理解しやすい書式(成果物チェックリスト等)で提示する。</li> <li>プロジェクト保証と協議し、ビジネスニーズを満たしているか確認した上で、委員会の承認を得る。</li> </ul> </li> </ul> </li> </ol> <h4>完全なビジネス・ケースの準備<a href="#完全なビジネスケースの準備"><span></span></a></h4> <blockquote> <p>プロジェクトの始動段階で作成された<strong>ビジネス・ケース概要</strong>を、最新のプロジェクト計画書(見積もり時間・コスト)およびプロジェクト・ログ(集約されたリスク)に基づいて詳細化する</p> </blockquote> <ol> <li>PMに推奨される処置 <ul> <li>情報の収集と詳細化 <ul> <li><strong>要件の確認</strong>: プロジェクト要約書をレビューし、求めるビジネス・ケースの書式や内容を把握する。</li> <li><strong>教訓の反映</strong>: 過去の類似プロジェクトや外部事例から、効果的なビジネス・ケース開発に関連する教訓を収集する。</li> <li><strong>詳細版の構築</strong>: プロジェクト計画書の見積もりとプロジェクト・ログのリスクを集約し、詳細なビジネス・ケースを作成する。</li> </ul> </li> <li>管理と妥当性の確認 <ul> <li><strong>ログの更新</strong>: ビジネス・ケース策定中に特定された新たなリスクや課題、または既存情報の変化をプロジェクト・ログに反映させる。</li> <li><strong>プロジェクト保証との協議</strong>: 提案内容がプロジェクト委員会やビジネス層のニーズに合致しているか、客観的な評価(プロジェクト保証)を受ける。</li> </ul> </li> <li>承認の取得 <ul> <li><strong>委員会の承認</strong>: 完成したビジネス・ケースについて、プロジェクト委員会に承認を求める。 ※多くの場合、最終的な**プロジェクト立ち上げ文書(PID)**の一部として一括で承認される。</li> </ul> </li> </ul> </li> </ol> <h4>プロジェクト立ち上げ文書のとりまとめ<a href="#プロジェクト立ち上げ文書のとりまとめ"><span></span></a></h4> <blockquote> <p>PIDは、プロジェクトの<strong>何を、なぜ、誰が、どのように、いつ、いくらで</strong>に関する全情報を集約。</p> </blockquote> <p>＊プロジェクトの<strong>憲章</strong>とも呼べる。</p> <ol> <li>役割 <ul> <li><strong>合意の形成</strong>: 主要な利害関係者がプロジェクトの内容に合意したことを確認する。</li> <li><strong>ガイダンスの提供</strong>: プロジェクト関係者がいつでも参照できる公式な情報源として機能させる。</li> <li><strong>認可の根拠</strong>: プロジェクト実行の認可を得るための最終的な判断材料となる。</li> </ul> </li> <li>性質 <ul> <li><strong>情報の集約</strong>: 立ち上げ中に作成された多くのマネジメント成果物を参照または包含する。必ずしも単一の文書である必要はなく、ツール上のデータや複数のドキュメントの集合体でもよい。</li> <li><strong>ベースライン化</strong>: 認可を受けたPIDのバージョンはベースラインとして保存し、<strong>変更コントロール</strong>の対象とする。これは、プロジェクト終了時に当初の予測と実績を比較するための基準となる。</li> </ul> </li> <li>プロジェクト・マネージャーに推奨される処置 <ul> <li>プロジェクト要約書の情報を最新の状態に修正して取り込む。</li> <li><strong>要素の包含</strong>: 以下の主要な情報をPIDに含める、あるいは参照させる。 <ul> <li>プロジェクト・マネジメント・チームの組織構造と役割記述書</li> <li>完全なビジネス・ケース</li> <li>各マネジメント・アプローチ(品質、リスク、コミュニケーションなど)</li> <li>プロジェクト計画書</li> </ul> </li> <li><strong>テーラリングの要約</strong>: プロジェクトの性質に合わせてどのように手法を調整(テーラリング)したかを要約する。</li> <li><strong>互換性のチェック</strong><div></div>、相互の互換性を確認する。</li> <li><strong>プロジェクト保証との協議</strong>: PIDの内容がプロジェクト委員会や組織のニーズを満たしているかを確認する。</li> <li><strong>次のステージへの準備</strong>: PIDのとりまとめにより<strong>ステージ境界のマネジメント</strong>プロセスをトリガーし、次期ステージの実行に向けた準備を開始する。</li> </ul> </li> </ol> <h4>プロジェクト認可の要求<a href="#プロジェクト認可の要求"><span></span></a></h4> <blockquote> <p><strong>プロジェクトの立ち上げ</strong>プロセスを締めくくり、プロジェクトの実行フェーズ(デリバリーステージ)へ進むための最終的な承認を得る。</p> </blockquote> <ol> <li>PMに推奨される処置 <ul> <li>成果物の共有と提示 <ul> <li><strong>最終ドキュメントの提出</strong>: ビジネス・ケースの最終バージョン、プロジェクト立ち上げ文書(PID)、およびプロジェクト計画書をプロジェクト委員会へ提示する。</li> </ul> </li> <li>権限とリソースの要求 <ul> <li><strong>実行権限の正式要求</strong>: プロジェクト成果物を提供し、計画を実行に移すための公式な権限を要求する。</li> <li><strong>リソースの確保</strong>: プロジェクトの成果物を提供(デリバリー)するために必要な人員やリソースを確保・使用する権限を、プロジェクト委員会に対して正式に要求する。</li> </ul> </li> </ul> </li> </ol> <h3>適用<a href="#適用"><span></span></a></h3> <blockquote> <p>このプロセスを実務に適用する際は、形式的な文書作成に陥ることなく、プロジェクトの確固とした基盤(ファウンデーション)を築くための柔軟な運用が求められる。</p> </blockquote> <h4>一般的な考慮事項<a href="#一般的な考慮事項"><span></span></a></h4> <blockquote> <p>プロセスの規模や詳細度は、プロジェクトの複雑性やリスクに応じて適切にテーラリングされるべきである。</p> </blockquote> <ul> <li><strong>活動の柔軟な運用</strong>: 立ち上げプロセスの各活動は、プロジェクトの都合や状況に応じて、結合・分割、あるいは同時並行で実行できる。</li> <li><strong>テーラリングの段階的詳細化</strong>: 立ち上げ開始時点では不明な要因も多いため、最初から過度な詳細を求める必要はない。<strong>シンプルに開始し、状況が明らかになるにつれて、内容を具体化</strong>することが推奨される。</li> <li><strong>不確実性への対処(調査ステージ)</strong>: アウトプットを即座に完全定義できないほど複雑なプロジェクトでは、ライフサイクル内に調査用のステージを設ける。この場合、立ち上げプロセスは<strong>第 1ステージ開始時の管理・コントロール環境を確立するため</strong>に使用される。</li> </ul> <h4>役割のテーラリング<a href="#役割のテーラリング"><span></span></a></h4> <blockquote> <p>実務の委任は可能だが、プロジェクトの実行方法に関する最終的な責任の所在を明確にしておく必要がある。</p> </blockquote> <ul> <li><strong>PMの実行責任</strong>: マネジメント成果物の作成に関する実行責任はPMにある。PMはタスクに応じて適切な人員に作業を割り当てることができる。</li> <li><strong>支援組織の活用</strong>: プロジェクト支援やプログラム・オフィス(PMO)などの既存組織は、補助的な成果物の作成においてPMに支援を提供できる。</li> <li><strong>責任の維持</strong>: 誰が実務を補助したとしても、<strong>プロジェクトの実行方法についてプロジェクト・エグゼクティブに対して負う実行責任は、PM 一元化</strong>されていなければならない。</li> </ul> <h3>責任<a href="#責任"><span></span></a></h3> <table><thead><tr><th>活動</th><th>ビジネス・レイヤー</th><th>プロジェクト・エグゼクティブ</th><th>シニア・ユーザー</th><th>シニア・サプライヤー</th><th>プロジェクト・マネージャー</th><th>チーム・マネージャー</th><th>プロジェクト保証</th><th>プロジェクト支援</th></tr></thead><tbody><tr><td>テーラリング要件への合意</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>I</td></tr><tr><td>マネジメント・アプローチへの合意</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>I</td></tr><tr><td>プロジェクト・コントロールの確立</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>I</td></tr><tr><td>プロジェクト計画書の準備</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>完全なビジネス・ケースの準備</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>I</td></tr><tr><td>プロジェクト立ち上げ文書のとりまとめ</td><td></td><td>C</td><td>C</td><td>C</td><td>A</td><td>C</td><td>C</td><td>R</td></tr><tr><td>プロジェクト認可の要求</td><td>I</td><td>A</td><td>C</td><td>C</td><td>R</td><td>I</td><td>C</td><td>I</td></tr></tbody></table> <p>R = 実行責任、A = 説明責任、C = 協議先、I = 情報先</p> <h3>プロセスへのプラクティスの適用<a href="#プロセスへのプラクティスの適用"><span></span></a></h3> <table><thead><tr><th>プラクティス</th><th>プロジェクトの立ち上げプロセスへの適用</th></tr></thead><tbody><tr><td><strong>ビジネス・ケース</strong></td><td>概要を<strong>完全なビジネス・ケース</strong>へと発展させる。ベネフィットおよび持続可能性マネジメント・アプローチを策定し、投資の正当性を強固にする</td></tr><tr><td><strong>組織化</strong></td><td>権限委任の詳細を反映してチーム組織を更新し、残りのメンバーを任命・オンボーディングする。<strong>コミュニケーション・変更・商業マネジメント・アプローチ</strong>を作成し、WBSを用いて作業編成や外部調達を判断する</td></tr><tr><td><strong>計画</strong></td><td>成果物ベースの計画手法(PBS、成果物流れ図)を用いて<strong>プロジェクト計画書</strong>を作成し、必要なステージ構成を定義する</td></tr><tr><td><strong>品質</strong></td><td><strong>成果物記述書</strong>、<strong>品質マネジメント・アプローチ</strong>、<strong>成果物登録簿</strong>、<strong>品質登録簿</strong>を作成。必要に応じてプロジェクト成果物記述書を更新する</td></tr><tr><td><strong>リスク</strong></td><td><strong>リスク・マネジメント・アプローチ</strong>と<strong>リスク登録簿</strong>を作成。特定されたリスクを評価・記録し、必要に応じて<strong>リスク予算</strong>を設定する</td></tr><tr><td><strong>課題</strong></td><td><strong>課題マネジメント・アプローチ</strong>と<strong>課題登録簿</strong>を作成。特定された課題を評価・記録し、必要に応じて<strong>変更予算</strong>を設定する</td></tr><tr><td><strong>進捗</strong></td><td><strong>デジタルおよびデータ・マネジメント・アプローチ</strong>を作成。全アプローチのコントロールを確立して進捗管理の基盤とし、当ステージの報告にはハイライト報告書を使用する</td></tr></tbody></table>category:项目管理tag:プロジェクトtag:マネジメントtag:プロセスtag:プロジェクトの立ち上げhttps://blog.issyuu.com/zh/post/pm-processes-initiating-szh:pm-processes-initiating-s生きている限り、学び続けるSat, 18 Apr 2026 04:12:12 GMT<h2>プロジェクトの立ち上げ<a href="#プロジェクトの立ち上げ"><span></span></a></h2> <blockquote> <p>プロジェクトの立ち上げプロセスの目的は、プロジェクトの<strong>確固とした基盤</strong>を確立し、ビジネスは本格的なリソース投入の前に、達成すべき作業とコストを正確に理解できる。</p> </blockquote> <h3>基本コンセプト<a href="#基本コンセプト"><span></span></a></h3> <ul> <li><strong>目的</strong>: プロジェクトの<strong>何を、なぜ、誰が、どのように、いつ、いくらで</strong>について、関係者間で共通の理解を得る。</li> <li><strong>特徴</strong>: <strong>プロジェクト立ち上げ文書 (PID)</strong> を作成し、プロジェクト全体のベースラインを確定させる。</li> <li><strong>位置づけ</strong>: 立ち上げステージ全体をカバーし、プロジェクト委員会による実行認可(Go/No-Go 判断)で終了する。</li> </ul> <h3>主要な活動<a href="#主要な活動"><span></span></a></h3> <table><thead><tr><th>活動</th><th>概要</th><th>主なアウトプット</th></tr></thead><tbody><tr><td><strong>テーラリングの合意</strong></td><td>組織の標準をどのようにプロジェクトに適合させるかを決定</td><td>PIDの一部</td></tr><tr><td><strong>各種アプローチの策定</strong></td><td>リスク、課題、品質、コミュニケーション、データ管理等の手順を定義</td><td>各マネジメント・アプローチ</td></tr><tr><td><strong>コントロールの確立</strong></td><td>ステージ数、許容度、エスカレーションなどの管理メカニズムを確立</td><td>プロジェクト・コントロール</td></tr><tr><td><strong>プロジェクト計画書の準備</strong></td><td>成果物、期間、コスト、リソースの詳細なスケジュールと予算を策定</td><td>プロジェクト計画書</td></tr><tr><td><strong>完全なビジネス・ケース作成</strong></td><td>始動時の<strong>概要</strong>を、最新の見積もりとリスクを反映した<strong>完全版</strong>へ更新</td><td>ビジネス・ケース</td></tr><tr><td><strong>PIDの集約</strong></td><td>上記全ての情報を集約し、ベースラインとして保存</td><td><strong>プロジェクト立ち上げ文書 (PID)</strong></td></tr><tr><td><strong>プロジェクト認可の要求</strong></td><td>プロジェクト委員会に対し、実行フェーズへの移行許可を申請</td><td>認可の要求</td></tr></tbody></table> <h3>プロジェクト立ち上げ文書(PID)の構成<a href="#プロジェクト立ち上げ文書pidの構成"><span></span></a></h3> <blockquote> <p>PIDは以下の要素を含む、プロジェクトの<strong>憲章</strong>となる情報群である。</p> </blockquote> <ul> <li><strong>ビジネス・ケース</strong>: なぜやるのか(正当性)。</li> <li><strong>プロジェクト計画書</strong>: いつ、いくらで、何を(スケジュールと予算)。</li> <li><strong>マネジメント・アプローチ</strong>: どのように管理するか(リスク、品質、変更管理等)。</li> <li><strong>プロジェクト・コントロール</strong>: 意思決定の仕組みと権限。</li> <li><strong>テーラリングの概要</strong>: 手法をどうカスタマイズしたか。</li> </ul> <h3>主要な役割と責任(RACI)<a href="#主要な役割と責任raci"><span></span></a></h3> <table><thead><tr><th>活動</th><th>ビジネス・レイヤー</th><th>プロジェクト・エグゼクティブ</th><th>シニア・ユーザー</th><th>シニア・サプライヤー</th><th>プロジェクト・マネージャー</th><th>チーム・マネージャー</th><th>プロジェクト保証</th><th>プロジェクト支援</th></tr></thead><tbody><tr><td>テーラリング要件への合意</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>I</td></tr><tr><td>マネジメント・アプローチへの合意</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>I</td></tr><tr><td>プロジェクト・コントロールの確立</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>I</td></tr><tr><td>プロジェクト計画書の準備</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>完全なビジネス・ケースの準備</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>I</td></tr><tr><td>プロジェクト立ち上げ文書のとりまとめ</td><td></td><td>C</td><td>C</td><td>C</td><td>A</td><td>C</td><td>C</td><td>R</td></tr><tr><td>プロジェクト認可の要求</td><td>I</td><td>A</td><td>C</td><td>C</td><td>R</td><td>I</td><td>C</td><td>I</td></tr></tbody></table> <p>R = 実行責任、A = 説明責任、C = 協議先、I = 情報先</p>category:项目管理tag:プロジェクトtag:マネジメントtag:プロセスtag:プロジェクトの立ち上げhttps://blog.issyuu.com/zh/post/pm-processes-initiatingzh:pm-processes-initiating生きている限り、学び続けるSat, 18 Apr 2026 04:12:12 GMT<h2>プロジェクトの立ち上げ<a href="#プロジェクトの立ち上げ"><span></span></a></h2> <p>プロジェクトの立ち上げプロセスの目的は、プロジェクトの確固とした基盤を確立することです。これにより、ビジネスは本格的な支出やリソースをコミットする前に、プロジェクト成果物を提供するために行う必要のある作業を理解できるようになります。</p> <p>プロジェクトの立ち上げプロセスの達成目標は、以下についての共通の理解を得ることです。 * プロジェクトを実施する理由、期待されるベネフィットおよび関連するリスク(完全なビジネス・ケースで文書化される) * 実施されるスコープ、提供される成果物 * 成果物を提供する方法、時期、コスト * プロジェクトの意思決定に関与する人物 * 求められている品質を達成する手段 * ベースラインを確立してコントロールする方法 * リスクと課題を特定、評価、コントロールする方法 * 進捗をモニタリングおよびコントロールする方法 * 情報を必要とする人、情報の書式、必要な時期 * プロジェクトでビジネスの方針、手法、ガイダンスを適用する方法</p> <p>プロジェクトの立ち上げでは、プロジェクトの成功を達成させるための基盤が整います。特に、プロジェクトが達成しようとしていること、プロジェクトが必要な理由、成果の達成方法、責任について、関係者全員が明確なアイデアを持ち、プロジェクトに真にコミットメントする必要があります。 プロジェクトの立ち上げプロセスにより、プロジェクト委員会は、プロジェクトの指揮プロセスを経て、プロジェクトが十分ビジネス目標に整合しており、その継続を正当化できるかどうかを判断します。 プロジェクトの立ち上げプロセス中に、プロジェクト・マネージャーは、プロジェクト委員会が特定したコントロール・レベルに必要な一連のマネジメント成果物を作成します。プロジェクト・マネージャーは、マネジメント成果物をどのようにレビューおよび承認するかについて、プロジェクト委員会と合意している必要があります。 プロジェクトの立ち上げプロセスのすべての活動は、ユーザーとサプライヤーが商業的関係である場合、さらに検討が必要となります。この理由は、リスク、報酬、プロジェクトの引き受け理由が、(顧客である)ユーザーとサプライヤーとで異なるためです。</p> <h3>活動<a href="#活動"><span></span></a></h3> <table><thead><tr><th>インプット</th><th>活動</th><th>アウトプット</th></tr></thead><tbody><tr><td><strong>プロジェクト立ち上げの認可</strong><br />(このプロセスをトリガー)<br /><br /><strong>プロジェクト要約書</strong> (レビュー)<br /><strong>プロジェクト・ログ</strong> (確認)<br /><strong>プロジェクト成果物記述書</strong> (レビュー)<br /><strong>ステージ計画書</strong> (立ち上げ)<br />(レビュー)</td><td>テーラリング要件への合意</td><td><strong>マネジメント・アプローチ</strong> (作成)<br /><strong>プロジェクト計画書</strong> (作成)</td></tr><tr><td><strong>プロジェクト立ち上げの認可</strong><br />(このプロセスをトリガー)<br /><br /><strong>プロジェクト要約書</strong> (レビュー)<br /><strong>プロジェクト・ログ</strong> (確認)<br /><strong>プロジェクト成果物記述書</strong> (レビュー)<br /><strong>ステージ計画書</strong> (立ち上げ)<br />(レビュー)</td><td>マネジメント・アプローチへの合意</td><td><strong>マネジメント・アプローチ</strong> (作成)<br /><strong>プロジェクト計画書</strong> (作成)</td></tr><tr><td><strong>プロジェクト立ち上げの認可</strong><br />(このプロセスをトリガー)<br /><br /><strong>プロジェクト要約書</strong> (レビュー)<br /><strong>プロジェクト・ログ</strong> (確認)<br /><strong>プロジェクト成果物記述書</strong> (レビュー)<br /><strong>ステージ計画書</strong> (立ち上げ)<br />(レビュー)</td><td>プロジェクト・コントロールの確立</td><td><strong>マネジメント・アプローチ</strong> (作成)<br /><strong>プロジェクト計画書</strong> (作成)</td></tr><tr><td><strong>プロジェクト立ち上げの認可</strong><br />(このプロセスをトリガー)<br /><br /><strong>プロジェクト要約書</strong> (レビュー)<br /><strong>プロジェクト・ログ</strong> (確認)<br /><strong>プロジェクト成果物記述書</strong> (レビュー)<br /><strong>ステージ計画書</strong> (立ち上げ)<br />(レビュー)</td><td>プロジェクト計画書の準備</td><td><strong>マネジメント・アプローチ</strong> (作成)<br /><strong>プロジェクト計画書</strong> (作成)</td></tr><tr><td><strong>ビジネス・ケース概要</strong></td><td>完全なビジネス・ケースの準備</td><td><strong>ビジネス・ケース</strong> (作成)</td></tr><tr><td><strong>ビジネス・ケース</strong><br /><strong>プロジェクト要約書</strong><br /><strong>プロジェクト成果物記述書</strong><br /><strong>プロジェクト計画書</strong><br /><strong>マネジメント・アプローチ</strong><br /><br /><strong>プロジェクト立ち上げ文書</strong></td><td>プロジェクト立ち上げ文書のとりまとめ</td><td><strong>プロジェクト立ち上げ文書</strong> (作成)<br /><strong>プロジェクト・ログ</strong> (更新)<br />ステージ終了が近づく(ステージ境界のマネジメント・プロセスをトリガー)</td></tr><tr><td><strong>プロジェクト立ち上げ文書</strong></td><td>プロジェクト認可の要求</td><td><strong>プロジェクト認可の要求</strong> (プロジェクトの指揮プロセスをトリガー)</td></tr></tbody></table> <h4>テーラリング要件への合意<a href="#テーラリング要件への合意"><span></span></a></h4> <p>プロジェクト・マネージャーは、プロジェクトの遂行方法に影響を与える内部要因や外部要因を認識するために、テーラリングしなければならない場合があります。ビジネスには、プロジェクトに適用する準備ができている、テーラリングされたバージョンに基づく標準のプロジェクト・マネジメント・フレームワークがすでに存在する場合があります。ビジネスの標準的なプロジェクト・マネジメント・フレームワークにどのように適用と調整の両方またはいずれかを行うかを文書化し、合意する必要があります。</p> <p>プロジェクト・マネージャーに推奨される処置 * テーラリング・アプローチの概要(定義されている場合) を理解するために、プロジェクト要約書をレビューする。 * 過去の類似のプロジェクト、ビジネス、外部組織からテーラリングを適用する方法についての教訓を集める。 * 関連するプロジェクト・コントロールを含むプロジェクト立ち上げ文書の一部として、テーラリング要件を定義する。 * プロジェクト保証と協議して、提案されたテーラリングがプロジェクト委員会またはビジネスのニーズに応えていることを確認する。 * テーラリングについて、プロジェクト委員会に承認を求める(ただしプロジェクト委員会は、プロジェクト立ち上げ文書の一部として後でレビューすることを望む場合もあります)。</p> <h4>マネジメント・アプローチへの合意<a href="#マネジメントアプローチへの合意"><span></span></a></h4> <p>プロジェクトのアプローチを確立する活動は複数を並行して実行することができます。ただし、コミュニケーション・マネジメント・アプローチは、その他のアプローチで必要なコミュニケーションを含むため最後に完了させることをお勧めします。 プロジェクトが準拠しなくてはならないビジネス戦略、標準、プラクティス、プロジェクト成果物記述書で把握されているユーザーの期待品質と持続可能性に基づいてマネジメント・アプローチは策定されます。アプローチが定義されると、プロジェクト・コントロールを確立し、プロジェクト計画書の作成が可能になります。異なるマネジメント・アプローチは次のとおりです。 * 変更マネジメント・アプローチ * コミュニケーション・マネジメント・アプローチ * 持続可能性マネジメント・アプローチ * ベネフィット・マネジメント・アプローチ * 商業マネジメント・アプローチ * 品質マネジメント・アプローチ * リスク・マネジメント・アプローチ * 課題マネジメント・アプローチ * デジタルおよびデータ・マネジメント・アプローチ</p> <p>プロジェクト・マネージャーに推奨される処置 * テーラリング方法と、それがマネジメント・アプローチに与える影響をレビューする。 * プロジェクト要約書をレビューし、マネジメント・アプローチに関するビジネス戦略、標準、プラクティスをプロジェクト中に適用する必要があるかどうかを理解する(すべての契約上の要件も含みます)。 * 過去の類似のプロジェクト、ビジネス、外部組織から、マネジメント・アプローチに関連する教訓を集める(これらの中にはプロジェクト・ログにすでに盛り込まれているものもある)。 * プロジェクト・ログをレビューして、マネジメント・アプローチに関連する課題やリスクがあるかどうかを確認する。 * 新たなリスクや課題が特定された(または既存のリスクに変化が生じた)場合は、プロジェクト・ログを更新する。 * プロジェクト保証と協議して、提案されたマネジメント・アプローチがプロジェクト委員会またはビジネスのニーズに応えていることを確認する。 * マネジメント・アプローチについて、プロジェクト委員会に承認を求める(ただしプロジェクト委員会は、プロジェクト立ち上げ文書の一部として後でレビューすることを望む場合もある)。</p> <h4>プロジェクト・コントロールの確立<a href="#プロジェクトコントロールの確立"><span></span></a></h4> <p>プロジェクト委員会が要求する立ち上げ以降のコントロール・レベルについて合意する必要があります。また、そのコントロールのメカニズムを確立することも必要です。チーム・マネージャーが実施する作業に関して、プロジェクト・マネージャーが要求するコントロール・レベルについても同じことが言えます。プロジェクト・コントロールにより、プロジェクトを規模、リスク、複雑性、重要性に応じて効果的、効率的な方法で管理することができます。</p> <p>効果的なプロジェクト・コントロールは、例外によるマネジメントの必須条件です。プロジェクト・コントロールには以下の内容が含まれます。 * プロジェクト・マネジメント・レイヤー間およびプロジェクト・マネジメント・レイヤー内のコミュニケーションの頻度と形式 * ステージの数 * 課題を把握、分析するメカニズム * 委任された権限の許容度の設定 * あるマネジメント・レベルから別のレベルに委任された権限のモニタリング方法 * 例外をエスカレーションするメカニズム これらのコントロールの多くがマネジメント・アプローチで定義済みですが、必ず確立されるわけではありません。この活動の主眼は、このようなコントロールを確立し、首尾一貫して意味のある活動にすることです。</p> <p>プロジェクト・マネージャーとプロジェクト支援に推奨される措置 * デリバリー手法(直線的かつ連続的、反復的かつ段階的、ハイブリッド)を確認し、プロジェクト・コントロールへの影響を評価する。 * テーラリングし、プロジェクト立ち上げ文書に含める方法と、プロジェクト・コントロールへの影響を確認する。 * マネジメント・アプローチを確認して、確立する必要があるコントロールを特定する。 * 過去の類似のプロジェクト、ビジネス、外部組織からプロジェクト・コントロールに関連した教訓を集める。その中には、プロジェクト・ログに記録済みのものがある場合もある。 * プロジェクト・ログをレビューして、プロジェクト・コントロールと関連したリスクや課題があるかどうかを確認する(一連のリスクが積み重なると、コントロール活動の規模や厳格さにインパクトを与えることになる)。 * 適切なコントロール・レベルを提供するために必要なステージ境界を確認し、文書化する。 * プロジェクト内で必要とされるさまざまな意思決定レベルを、最適なプロジェクト・マネジメント・レベルに割り当てる。 * 適切であると考えられる意思決定手順を確立する。このために、既存の品質マネジメント・システム内あるいは他の標準手順内の手順をテーラリングする場合がある。 * 合意された意思決定権限と責任をプロジェクト・マネジメント・チーム組織構造と役割記述書に適宜構築する。これには、それまで割り当てたことのない役割の確定や、以前に割り当てたことのある役割の再割り当てが含まれる場合がある。また、必要に応じて、プロジェクト・マネジメント・チームの再編成を行って、必要な利害関係者をすべて含め、首尾一貫したチームを構築することが含まれる * プロジェクトの許容度とエスカレーション手順を確認する(チーム・マネージャーからプロジェクト・マネージャー、プロジェクト・マネージャーからプロジェクト委員会、プロジェクト委員会からビジネス)。 * プロジェクト計画書のプロジェクト・コントロールについて説明する。 * プロジェクト保証と協議して、提案したプロジェクト・コントロールが、プロジェクトの性質と整合するものであり、プロジェクト委員会またはビジネスのニーズに応えていることを確認する。 * 新たなリスクや課題が特定された(または既存のリスクに変化が生じた)場合は、プロジェクト・ログを更新する。 * プロジェクト・コントロールについて、プロジェクト委員会に承認を求める(プロジェクト委員会は、プロジェクト立ち上げ文書の一部として後でレビューする場合もある)。</p> <h4>プロジェクト計画書の準備<a href="#プロジェクト計画書の準備"><span></span></a></h4> <p>プロジェクトへの本格的な支出をコミットする前に、期間、リソース、人員の要件を確立する必要があります。この情報はプロジェクト計画書に記載され、ベネフィット・マネジメント・アプローチの策定と、プロジェクト委員会によるプロジェクト・コントロールを可能にするために必要です。 計画立案は、プロジェクト・マネージャーが単独で行う活動ではなく、プロジェクト計画書を共創するためにユーザーやサプライヤーと緊密に関係しながら実施されるべきものです。計画立案ワークショップを開催することは、必要とされるすべての成果物、その詳細、成果物間の依存関係を特定するのに役立つことがよくあります。</p> <p>プロジェクト・マネージャーに推奨される処置 * デリバリー手法(直線的かつ連続的、反復的かつ段階的、ハイブリッド)を確認し、計画立案への影響を評価する。 * プロジェクト要約書をレビューして、スコープと計画立案要件を理解する。 * プロジェクトに合わせてテーラリングし、プロジェクト立ち上げ文書に含める方法と、計画立案への影響を確認する。 * 過去の類似のプロジェクト、ビジネス、外部組織から、計画立案に関連する教訓を集める(これらの中にはプロジェクト・ログにすでに盛り込まれているものもある)。 * プロジェクト・ログをレビューして、計画立案と関連したリスクや課題があるかどうかを確認する。 * プロジェクトで使用する計画立案ツールとコントロール・ツールを特定し、それらの使用方法をプロジェクト計画書で文書化する。 * プロジェクトの計画の見積もり手法を選択する。 * マネジメント・アプローチをレビューして、実施する作業のリソース、標準、方法、コストを理解する。 * プロジェクト成果物とその主なコンポーネントの成果物ブレークダウン・ストラクチャー、これらの成果物記述書、成果物流れ図を作成し、これらをすべてプロジェクト計画書に含める。 * プロジェクト成果物を運用へと移行する際の取り決めを特定する(プロジェクト成果物を運用することで、保守が必要となる可能性がある場合、支援グループとユーザー間で、適切なサービス合意を作成する。その場合、プロジェクト計画書に成果物としての契約を含める必要がある)。 * プロジェクト成果物記述書を更新する必要があるかどうかを検討する(例えば、プロジェクトの立ち上げを実施中に、受け入れ基準の理解が変更されたり、詳細化されたりした場合)。 * 計画により提供される各成果物について、プロジェクト・ログの成果物登録簿のレコードを作成または更新する。 * 必要な人員とリソースを特定および確認する。 * 人員の可用性、役割の受け入れ、役割実行へのコミットメントを確認する。 * プロジェクト・コントロールの活動、リソース、人員、時期を特定し、それらを計画書に記載する。 * プロジェクト計画書の対象者と計画書の使用法を考慮して、プロジェクト計画書の書式とプレゼンテーションについて文書化して決定する(例えば、プロジェクト委員会に計画を提示するのに成果物チェックリストを使用するだけで十分な場合もある)。 * プロジェクト保証と協議して、提案されたプロジェクト計画書がプロジェクト委員会またはビジネスのニーズに応えていることを確認する。 * 新たなリスクや課題が特定された(または既存のリスクに変化が生じた)場合は、プロジェクト・ログを更新する。 * プロジェクト計画書について、プロジェクト委員会に承認を求める(ただしプロジェクト委員会は、プロジェクト立ち上げ文書の一部として後でレビューすることを望む場合もある)。</p> <h4>完全なビジネス・ケースの準備<a href="#完全なビジネスケースの準備"><span></span></a></h4> <p>プロジェクトの始動で作成されたビジネス・ケース概要は、プロジェクト計画書で定められた見積もり時間とコスト、および更新されたプロジェクト・ログの集約されたリスクを反映して更新する必要があります。 完全なビジネス・ケースの準備は、プロジェクト・マネージャーが単独で実行する活動ではなく、ビジネス・ケースを共創するためにプロジェクト・エグゼクティブと緊密に関係しながら実施されるべきものです。完全なビジネス・ケースはプロジェクト委員会によるプロジェクトの認可に使用され、プロジェクトが引き続き実行可能であることを継続的に確認するための根拠となります</p> <p>プロジェクト・マネージャーに推奨される処置 * プロジェクト要約書をレビューし、ビジネス・ケースの書式や内容に関するビジネス要件があるかどうかを確認する。 * 過去の類似のプロジェクト、ビジネス、外部組織から、ビジネス・ケース開発に関連する教訓を集める(これらの中にはプロジェクト・ログにすでに盛り込まれているものもある)。 * 詳細情報を追加した詳細なビジネス・ケースを作成する。 * 新たなリスクや課題が特定された(または既存のリスクに変化が生じた)場合は、プロジェクト・ログを更新する。 * プロジェクト保証と協議して、提案されたビジネス・ケースがプロジェクト委員会またはビジネスのニーズに応えていることを確認する。 * ビジネス・ケースについて、プロジェクト委員会に承認を求める(ただしプロジェクト委員会は、プロジェクト立ち上げ文書の一部として後でレビューすることを望む場合もある)。</p> <h4>プロジェクト立ち上げ文書のとりまとめ<a href="#プロジェクト立ち上げ文書のとりまとめ"><span></span></a></h4> <p>プロジェクトの「何を、なぜ、誰が、どのように、どこで、いつ、どのぐらい」に関係するすべての情報については、以下の点に注意する必要があります。 * 収集した情報については主要な利害関係者が合意する。 * プロジェクトの関係者にとってのガイダンスや情報として利用できる。 この情報はプロジェクト立ち上げ文書に集約されます。プロジェクト立ち上げ文書は立ち上げ中に作成または更新される多くのマネジメント成果物を集約したもので、プロジェクト続行の認可を得るのに使用されます。(プロジェクト立ち上げ文書は必ずしも単一の文書ではなく、文書やその他の形式の情報(業務工程表やプロジェクト・マネジメント・ツールのコンテンツなど)を集めたものです。) プロジェクトの立ち上げプロセス中に作成され、プロジェクト実施の認可を得るために使用されたプロジェクト立ち上げ文書のバージョンは、ベースライン化して変更コントロールの対象とする必要がありますこれは、承認の基となった当初の予測とプロジェクトの実際のパフォーマンスを比較するために、後で使用されます。</p> <p>プロジェクト・マネージャーに推奨される処置 * プロジェクト要約書から情報を抽出し、必要に応じて修正する。 * 以下の情報を含めるか、参照する。 * プロジェクトのマネジメント・チーム組織構造および役割記述書 * ビジネス・ケース * マネジメント・アプローチ * プロジェクト計画書 * プロジェクト・コントロールを含めるか参照し、プロジェクトでどのようにテーラリングしたかを要約する。 * プロジェクト立ち上げ文書をとりまとめる。 * さまざまな要素にある情報の照合確認を実施し、情報に互換性のあるようにする。 * プロジェクト保証と協議して、まとめられたプロジェクト立ち上げ文書がプロジェクト委員会またはビジネスのニーズに応えていることを確認する。 * 次のステージに備える(このステージによってステージ境界のマネジメント・プロセスがトリガーされる)。</p> <h4>プロジェクト認可の要求<a href="#プロジェクト認可の要求"><span></span></a></h4> <p>プロジェクトの立ち上げプロセス、つまり立ち上げステージを終了するために、プロジェクト・マネージャーはプロジェクト委員会に連絡してプロジェクト認可を要求します。正式な正当性は、ビジネス・ケースとプロジェクト立ち上げ文書に記載されています。</p> <p>プロジェクト・マネージャーに推奨される処置 * ビジネス・ケースの最終バージョン、プロジェクト立ち上げ文書、プロジェクト計画書をプロジェクト委員会と共有する。 * 必要な人員とリソースを確保するために、プロジェクトを提供する権限をプロジェクト委員会に正式に要求する。</p> <h3>適用<a href="#適用"><span></span></a></h3> <h4>一般的な考慮事項<a href="#一般的な考慮事項"><span></span></a></h4> <p>このプロセスの活動はプロジェクトの都合に応じて結合、分割、または同時に実行できます。</p> <p>(このプロセスで作成されるマネジメント成果物の数は膨大になる場合があり、さらに、必ずしも必要ではない詳細レベルになることもあります。このプロセスはプロジェクトの基盤であり、この時点でプロジェクトに応じたテーラリングが主に決定されます。) テーラリングはプロジェクトの事情に合わせるために必要ですが、立ち上げの開始時点では、関連する要因が明らかではない場合もあります。プロジェクトのこのような初期ステージでは、十分な情報がない場合もあります。テーラリングのニーズは、立ち上げ作業が進むにつれて明らかになります。(そのため、仮説的な主要プロジェクトに適したマネジメント環境を作成するよりも、シンプルに開始し、必要に応じて詳細化することをお勧めします。) (一部のプロジェクトは複雑すぎて、このプロセスが終了するまでに、合意済みのプロジェクトのアウトプット(ひいてはプロジェクトの最終成果物)を完全に定義できません。このような場合は一般的に、プロジェクト・ライフサイクルに、選択肢を検討して解決策を選択するための調査ステージが複数含まれています。その場合、プロジェクトの立ち上げプロセスは、マネジメントおよびコントロール環境を確立するために第 1 ステージの開始時のみに使用されます。)</p> <h4>役割のテーラリング<a href="#役割のテーラリング"><span></span></a></h4> <p>マネジメント成果物の作成はプロジェクト・マネージャーに実行責任があるものとして示します。プロジェクト支援が一部の補助的な成果物を担当する場合がありますが、いずれの場合もプロジェクト・マネージャーが、プロジェクトの実行方法についてプロジェクト・エグゼクティブに対し実行責任を負います。したがって、プロジェクト・マネージャーはタスクに適した人にさまざまな役割をアサインできます。多くの場合、より概要でのプログラム・オフィスや同様のセットアップが支援を提供できます。</p> <h3>責任<a href="#責任"><span></span></a></h3> <table><thead><tr><th>活動</th><th>ビジネス・レイヤー</th><th>プロジェクト・エグゼクティブ</th><th>シニア・ユーザー</th><th>シニア・サプライヤー</th><th>プロジェクト・マネージャー</th><th>チーム・マネージャー</th><th>プロジェクト保証</th><th>プロジェクト支援</th></tr></thead><tbody><tr><td>テーラリング要件への合意</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>I</td></tr><tr><td>マネジメント・アプローチへの合意</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>I</td></tr><tr><td>プロジェクト・コントロールの確立</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>I</td></tr><tr><td>プロジェクト計画書の準備</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>C</td></tr><tr><td>完全なビジネス・ケースの準備</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C</td><td>C</td><td>I</td></tr><tr><td>プロジェクト立ち上げ文書のとりまとめ</td><td></td><td>C</td><td>C</td><td>C</td><td>A</td><td>C</td><td>C</td><td>R</td></tr><tr><td>プロジェクト認可の要求</td><td>I</td><td>A</td><td>C</td><td>C</td><td>R</td><td>I</td><td>C</td><td>I</td></tr></tbody></table> <p>R = 実行責任、A = 説明責任、C = 協議先、I = 情報先</p> <h3>プロセスへのプラクティスの適用<a href="#プロセスへのプラクティスの適用"><span></span></a></h3> <table><thead><tr><th>プラクティス</th><th>プロジェクトの立ち上げプロセスへの適用</th></tr></thead><tbody><tr><td>ビジネス・ケース</td><td>プロジェクト要約書のビジネス・ケース概要は、プロジェクトと提案されたオプションに対するより深い理解に基づいて、プロジェクト委員会による承認の準備ができている完全なビジネス・ケースへとさらに発展させます。ベネフィット・マネジメント・アプローチと持続可能性マネジメント・アプローチはビジネス・ケースを支援し、コントロールを確立するためのインプットを提供するために作成されます</td></tr><tr><td>組織化</td><td>プロジェクト・マネジメント・チーム組織は、あるレイヤーから次のレイヤーに委任された権限のレベルの詳細で更新され、残りのプロジェクト・マネジメント・チームの任命とオンボーディングが行われます。ワーク・ブレークダウン・ストラクチャーは、プロジェクト計画書に基づいて考慮され、チームへの作業編成に関する情報を提供し、どの要素が外部から供給されるかを判断します。コミュニケーション・マネジメント・アプローチ、変更マネジメント・アプローチ、商業マネジメント・アプローチが作成され、プロジェクト・コントロールを確立するためのインプットを提供します</td></tr><tr><td>計画</td><td>プロジェクト成果物記述書は、プロジェクト計画書の作成に使用される成果物ブレークダウン・ストラクチャーと成果物流れ図を作成するために使用されます。プロジェクト計画書は、プロジェクトに必要なステージを定義します</td></tr><tr><td>品質</td><td>成果物登録簿が作成されます。成果物記述書が作成され、必要に応じてプロジェクト成果物記述書が更新されます。成果物記述書の品質仕様は、コントロールを確立するためのインプットを提供する品質マネジメント・アプローチの作成に役立ちます。品質登録簿が作成されます</td></tr><tr><td>リスク</td><td>リスク・マネジメント・アプローチは、プロジェクト・コントロールを確立するためのインプットを提供するために作成されます。リスク登録簿はカテゴリーに基づいて作成され、格付けシステムはリスク・マネジメント・アプローチで定義されます。ビジネス・ケース、プロジェクト計画書などで特定されたリスクは、リスク登録簿に記録され、評価されます。リスク予算が考慮され、必要に応じて作成されます</td></tr><tr><td>課題</td><td>課題マネジメント・アプローチは、変更コントロールと課題マネジメントのプロジェクト・コントロールを確立するインプットを提供するために作成されます。課題登録簿はカテゴリーに基づいて作成され、格付けシステムは課題マネジメント・アプローチで定義されます。ビジネス・ケース、プロジェクト計画書などで特定された課題は、課題登録簿に記録され、評価されます。変更予算が考慮され、必要に応じて作成されます</td></tr><tr><td>進捗</td><td>デジタルおよびデータ・マネジメント・アプローチは、プロジェクト・コントロールを確立するためのインプットを提供するために作成されます。<br />すべてのマネジメント・アプローチのプロジェクト・コントロールが確立され、進捗マネジメントの基盤が提供されます。<br />ハイライト報告書は、立ち上げステージの進捗を示すために使用されます</td></tr></tbody></table>category:项目管理tag:プロジェクトtag:マネジメントtag:プロセスtag:プロジェクトの立ち上げhttps://blog.issyuu.com/zh/post/pm-processes-directing-dzh:pm-processes-directing-d生きている限り、学び続けるFri, 17 Apr 2026 04:12:12 GMT<h2>プロジェクトの指揮<a href="#プロジェクトの指揮"><span></span></a></h2> <blockquote> <p>プロジェクトの指揮プロセスの目的は、<strong>プロジェクト委員会</strong>が全体的なコントロールと主要な意思決定を行い、プロジェクトの成功に対する<strong>説明責任</strong>を果たす。一方で、日々のマネジメント業務はPMに委任される。</p> </blockquote> <h3>達成目標<a href="#達成目標"><span></span></a></h3> <blockquote> <p>以下の点を確認・確立することを目指す。</p> </blockquote> <ul> <li><strong>認可の実施(前)</strong>: プロジェクトの<strong>立ち上げ</strong>、<strong>成果物の提供</strong>、<strong>クローズ</strong>を適切なタイミングで認可する。</li> <li><strong>ガバナンスの維持(中)</strong>: ライフサイクル全体で適切な指揮とコントロールを行う。</li> <li><strong>正当性の確認(中)</strong>: プロジェクトが継続して実行可能を保証する。</li> <li><strong>戦略的整合(中)</strong>: ビジネス・レイヤーとの関連性を維持する。</li> <li><strong>価値の実現(後)</strong>: 終了後のベネフィット実現計画が適切に管理・レビューされていることを確認する。</li> </ul> <h3>位置付け<a href="#位置付け"><span></span></a></h3> <h4>トリガー<a href="#トリガー"><span></span></a></h4> <blockquote> <p><strong>プロジェクトの始動</strong>プロセスが完了し、PMから<strong>プロジェクト立ち上げ要求</strong>が出された時点で開始される。</p> </blockquote> <h4>実施のポイント<a href="#実施のポイント"><span></span></a></h4> <ul> <li>運用 <ul> <li><strong>例外によるマネジメント</strong>: プロジェクト委員会は日々の活動には関与せず、<strong>報告書を通じたモニタリングと重要な意思決定</strong>に専念する。これにより、委員会メンバーが過度な業務負担を負うことなく、効果的なガバナンスを維持できる仕組みとなっている。</li> <li><strong>権限の委任</strong>: PMやチーム・マネージャーに適切な権限を与え、意思決定プロセスを明確に定義することが重要である。</li> </ul> </li> <li>主要な役割 委員会は<strong>プロジェクト</strong>と**ビジネス・レイヤー(組織の戦略層)**をつなぐ架け橋として機能する。 <ul> <li><strong>外部との連携</strong>: ビジネス・レイヤーの戦略とプロジェクトを整合させ、コミュニケーション・チャネルとしての役割を担う。</li> <li><strong>統一された指揮</strong>: PMに対して矛盾のない、一貫したガイダンスを提供する。 ※委員会内で意見が分かれた場合は、<strong>プロジェクト・エグゼクティブ</strong>が最終決定を下す。一貫性のない指示は、プロジェクトを停滞させる大きなリスクとなる。 ＊このプロセスはあくまで<strong>プロジェクト委員会の活動</strong>に焦点を当てたものであり、PMの実務を細かく管理(マイクロマネジメント)するためのものではない。PMに適切な権限を与え、自律的なチーム運営を促すことが、プロジェクト成功の鍵となる。</li> </ul> </li> <li>助言とガイダンス 公式な決定(指揮)だけでなく、非公式なサポートも重要である。 <ul> <li><strong>双方向のやり取り</strong>: <ul> <li>委員会からPMへ: プロジェクト外の状況変化を伝え、非公式な助言を与える。</li> <li>PMから委員会へ: 必要に応じて専門的な知見や助言を求める。</li> </ul> </li> </ul> </li> </ul> <h3>活動<a href="#活動"><span></span></a></h3> <table><thead><tr><th>インプット</th><th>活動</th><th>アウトプット</th></tr></thead><tbody><tr><td>プロジェクト立ち上げの要求(このプロセスをトリガー)<br />ビジネス・ケース概要(レビュー)<br />プロジェクト要約書(レビュー)<br />プロジェクト成果物記述書(レビュー)<br />ステージ計画書(立ち上げ用)(レビュー)</td><td>立ち上げの認可</td><td>ビジネス・ケース概要(承認済み)<br />プロジェクト要約書(承認済み)<br />プロジェクト成果物記述書(承認済み)<br />ステージ計画書(立ち上げ用)(承認済み)<br />立ち上げ通知<br />プロジェクト立ち上げの認可(プロジェクトの立ち上げプロセスをトリガー)</td></tr><tr><td>プロジェクト認可の要求(このプロセスをトリガー)<br />プロジェクト立ち上げ文書(レビュー)<br />ビジネス・ケース(レビュー)</td><td>プロジェクトの認可</td><td>プロジェクト立ち上げ文書(承認済み)<br />ビジネス・ケース(承認済み)<br />プロジェクト認可の通知</td></tr><tr><td>次のステージの要求(このプロセスをトリガー)<br />例外計画書の承認の要求(プロセスをトリガー)<br />ステージ終了報告書(レビュー)<br />ステージ計画書(次のステージ用)(レビュー)<br />プロジェクト計画書(確認)<br />ビジネス・ケース(確認)</td><td>ステージまたは例外計画書の認可</td><td>ステージ終了報告書(承認済み)<br />ステージ計画書(次のステージ用)(承認済み)<br />プロジェクト計画書(必要に応じて更新)(承認済み)<br />ビジネス・ケース(必要に応じて更新)(承認済み)<br />認可されたステージまたは例外(ステージのコントロール・プロセスをトリガー)<br />プロジェクト立ち上げ文書(必要に応じて更新)(承認済み)</td></tr><tr><td>助言の要求(このプロセスをトリガー)<br />例外の提起(このプロセスをトリガー)<br />教訓報告書(レビュー)<br />ハイライト報告書(レビュー)<br />課題報告書(レビュー)<br />例外報告書(レビュー)<br />ビジネス・ケース(確認)</td><td>継続的な指揮</td><td>例外計画書の要求(ステージ境界のマネジメント・プロセスをトリガー)<br />プロジェクト委員会の助言と決定(ステージのコントロール・プロセスをトリガー)<br />早期クローズの通知(ステージのクローズ・プロセスをトリガー)</td></tr><tr><td>プロジェクトのクローズの要求(このプロセスをトリガー)<br />プロジェクト終了報告書(レビュー)<br />ビジネス・ケース(確認)</td><td>プロジェクトのクローズの認可</td><td>プロジェクトのクローズの通知</td></tr></tbody></table> <h4>立ち上げの認可<a href="#立ち上げの認可"><span></span></a></h4> <blockquote> <p>プロジェクトの立ち上げ(Initiation)には相応の時間、コスト、リソースの投資が必要となる。</p> </blockquote> <p>＊この活動の目的は、プロジェクト委員会がその投資に価値があるかを厳密に判断し、正式なゴーサインを出す。</p> <ol> <li>意思決定のプロセス <strong>プロジェクトの始動</strong>プロセスの最終ステップとして、プロジェクト・マネージャー(PM)から立ち上げ要求を受けた際に行われる。 <ul> <li><strong>形式</strong>: <strong>公式な会議</strong>を開く場合もあれば、<strong>持ち回り</strong>での承認となる場合もある。</li> <li><strong>必須条件</strong>: <ul> <li>委員会の全メンバーが決定に合意していること。</li> <li>プロジェクト・エグゼクティブからPMに対し、<strong>文書による立ち上げ指示</strong>が出されていること。</li> </ul> </li> <li><strong>プロジェクト保証の活用</strong>: 委員会のメンバーが多忙な場合、立ち上げステージ計画書の妥当性確認を<strong>プロジェクト保証</strong>(個人またはグループ)に委任することができる。ただし、最終的な<strong>説明責任</strong>が負う。</li> </ul> </li> <li>プロジェクト委員会に推奨される処置 委員会は、立ち上げを認可するにあたり、以下のチェックとアクションを実行する。 <ul> <li><strong>整合性と妥当性の確認</strong> <ul> <li>プロジェクト・アプローチが組織(ビジネス)の方針と一致しているか。</li> <li>ビジネス・ケース概要が実行可能であり、戦略的な目標に貢献するか。</li> </ul> </li> <li><strong>主要文書の承認</strong> <ul> <li><strong>プロジェクト要約書</strong>および<strong>プロジェクト成果物記述書</strong>をレビューし、承認する。</li> </ul> </li> <li><strong>計画とリソースの確定</strong> <ul> <li>立ち上げステージのための<strong>ステージ計画書</strong>を承認し、ステージに対する<strong>許容度(トレランス)</strong> を設定する。</li> <li>必要な人員、設備(通信設備、備品)、プロジェクト支援などのロジスティック面の確保を指示する。</li> </ul> </li> <li><strong>通知と認可</strong> <ul> <li>利害関係者や関連部門に対し、プロジェクトが立ち上げステージに入ったことを公式に通知する。</li> <li>PMに対し、立ち上げステージの開始を正式に認可する。</li> </ul> </li> </ul> </li> </ol> <h4>プロジェクトの認可<a href="#プロジェクトの認可"><span></span></a></h4> <blockquote> <p>立ち上げステージの最後に、PMから<strong>プロジェクト実行の認可要求</strong>を受けることで開始される。</p> </blockquote> <ol> <li>目的と達成目標 プロジェクト委員会は資金やリソースを投入する前に、以下のことが確保されているかを厳格に判断する。 <ul> <li><strong>ビジネス正当性</strong>: 堅固なビジネス・ケースが存在し、プロジェクトが実行可能でかつ有益であるか。</li> <li><strong>実現可能性</strong>: プロジェクト計画書とベネフィット・マネジメント・アプローチが、期待される価値を確実に提供できるか。</li> <li><strong>管理体制</strong>: マネジメント・アプローチ(品質、リスク、課題など)とコントロールが、計画の達成を適切に支援できるか。 ＊プロジェクト委員会がプロジェクトを認可しなかった(正当性がないと判断した)場合、プロジェクトはその時点で<strong>早期クローズ</strong>しなければならない。</li> </ul> </li> <li>プロジェクト保証の活用 委員会は、詳細なレビュー(例: コミュニケーション・マネジメント・アプローチが適切か等の検査)を<strong>プロジェクト保証</strong>(個人またはグループ)に委任することができる。ただし、最終的な<strong>説明責任</strong>が負う。</li> <li>プロジェクト委員会に推奨される処置 認可を下す際、委員会は以下の具体的なアクションを実行する。 <ul> <li><strong>文書と基準の承認</strong> <ul> <li><strong>プロジェクト立ち上げ文書(PID)</strong> をレビューし、承認する。</li> <li>プロジェクト全体の<strong>許容度(トレランス)</strong> を確認し、合意する。</li> </ul> </li> <li><strong>妥当性のチェック</strong> <ul> <li>過去の類似プロジェクトからの教訓が計画に反映されているかを確認する。</li> <li>レビューが実施済みであるリスク(脅威と機会)に対する対応策が適切に計画されているかを確認する。</li> </ul> </li> <li><strong>リソースの確保と通知</strong> <ul> <li>プロジェクト完遂に必要な人員とリソースを確保、または提供を約束(コミット)する(これらは、各ステージの承認ごとに順次 PMへ提供される)。</li> <li>プロジェクトが認可されたことをビジネスや利害関係者に公式に通知する。</li> </ul> </li> <li><strong>最終指示</strong> <ul> <li>PMに対し、プロジェクトの実行を認可する。または、不認可の場合は早期クローズを指示する。</li> </ul> </li> </ul> </li> </ol> <h4>継続的な指揮<a href="#継続的な指揮"><span></span></a></h4> <blockquote> <p>プロジェクト委員会は、認可のタイミングだけでなく、プロジェクトの全期間を通じて、PMを支援し、進捗をコントロールする。</p> </blockquote> <ol> <li>指導とガイダンスの提供 プロジェクト委員会のメンバーは、PMからの助言要求に対し、随時(特に立ち上げ時やステージ境界付近で)非公式なガイダンスや助言を提供する。 <ul> <li><strong>継続的な指揮がトリガーされる主な場面</strong>: <ul> <li><strong>一般的な助言</strong>: ビジネスの持続可能性目標(ESG 要件など)の明確化。</li> <li><strong>要求対応</strong>: 対立の解消や、複雑な選択肢の絞り込み。</li> <li><strong>報告書対応</strong>: ハイライト報告書、例外報告書、課題報告書の受領。</li> <li><strong>外部変化</strong>: ビジネス優先度の変更や、外部要因によるプロジェクトへの影響。</li> <li><strong>懸念事項</strong>: プロジェクト委員会メンバーの個別の懸念事項。</li> <li><strong>体制変更</strong>: 委員会の構成員の変更。</li> </ul> </li> </ul> </li> <li>例外と変更への対応 ステージ内で許容度を超える事態(例外)が発生した場合、委員会は以下の原則に従って意思決定を行う。 <ul> <li><strong>例外計画の認可</strong>: ステージの許容度を超える例外が発生した場合、委員会は<strong>例外計画書</strong>を審査し、承認する。承認された計画は新たなベースラインとなる。 ※ワーク・パッケージ(WP)レベルの例外はPMが処理し、プロジェクトレベルの例外はビジネスの承認が必要となる。</li> <li><strong>プロジェクト権限委任の変更</strong>: ビジネス側から方針変更やクローズの指示があった場合、委員会は以下のいずれかを選択する。 <ol> <li><strong>変更要求として扱う</strong>: PMにステージまたはプロジェクトの再計画を求める。</li> <li><strong>早期クローズと再開始</strong>: 現在のプロジェクトを停止し、新しい権限委任に基づいてゼロから開始する(追加コストがかかる可能性がある)。</li> </ol> </li> </ul> </li> <li>プロジェクト保証の委任 委員会は、変更要求のインパクト評価が適切かどうかの検査など、実務的な評価措置を<strong>プロジェクト保証</strong>(個人またはグループ)に委任することができる。ただし、最終的な<strong>説明責任</strong>が負う。</li> <li>プロジェクト委員会に推奨される処置 委員会は、PMを適切にコントロールするために以下の実務を行う。 <ul> <li><strong>助言と支援</strong>: PMからの非公式な要求に対し、必要なリサーチや助言を行い支援する。</li> <li><strong>エスカレーション対応</strong>: <ul> <li><strong>課題</strong>: 意思決定を下す。仕様外項目の場合、<strong>拒否(修正要求)</strong> または<strong>条件付き承認(現状受け入れ)</strong> を判断する。</li> <li><strong>例外報告書</strong>: 内容を精査し、続行の可否を決定する。</li> </ul> </li> <li><strong>進捗の監視</strong>: ハイライト報告書を確認し、必要に応じて是正措置を講じる。</li> <li><strong>情報の伝達</strong>: ビジネスからの決定や方針変更を速やかにPMに通知する。</li> </ul> </li> </ol> <h4>ステージまたは例外計画書の認可<a href="#ステージまたは例外計画書の認可"><span></span></a></h4> <blockquote> <p>プロジェクト委員会による正式な承認なしに、次のステージを開始してはならない。この活動により、現在の実績を確認し、次の活動への投資を正当化する。</p> </blockquote> <ol> <li>認可の基本原則 * <strong>全ステージでの必須プロセス</strong>: すべてのステージを開始する前に、必ずこの承認プロセスを経る。<strong>なんとなく次の作業に入る</strong>といった曖昧な進行を排除するためである。 * <strong>レビューの焦点</strong>: 現在のステージのパフォーマンス(実績)を確認した上で、次のステージ計画書(または立て直しのための例外計画書)が妥当であるかを判断する。</li> <li>プロジェクト保証の委任 委員会は、計画書の詳細な検査(実行可能性の確認など)を<strong>プロジェクト保証</strong>(個人またはグループ)に委任することができる。ただし、最終的な<strong>説明責任</strong>が負う。</li> <li>プロジェクト委員会に推奨される処置 委員会は、以下のステップを通じてガバナンスを効かせ、次のステップへのゴーサインを出す。 <ul> <li><strong>実績の評価</strong>: <strong>ステージ終了報告書</strong>をレビューし、承認する。</li> <li><strong>計画の審査</strong>: PMが承認を求めている<strong>ステージ計画書</strong>または<strong>例外計画書</strong>を精査する。</li> <li><strong>意思決定の実行</strong>: 委員会の判断は、状況に応じて以下の3つのいずれかとなる。 <ol> <li>計画を<strong>承認</strong>し、次へ進める。</li> <li>計画を却下し、PMに<strong>再考・修正</strong>を依頼する。</li> <li>プロジェクトの正当性が失われたと判断し、<strong>早期クローズ</strong>を指示する。</li> </ol> </li> <li><strong>ステータスの伝達</strong>: コミュニケーション・マネジメント・アプローチに基づき、プロジェクトの最新の進捗状況をビジネスや利害関係者にを通知する。</li> </ul> </li> </ol> <h4>プロジェクトのクローズの認可<a href="#プロジェクトのクローズの認可"><span></span></a></h4> <blockquote> <p>プロジェクトを制御された状態で終了させることは、開始時と同等に重要である。プロジェクト委員会は、当初の計画(PID)と最終的な実績を比較評価し、プロジェクトがその役割を全うしたことを確認する。</p> </blockquote> <ol> <li>目的と重要性 プロジェクト委員会は、解散前の最後の活動として、当初の計画(ベースライン)と実績を比較評価する。 <ul> <li><strong>達成度の評価</strong>: 当初の<strong>プロジェクト立ち上げ文書(PID)<strong>や</strong>プロジェクト計画書</strong>に掲げた目標が達成されたかを確認する。</li> <li><strong>逸脱の把握</strong>: 計画からどの程度の乖離が生じたか、またはこれ以上プロジェクトを継続しても追加の貢献が見込めない状態(＝完了)であるかを判断する。</li> </ul> </li> <li>クローズが不適切な場合のリスク コントロールされた方法でクローズが行われない場合、以下のリスクが生じる。 <ul> <li>運用側への移管が不完全になり、ベネフィットが実現されない。</li> <li>プロジェクトチームが解放されず、次の業務に支障をきたす。</li> <li>プロジェクトの最終的な成否や逸脱の度合いが曖昧になる。</li> </ul> </li> <li>プロジェクト委員会に推奨される処置 委員会は、責任を持ってプロジェクトを終了させるために以下の実務を行う。 <ul> <li><strong>達成状況の評価</strong> <ul> <li><strong>プロジェクト立ち上げ文書(PID)</strong> の初期版と最終版を比較し、目標の達成度や計画からの逸脱を評価する。</li> <li><strong>プロジェクト終了報告書</strong>をレビューし、承認する。</li> </ul> </li> <li><strong>ベネフィット管理の移管</strong> <ul> <li>更新された<strong>ベネフィット・マネジメント・アプローチ</strong>を承認する。</li> <li>プロジェクト終了後にしか確認できないベネフィットの評価責任を、ビジネス(運用側)へ正式に移管する。</li> <li>運用時の成果物のパフォーマンスや、予期せぬ副作用(有益・有害双方)を特定できる体制を確認する。</li> </ul> </li> <li><strong>ビジネス・ケースの最終確認</strong> <ul> <li>実績値(コスト、リスク、期間)をビジネス・ケース概要と比較し、最終的な正当性を評価する。</li> </ul> </li> <li><strong>通知とリソースの解放</strong> <ul> <li>コミュニケーション・マネジメント・アプローチに従い、関係各所へクローズを正式通知する。</li> <li>支援インフラやリソースの撤去・返却を指示し、コスト計算を止めるための<strong>終了日</strong>を明記する。</li> <li>チームメンバーの<strong>オフボーディング(解任手続き)</strong> が正しく行われていることを確認する。</li> </ul> </li> </ul> </li> </ol> <h3>適用<a href="#適用"><span></span></a></h3> <blockquote> <p>このプロセスを実務に適用する際は、最も重要なのは<strong>指揮</strong>と<strong>管理</strong>の境界線を明確にすることである。</p> </blockquote> <ol> <li>プロジェクト・エグゼクティブの責務 プロジェクトの指揮におけるすべての活動は、最終的に<strong>プロジェクト・エグゼクティブ</strong>が責任(実行責任および説明責任)を負う。 <ul> <li><strong>作業の委任</strong>: プロジェクト・エグゼクティブは、プロセス内の実務的な作業を他の担当者に任せることができる。</li> <li><strong>意思決定の保持</strong>: 作業を委任したとしても、主要な決定や認可を行う権限はエグゼクティブ自身に留まる。</li> </ul> </li> <li>実務上のポイント <ul> <li><strong>自律性とガバナンスの両立</strong>: PMには日々の管理権限が委任されるが、それはあくまで<strong>合意された許容度の範囲内</strong>である。その範囲を超える、またはプロジェクトの前提に関わる判断は、必ずプロジェクト・エグゼクティブ(およびプロジェクト委員会)が担う。 ＊PMは、プロジェクト・エグゼクティブの責任範囲にある事項(プロジェクトの認可、資金の最終承認、戦略的判断など)について、自ら決定を下したり、承認したり、指揮を執ったりすることはできない。</li> <li><strong>一貫した指揮</strong>: 役割を分離することで、PMは<strong>実行</strong>に集中し、エグゼクティブは<strong>ビジネス上の正当性の維持</strong>に集中する。</li> </ul> </li> </ol> <h3>責任<a href="#責任"><span></span></a></h3> <table><thead><tr><th>活动</th><th>ビジネス・レイヤー</th><th>プロジェクト・エグゼクティブ</th><th>シニア・ユーザー</th><th>シニア・サプライヤー</th><th>プロジェクト・マネージャー</th><th>チーム・マネージャー</th><th>プロジェクト保証</th><th>プロジェクト支援</th></tr></thead><tbody><tr><td><strong>立ち上げの認可</strong></td><td>I</td><td>A/R</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td><strong>プロジェクトの認可</strong></td><td>I</td><td>A/R</td><td>C</td><td>C</td><td>I</td><td>I</td><td>C</td><td>I</td></tr><tr><td><strong>継続的な指揮</strong></td><td>C</td><td>A/R¹</td><td>R²</td><td>R³</td><td>C/I</td><td>I</td><td>C</td><td>I</td></tr><tr><td><strong>ステージまたは例外計画書の認可</strong></td><td>I</td><td>A/R</td><td>C</td><td>C</td><td>I</td><td>I</td><td>C</td><td>I</td></tr><tr><td><strong>プロジェクトのクローズの認可</strong></td><td>I</td><td>A/R</td><td>C</td><td>C</td><td>I</td><td>I</td><td>C</td><td>I</td></tr></tbody></table> <p>R = 実行責任、A = 説明責任、C = 協議先、I = 情報先</p> <ul> <li><strong>R¹</strong>: ビジネス関連</li> <li><strong>R²</strong>: ユーザー関連</li> <li><strong>R³</strong>: サプライヤー関連</li> </ul> <h3>プロセスへのプラクティスの適用<a href="#プロセスへのプラクティスの適用"><span></span></a></h3> <table><thead><tr><th>プラクティス</th><th>プロジェクトの指揮プロセスへの適用内容</th></tr></thead><tbody><tr><td><strong>ビジネス・ケース</strong></td><td>戦略との整合性、実行可能性を確認し、ビジネス・ケースの各バージョンを承認する。ベネフィットおよび持続可能性の許容度をビジネス側と合意し、ステージごとの許容度を設定する</td></tr><tr><td><strong>組織化</strong></td><td>三つの利益(ビジネス・ユーザー・サプライヤー)を代表する適切な権限者が委員会を構成。PMチーム組織、各マネジメント・アプローチ(商務・コミュニケーション・変更)、デリバリー・モデルを承認する</td></tr><tr><td><strong>計画</strong></td><td>計画や手法が戦略や主要マイルストーンと整合しているかレビューする。プロジェクト計画書、各ステージ/例外計画書を承認し、必要な資金・人員・リソースをコミット(確約)させる</td></tr><tr><td><strong>品質</strong></td><td>シニア・ユーザーが期待品質と受け入れ基準を定義。プロジェクト保証の実行責任を負い、各マネジメント・アプローチや成果物記述書を承認する。品質許容度を合意・設定する</td></tr><tr><td><strong>リスク</strong></td><td>立ち上げ前や各ステージ承認前に高レベルのリスクを検討。リスク・マネジメント・アプローチを承認し、全体のリスクレベルが許容範囲内であることを継続的に確認する</td></tr><tr><td><strong>課題</strong></td><td>課題マネジメント・アプローチを承認し、提起された課題にタイムリーに対応する。必要に応じて<strong>変更許可委員</strong>を委任し、変更予算の設定を決定する</td></tr><tr><td><strong>進捗</strong></td><td>デジタルおよびデータ管理アプローチを承認。時間・コスト・スコープの許容度をビジネスと合意し、ハイライト報告書や例外報告書を通じて、計画どおりの進行を監督する</td></tr></tbody></table> <p>＊プロジェクト委員会の役割は<strong>作業</strong>ではなく<strong><strong>ガードレールの設定と通過許可</strong></strong>に集約されている。</p> <ol> <li><strong>認可 (Authorize)</strong>: 計画書やアプローチが適切か判断し、GOサインを出す。</li> <li><strong>合意 (Agree)</strong>: ビジネス側(経営層)とプロジェクト・レベルの限界値(許容度)を合意する。</li> <li><strong>確約 (Commit)</strong>: 計画達成に必要なリソースを、口先だけでなく実際に確保する。</li> <li><strong>対応 (Respond)</strong>: 例外や課題が発生した際、PMが動けなくなる前に迅速に指揮を執る。</li> </ol>category:项目管理tag:プロジェクトtag:マネジメントtag:プロセスtag:プロジェクトの指揮https://blog.issyuu.com/zh/post/pm-processes-directing-szh:pm-processes-directing-s生きている限り、学び続けるFri, 17 Apr 2026 04:12:12 GMT<h2>プロジェクトの指揮<a href="#プロジェクトの指揮"><span></span></a></h2> <blockquote> <p>プロジェクトの指揮プロセスの目的は、プロジェクト委員会が<strong>主要な決定</strong>と<strong>全体的なコントロール</strong>を行う一方、日々のマネジメントをPMに委任し、プロジェクトの成功に対する説明責任を果たす。</p> </blockquote> <h3>基本コンセプト<a href="#基本コンセプト"><span></span></a></h3> <ul> <li><strong>目的</strong>: 委員会の過度な負担を避けつつ、ビジネス正当性の継続を確保する。</li> <li><strong>特徴</strong>: <strong>例外によるマネジメント</strong>(許容度を超えない限りPMに任せる)。</li> <li><strong>位置づけ</strong>: プロジェクトの始動プロセスの完了(立ち上げ要求)から、クローズ認可まで継続。</li> <li><strong>意思決定の統一</strong>: 委員会はPMに対し、矛盾のない統一された指揮・ガイダンスを提供する。</li> </ul> <h3>主要な活動<a href="#主要な活動"><span></span></a></h3> <table><thead><tr><th>活動内容</th><th>概要</th><th>決定のタイミング</th></tr></thead><tbody><tr><td><strong>立ち上げの認可</strong></td><td>始動プロセスの結果をレビューし、立ち上げステージ(詳細計画)への投資価値を判断</td><td>始動プロセスの終了時</td></tr><tr><td><strong>プロジェクトの認可</strong></td><td>プロジェクト立ち上げ文書(PID)をレビューし、実行フェーズへの移行を認可</td><td>立ち上げステージの終了時</td></tr><tr><td><strong>ステージ/例外計画の認可</strong></td><td>現在の進捗を承認し、次ステージ(または例外計画)への進行を認可する</td><td>各ステージの境界時</td></tr><tr><td><strong>継続的な指揮</strong></td><td>随時、PMへの助言・エスカレーションされた課題への決定・ハイライト報告の確認を行う</td><td>随時(ライフサイクル全体)</td></tr><tr><td><strong>クローズの認可</strong></td><td>成果物の移管、目標達成度の評価、教訓の確認を行い、プロジェクトを正式に終了させる</td><td>最終ステージの終了時</td></tr></tbody></table> <h3>主要な判断基準<a href="#主要な判断基準"><span></span></a></h3> <ul> <li><strong>ビジネス正当性の継続</strong>: プロジェクトは今でも「やる価値」があるか？</li> <li><strong>実行可能性</strong>: 計画は現実的で達成可能か？</li> <li><strong>リスクと許容度</strong>: 全体的なリスクレベルは許容範囲内か？</li> </ul> <h3>主要な役割と責任(RACI)<a href="#主要な役割と責任raci"><span></span></a></h3> <table><thead><tr><th>活动</th><th>ビジネス・レイヤー</th><th>プロジェクト・エグゼクティブ</th><th>シニア・ユーザー</th><th>シニア・サプライヤー</th><th>プロジェクト・マネージャー</th><th>チーム・マネージャー</th><th>プロジェクト保証</th><th>プロジェクト支援</th></tr></thead><tbody><tr><td><strong>立ち上げの認可</strong></td><td>I</td><td>A/R</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td><strong>プロジェクトの認可</strong></td><td>I</td><td>A/R</td><td>C</td><td>C</td><td>I</td><td>I</td><td>C</td><td>I</td></tr><tr><td><strong>継続的な指揮</strong></td><td>C</td><td>A/R¹</td><td>R²</td><td>R³</td><td>C/I</td><td>I</td><td>C</td><td>I</td></tr><tr><td><strong>ステージまたは例外計画書の認可</strong></td><td>I</td><td>A/R</td><td>C</td><td>C</td><td>I</td><td>I</td><td>C</td><td>I</td></tr><tr><td><strong>プロジェクトのクローズの認可</strong></td><td>I</td><td>A/R</td><td>C</td><td>C</td><td>I</td><td>I</td><td>C</td><td>I</td></tr></tbody></table> <p>R = 実行責任、A = 説明責任、C = 協議先、I = 情報先</p> <ul> <li><strong>R¹</strong>: ビジネス関連</li> <li><strong>R²</strong>: ユーザー関連</li> <li><strong>R³</strong>: サプライヤー関連</li> </ul>category:项目管理tag:プロジェクトtag:マネジメントtag:プロセスtag:プロジェクトの指揮https://blog.issyuu.com/zh/post/pm-processes-directingzh:pm-processes-directing生きている限り、学び続けるFri, 17 Apr 2026 04:12:12 GMT<h2>プロジェクトの指揮<a href="#プロジェクトの指揮"><span></span></a></h2> <p>プロジェクトの指揮プロセスの目的は、プロジェクト委員会が主要な決定を行い、全体的なコントロールを行う一方、プロジェクトの日々のマネジメントをプロジェクト・マネージャーに委任し、プロジェクトの成功に対する説明責任を果たせるようにする。 プロジェクトの指揮プロセスの達成目標は、次の点を確認する。 * プロジェクトの立ち上げが認可されていること。 * プロジェクト成果物の提供が認可されていること。 * プロジェクトのライフサイクルを通して、マネジメントの指揮とコントロールが適切に行われていること。 * プロジェクトが継続して実行可能であること。 * ビジネス・レイヤーにプロジェクトとの関連性があること。 * プロジェクトのクローズが認可されていること。 * プロジェクト終了後のベネフィットを実現するための計画書がマネジメントされ、レビューされていること。</p> <p>プロジェクトの指揮のプロセスはプロジェクトの始動プロセスが完了すると始まり、プロジェクトの立ち上げ要求によってトリガーされます。</p> <p>プロジェクトの指揮プロセスでは、プロジェクト委員会の活動が対象であり、プロジェクト・マネージャーの日々の活動は対象となりません。プロジェクト委員会は例外によるマネジメントを行います。少数者による決定によって、報告書を通してモニタリングし、コントロールします。(プロジェクト・マネージャーは例外的な状況をプロジェクト委員会に通知するため、プロジェクト委員会以外の進捗会議は必要ありません。権限のレベルと意思決定プロセスを明確に定義し、プロジェクト・マネージャーとチーム・マネージャーに権限を与えることも重要です。) (プロジェクト期間中は、プロジェクト委員会とビジネス・レイヤーとの間で情報を相互にやり取りする必要があります。プロジェクト委員会は、プロジェクトが常にビジネス・レイヤーの戦略に整合していることを確かなものにする必要があります。) プロジェクト委員会の主要な役割は、ビジネス・レイヤーに関与し、コミュニケーション・チャネルとして機能することです。(プロジェクト委員会がコミュニケーション・チャネルとして機能するための要件とその方法については、コミュニケーション・マネジメント・アプローチで文書化する必要があります。) プロジェクト委員会はプロジェクト・マネージャーに対して、統一性のある指揮とガイダンスを提供します。(プロジェクト委員会が統一された意見を提供できない場合、プロジェクト・マネージャーは矛盾する要件と優先順位に基づいて行動する可能性があるため、プロジェクトに障害が発生するリスクが大幅に高まります。そのような場合は、プロジェクト・エグゼクティブが決定を下します。) プロジェクトの指揮プロセスは、プロジェクト委員会が現場でのプロジェクト・マネジメント活動による過度な負担を負うことなく、ビジネス正当性の継続の確保という責任を全うするためのメカニズムを提供します。(また、プロジェクト委員会がプロジェクト・マネージャーに細かく指示することを回避するメカニズムも提供します。) プロジェクト委員会の機能の 1 つは、プロジェクト・マネージャーに対して非公式に助言とガイダンスを提供すると同時に、公式な指揮をすることです。(これは双方向であり、プロジェクト委員会はプロジェクト外の問題についてプロジェクト・マネージャーに報告し、プロジェクト・マネージャーはプロジェクトの過程で必要に応じて助言を求めます。)</p> <h3>活動<a href="#活動"><span></span></a></h3> <table><thead><tr><th>インプット</th><th>活動</th><th>アウトプット</th></tr></thead><tbody><tr><td>プロジェクト立ち上げの要求(このプロセスをトリガー)<br />ビジネス・ケース概要(レビュー)<br />プロジェクト要約書(レビュー)<br />プロジェクト成果物記述書(レビュー)<br />ステージ計画書(立ち上げ用)(レビュー)</td><td>立ち上げの認可</td><td>ビジネス・ケース概要(承認済み)<br />プロジェクト要約書(承認済み)<br />プロジェクト成果物記述書(承認済み)<br />ステージ計画書(立ち上げ用)(承認済み)<br />立ち上げ通知<br />プロジェクト立ち上げの認可(プロジェクトの立ち上げプロセスをトリガー)</td></tr><tr><td>プロジェクト認可の要求(このプロセスをトリガー)<br />プロジェクト立ち上げ文書(レビュー)<br />ビジネス・ケース(レビュー)</td><td>プロジェクトの認可</td><td>プロジェクト立ち上げ文書(承認済み)<br />ビジネス・ケース(承認済み)<br />プロジェクト認可の通知</td></tr><tr><td>次のステージの要求(このプロセスをトリガー)<br />例外計画書の承認の要求(プロセスをトリガー)<br />ステージ終了報告書(レビュー)<br />ステージ計画書(次のステージ用)(レビュー)<br />プロジェクト計画書(確認)<br />ビジネス・ケース(確認)</td><td>ステージまたは例外計画書の認可</td><td>ステージ終了報告書(承認済み)<br />ステージ計画書(次のステージ用)(承認済み)<br />プロジェクト計画書(必要に応じて更新)(承認済み)<br />ビジネス・ケース(必要に応じて更新)(承認済み)<br />認可されたステージまたは例外(ステージのコントロール・プロセスをトリガー)<br />プロジェクト立ち上げ文書(必要に応じて更新)(承認済み)</td></tr><tr><td>助言の要求(このプロセスをトリガー)<br />例外の提起(このプロセスをトリガー)<br />教訓報告書(レビュー)<br />ハイライト報告書(レビュー)<br />課題報告書(レビュー)<br />例外報告書(レビュー)<br />ビジネス・ケース(確認)</td><td>継続的な指揮</td><td>例外計画書の要求(ステージ境界のマネジメント・プロセスをトリガー)<br />プロジェクト委員会の助言と決定(ステージのコントロール・プロセスをトリガー)<br />早期クローズの通知(ステージのクローズ・プロセスをトリガー)</td></tr><tr><td>プロジェクトのクローズの要求(このプロセスをトリガー)<br />プロジェクト終了報告書(レビュー)<br />ビジネス・ケース(確認)</td><td>プロジェクトのクローズの認可</td><td>プロジェクトのクローズの通知</td></tr></tbody></table> <h4>立ち上げの認可<a href="#立ち上げの認可"><span></span></a></h4> <p>プロジェクトの立ち上げには時間とコストがかかるため、立ち上げの活動を計画、モニタリング、コントロールすることが必要です。プロジェクト委員会による立ち上げの認可という活動によって、このような投資に価値があることを確認します。 (プロジェクト・マネージャーからプロジェクトの立ち上げ要求を受け取ると(プロジェクトの始動プロセスの後)、プロジェクト委員会はプロジェクトを立ち上げステージに進めるかどうかを決定する必要があります。)これは公式なプロジェクト委員会の会議で決定することも、公式な会議を開かずに決定することもできます。ただし、すべてのメンバーが決定に合意していることに加え、プロジェクト・マネージャーがプロジェクト・エグゼクティブから文書で立ち上げ指示を受け取ることが条件です。プロジェクト委員会は、処置のレビューと評価(実行可能性を確認するための立ち上げステージ計画書のレビューなど)を行うプロジェクト保証を個人またはグループに委任することもできます。プロジェクト保証活動が委任されている場合、プロジェクト委員会は引き続き説明責任を負います。</p> <p>プロジェクト委員会に推奨される処置 * プロジェクト・アプローチがビジネスの方針に整合していることを確認する。 * プロジェクト要約書とプロジェクト成果物記述書をレビューし、承認する。 * ビジネス・ケース概要が、ビジネス戦略に整合した実行可能なプロジェクトを示していることを確認する。 * 立ち上げステージのステージ計画書をレビューし、承認する。立ち上げステージに対する許容度を設定する。 * すべての利害関係者とインパクトを受けるサイトに対し、プロジェクトが立ち上げステージにあることを通知し、立ち上げステージに必要とされるロジスティックに関する支援(通信設備、備品、プロジェクト支援など)を要求する。 * プロジェクト・マネージャーが立ち上げステージに進めることを認可する。</p> <h4>プロジェクトの認可<a href="#プロジェクトの認可"><span></span></a></h4> <p>この活動はプロジェクト・マネージャーからのプロジェクト実行の認可要求によって開始します。(ステージ計画書または例外計画書の認可と並行して行う場合があります。)</p> <p>プロジェクトの認可の達成目標は、これ以降プロジェクトを進めてよいかどうかを決定する。プロジェクト委員会は、以下のことを確認する必要があります。 * 堅固なビジネス・ケースが存在し、実行可能なプロジェクトを示していること。 * プロジェクト計画書とベネフィット・マネジメント・アプローチは、プロジェクトがビジネス・ケースを提供できることを示していること。 * マネジメント・アプローチとコントロールが、プロジェクト計画書のデリバリーを支援していること。</p> <p>プロジェクト委員会がプロジェクトを認可しなかった場合、プロジェクトを早期にクローズする必要があります。 プロジェクト委員会は、すべての利害関係者がカバーされていることを確認するためにコミュニケーション・マネジメント・アプローチを検査するなど、レビューおよび評価措置の一部を実施するように個人またはグループに指示することにより、プロジェクト保証を委任できます。プロジェクト保証活動が委任されている場合、プロジェクト委員会は引き続き説明責任を負います。</p> <p>プロジェクト委員会に推奨される処置 * プロジェクト立ち上げ文書をレビューし承認する * プロジェクトの許容度を確認する * 過去の同様のプロジェクトからの教訓をレビューし、これに対処していることを確認する * リスクのレビューが行われており、脅威と機会に対するリスク対応策が適切で、計画済みであることを確認する * プロジェクトに必要な人員とリソースを入手またはコミットする(このリソースはステージごとにプロジェクト・マネージャーに提供される) * プロジェクトが認可されたことをビジネスおよびその他の利害関係者に通知する * プロジェクト・マネージャーによるプロジェクトの実行を認可する。または、プロジェクトを進めないと決定した場合はプロジェクトの早期クローズをプロジェクト・マネージャーに指示する</p> <h4>継続的な指揮<a href="#継続的な指揮"><span></span></a></h4> <p>プロジェクト委員会のメンバーは、プロジェクト期間中いつでも、非公式なガイダンスを与えたり、助言要求に対応したりする必要があります。プロジェクト・マネージャーとプロジェクト委員会の間で行う協議は、立ち上げステージ中とステージ境界に近づいている場合に、特に頻繁に必要となる可能性があります。 継続的な指揮は、プロジェクト委員会全体として、または個々のプロジェクト委員会のメンバーが行う場合があります。継続的な指揮はさまざまな場面でトリガーされます。 * プロジェクトに関する一般的な助言(プロジェクトに関連するビジネスの持続可能性目標と ESG 報告要件の説明など) * 要求への対応(選択肢を明確にする必要がある場合や、対立が生じている状況を解決しなければならない場合など) * 報告書への対応(ハイライト報告書、例外報告書、課題報告書など) * 外部からの影響への対応(ビジネスの優先度の変更など) * プロジェクト委員会メンバーの個別の懸念事項 * プロジェクト委員会の構成員の変更への対応(ビジネスの承認も必要となる場合がある)</p> <p>ステージ中に例外が発生した場合、プロジェクト委員会はプロジェクト・マネージャーに、例外計画書を作成してプロジェクト委員会の承認を受けることを求める場合があります。プロジェクト委員会による承認のためにエスカレーションする必要があるのは、ステージ計画書の例外のみです。プロジェクト計画書からの偏差には、ビジネスの承認が必要です。(ワーク・パッケージのレベルの例外は、ステージのコントロール・プロセスを使用して、プロジェクト・マネージャーが対応します。)承認された例外計画書は、例外となった計画書と置き換わり、新しいベースライン計画書となります。 また、ビジネスがプロジェクトの外部で生じたイベントに対応してプロジェクト権限委任を見直したり、プロジェクト委員会にプロジェクトのクローズを指示したりする場合もあります。ビジネスがプロジェクト権限委任の変更を決定した場合、プロジェクト委員会には主に 2 つの選択肢があります。 * 変更要求として取り扱い、プロジェクト・マネージャーに対し、ステージまたはプロジェクトを計画し直すよう求める。 * 停止し、早期のクローズをトリガーし、変更されたプロジェクト権限委任を満たすために新しいプロジェクトを開始する。この場合は、変更要求として取り扱う場合に比べて、追加コストがかかる場合がある。</p> <p>プロジェクト委員会は、インパクトが適切に評価されたことを確認するために変更要求を検査するなど、レビューおよび評価措置の一部を実施するように個人またはグループに指示することにより、プロジェクト保証を委任できます。(プロジェクト保証活動が委任されている場合、プロジェクト委員会は引き続き説明責任を負います。)決定を下す際には、すべての利害関係者(コミュニケーション・マネジメント・アプローチで特定)へのインパクトを考慮することが重要です。</p> <p>プロジェクト委員会に推奨される措置 * 助言やガイダンスの非公式の要求に応じて、(必要に応じて)助言を求め、プロジェクト・マネージャーを支援する。 * エスカレーションされた課題に応じて、(必要に応じて)助言を求め、決定を下す。課題が仕様外項目の場合、対応として、プロジェクト・マネジメント・チームまたはサプライヤーが関連する成果物を完成させる必要があることを意味する拒否を行うか、不完全な成果物が受け入れられることを意味する条件付き承認を行う。 * 例外報告書に応じて、(必要に応じて)助言を求め、決定を下す。 * ハイライト報告書の受領に応じて、必要に応じてレビューを行い措置を講じる。 * ビジネスからの助言や決定に応じて、プロジェクト・マネージャーに変更を通知する。</p> <h4>ステージまたは例外計画書の認可<a href="#ステージまたは例外計画書の認可"><span></span></a></h4> <p>ステージは、プロジェクト委員会が決定したときのみに開始することが重要です。プロジェクト委員会は現在のステージのパフォーマンスをレビューし、次のステージのステージ計画書を認可して、ステージを承認します。ステージ計画書の承認は、すべてのステージの前に行われます。 プロジェクト委員会は、ステージ計画書を検査して実行可能であることを確認するなど、レビューおよび評価措置の一部を実施するように個人またはグループに指示することにより、プロジェクト保証を委任します。プロジェクト保証活動が委任されている場合、プロジェクト委員会は引き続き説明責任を負います。</p> <p>プロジェクト委員会に推奨される措置 * ステージ終了報告書をレビューし、承認する。 * プロジェクト・マネージャーが承認を求めているステージ計画書または例外計画書をレビューする。 * 計画を承認するか、却下された計画を修正するようにプロジェクト・マネージャーに依頼するか、プロジェクトの早期クローズを開始するようにプロジェクト・マネージャーに指示する。 * プロジェクトのステータスをビジネスに伝達し、プロジェクト進捗について他の利害関係者に最新情報を通知する(コミュニケーション・マネジメント・アプローチに基づく)。</p> <h4>プロジェクトのクローズの認可<a href="#プロジェクトのクローズの認可"><span></span></a></h4> <p>プロジェクトのクローズをコントロールすることは、開始のコントロールと同様に重要です。元のバージョンと最新バージョンのプロジェクト立ち上げ文書とプロジェクト計画書の達成目標を評価するポイントを設け、次の点を把握する。 * 達成目標が達成されたかどうか * プロジェクトが初期計画からどの程度逸脱したか * プロジェクトにはこれ以上貢献できることがないか</p> <p>このアプローチを取らないと、ビジネスへの移管が完了せず、コントロールされた方法でプロジェクトをクローズできず、本来のベネフィットが重視されなくなるリスクがあります。また、チームが新しい作業のために完全にリリースされないリスクがあります。 プロジェクトのクローズ認可は、プロジェクト委員会の解散前に行う最後の活動となります。また、ビジネスによる承認が必要となる場合があります。プロジェクト委員会は、処置のレビューと評価(プロジェクト終了報告書の正確性を確認するためのレビューなど)を行うプロジェクト保証を要求することもできます。</p> <p>プロジェクト委員会に推奨される措置 * 元のバージョンと最新バージョンのプロジェクト立ち上げ文書をレビューして、プロジェクト当初のベースライン、現在のアプローチとコントロールを把握する。 * プロジェクト終了報告書をレビューし、承認する。 * 更新されたベネフィット・マネジメント・アプローチで定義されたプロジェクト終了後のベネフィット・レビューで、運用使用時のプロジェクト成果物のパフォーマンスが対象となっていることを確認し、副作用(有益または有害なもの)の有無を特定できるようにする。 * 更新されたベネフィット・マネジメント・アプローチをレビューし、承認を得る。まだ確認できていない予想ベネフィットも言及されていることを確認する(ベネフィット・マネジメント・アプローチには、プロジェクト・ライフサイクル外のリソースを含むため、このアプローチの責任をビジネスに移転する必要がある)。 * 更新されたビジネス・ケースをプロジェクトの正当性の確保に使用したビジネス・ケース概要とベネフィット、コスト、リスクの実績値と予測値を比較して、確認する(プロジェクトがクローズした後でなければ実現しないベネフィットがあるため、すべてのベネフィットは確認できない場合がある)。 * コミュニケーション・マネジメント・アプローチに従って、プロジェクトのクローズ通知をレビューし、通知を送る。プロジェクト委員会は、プロジェクト用の支援インフラストラクチャーとリソースの提供者に対して、その撤去が可能になったことを伝える。プロジェクトに請求されるコストを計算するため、終了日を明記する。 * 残りのすべてのプロジェクト・チーム・メンバーのオフボーディングが正しい方法で処理されていることを確認する。</p> <h3>適用<a href="#適用"><span></span></a></h3> <p>このプロセスのすベての活動はプロジェクト・エグゼクティブが実行責任を負いますが、実際の作業は他の担当者に任せられます。(ただし、プロジェクト・マネージャーは、プロジェクト・エグゼクティブの責任の範囲内にある事項について決定を下したり、承認したり、指揮したりすることはできないことに留意する必要があります。プロジェクト・エグゼクティブとプロジェクト・マネージャーの役割は分離する必要があります。)</p> <h3>責任<a href="#責任"><span></span></a></h3> <table><thead><tr><th>活动</th><th>ビジネス・レイヤー</th><th>プロジェクト・エグゼクティブ</th><th>シニア・ユーザー</th><th>シニア・サプライヤー</th><th>プロジェクト・マネージャー</th><th>チーム・マネージャー</th><th>プロジェクト保証</th><th>プロジェクト支援</th></tr></thead><tbody><tr><td><strong>立ち上げの認可</strong></td><td>I</td><td>A/R</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td><strong>プロジェクトの認可</strong></td><td>I</td><td>A/R</td><td>C</td><td>C</td><td>I</td><td>I</td><td>C</td><td>I</td></tr><tr><td><strong>継続的な指揮</strong></td><td>C</td><td>A/R¹</td><td>R²</td><td>R³</td><td>C/I</td><td>I</td><td>C</td><td>I</td></tr><tr><td><strong>ステージまたは例外計画書の認可</strong></td><td>I</td><td>A/R</td><td>C</td><td>C</td><td>I</td><td>I</td><td>C</td><td>I</td></tr><tr><td><strong>プロジェクトのクローズの認可</strong></td><td>I</td><td>A/R</td><td>C</td><td>C</td><td>I</td><td>I</td><td>C</td><td>I</td></tr></tbody></table> <p>R = 実行責任、A = 説明責任、C = 協議先、I = 情報先</p> <ul> <li><strong>R¹</strong>: ビジネス関連</li> <li><strong>R²</strong>: ユーザー関連</li> <li><strong>R³</strong>: サプライヤー関連</li> </ul> <h3>プロセスへのプラクティスの適用<a href="#プロセスへのプラクティスの適用"><span></span></a></h3> <table><thead><tr><th>プラクティス</th><th>プロジェクトの指揮プロセスへの適用</th></tr></thead><tbody><tr><td><strong>ビジネス・ケース</strong></td><td>プロジェクト委員会は、ビジネス・ケースが望ましく、実行可能で、達成可能であり、提案されたオプションがビジネス戦略と整合していることを確認するために、ビジネス・ケースにインプットを提供します。<br />プロジェクト要約書内のビジネス・ケース概要は、プロジェクトを開始する価値があるかどうかを確認するためにレビューされ、価値がある場合は、プロジェクト委員会が承認を提供します。<br />完全なビジネス・ケースがレビューされ、プロジェクトと次のステージを認可する価値があるかどうかが確認されます。価値がある場合は、プロジェクト委員会が承認を提供します。プロジェクトのクローズの認可を求められた場合、プロジェクト委員会は完全なビジネス・ケースをレビューして、ビジネス・ケースに対するプロジェクトのパフォーマンスを確認します。<br />プロジェクト委員会はビジネス・ケースとビジネス戦略との整合性を図り、ベネフィット・マネジメント・アプローチと持続可能性マネジメント・アプローチの初期バージョンと更新バージョンを承認します。プロジェクト委員会は、プロジェクト・レベルのベネフィットと持続可能性の許容度をビジネスと合意し、それらにステージ・レベルの許容度を設定します</td></tr><tr><td><strong>組織化</strong></td><td>ユーザー、ビジネス、サプライヤーの3つの利害関係者の利益は、プロジェクトの性質と規模、およびプロジェクト・エコシステム全体の信頼性に対して適切なレベルの権限を持つシニア・リーダーによってプロジェクト委員会に代表されます。<br />プロジェクト委員会は、プロジェクト・マネジメント・チーム組織と役割記述書、商業マネジメント・アプローチ、コミュニケーション・マネジメント・アプローチ、変更マネジメント・アプローチの初期バージョンと更新バージョンを承認します。プロジェクト委員会は、提案されたデリバリー・モデルを確認します</td></tr><tr><td><strong>計画</strong></td><td>計画と提案されたデリバリー手法は、ビジネス・ケース、ビジネス戦略、主要なマイルストーンとクリティカルな決定の時期との整合性がレビューされます。<br />プロジェクト委員会は、プロジェクト・アプローチ、プロジェクト計画書、各ステージ計画書、例外計画書の初期バージョンと更新バージョンを承認します。プロジェクト委員会は資金、人、リソースを計画にコミットさせます</td></tr><tr><td><strong>品質</strong></td><td>プロジェクト委員会のシニア・ユーザーは、ユーザーの期待品質と受け入れ基準を定義します。プロジェクト委員会はプロジェクト保証に実行責任があり、ユーザー、ビジネス、サプライヤーの観点から適切な保証が計画および実施されるようにします。<br />プロジェクト委員会は、プロジェクト成果物記述書、成果物記述書、品質マネジメント・アプローチの初期バージョンと更新バージョンを承認します。<br />プロジェクト委員会は、プロジェクト・レベルの品質許容度をビジネスと合意し、成果物レベルの品質許容度を設定します。</td></tr><tr><td><strong>リスク</strong></td><td>プロジェクト委員会は、プロジェクト立ち上げを認可する前のプロジェクト要約書と、プロジェクトと各ステージを承認する前のビジネス・ケースで、高いレベルのリスクを検討します。<br />プロジェクト委員会は、プロジェクト・レベルのリスク許容度をビジネスと合意し、ステージ・レベルのリスク許容度を設定します。プロジェクト委員会は、プロジェクト・ライフサイクルを通じてリスクの全体的なレベルが受け入れ可能であることを確認します。<br />プロジェクト委員会は、リスク・マネジメント・アプローチの初期バージョンと更新バージョンを承認します</td></tr><tr><td><strong>課題</strong></td><td>プロジェクト委員会は、課題マネジメント・アプローチの初期バージョンと更新バージョンを承認します。プロジェクト委員会は課題報告書にタイムリーに対応し、プロジェクト・マネジャーに継続的な指揮を提供します。<br />プロジェクト委員会は変更許可委員を委任し、変更予算を設定するかどうか、またどのように行うかを確立します</td></tr><tr><td><strong>進捗</strong></td><td>プロジェクト委員会は、デジタルおよびデータ・マネジメント・アプローチの初期バージョンと更新バージョンを承認します。<br />プロジェクト委員会は、プロジェクト・レベルの時間、コスト、スコープ許容度をビジネスと合意し、それらにステージ・レベルの許容度を設定します。<br />プロジェクト委員会は、プロジェクト・マネジャーから提供されたハイライト報告書を合意された頻度でレビューおよび対応することにより、プロジェクトが計画どおりに進んでいることを確認します。<br />プロジェクト委員会は例外報告書にタイムリーに対応し、例外計画書が必要かどうかを検討します。<br />プロジェクト委員会はプロジェクト終了報告書を確認して承認し、プロジェクトがクローズすることをビジネスに通知します</td></tr></tbody></table>category:项目管理tag:プロジェクトtag:マネジメントtag:プロセスtag:プロジェクトの指揮https://blog.issyuu.com/zh/post/pm-processes-start-up-dzh:pm-processes-start-up-d生きている限り、学び続けるThu, 16 Apr 2026 04:12:12 GMT<h2>プロジェクトの始動<a href="#プロジェクトの始動"><span></span></a></h2> <blockquote> <p>プロジェクトの始動プロセスの目的は、<strong>このプロジェクトは実行可能で、利益をもたらすものか</strong>という問いに答える。</p> </blockquote> <p>＊本格的な立ち上げの前に、必須条件が整っているかを確認する「ゲートキーパー」の役割を果たす。</p> <ul> <li><strong>合理的な判断</strong>: 十分に吟味されていないアイデアがそのまま立ち上がるのを防ぐ。</li> <li><strong>効率性</strong>: 詳細かつ綿密な<strong>プロジェクトの立ち上げ</strong>プロセスに比べ、最低限の活動で価値を判断する簡略的なプロセスである。</li> <li><strong>基盤整備</strong>: 役割と責任を割り当て、詳細な計画立案のための基盤を整えるまでは、いかなる作業も開始すべきではない。</li> </ul> <h3>達成目標<a href="#達成目標"><span></span></a></h3> <blockquote> <p>以下の点を確認・確立することを目指す。</p> </blockquote> <ul> <li><strong>ビジネス正当性</strong>: プロジェクトを立ち上げる正当性があること(ビジネス・ケース概要)。</li> <li><strong>権限とリソース</strong>: 人のアサインやリソースの確保など、開始に必要な権限が存在すること。</li> <li><strong>スコープの定義</strong>: 曖昧な前提を排除し、スコープや受け入れ基準、制約条件を明確にすること(プロジェクト要約書)。</li> <li><strong>アプローチの選定</strong>: 代替案を評価し、最適なプロジェクト・アプローチを合意すること。</li> <li><strong>役割の任命</strong>: プロジェクト・マネージャーやプロジェクト委員会の主要な役割を任命すること。</li> <li><strong>次段階の計画</strong>: 立ち上げステージに必要な<strong>ステージ計画書</strong>を策定すること。</li> </ul> <h3>位置付け<a href="#位置付け"><span></span></a></h3> <h4>トリガー(プロジェクト権限委任)<a href="#トリガープロジェクト権限委任"><span></span></a></h4> <blockquote> <p>プロジェクトが正式に開始される前のトリガーを**プロジェクト権限委任(Project Mandate)**と呼ぶ。</p> </blockquote> <ul> <li><strong>提供元</strong>: ビジネス・レイヤー(プロジェクト外部)の責任権限者(エグゼクティブ・グループ、プログラム、ポートフォリオ、顧客など)から提供される。</li> <li><strong>内容</strong>: 実行可能性調査や提案依頼書など、形態はさまざまである。少なくとも、プロジェクト・エグゼクティブ候補を特定できるだけの情報が必要である。</li> <li><strong>権限委任</strong>: この権限委任の情報が詳細化され、<strong>プロジェクト要約書</strong>へとまとめられる。</li> </ul> <h4>実施のポイント<a href="#実施のポイント"><span></span></a></h4> <ul> <li><strong>反復的な作業</strong>: ビジネス・ケース概要の準備とプロジェクト要約書の作成は、並行かつ反復的に行う。</li> <li><strong>頻繁なコミュニケーション</strong>: PMとプロジェクト委員会などの利害関係者間で、密なやり取りが必要である。</li> <li><strong>プログラムとの関連</strong>: プロジェクトがプログラムの一部である場合、多くの作業(要約書の提供やメンバー任命)がプログラム側で行われるため、本プロセスの作業は大半が省かれる。</li> <li><strong>先行投資のメリット</strong>: この段階で要件を明確に把握しておくことで、後のデリバリーにおける課題や計画見直しを避け、大幅な時間を節約できる。</li> </ul> <h4>主要なアウトプット<a href="#主要なアウトプット"><span></span></a></h4> <ul> <li><strong>プロジェクト要約書</strong>: プロジェクトの定義、アプローチ、役割などをまとめた文書。</li> <li><strong>ビジネス・ケース概要</strong>: プロジェクトの正当性を示す根拠。</li> <li><strong>ステージ計画書(立ち上げステージ用)</strong>: 次のステップである<strong>立ち上げステージ</strong>で何を行うかを定義した計画。</li> </ul> <h3>活動<a href="#活動"><span></span></a></h3> <table><thead><tr><th>インプット</th><th>活動</th><th>アウトプット</th></tr></thead><tbody><tr><td>プロジェクト権限委任(このプロセスのトリガー)<br />前回の教訓報告書(レビュー)</td><td>プロジェクト・エグゼクティブとプロジェクト・マネージャーの任命</td><td>デイリー・ログ(作成)</td></tr><tr><td>プロジェクト権限委任(このプロセスのトリガー)<br />前回の教訓報告書(レビュー)</td><td>前回の教訓の評価</td><td>教訓ログ(作成)</td></tr><tr><td>プロジェクト権限委任(このプロセスのトリガー)<br />前回の教訓報告書(レビュー)</td><td>ビジネス・ケース概要の準備</td><td>プロジェクト成果物記述書(作成)<br />ビジネス・ケース概要(作成)</td></tr><tr><td>プロジェクト権限委任(このプロセスのトリガー)<br />前回の教訓報告書(レビュー)</td><td>プロジェクト・マネジメント・チームの任命</td><td>プロジェクト要約書(作成)</td></tr><tr><td>プロジェクト権限委任(このプロセスのトリガー)<br />前回の教訓報告書(レビュー)</td><td>プロジェクト・アプローチの選択</td><td>プロジェクト要約書(作成)</td></tr><tr><td>プロジェクト権限委任(このプロセスのトリガー)<br />前回の教訓報告書(レビュー)</td><td>プロジェクト要約書のとりまとめ</td><td>プロジェクト要約書(作成)</td></tr><tr><td>プロジェクト権限委任(このプロセスのトリガー)<br />前回の教訓報告書(レビュー)</td><td>立ち上げステージの計画</td><td>ステージ計画書(立ち上げステージ用に作成)</td></tr><tr><td>プロジェクト権限委任(このプロセスのトリガー)<br />前回の教訓報告書(レビュー)</td><td>プロジェクトの立ち上げ要求</td><td>プロジェクト立ち上げの要求(プロジェクトの指揮プロセスをトリガー)</td></tr></tbody></table> <h4>プロジェクト・エグゼクティブとPMの任命<a href="#プロジェクトエグゼクティブとpmの任命"><span></span></a></h4> <blockquote> <p>プロジェクトを推進するためには、意思決定権を持つ責任者と、日々の管理を担う実務責任者を早期に確立する。</p> </blockquote> <ol> <li>役割 <ul> <li><strong>プロジェクト・エグゼクティブ</strong>: ビジネス側の利害関係者を代表し、プロジェクトの正当性を確保する役割を担う。 ＊エグゼクティブの任命は、プロジェクトを開始する上での必須条件である。</li> <li><strong>PM</strong>: エグゼクティブに代わり、日々のプロジェクト運営を管理する。PMを任命することで、マネジメント業務が具体的に動き出す。</li> </ul> </li> <li>推奨される処置 役割に応じて以下の処置を取る。 <ul> <li><strong>プロジェクト権限委任のレビュー(ビジネス)</strong> <ul> <li>ビジネス側が内容を確認し、不明点や曖昧な箇所を明確にする。</li> </ul> </li> <li><strong>プロジェクト・エグゼクティブの特定と任命(ビジネス)</strong> <ul> <li>適切な権限を持つ人物を選択し、正式に任命する。</li> </ul> </li> <li><strong>PMの特定と任命(プロジェクト・エグゼクティブ)</strong> <ul> <li>エグゼクティブが実務を任せるPMを選択し、任命する。 ＊必要に応じてビジネス側と協議し合意を得る。</li> </ul> </li> <li><strong>デイリー・ログの作成(PM)</strong> <ul> <li>PMはプロジェクト情報の最初のリポジトリ(保管場所)として、<strong>デイリー・ログ</strong>を作成し、記録を開始する。</li> </ul> </li> </ul> </li> </ol> <h4>前回の教訓の評価<a href="#前回の教訓の評価"><span></span></a></h4> <blockquote> <p>過去のプロジェクト(組織内・外を問わず)から得られた知見を、今回のプロジェクトの基盤構築に反映させる。</p> </blockquote> <ol> <li>教訓の内容と活用範囲 <ul> <li><strong>教訓の対象</strong>: プロセスの強み・弱み、使用された手順、技法、ツール、それらの使用タイミングや方法、関与した人員などが含まれる。</li> <li><strong>活用の場</strong>: 以下の策定において、過去の教訓を反映させる。 <ul> <li>プロジェクト・マネジメント・チームの編成</li> <li>ビジネス・ケース概要</li> <li>プロジェクト要約書</li> <li>立ち上げステージのステージ計画書</li> </ul> </li> </ul> </li> <li>知見を把握する手段 <ul> <li><strong>ワークショップの開催</strong>: 関係者や類似プロジェクトの経験者を集めて議論する。</li> <li><strong>外部知見の活用</strong>: 組織内に類似の経験がない場合は、外部の専門家や経験者を含めることも検討する。</li> </ul> </li> <li>PMに推奨される処置 PMは以下のステップを通じて、教訓を具体的に管理・適用する。 <ul> <li><strong>関連教訓のレビュー</strong>: 類似プロジェクトの監査結果やレビュー報告書を確認し、適用可能な教訓を特定する。</li> <li><strong>ヒアリングの実施</strong>: 類似プロジェクトに関わった個人やチームと直接対話し、詳細な情報を得る。</li> <li><strong>教訓ログの作成</strong>: 特定した教訓と、それに対する具体的な措置を記録するための<strong>教訓ログ</strong>を作成し、管理を開始する。</li> </ul> </li> </ol> <h4>ビジネス・ケース概要の準備<a href="#ビジネスケース概要の準備"><span></span></a></h4> <blockquote> <p>この段階では情報が限られているため、ビジネス・ケースは詳細なものではなく、あくまで全体像を示す「概要」に留める。</p> </blockquote> <p>＊<strong>立ち上げ</strong>プロセスで詳細なビジネス・ケースを策定する際の<strong>合意形成の基盤</strong>となる。</p> <ol> <li>推奨される処置 役割に応じて以下の処置を取る。 <ul> <li><strong>ビジネス・ケース概要の作成(プロジェクト・エグゼクティブ)</strong> <ul> <li>プロジェクト権限委任と最新情報に基づき作成する。 ＊シニア・ユーザーが任命されている場合は協議を行い、プロジェクトがどのようにビジネス目標に貢献するのかを明確にする。</li> </ul> </li> <li><strong>成果物の定義(PM)</strong> <ul> <li>プロジェクト・エグゼクティブ、シニア・ユーザー、シニア・サプライヤーと協議し、プロジェクトが提供すべき成果物を定義し、<strong>プロジェクト成果物記述書</strong>としてまとめる。</li> </ul> </li> <li><strong>主要リスクの特定(PM)</strong> <ul> <li>デイリー・ログに記録されたリスクを再確認する。</li> <li>プロジェクトの継続・実行可能性に重大な影響を及ぼす<strong>主要リスク</strong>を抽出し、<strong>ビジネス・ケース概要</strong>に反映させる。</li> </ul> </li> </ul> </li> </ol> <h4>プロジェクト・マネジメント・チームの任命<a href="#プロジェクトマネジメントチームの任命"><span></span></a></h4> <blockquote> <p>プロジェクトにおいて迅速な意思決定を行うためには、適切な権限・責任・知識を持つ人員を配置し、体制を明確にすることが不可欠である。</p> </blockquote> <ol> <li>チーム編成の基本原則 <ul> <li><strong>利益の反映</strong>: ビジネス、ユーザー、サプライヤーという**「3つの利益」**を代表する関係者が含まれる。</li> <li><strong>協力体制</strong>: 権限や知識だけでなく、関係者が協力してパフォーマンスの高いチームを形成できる。</li> <li><strong>責任と系統の明確化</strong>: 誰が誰に対して<strong>説明責任</strong>を負い、誰が何の<strong>実行責任</strong>を負うのか、また報告・コミュニケーション系統について全員が合意していなければならない。</li> </ul> </li> <li>推奨される処置 役割に応じて以下の処置を取る。 <ul> <li><strong>組織設計と役割の定義(PM)</strong> <ul> <li>教訓ログを確認し、過去の知見を活かした組織設計を行う。</li> <li>各メンバーの**役割記述書(Role Description)**を準備し、責任範囲を明確にする。</li> </ul> </li> <li><strong>チームの特定と任命(プロジェクト・エグゼクティブ)</strong> <ul> <li>シニア・ユーザーおよびPMと協議し、最適なメンバーを特定・選択した上で正式に任命する。</li> </ul> </li> <li><strong>作業基盤の合意とリスク管理(PM)</strong> <ul> <li>立ち上げステージにおけるチームの作業ルール(プラクティス)やコミュニケーション方法について合意を形成する。</li> <li>この過程で特定されたリスクは、速やかにプロジェクト・ログ(デイリー・ログ等)に追加する。</li> </ul> </li> </ul> </li> </ol> <h4>プロジェクト・アプローチの選択<a href="#プロジェクトアプローチの選択"><span></span></a></h4> <blockquote> <p>計画立案を立てる前に、プロジェクトを「どのように進めるか」という戦略的な方向性を決定する。</p> </blockquote> <p>＊この選択は、後のマネジメント・アプローチや進捗管理の基盤となる。</p> <ol> <li>検討すべき主要な疑問 プロジェクト作業の方針を決める際、以下の観点から最適なアプローチを検討する。 <ul> <li><strong>デリバリー・モデル</strong>: ソリューション開発を<strong>自社</strong>で行うか、それとも<strong>外部</strong>へ委託するか。</li> <li><strong>構築方法</strong>: 既存の成果物を<strong>修正・再利用</strong>するか、完全に<strong>ゼロから構築</strong>するか。</li> <li><strong>製品の性質</strong>: 既製品(COTS/オフザシェルフ)をベースにするか、要件に合わせて <strong>特注(フルスクラッチ)</strong> とするか。</li> <li><strong>デリバリー手法</strong>: アジャイルなどの「反復的・段階的」な方法を用いるか、またはウォーターフォールのような「直線的・連続的」な方法を用いるか。</li> <li><strong>持続可能性</strong>: 選択したアプローチが、持続可能性に関する期待や要件をどのように支援・実現するか。</li> </ul> </li> <li>基準と理解の共有 業務の実施方法は、ユーザーやサプライヤーが持つ標準、プラクティス、ガイドラインに強く影響される。 <ul> <li><strong>要約書への盛り込み</strong>: これらの基準は、プロジェクト要約書の一部として明文化する。</li> <li><strong>目的</strong>: ユーザーとサプライヤーがプロジェクト・アプローチを共通認識として持つことで、予期せぬ誤解がプロジェクトを脅かすリスクを防ぐ。</li> </ul> </li> <li>PMに推奨される処置 PMは、具体的な計画を立てる前に以下の実務を行う。 <ul> <li><strong>最適なアプローチの判断</strong>: デリバリー案を評価し、成果物の提供とビジネス・ケースの実現にとって<strong>最も効果的なアプローチ</strong>を決定する。</li> <li><strong>テーラリングの定義</strong>: 現時点で判明している範囲で、標準的な管理手法をどのようにプロジェクトの規模や状況に合わせて<strong>テーラリング</strong>するかを定義する。</li> <li><strong>リスク管理</strong>: 検討過程で判明した新たな課題やリスクを、速やかにプロジェクト・ログに記録する。</li> </ul> </li> </ol> <h4>プロジェクト要約書のとりまとめ<a href="#プロジェクト要約書のとりまとめ"><span></span></a></h4> <blockquote> <p>関係者全員が共通の理解を持ち、プロジェクトの開始点を明確に定義できる。</p> </blockquote> <ol> <li>PMに推奨される処置 プロジェクト要約書を完成させるために、PMは以下の項目を確認・整理し、文書化する。 <ul> <li><strong>現状と背景の確認</strong> <ul> <li>プロジェクトの背景や、これまでに実施された準備作業などの現在のステータスを確認する。</li> </ul> </li> <li><strong>目標と成果の定義</strong> <ul> <li>達成すべき目標と、最終的に望まれる成果を明確にする。</li> </ul> </li> <li><strong>範囲と限界の設定</strong> <ul> <li>スコープ(範囲)、除外項目(範囲外)、およびプロジェクト許容度(トレランス)を確認する。</li> </ul> </li> <li><strong>前提と制約の特定</strong> <ul> <li>プロジェクトを縛る制約条件や、成立の前提となる条件を特定する。</li> </ul> </li> <li><strong>関係者の特定と組織のレビュー</strong> <ul> <li>ユーザーを含む既知の関係者を特定する。</li> <li>プロジェクト・マネジメント・チームの組織と役割記述書をレビューし、プロジェクト・エコシステムに不足している役割やスキルがあれば追加で特定・作成する。</li> </ul> </li> <li><strong>依存関係の把握</strong> <ul> <li>他のプロジェクトや進行中の活動との相互影響(依存関係)を特定する。</li> </ul> </li> <li><strong>文書化とリスク管理</strong> <ul> <li>以上の情報をプロジェクト要約書として集約・文書化する。</li> <li>この過程で発見された新たな課題やリスクは、速やかにプロジェクト・ログへ記録する。</li> </ul> </li> </ul> </li> </ol> <h4>立ち上げステージの計画<a href="#立ち上げステージの計画"><span></span></a></h4> <blockquote> <p>プロジェクトの立ち上げには相応の時間とリソースが必要である。無計画な開始を避け、整理された状態で進めるために、このステージの作業内容を計画し、承認を得る必要がある。</p> </blockquote> <ol> <li>計画立案の意義 <ul> <li><strong>秩序ある開始</strong>: 狙いが不明確で整理されていない状態での立ち上げを防ぐ。</li> <li><strong>プログラムとの整合性</strong>: プロジェクトがプログラムの一部である場合、立ち上げステージの終了日をプログラム計画と照合し、要件に矛盾がないか確認する。</li> <li><strong>プロセスの適用</strong>: プロジェクトによっては、立ち上げステージ内であっても<strong>ステージのコントロール</strong>や<strong>成果物デリバリーのマネジメント</strong>プロセスを適用し、厳密に管理する場合がある。</li> </ul> </li> <li>PMに推奨される処置 PMは、立ち上げステージを円滑に進めるために以下の実務を行う。 <ul> <li><strong>マネジメント・コントロールの決定</strong> <ul> <li>採用したプロジェクト・アプローチに基づき、立ち上げステージの活動に適したコントロールを決定する。</li> </ul> </li> <li><strong>ステージ計画書の作成</strong> <ul> <li>時間とコストの制約条件を特定し、適切な原則と技法を用いて<strong>立ち上げステージ</strong>のための<strong>ステージ計画書</strong>を作成する。</li> </ul> </li> <li><strong>リスクの評価とログの更新</strong> <ul> <li>プロジェクト・ログ(デイリー・ログ等)に記録されたリスクをレビューし、立ち上げステージの計画に対するインパクトを評価する。</li> <li>新たなリスクの特定や既存リスクの変化があった場合は、速やかにログを更新する。</li> </ul> </li> </ul> </li> </ol> <h4>プロジェクトの立ち上げ要求<a href="#プロジェクトの立ち上げ要求"><span></span></a></h4> <blockquote> <p><strong>プロジェクトの始動</strong>プロセスを締めくくり、次なる<strong>プロジェクトの立ち上げ</strong>フェーズへ進むための正式な手続きである。</p> </blockquote> <ol> <li>プロジェクト委員会への報告 PMは、これまでに作成した成果物を基に、プロジェクト委員会に対してプロジェクトの立ち上げを要求する。 <ul> <li><strong>正当性の提示</strong>: <strong>ビジネス・ケース概要</strong>と<strong>プロジェクト要約書</strong>を提示し、プロジェクトを開始するに足る合理的な理由を説明する。</li> </ul> </li> <li>推奨される処置 PMは、以下の活動を通じてプロジェクト委員会の承認を取り付ける。 <ul> <li><strong>重要事項の説明</strong> <ul> <li>以下の項目について、プロジェクト委員会に詳細を説明し、理解を得る。 <ul> <li><strong>ビジネス・ケース概要</strong>: プロジェクトの投資対効果と正当性。</li> <li><strong>プロジェクト成果物</strong>: 何を完成させるのか。</li> <li><strong>プロジェクト・アプローチ</strong>: どのように進めるのか。</li> <li><strong>プロジェクト・マネジメント・チームの任命</strong>: 誰が責任を負うのか。</li> <li><strong>立ち上げステージの活動とコントロール</strong>: 次のステージで何を行い、どう管理するか。</li> </ul> </li> </ul> </li> <li><strong>権限とリソースの正式要求</strong> <ul> <li>必要な人員の確保やリソースの割り当てを確定させるため、プロジェクトを正式に開始する権限をプロジェクト委員会に要求する。</li> </ul> </li> </ul> </li> </ol> <h3>適用<a href="#適用"><span></span></a></h3> <blockquote> <p>このプロセスを実務に適用する際は、プロジェクトの規模や複雑性、組織の状況に応じて、柔軟な運用が求められる。</p> </blockquote> <h4>一般的な考慮事項<a href="#一般的な考慮事項"><span></span></a></h4> <blockquote> <p>プロセスの実行にあたっては、形式に縛られず、本質的な「プロジェクトの正当性」の確保に注力する。</p> </blockquote> <ul> <li><strong>活動の柔軟な運用</strong>: 始動プロセスの各活動は、状況に応じて<strong>結合・分割・同時実行</strong>が可能である。ただし、プロジェクトの立ち上げ要求を行う際には、<strong>プロジェクトの指揮</strong>プロセスとの連携が完全である(必要な情報が揃っている)よう配慮しなければならない。</li> <li><strong>不確実性への対処</strong>: プロジェクト初期段階では、アウトプット(成果物)が明確でない場合も多い。その場合でも、少なくとも<strong>どのビジネス上の問題を解決するのか</strong>、または<strong>どのような成果(Outcome)を求めているのか</strong>を明確に定義しておく。</li> <li><strong>関係者との共創</strong>: ビジネス・ケース概要、プロジェクト要約書、立ち上げステージ計画書などは、PMが一人で作成するのではなく、将来のユーザーや利害関係者と<strong>共に作り上げる</strong>ことで、提案内容への理解と賛同(バイイン)を深めることができる。</li> </ul> <h4>役割のテーラリング<a href="#役割のテーラリング"><span></span></a></h4> <blockquote> <p>役割の割り当ては、組織の体制に合わせて柔軟に変更できるが、説明責任の所在は曖昧にしてはならない。</p> </blockquote> <ul> <li><strong>PM 任命のタイミング</strong>: 初期段階でのPM 任命がベストプラクティスである。</li> <li><strong>代行の許容</strong>: プロセスの後半までPMが任命されていない場合は、プロジェクト・エグゼクティブ(またはその指名者)がマネジメント成果物を作成しても構わない。</li> <li><strong>実行の委任と説明責任</strong>: <ul> <li>プロジェクト・エグゼクティブは、ビジネス・ケース概要の作成を自ら行う必要はなく、他者に依頼(委任)できる。ただし、内容に対する<strong>最終的な説明責任は、常に各役割の本来の責任者に一元化</strong>されていなければならない。</li> </ul> </li> </ul> <h3>責任<a href="#責任"><span></span></a></h3> <table><thead><tr><th>活動</th><th>ビジネス・レイヤー</th><th>プロジェクト・エグゼクティブ</th><th>シニア・ユーザー</th><th>シニア・サプライヤー</th><th>プロジェクト・マネージャー</th><th>チーム・マネージャー</th><th>プロジェクト保証</th><th>プロジェクト支援</th></tr></thead><tbody><tr><td>プロジェクト・エグゼクティブとプロジェクト・マネージャーの任命</td><td>A/R¹</td><td>R</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>前回の教訓の評価</td><td>C</td><td>A</td><td></td><td></td><td>R</td><td></td><td></td><td></td></tr><tr><td>ビジネス・ケース概要の準備</td><td>C</td><td>A/R</td><td>C³</td><td>C³</td><td>R</td><td></td><td></td><td></td></tr><tr><td>プロジェクト・マネジメント・チームの任命</td><td>A</td><td>R</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>プロジェクト・アプローチの選択</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C²</td><td>C</td><td></td></tr><tr><td>プロジェクト要約書のとりまとめ</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td></td><td>C</td><td>C</td></tr><tr><td>立ち上げステージの計画</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>I²</td><td>C</td><td>C</td></tr><tr><td>プロジェクトの立ち上げ要求</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>I²</td><td>C</td><td>I</td></tr></tbody></table> <p>R = 実行責任、A = 説明責任、C = 協議先、I = 情報先</p> <ul> <li><strong>A/R¹</strong>: ビジネスは、プロジェクト・エグゼクティブとプロジェクト・マネージャーの任命に説明責任を負います。また、ビジネスはプロジェクト・エグゼクティブを任命する実行責任があります。</li> <li><strong>C²/I²</strong>: プロジェクト・マネジメント・チームを設計および任命するときにチーム・マネージャーが特定された場合、チーム・マネージャーがそのステージに関与しているのであれば、プロジェクト・アプローチについて協議し、立ち上げステージのステージ計画書の重要な詳細を通知することがグッド・プラクティスです。</li> <li><strong>C³</strong>: 任命された場合</li> </ul> <h3>プロセスへのプラクティスの適用<a href="#プロセスへのプラクティスの適用"><span></span></a></h3> <table><thead><tr><th>プラクティス</th><th>プロジェクトの始動プロセスへの適用</th></tr></thead><tbody><tr><td><strong>ビジネス・ケース</strong></td><td>プロジェクト権限委任や教訓、関係者との協議に基づき、**ビジネス・ケース概要(アウトライン)**を作成。プロジェクト要約書の一部となる</td></tr><tr><td><strong>組織化</strong></td><td>プロジェクト・エグゼクティブとPMを任命し、必要なチーム組織を設計。立ち上げに必要な役割に人員を割り当てる</td></tr><tr><td><strong>計画</strong></td><td>主要マイルストーンを要約書に含める。プロジェクト・アプローチ(デリバリー手法等)を決定し、<strong>立ち上げステージ専用の計画書</strong>(期間、コスト、作業内容)を作成する</td></tr><tr><td><strong>品質</strong></td><td>ユーザーの期待品質や既知の標準を<strong>プロジェクト成果物記述書</strong>に記録。これらは後のプロセスで段階的に精緻化される</td></tr><tr><td><strong>リスク</strong></td><td>判明している<strong>上位レベルのリスク</strong>を特定し、プロジェクト要約書に組み込む</td></tr><tr><td><strong>課題</strong></td><td>判明している<strong>上位レベルの課題</strong>を特定し、プロジェクト要約書に組み込む</td></tr><tr><td><strong>進捗</strong></td><td>プロジェクト全体の<strong>暫定的な許容度</strong>を特定。また、立ち上げステージ自体の許容度をステージ計画書に設定する</td></tr></tbody></table>category:项目管理tag:プロジェクトtag:マネジメントtag:プロセスtag:プロジェクトの始動https://blog.issyuu.com/zh/post/pm-processes-start-up-szh:pm-processes-start-up-s生きている限り、学び続けるThu, 16 Apr 2026 04:12:12 GMT<h2>プロジェクトの始動<a href="#プロジェクトの始動"><span></span></a></h2> <blockquote> <p>プロジェクトの始動プロセスの目的は、<strong>このプロジェクトは実行可能で、利益をもたらすものか</strong> という問いに答え、本格的な立ち上げのための必須条件を確立する。</p> </blockquote> <h3>基本コンセプト<a href="#基本コンセプト"><span></span></a></h3> <ul> <li><strong>目的</strong>: 不十分なアイデアの立ち上げを防ぎ、時間を無駄にしない。</li> <li><strong>トリガー</strong>: <strong>プロジェクト権限委任</strong>(口頭、指示書、提案依頼書など)。</li> <li><strong>位置づけ</strong>: プロジェクトの立ち上げプロセスの前段階。</li> <li><strong>主要な問い</strong>: <ul> <li>ビジネス上の正当性(やる価値)はあるか？</li> <li>実現可能なアプローチ(やり方)はあるか？</li> <li>適切なメンバー(人)は揃っているか？</li> </ul> </li> </ul> <h3>主要な活動<a href="#主要な活動"><span></span></a></h3> <table><thead><tr><th>活動内容</th><th>概要</th><th>アウトプット</th></tr></thead><tbody><tr><td><strong>エグゼクティブとPMの任命</strong></td><td>意思決定者と日々の管理者を決定</td><td>デイリー・ログ (作成)</td></tr><tr><td><strong>前回の教訓の評価</strong></td><td>過去の類似プロジェクトの成功・失敗事例をレビュー</td><td>教訓ログ (作成)</td></tr><tr><td><strong>ビジネス・ケース概要の準備</strong></td><td>プロジェクトの正当性を概観</td><td>プロジェクト成果物記述書、ビジネス・ケース概要</td></tr><tr><td><strong>プロジェクト・マネジメント・チームの任命</strong></td><td>ビジネス・ユーザー・サプライヤーの利益を代表するチームを編成</td><td>プロジェクト要約書 (組織図・役割分担)</td></tr><tr><td><strong>プロジェクト・アプローチの選択</strong></td><td>内製か外注か、アジャイルあるいはウォーターフォールか等の進め方を決定</td><td>プロジェクト要約書 (デリバリー手法、手法の決定)</td></tr><tr><td><strong>プロジェクト要約書のとりまとめ</strong></td><td>背景、目標、スコープ、制約、リスク等を<strong>プロジェクト要約書</strong>に集約</td><td><strong>プロジェクト要約書 (Project Brief)</strong></td></tr><tr><td><strong>立ち上げステージの計画</strong></td><td>次のステージ(詳細計画フェーズ)の時間・コスト・活動を計画</td><td><strong>ステージ計画書 (立ち上げステージ用)</strong></td></tr><tr><td><strong>プロジェクトの立ち上げ要求</strong></td><td>プロジェクト委員会に対し、本格的な立ち上げの許可を申請</td><td>立ち上げの要求 (指揮プロセスのトリガー)</td></tr></tbody></table> <h3>主要なマネジメント成果物<a href="#主要なマネジメント成果物"><span></span></a></h3> <ul> <li><strong>プロジェクト要約書</strong>: <ul> <li>プロジェクトの<strong>何、なぜ、誰が、どのように</strong>を定義した文書。プロジェクト・アプローチやビジネス・ケース概要を含む。</li> </ul> </li> <li><strong>ステージ計画書(立ち上げステージ用)</strong>: <ul> <li>次のステージ(プロジェクト立ち上げ文書の作成など)をどのように進めるかの計画。</li> </ul> </li> <li><strong>プロジェクト成果物記述書</strong>: <ul> <li>プロジェクト全体の最終成果物と、その受け入れ基準を定義したもの。</li> </ul> </li> </ul> <h3>主要な役割と責任(RACI)<a href="#主要な役割と責任raci"><span></span></a></h3> <table><thead><tr><th>活動</th><th>ビジネス・レイヤー</th><th>プロジェクト・エグゼクティブ</th><th>シニア・ユーザー</th><th>シニア・サプライヤー</th><th>プロジェクト・マネージャー</th><th>チーム・マネージャー</th><th>プロジェクト保証</th><th>プロジェクト支援</th></tr></thead><tbody><tr><td>プロジェクト・エグゼクティブとプロジェクト・マネージャーの任命</td><td>A/R¹</td><td>R</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>前回の教訓の評価</td><td>C</td><td>A</td><td></td><td></td><td>R</td><td></td><td></td><td></td></tr><tr><td>ビジネス・ケース概要の準備</td><td>C</td><td>A/R</td><td>C³</td><td>C³</td><td>R</td><td></td><td></td><td></td></tr><tr><td>プロジェクト・マネジメント・チームの任命</td><td>A</td><td>R</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>プロジェクト・アプローチの選択</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C²</td><td>C</td><td></td></tr><tr><td>プロジェクト要約書のとりまとめ</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td></td><td>C</td><td>C</td></tr><tr><td>立ち上げステージの計画</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>I²</td><td>C</td><td>C</td></tr><tr><td>プロジェクトの立ち上げ要求</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>I²</td><td>C</td><td>I</td></tr></tbody></table> <p>R = 実行責任、A = 説明責任、C = 協議先、I = 情報先</p> <ul> <li><strong>A/R¹</strong>: ビジネスは、プロジェクト・エグゼクティブとプロジェクト・マネージャーの任命に説明責任を負います。また、ビジネスはプロジェクト・エグゼクティブを任命する実行責任があります。</li> <li><strong>C²/I²</strong>: プロジェクト・マネジメント・チームを設計および任命するときにチーム・マネージャーが特定された場合、チーム・マネージャーがそのステージに関与しているのであれば、プロジェクト・アプローチについて協議し、立ち上げステージのステージ計画書の重要な詳細を通知することがグッド・プラクティスです。</li> <li><strong>C³</strong>: 任命された場合</li> </ul>category:项目管理tag:プロジェクトtag:マネジメントtag:プロセスtag:プロジェクトの始動https://blog.issyuu.com/zh/post/pm-processes-start-upzh:pm-processes-start-up生きている限り、学び続けるThu, 16 Apr 2026 04:12:12 GMT<h2>プロジェクトの始動<a href="#プロジェクトの始動"><span></span></a></h2> <p>プロジェクトの始動プロセスの目的は、「このプロジェクトは実行可能で、利益をもたらすものか」という問いに答えることによって、プロジェクトの立ち上げのための必須条件が確立されていることを確認する。 プロジェクトを開始する決定は明確に行われる必要があります。プロジェクトの始動プロセスで行う活動はこの決定の前に行われるためです。プロジェクトを委託する合理的な判断を下すために必要な基本情報を明確に定義し、主要な役割と責任を割り当て、詳細な計画立案のための基盤を整備するまでは、いかなる作業も開始すべきではありません。 プロジェクトの始動プロセスの目的は、十分に吟味されていないアイデアの立ち上げを防ぎ、実行可能なプロジェクトを承認に向けて進行することにあります。(そのため、プロジェクトの始動プロセスは、詳細かつ綿密なプロジェクトの立ち上げプロセスに比ベると簡略的なプロセスです。)主な狙いは、プロジェクトを立ち上げる価値が本当にあるのかどうかを判断するために、最低限の活動を行うことにあります。</p> <p>プロジェクトの始動プロセスの達成目標は、次の点を確認する。 * プロジェクトを立ち上げるビジネス正当性があること(ビジネス・ケース概要で文書化)。 * プロジェクトを開始するために必要な権限がすべて存在すること(例: 人のアサインやリソースの確保)。 * プロジェクト・スコープを定義、確認するために十分な情報が(プロジェクト要約書の形式で)用意されていること。 * 代替のアプローチが評価され、選択されたプロジェクト・アプローチが合意されていること。 * 立ち上げステージに必要な作業を行う者、プロジェクト中にプロジェクト・マネジメントの重要な役割を担う者のいずれかが任命されていること。 * 立ち上げステージ(ステージ計画書で文書化)に必要な作業計画が策定されていること。 * プロジェクト・スコープ、期間、受け入れ基準、制約条件について、曖昧な前提に基づきプロジェクトを立ち上げ、時間を無駄にしないこと。</p> <p>プロジェクトはさまざまな方法でトリガ一できるため、正式に開始される前に利用できる情報にはさまざまなバリエーションがあります。プロジェクトのトリガーをプロジェクト権限委任と呼んでいます。これは、プロジェクトを委託しているビジネスの責任権限者によって提供されます。責任権限者が生まれる可能性のある領域もさまざまです。(例えば、プロジェクト・エグゼクティブ・グループ、機能単位または運用単位、プログラム、ポートフォリオ、顧客などです。) 責任権限者はビジネス・レイヤーのプロジェクトの外部にあると見なされます。「プロジェクト権限委任」という用語は、実行可能性調査やサプライヤー環境での提案依頼書の受領など、プロジェクトのトリガーに使用されるあらゆる情報に適用されます。プロジェクト権限委任には、プロジェクトの委任事項に加え、少なくともプロジェクト委員会のプロジェクト・エグゼクティブ候補者を特定するために十分な情報が提供される必要があります。プロジェクト権限委任の情報は詳細化され、プロジェクト要約書としてまとめられます。 プロジェクト委員会には、プロジェクト立ち上げの決定を下すための十分な情報が提供される必要があります。これを目的としてプロジェクト要約書が作成されます。 プロジェクトの始動プロセスにかかる労力は、プロジェクトによって大きく異なる場合があります。プロジェクトがプログラムのー環として実施される場合、プログラム・マネジメント・チームがプロジェクト要約書を提供し、プロジェクト委員会のー部または全メンバーを任命します。(これにより、このプロセスで求められる作業の大半が省かれます。このようなケースでは、プロジェクト・マネージャーはプログラムが提供するものを確認し、必要に応じて修正を提案します。) ビジネス・ケース概要の準備と、プロジェクト要約書をまとめる活動は、並行して反復的に行います。プロジェクト・マネージャーやプロジェクト委員会などの利害関係者間で、定期的かつ頻繁なやり取りを行う必要があります。プロジェクトの始動プロセスに多くの時間を確保し、要件事項を明確に把握することにより、プロジェクトの立ち上げとデリバリーでの課題、例外、計画見直しが避けられ、大幅な時間の節約につながります。</p> <h3>活動<a href="#活動"><span></span></a></h3> <table><thead><tr><th>インプット</th><th>活動</th><th>アウトプット</th></tr></thead><tbody><tr><td>プロジェクト権限委任(このプロセスのトリガー)<br />前回の教訓報告書(レビュー)</td><td>プロジェクト・エグゼクティブとプロジェクト・マネージャーの任命</td><td>デイリー・ログ(作成)</td></tr><tr><td>プロジェクト権限委任(このプロセスのトリガー)<br />前回の教訓報告書(レビュー)</td><td>前回の教訓の評価</td><td>教訓ログ(作成)</td></tr><tr><td>プロジェクト権限委任(このプロセスのトリガー)<br />前回の教訓報告書(レビュー)</td><td>ビジネス・ケース概要の準備</td><td>プロジェクト成果物記述書(作成)<br />ビジネス・ケース概要(作成)</td></tr><tr><td>プロジェクト権限委任(このプロセスのトリガー)<br />前回の教訓報告書(レビュー)</td><td>プロジェクト・マネジメント・チームの任命</td><td>プロジェクト要約書(作成)</td></tr><tr><td>プロジェクト権限委任(このプロセスのトリガー)<br />前回の教訓報告書(レビュー)</td><td>プロジェクト・アプローチの選択</td><td>プロジェクト要約書(作成)</td></tr><tr><td>プロジェクト権限委任(このプロセスのトリガー)<br />前回の教訓報告書(レビュー)</td><td>プロジェクト要約書のとりまとめ</td><td>プロジェクト要約書(作成)</td></tr><tr><td>プロジェクト権限委任(このプロセスのトリガー)<br />前回の教訓報告書(レビュー)</td><td>立ち上げステージの計画</td><td>ステージ計画書(立ち上げステージ用に作成)</td></tr><tr><td>プロジェクト権限委任(このプロセスのトリガー)<br />前回の教訓報告書(レビュー)</td><td>プロジェクトの立ち上げ要求</td><td>プロジェクト立ち上げの要求(プロジェクトの指揮プロセスをトリガー)</td></tr></tbody></table> <h4>プロジェクト・エグゼクティブとプロジェクト・マネージャーの任命<a href="#プロジェクトエグゼクティブとプロジェクトマネージャーの任命"><span></span></a></h4> <p>プロジェクトで物事を進めるには、ビジネスの各利害関係者の関心を代表する、適切な権限を持った意思決定者(プロジェクト・エグゼクティブ)が必要です。プロジェクト・エグゼクティブの任命は、プロジェクトの正当性を確保するうえで必須条件です。 プロジェクト・マネージャーを任命することによって、プロジエクト・エグゼクティブに代わってプロジェクト・マネージャーが日々プロジェクトをマネジメントできるようになります。(プロジェクト・エグゼクティブがプロジェクト・マネージャーを任命する際は、ビジネスと協議し、合意を得る必要がある場合があります。) 推奨される処置 - ビジネスはプロジェクト権限委任をレビューし、理解を確認し、曖昧さを明確にする。 - ビジネスはプロジェクト・エグゼクティブを特定、選択、任命する。 - プロジェクト・エグゼクティブはプロジェクト・マネージャーを特定、選択、任命する。 - プロジェクト・マネージャーはプロジェクト情報のリポジトリとしてデイリー・ログを作成する。</p> <h4>前回の教訓の評価<a href="#前回の教訓の評価"><span></span></a></h4> <p>(数多くの教訓が、ビジネスや外部組織の他のプロジェクトにより明らかになっている場合があります。)教訓には、プロセスの弱点または強み、使用された手順、技法、ツール、使用されたタイミング、使用方法、使用者などが含まれます。過去のプロジェクトからの教訓は、プロジェクト・マネジメント・チーム編成、ビジネス・ケース概要、プロジェクト要約書の内容、立ち上げステージのステージ計画書で活用できます。 関連する教訓を把握する手段として、ワークショップの開催が役立つ場合があります。ワークショップの参加者には、このプロジェクトの関係者や、過去の類似するプロジェクトの関係者を含めることもできます。ビジネスにこのプロジェクトと同種のプロジェクト経験がない場合は、関連する経験のある組織外の人員を含めることも有効です。 プロジェクト・マネージャーに推奨される処置 - 過去の類似するビジネス組織および外部組織のプロジェクトの関連する教訓をレビューし、今回のプロジェクトに適用できる教訓を特定する(例えば、監査とプロジェクト・レビューの結果などが当てはまる)。 - 類似したプロジェクトの経験を持つ個人やチームと協議する。 - 必要に応じて教訓ログを作成し、特定した教訓や関連する措置を記録する。</p> <h4>ビジネス・ケース概要の準備<a href="#ビジネスケース概要の準備"><span></span></a></h4> <p>この時点で利用できる情報量を考えると、ビジネス・ケース概要は概観に過ぎません。(ビジネス・ケース概要は、プロジェクトの立ち上げプロセスにおいて、より詳細にビジネス・ケースを作成する際の合意形成基盤となります。) 推奨される処置 - プロジェクト・エグゼクティブは、プロジェクト権限委任に従い、プロジェクトに関する現在の情報に基づいてビジネス・ケース概要を作成する。ビジネス・ケース概要の作成は、この時点でシニア・ユーザーが任命されている場合、シニア・ユーザーと協議の下で行う。シニア・ユーザーは、プロジェクトがビジネス目標にどのように貢献するかを理解する必要がある。 - プロジェクト・マネージャーはシニア・ユーザー、シニア・サプライヤー、プロジェクト・エグゼクティブと協議のうえ、プロジェクトの成果物を定義し、プロジェクト成果物記述書を作成する - デイリー・ログに記録されたリスクをレビューし、プロジェクトの実行可能性を左右する主要リスクをビジネス・ケース概要にまとめる。</p> <h4>プロジェクト・マネジメント・チームの任命<a href="#プロジェクトマネジメントチームの任命"><span></span></a></h4> <p>プロジェクトで迅速に決定を下すには、ふさわしい権限、責任、知識を持つ人員の配置が不可欠です。プロジェクト・マネジメント・チームには、ビジネス、ユーザー、サプライヤーの利益を含め、全関係者の利益を反映させる必要があります。上記の権限、責任、知識に加えて、関係者が協力してパフォーマンスの高いチームを結成できることが重要です。 プロジェクトを安定して進行させるためには、誰が何の説明責任を誰に対して負うのか、誰が何の実行責任を負うのか、また報告およびコミュニケーション系統について、プロジェクト・マネジメントに関わる全員が理解し、合意することが不可欠です。 推奨される処置 - プロジェクト・マネージャーは教訓ログを確認して、プロジェクト・マネジメント・チーム組織を設計し、役割記述書を準備する。 - プロジェクト・エグゼクティブは、シニア・ユーザーおよびプロジェクト・マネージャーと協議の下、プロジェクト・マネジメント・チームを特定、選択、任命する。 - プロジェクト・マネージャーは、立ち上げステージのチームの作業プラクティスとコミュニケーションに合意し、リスクが特定された場合はそのリスクをプロジェクト・ログに追加する。</p> <h4>プロジェクト・アプローチの選択<a href="#プロジェクトアプローチの選択"><span></span></a></h4> <p>プロジェクトの計画立案を開始する前に、プロジェクト作業にアプローチする方法について疑問点を挙げる。 * ソリューション開発を社内で行うか、第三者に委託するか(デリバリー・モデルとも呼ばれる) * 既存の成果物を修正するか、ゼロから構築するか * 商業的オフザシェルフの成果物(既製品または COTS 成果物とも呼ばれる)を基盤とするか、特注とするか * どのデリバリー手法を使用するか、例えば、プロジェクト成果物はアジャイルな作業方法を使用して段階的に提供することができるのか、それとも直線的で連続的な方法で提供する必要があるのか * プロジェクト・アプローチは、持続可能性に関する期待や要件をどのように支援するか 業務の実施方法は、ユーザーまたはサプライヤーの標準、プラクティス、ガイドラインに左右されます(例えば、特定のデリバリー手法を採用する場合もあります)。これらの基準はプロジェクトの立ち上げプロセスで策定されるマネジメント・アプローチに影響を与えるため、プロジェクト・アプローチの一環としてプロジェクト要約書に盛り込む必要があります。こうした側面を捉えることは、ユーザーとサプライヤーがプロジェクト・アプローチを確実に理解し、何らかの形でプロジェクトを脅かすことを防ぐうえでも役立ちます。 プロジェクト・マネージャーに推奨される処置 * デリバリー・ソリューション案を評価し、プロジェクト成果物のデリバリーとビジネス・ケース概要の実現において最適なプロジェクト・アプローチを判断する。 * 現時点で判明している場合、方法をテーラリングする要件を定義する。 * 新たな課題またはリスクがあれば、プロジェクト・ログに記録する。</p> <h4>プロジェクト要約書のとりまとめ<a href="#プロジェクト要約書のとりまとめ"><span></span></a></h4> <p>合意されたプロジェクト要約書によって、共通の理解に基づきプロジェクトの開始点を明確に定義できます。 プロジェクト・マネージャーに推奨される処置 * プロジェクトの現在のステータスを確認する。 * 例えば、プロジェクトの背景やこれまでに実施された準備作業など。 * 達成目標と望ましい成果を確認する。 * プロジェクト・スコープ、除外項目、プロジェクト許容度を確認する。 * 制約条件と前提条件を特定する。 * ユーザーを含む既知の関係者を特定する。 * プロジェクト・マネジメント・チーム組織と役割記述書をレビューして、プロジェクト・エコシステムに必要な追加の役割またはスキルを特定する。 * 必要に応じて役割記述書を追加で作成する。 * プロジェクトが維持する必要がある他のプロジェクトまたは活動との依存関係を特定する。 * 上記をプロジェクト要約書に文書化する。 * 新たな課題またはリスクがあれば、プロジェクト・ログに記録する。</p> <h4>立ち上げステージの計画<a href="#立ち上げステージの計画"><span></span></a></h4> <p>プロジェクトの立ち上げには時間とリソースが必要です。狙いがないまま、整理されていない状態でプロジェクトの立ち上げに至らないよう、作業を計画し、承認を得る必要があります。(プロジェクトがプログラムの一環として実施される場合、立ち上げステージの終了日はプログラムの計画で定義されている日付と照らし合わせて確認する必要があります。立ち上げステージのステージ計画書も、プログラムからの要件に関して、プログラム・マネジメント・チームへの注意を促すものになります。) 立ち上げステージは、プロジェクトの始動プロセスのー環と見なす必要があります。(例えば、プロジェクトによってはプロジェクトの立ち上げプロセスの中で、ステージのコントロールと成果物デリバリーのマネジメント・プロセスを適用する場合があります。) プロジェクト・マネージャーに推奨される処置 * プロジェクト・アプローチに基づいて、立ち上げステージの活動に適したマネジメント・コントロールを決定する。 * 立ち上げステージにおける時間とコストの制約条件を特定し、原則と技法に基づいて、このステージのステージ計画書を作成する。 * プロジェクト・ログに記録されたリスクをレビューし、立ち上げステージのステージ計画書に及ぼすインパクトを評価する。新たなリスクが特定された(または既存のリスクに変化が生じた)場合は、プロジェクト・ログを更新する。</p> <h4>プロジェクトの立ち上げ要求<a href="#プロジェクトの立ち上げ要求"><span></span></a></h4> <p>プロジェクトの始動プロセスを終了するために、プロジェクト・マネージャーはプロジェクト委員会に連絡してプロジェクト立ち上げを要求します。ビジネス・ケース概要とプロジェクト要約書の正式な正当性がプロジェクト委員会に提示されます。 推奨される処置 * ビジネス・ケース概要、プロジェクト成果物、プロジェクト・アプローチ、プロジェクト・マネジメント・チームの任命、立ち上げステージの活動とコントロールについてプロジェクト委員会に説明する。 * 必要な人員とリソースを確保するために、プロジェクトを開始する権限をプロジェクト委員会に正式に要求する。</p> <h3>適用<a href="#適用"><span></span></a></h3> <h4>一般的な考慮事項<a href="#一般的な考慮事項"><span></span></a></h4> <p>このプロセスの活動は、状況に合わせて結合したり、分割したり、同時に実行したりできますが、プロジェクトの立ち上げ要求時に、プロジェクトの指揮プロセスとの関連の完全性を確保することに配慮します。 (プロジェクト・ライフサイクルのこの時点では、プロジェクトの作成によるアウトプットが必すしも明確ではない場合があります。そのような場合、少なくともどのビジネス上の問題を解決するか、またはどのような成果が求められるかを明確にしておきます。) 提案されたアプローチへの理解と賛同を高めるために、ビジネス・ケース概要、プロジェクト要約書、立ち上げステージ計画書を将来のユーザーや利害関係者と共創することの価値を考慮する。</p> <h4>役割のテーラリング<a href="#役割のテーラリング"><span></span></a></h4> <p>(このプロセスのできるだけ早い段階でプロジェクト・マネージャーを任命することがグッド・プラクティスですが、プロセスの後半までプロジェクト・マネージャーが任命されていない場合は、プロジェクト・エグゼクティブまたはプロジェクト・エグゼクティブによって任命された人が必要なマネジメント成果物を作成しても構いません。同様に、プロジェクト・エグゼクティブはビジネス・ケース概要を自ら作成する必要はなく、代わりに別の担当者に作成を依頼できます。各役割の義務に対する説明責任の一元化は維持されます。)</p> <h3>責任<a href="#責任"><span></span></a></h3> <table><thead><tr><th>活動</th><th>ビジネス・レイヤー</th><th>プロジェクト・エグゼクティブ</th><th>シニア・ユーザー</th><th>シニア・サプライヤー</th><th>プロジェクト・マネージャー</th><th>チーム・マネージャー</th><th>プロジェクト保証</th><th>プロジェクト支援</th></tr></thead><tbody><tr><td>プロジェクト・エグゼクティブとプロジェクト・マネージャーの任命</td><td>A/R¹</td><td>R</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>前回の教訓の評価</td><td>C</td><td>A</td><td></td><td></td><td>R</td><td></td><td></td><td></td></tr><tr><td>ビジネス・ケース概要の準備</td><td>C</td><td>A/R</td><td>C³</td><td>C³</td><td>R</td><td></td><td></td><td></td></tr><tr><td>プロジェクト・マネジメント・チームの任命</td><td>A</td><td>R</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>プロジェクト・アプローチの選択</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>C²</td><td>C</td><td></td></tr><tr><td>プロジェクト要約書のとりまとめ</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td></td><td>C</td><td>C</td></tr><tr><td>立ち上げステージの計画</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>I²</td><td>C</td><td>C</td></tr><tr><td>プロジェクトの立ち上げ要求</td><td></td><td>A</td><td>C</td><td>C</td><td>R</td><td>I²</td><td>C</td><td>I</td></tr></tbody></table> <p>R = 実行責任、A = 説明責任、C = 協議先、I = 情報先</p> <ul> <li><strong>A/R¹</strong>: ビジネスは、プロジェクト・エグゼクティブとプロジェクト・マネージャーの任命に説明責任を負います。また、ビジネスはプロジェクト・エグゼクティブを任命する実行責任があります。</li> <li><strong>C²/I²</strong>: プロジェクト・マネジメント・チームを設計および任命するときにチーム・マネージャーが特定された場合、チーム・マネージャーがそのステージに関与しているのであれば、プロジェクト・アプローチについて協議し、立ち上げステージのステージ計画書の重要な詳細を通知することがグッド・プラクティスです。</li> <li><strong>C³</strong>: 任命された場合</li> </ul> <h3>プロセスへのプラクティスの適用<a href="#プロセスへのプラクティスの適用"><span></span></a></h3> <table><thead><tr><th>プラクティス</th><th>プロジェクトの始動プロセスへの適用</th></tr></thead><tbody><tr><td><strong>ビジネス・ケース</strong></td><td>ビジネス・ケースは、プロジェクト権限委任と学んだ教訓から得られた理解と、ビジネスおよび将来のユーザーとの協議に基づいて、アウトラインとして作成されるとともにプロジェクト要約書の一部を形成します</td></tr><tr><td><strong>組織化</strong></td><td>プロジェクト・エグゼクティブとプロジェクト・マネージャーはビジネスによって任命され、プロジェクトに必要なプロジェクト・マネジメント・チーム組織を判断し、プロジェクト立ち上げに必要な役割に人を任命します</td></tr><tr><td><strong>計画</strong></td><td>この早い段階で判明している主要なマイルストーンは、プロジェクト要約書に組み込まれます。<br />プロジェクト・エグゼクティブとプロジェクト・マネージャーは、このプロセスの後に使用されるプロジェクト・アプローチを開発し、デリバリー手法とプロジェクト計画書を決めます。ステージの数はこの時点で特定される場合があり、プロジェクト・アプローチで記録される場合もあります。<br />プロジェクト・マネージャーは、プロジェクトを正常に開始するために必要な成果物と作業、およびステージの期間とコストを詳述した立ち上げステージのステージ計画書を作成します</td></tr><tr><td><strong>品質</strong></td><td>ユーザーの期待品質と、この早い段階で判明している仕様や標準は、プロジェクト成果物記述書に組み込まれ、記録されます。ユーザーの期待品質は、このプロセスの後、プロジェクトの立ち上げ時や、個々の成果物記述書の開発を通じて各ステージを計画立案するときにさらに洗練されます</td></tr><tr><td><strong>リスク</strong></td><td>高いレベルのリスクが捕捉され、プロジェクト要約書に組み込まれます</td></tr><tr><td><strong>課題</strong></td><td>上位レベルの課題が補足され、プロジェクト要約書に組み込まれます</td></tr><tr><td><strong>進捗</strong></td><td>プロジェクトの既知の許容度が特定され、プロジェクト要約書に組み込まれますプロジェクトの既知の許容度はこのプロセスの後に洗練され、承認されます。<br />立ち上げステージの許容度が特定され、承認のためのステージ計画書に組み込まれます</td></tr></tbody></table>category:项目管理tag:プロジェクトtag:マネジメントtag:プロセスtag:プロジェクトの始動https://blog.issyuu.com/zh/post/pm-processes-dzh:pm-processes-d生きている限り、学び続けるWed, 15 Apr 2026 04:12:12 GMT<h2>プロセス<a href="#プロセス"><span></span></a></h2> <blockquote> <p>プロセスの目的は、特定の達成目標を達成するために、インプットとアウトプットを定義した一連の活動(アクション)を構造化し、プロジェクトを正しく指揮・管理・提供する。</p> </blockquote> <ul> <li> <ol> <li><strong>構成</strong></li> </ol> <blockquote> <p>7つのプロセスが定義されている。それぞれのプロセスには、適切な指揮・管理・提供を行うために必要な活動が含まれている。</p> </blockquote> <ul> <li>1.1. <strong>プロジェクトの始動(Starting up a Project)</strong>: 実行可能性の確認。</li> <li>1.2. <strong>プロジェクトの指揮(Directing a Project)</strong>: プロジェクト委員会による意思決定。</li> <li>1.3. <strong>プロジェクトの立ち上げ(Initiating a Project)</strong>: 詳細計画とベースライン策定。</li> <li>1.4. <strong>ステージのコントロール(Controlling a Stage)</strong>: PMによる日々の管理。</li> <li>1.5. <strong>成果物デリバリーのマネジメント(Managing Product Delivery)</strong>: チームによる制作。</li> <li>1.6. <strong>ステージ境界のマネジメント(Managing a Stage Boundary)</strong>: 次のステージへの準備。</li> <li>1.7. <strong>プロジェクトのクローズ(Closing a Project)</strong>: 正式な終了手続き。</li> </ul> </li> <li> <ol> <li><strong>ステージ構成</strong></li> </ol> <blockquote> <p>プロジェクトの規模に関わらず、時間軸においては少なくとも以下の2つのステージが必ず存在する。</p> </blockquote> <ul> <li><strong>立ち上げステージ(Initiation Stage)</strong></li> <li><strong>最終ステージ(Final Stage)</strong> ※プロジェクトの規模や必要性に応じて、これら2つのステージの間に複数の中間ステージを設けることもできる。</li> </ul> </li> </ul> <h3>ライフサイクル<a href="#ライフサイクル"><span></span></a></h3> <h4>プロジェクト開始前<a href="#プロジェクト開始前"><span></span></a></h4> <blockquote> <p>プロジェクトが正式に動き出す前には、アイデアやニーズを具体化し、その妥当性を検証する「準備段階」が必要である。</p> </blockquote> <ul> <li> <ol> <li>プロジェクトのトリガー(プロジェクト権限委任) プロジェクトが始まるきっかけを<strong>プロジェクト権限委任</strong>と呼ぶ。 <ul> <li><strong>提供元</strong>: ビジネス(プロジェクトを委託する組織)から提供される。</li> <li><strong>形態</strong>: 口頭による指示から、詳細に定義された正式な文書まで、その形式は多岐にわたる。</li> </ul> </li> </ol> </li> <li> <ol> <li>プロジェクトの始動(Starting up a Project)プロセス プロジェクトを正式に開始する前に、そのプロジェクトに<strong>価値があり、かつ実行可能であるか</strong>を評価・確認する。 <ul> <li><strong>主な活動</strong>: <ul> <li>プロジェクト・マネージャー(PM)およびプロジェクト委員会の任命。</li> <li><strong>プロジェクト要約書</strong>の作成。</li> <li>最初のステージ(立ち上げステージ)のための<strong>ステージ計画書</strong>の作成。</li> </ul> </li> </ul> </li> </ol> </li> <li> <ol> <li>プロジェクトの指揮プロセス プロジェクトを実際に開始するかどうかの決定は、プロジェクト委員会このプロセスを通じて行う。 <ul> <li><strong>レビューと意思決定</strong>: <ul> <li>プロジェクト委員会は、提出されたプロジェクト要約書とステージ計画書を精査する。</li> <li>プロジェクトの開始を承認するかどうか、および必要な人員やリソースの割り当てについて最終決定を下す。</li> </ul> </li> </ul> </li> </ol> </li> </ul> <h4>立ち上げステージ<a href="#立ち上げステージ"><span></span></a></h4> <blockquote> <p>プロジェクトの始動が承認された後、詳細な計画を策定し、管理体制を構築するステージである。</p> </blockquote> <ul> <li> <ol> <li>プロジェクトの立ち上げ(Initiating a Project)プロセス プロジェクトを成功させるために、以下の重要な要素を確立し、基盤を固める。 <ul> <li><strong>詳細計画の立案</strong>: スケジュールやリソースの明確化。</li> <li><strong>ガバナンスの構築</strong>: プロジェクト・マネジメント・アプローチとコントロールの定義。</li> <li><strong>ビジネス・ケースの精査</strong>: 投資対効果や正当性を裏付ける堅固なビジネス・ケースの開発。</li> <li><strong>ベネフィット・マネジメント</strong>: 成果がもたらす利益をどのようにレビューするかを決定。</li> </ul> </li> </ol> </li> <li> <ol> <li>次のステージの準備 立ち上げステージの後半で、<strong>ステージ境界のマネジメント</strong>プロセスを使用して、次のステージに関する詳細な計画を作成する。</li> </ol> </li> <li> <ol> <li>ステージの終了と認可 立ち上げステージは、プロジェクト委員会による最終レビューをもって終了する。 <ul> <li><strong>PID(プロジェクト立ち上げ文書)の作成</strong>: ステージの最後には、すべての情報をまとめた<strong>PID</strong>を作成する。</li> <li><strong>意思決定</strong>: プロジェクト委員会は、<strong>プロジェクトの指揮</strong>プロセスを用い、プロジェクト全体および次ステージを認可するかどうかを決定する。</li> <li><strong>PID(プロジェクト立ち上げ文書)の承認</strong>: 承認されたPIDは、その後のプロジェクトの進捗を評価するための<strong>ベースライン</strong>として保存される。 ※PIDはプロジェクト期間中に変更される可能性が高いため、初期状態を記録しておくことが重要である。</li> </ul> </li> </ol> </li> </ul> <h4>後続ステージ<a href="#後続ステージ"><span></span></a></h4> <blockquote> <p>立ち上げステージ以降、プロジェクトは一つまたは複数の実行ステージ(後続ステージ)を経て進行する。</p> </blockquote> <p>＊このステージでは、日々の管理、成果物の作成、ステージの切り替えが中心となる。</p> <ul> <li> <ol> <li>ステージのコントロール(Controlling a Stage)プロセス プロジェクト委員会は、ステージごとの日々の管理をPMに委任する。 <ul> <li><strong>PMの責務</strong>: 承認された計画に沿って進捗しているか、予測が「許容度(トレランス)」の範囲内に収まっているかを常に確認する。</li> <li><strong>委員会への報告</strong>: PMは<strong>ハイライト報告書</strong>を定期的に提出し、プロジェクト委員会に進捗状況を通知する。</li> </ul> </li> </ol> </li> <li> <ol> <li>成果物デリバリーのマネジメント(Managing Product Delivery)プロセス PMとチーム・マネージャー(またはチーム・メンバー)間のやり取りを管理するプロセスである。 <ul> <li><strong>作業の割当</strong>: PMは実行すべき作業を<strong>WP</strong>としてアサインする。</li> <li><strong>チームからの報告</strong>: チーム側は、<strong>チェックポイント報告書</strong>を通じて作業の進捗状況をPMに報告する。</li> </ul> </li> </ol> </li> <li> <ol> <li>ステージ境界のマネジメント(Managing a Stage Boundary)プロセス 各ステージの終盤に行われる、ステージの<strong>締め</strong>と<strong>次への準備</strong>のためのプロセスである。 <ul> <li><strong>実績報告と許可依頼</strong>: PMは現在のステージの実施状況を報告し、プロジェクト委員会に対して次のステージへ進むための許可を依頼する。</li> <li><strong>計画と更新</strong>: 次のステージの詳細計画を作成すると同時に、最新の状況に基づいて<strong>ビジネス・ケース</strong>を更新する。</li> <li><strong>委員会の意思決定</strong>: プロジェクト委員会は、プロジェクトがビジネス戦略と整合しており、実行可能性(妥当性)があるかを評価し、次ステージの開始を認可するか決定する。</li> </ul> </li> </ol> </li> </ul> <h4>最終ステージ<a href="#最終ステージ"><span></span></a></h4> <blockquote> <p>プロジェクトは一時的な組織体であるため、最終ステージの終盤で正式に終了させる手続きが必要となる。</p> </blockquote> <ul> <li> <ol> <li>プロジェクトのクローズ(Closing a Project)プロセス</li> </ol> <ul> <li>1.1. 成果物の移転とオーナーシップの確定 プロジェクト期間中、個別の成果物は随時運用側へ移転・移行されている場合がある。クローズに際しては、以下の点を確認する。 <ul> <li><strong>受領者の準備</strong>: 成果物の受領者がそれらを所有し、継続して使用できる状態にあること。</li> <li><strong>ビジネス側の責任</strong>: ビジネス(委託組織)がプロジェクト成果物の全体的なオーナーシップを完全に引き継げる状態にあること。</li> </ul> </li> <li>1.2. プロジェクトの評価とリソースの解放 プロジェクトを正式に終了させるために、以下の事務的・管理的作業を行う。 <ul> <li><strong>パフォーマンス評価</strong>: プロジェクトの最終的な実績を、当初の計画書と比較して評価する。</li> <li><strong>リソースのリリース</strong>: プロジェクトにアサインされていた人員やリソースを解放する。</li> <li><strong>文書の保管</strong>: 後の参照や監査に備え、プロジェクト関連文書を適切にアーカイブ(保管)する。</li> </ul> </li> <li>1.3. プロジェクト終了後の活動 プロジェクトが終了した後にしか評価できない事項についても、この段階で整理を行う。 <ul> <li><strong>ベネフィット・レビュー計画の確認</strong>: プロジェクト成果物の使用開始後に現れるベネフィットを、いつ、誰が、どのように評価するかを定めた計画を確認、または必要に応じて修正する。</li> </ul> </li> </ul> </li> </ul> <h4>プロジェクト終了後<a href="#プロジェクト終了後"><span></span></a></h4> <blockquote> <p>プロジェクトが正式にクローズした後も、価値の実現を確認するための活動は継続される。</p> </blockquote> <ul> <li> <ol> <li>ベネフィットの実現 一部のベネフィットはプロジェクト期間中に実現することもあるが、大半はプロジェクト完了後の運用フェーズで実現される。</li> </ol> </li> <li> <ol> <li>プロジェクト終了後のレビュー 計画に基づき、プロジェクト終 了後に1回以上のレビューが実施される。これは期待された成果が実際に出ているかを確認するために不可欠である。</li> </ol> </li> <li> <ol> <li>ベネフィット・マネジメント・アプローチの役割 ベネフィットを確実に把握するため、以下の事項を「ベネフィット・マネジメント・アプローチ」に文書化しておく必要がある。 <ul> <li><strong>時期と方法</strong>: ベネフィット・レビューをいつ、どのように実施するか。</li> <li><strong>責任の所在</strong>: 誰がレビューに対して<strong>実行責任</strong>と<strong>説明責任</strong>を負うか。</li> </ul> </li> </ol> </li> </ul> <h3>プロセス記述の構成要素<a href="#プロセス記述の構成要素"><span></span></a></h3> <table><thead><tr><th>項目</th><th>内容</th></tr></thead><tbody><tr><td><strong>目的</strong></td><td>プロセスを実行する理由</td></tr><tr><td><strong>達成目標</strong></td><td>プロセスで達成すべき固有の目標</td></tr><tr><td><strong>位置づけ</strong></td><td>他のプロセスとの関係、成果物のIN/OUT</td></tr><tr><td><strong>活動</strong></td><td>推奨される処置の一連の流れ</td></tr><tr><td><strong>責任</strong></td><td>RACI 図による役割分担の定義</td></tr></tbody></table>category:项目管理tag:プロジェクトtag:マネジメントtag:プロセスhttps://blog.issyuu.com/zh/post/pm-processes-szh:pm-processes-s生きている限り、学び続けるWed, 15 Apr 2026 04:12:12 GMT<h2>プロセス<a href="#プロセス"><span></span></a></h2> <blockquote> <p>プロセスの目的は、特定の達成目標を達成するために、インプットとアウトプットを定義した一連の活動(アクション)を構造化し、プロジェクトを正しく指揮・管理・提供する。</p> </blockquote> <h3>基本定義<a href="#基本定義"><span></span></a></h3> <ul> <li><strong>定義</strong>: 特定の目標を達成するための構造化された一連の活動(インプット、処置、アウトプット)。</li> <li><strong>構成</strong>: 全身で<strong>7つのプロセス</strong>があり、プロジェクトを指揮・管理・提供するために必要な活動が含まれる。</li> <li><strong>ステージ構成</strong>: 常に<strong>立ち上げステージ</strong>と<strong>最終ステージ</strong>の最低 2つが存在する。</li> </ul> <h3>ライフサイクル<a href="#ライフサイクル"><span></span></a></h3> <h4>プロジェクト開始前<a href="#プロジェクト開始前"><span></span></a></h4> <ul> <li><strong>トリガー</strong>: <strong>プロジェクト権限委任</strong>がビジネス側から提供されることで開始される。</li> <li><strong>プロジェクトの始動</strong>: <ul> <li>価値と実行可能性を評価。</li> <li>PMとプロジェクト委員会を任命。</li> <li>プロジェクト要約書とステージ計画書を作成。</li> </ul> </li> </ul> <h4>立ち上げステージ<a href="#立ち上げステージ"><span></span></a></h4> <ul> <li><strong>プロジェクトの立ち上げ</strong>: <ul> <li>詳細計画、ビジネス・ケース、コントロールを確立。</li> <li><strong>プロジェクト立ち上げ文書(PID)</strong> をベースラインとして保存。</li> </ul> </li> <li><strong>プロジェクトの指揮</strong>: <ul> <li>委員会がプロジェクトの認可および次ステージ進出の可否を決定する。</li> </ul> </li> </ul> <h4>後続ステージ(実行フェーズ)<a href="#後続ステージ実行フェーズ"><span></span></a></h4> <ul> <li><strong>ステージのコントロール</strong>: <ul> <li>PMによる日々の管理。許容範囲内での進捗確認と、ハイライト報告書で委員会へ通知。</li> </ul> </li> <li><strong>成果物デリバリーのマネジメント</strong>: <ul> <li>チームへの作業割当(ワーク・パッケージ)と、チェックポイント報告書で進捗報告。</li> </ul> </li> <li><strong>ステージ境界のマネジメント</strong>: <ul> <li>各ステージ終盤で実施。次ステージの計画、ビジネス・ケースの更新、継続の認可依頼を行う。</li> <li>例外計画書の作成時にも使用される。</li> </ul> </li> </ul> <h4>最終ステージ<a href="#最終ステージ"><span></span></a></h4> <ul> <li><strong>プロジェクトのクローズ</strong>: <ul> <li>成果物を運用側へ移転・移行。</li> <li>パフォーマンス評価、リソースを解放、プロジェクト文書を保管。</li> <li>終了後の<strong>ベネフィット・レビュー</strong>計画を更新。</li> </ul> </li> </ul> <h4>プロジェクト終了後<a href="#プロジェクト終了後"><span></span></a></h4> <ul> <li><strong>ベネフィット・レビュー</strong>: プロジェクト完了後に実現するベネフィットを評価。</li> <li><strong>ベネフィット・マネジメント・アプローチ</strong>: レビューの時期、方法、責任の所在を定義。</li> </ul> <h3>プロセス記述の構成要素<a href="#プロセス記述の構成要素"><span></span></a></h3> <table><thead><tr><th>項目</th><th>内容</th></tr></thead><tbody><tr><td><strong>目的</strong></td><td>プロセスを実行する理由</td></tr><tr><td><strong>達成目標</strong></td><td>プロセスで達成すべき固有の目標</td></tr><tr><td><strong>位置づけ</strong></td><td>他のプロセスとの関係、成果物のIN/OUT</td></tr><tr><td><strong>活動</strong></td><td>推奨される処置の一連の流れ</td></tr><tr><td><strong>責任</strong></td><td>RACI 図による役割分担の定義</td></tr></tbody></table> <h3>7つのプロセス一覧<a href="#7つのプロセス一覧"><span></span></a></h3> <ol> <li><strong>プロジェクトの始動(Starting up a Project)</strong>: 実行可能性の確認。</li> <li><strong>プロジェクトの指揮(Directing a Project)</strong>: プロジェクト委員会による意思決定。</li> <li><strong>プロジェクトの立ち上げ(Initiating a Project)</strong>: 詳細計画とベースライン策定。</li> <li><strong>ステージのコントロール(Controlling a Stage)</strong>: PMによる日々の管理。</li> <li><strong>成果物デリバリーのマネジメント(Managing Product Delivery)</strong>: チームによる制作。</li> <li><strong>ステージ境界のマネジメント(Managing a Stage Boundary)</strong>: 次のステージへの準備。</li> <li><strong>プロジェクトのクローズ(Closing a Project)</strong>: 正式な終了手続き。</li> </ol>category:项目管理tag:プロジェクトtag:マネジメントtag:プロセスhttps://blog.issyuu.com/zh/post/pm-processeszh:pm-processes生きている限り、学び続けるWed, 15 Apr 2026 04:12:12 GMT<h2>プロセス<a href="#プロセス"><span></span></a></h2> <p>定義：プロセス: 特定の達成目標を達成するための一連の処置およびそのインプットとアウトプットを定義する構造化された一連の活動。</p> <p>7 つのプロセスがあります。各プロセスには、プロジェクトを正しく指揮、管理、提供するために必要となる一連の活動が含まれています。 立ち上げステージと最終ステージという少なくとも 2 つのステージが常に存在し、その間にいくつかステージが存在する場合があります。</p> <h3>ジャーニー<a href="#ジャーニー"><span></span></a></h3> <h4>プロジェクト開始前<a href="#プロジェクト開始前"><span></span></a></h4> <p>プロジェクトの開始前に、アイデアやニーズを持っている人がいます。プロジェクトのトリガー（さまざまな方法で発生する可能性があります）は、プロジェクト権限委任と呼ばれます。プロジェクト権限委任は、ビジネス（プロジェクトを委託する組織）が提供するものであり、その形態は口頭での指示から、明確に定義され正当性が確保されたプロジェクトの定義まで多岐にわたります。 プロジェクトを正式に開始する前に、プロジェクトに価値があり実行可能であることを評価および確認することが重要です。この作業はプロジェクトの始動プロセスで行われます。プロジェクトの始動プロセスでは、プロジェクト・マネージャーとプロジェクト委員会が任命され、プロジェクト要約書と立ち上げステージのステージ計画書が作成されます。プロジェクト立ち上げを進める決定は、プロジェクト委員会がプロジェクトを指揮する独自のプロセスを使用して行います。その後、プロジェクト委員会はプロジェクト要約書とステージ計画書をレビューし、プロジェクトの開始と必要な人員およびリソースの割り当てについてその可否と方法を決定します。</p> <h4>立ち上げステージ<a href="#立ち上げステージ"><span></span></a></h4> <p>プロジェクトを進めることが決定されると、適切なレベルで詳細を計画する必要があります。計画立案、プロジェクト・マネジメント・アプローチとコントロールの確立、堅固なビジネス・ケースの開発、ベネフィットのレビュー方法については、プロジェクトの立ち上げプロセスで取り上げます。また、立ち上げステージでは、ステージ境界のマネジメント・プロセスを使用して、次のステージの詳細を計画します。 立ち上げステージは、プロジェクト立ち上げ文書がプロジェクト委員会によってレビューされることで終了します。ここでは、再び独自のプロセス（プロジェクトの指揮）を使用して、プロジェクトと次に進めるステージを認可するかどうかを決定します。プロジェクト立ち上げ文書の内容はプロジェクト期間中に（変更コントロールの下で）変更される可能性が高いため、このバージョンは今後のレビューの元となるベースラインとして保存しておきます。</p> <h4>後続ステージ<a href="#後続ステージ"><span></span></a></h4> <p>プロジェクト委員会は、ステージごとにプロジェクト・マネージャーに日々のコントロールを委任します。プロジェクト・マネージャーは、承認された計画書に沿ってプロジェクトが進捗しており、プロジェクトに対する予測が合意された許容度の範囲内にあることを確認する必要があります。プロジェクト・マネージャーは、ハイライト報告書を使用してプロジェクト委員会に進歩を定期的に通知します。各ステージをコントロールする活動については、ステージのコントロール・プロセスで取り上げます。 プロジェクト・マネージャーは、アサインされたワーク・パッケージを実行するチーム・マネージャーまたはチーム・メンバーに、実行する作業をアサインする必要があります。次に、チーム・マネージャーまたはチーム・メンバーは、チェックポイント報告書を通じてプロジェクト・マネージャーに進捗を通知します。この作業は、成果物デリバリーのマネジメント・プロセスでカバーされています。 各ステージの終盤で、プロジェクト・マネージャーは現在のステージの実施状況を報告して次のステージに進む許可を依頼し、ビジネス・ケースを更新し、次のステージを詳細に計画します。プロジェクト・マネージャーは、プロジェクト委員会がプロジェクトの継続的な実行可能性について評価し、次のステージに進むことを認可するかを決定するために必要な情報を提供します。プロジェクト委員会は常に、プロジェクトがビジネス戦略に整合していることを確認する必要があります。各ステージ境界を管理する活動については、ステージ境界のマネジメント・プロセスで取り上げます。</p> <h4>最終ステージ<a href="#最終ステージ"><span></span></a></h4> <p>プロジェクトはー時的に実行するものであるため、最終ステージの終盤でプロジェクトのクローズ・プロセスを開始するタイミングがあります。 プロジェクトのライフサイクルを通して、プロジェクトは個々の成果物を運用上の使用に移転および移行していた可能性があります。ここでプロジェクト委員会は、プロジェクトの成果物の受領者が成果物を所有し、継続して使用できる状態であり、ビジネスがプロジェクト成果物の全体的なオーナーシップを持つことができることを確認する必要があります。この場合、プロジェクトはクローズできます。プロジェクト文書は保管する必要があります。また、プロジェクトのパフォーマンスを当初の計画書と比較して評価し、プロジェクトにアサインされていた人員とリソースをリリースします。クローズ活動には、プロジェクト終了後のベネフィット・レビューの計画立案を確認または修正することも含まれます。これはプロジェクト成果物を使用しないと（つまりプロジェクト終了後でないと）評価できないベネフィットのレビューです。</p> <h4>プロジェクト終了後<a href="#プロジェクト終了後"><span></span></a></h4> <p>ベネフィットにはプロジェクト中に実現するものもありますが、ほとんどの場合、ほぼすべてのべネフィットはプロジェクトの完了後に実現します。したがって、プロジェクト終了後に1 回以上のベネフィット・レビューが行われる可能性があります。プロジェクトのベネフィット・マネジメント・アプ一チでは、ベネフィット・レビューをいつどのように行うか、そして誰がベネフィット・レビューに対して実行責任と説明責任を負うかを文書化します。</p> <h3>プロセスに関する章の形式<a href="#プロセスに関する章の形式"><span></span></a></h3> <p>各プロセスは、以下の構成と形式で説明されています。 * <strong>目的</strong>：プロセスを実行するには理由がなければならない。 * <strong>達成目標</strong>：プロセスで達成する固有の目標がなければならない。 * <strong>位置づけ</strong>：プロジェクトおよびビジネス内で行われている他のプロセスおよび活動の状況の中で、各プロセスを説明する。位置づけには、各活動のマネジメント成果物のインプット/アウトプットの表が含まれる。 * <strong>活動</strong>：各プロセスは一連の活動で構成され、プロジェクト中に順にまたは並行して実施される。活動は、特定の結果を達成するように設計された一連の推奨される処置から構成される。 * <strong>責任</strong>：各プロセスの章の RACI の表は、各プロセスの責任について説明する。</p> category:项目管理tag:プロジェクトtag:マネジメントtag:プロセス