プロジェクトマネジメントガイド · 計画とスコープ
プロジェクト立ち上げ文書（PID）：記載内容と例
プロジェクト開始文書（PID）とは、プロジェクトを定義し、その管理方法を説明し、提供開始前にプロジェクト委員会が承認するベースラインとなる一連の情報です。PRINCE2に由来し、プロジェクトマネージャーが開始段階で取りまとめるものですが、多くの組織が手法を問わずPIDを使っています。このガイドでは、PIDの内容、作成方法、実例、憲章との違いを解説します。
要点
- PIDは、プロジェクトが何を、なぜ提供するのか、どのように管理されるのか、どの範囲内で行うのかを定義します。
- PRINCE2では、プロジェクトマネージャーが「プロジェクトの開始」プロセスでPIDを取りまとめ、プロジェクト委員会が承認します。
- 承認されるとPIDはベースライン化され、変更は変更管理を通じて行われ、多くの場合ステージ境界でレビューされます。
- PIDに定める許容範囲により、プロジェクトマネージャーは小さな逸脱をいちいちエスカレーションせずに行動できます（例外による管理）。
- プロジェクトに合わせて規模を調整しましょう。小規模なプロジェクトやアジャイルのプロジェクトには短いPIDで十分ですが、大規模なプログラムにはずっと多くの内容が必要です。
プロジェクト開始文書とは？
A プロジェクト開始文書（PID） は、プロジェクトを定義し、その管理方法を示す情報の集まりです。プロジェクトの定義、ビジネスケース、チーム構成、プロジェクト計画、マネジメントのアプローチ、コントロール、調整内容をまとめたものです。プロジェクト委員会が承認すると、PIDはプロジェクトの運営と評価のベースラインになります。
PRINCE2では正式には プロジェクト開始文書一式（project initiation documentation）と呼びます。1つのファイルである必要がないためです。すべてがまとめて承認・管理される限り、単一の文書でも、リンクされた文書群でも、プロジェクト管理ツール上のページでも構いません。
PIDは、意思決定者がお金と人を投入する前に答えなければならない問いに答えます：
- 具体的に何を行い、何を行わないのか？
- なぜ行う価値があり、どのような便益を期待するのか？
- 誰が何に責任を持ち、誰が決めるのか？
- どれくらいの期間と費用がかかるのか？
- 品質、リスク、課題、変更、コミュニケーションをどのように管理するのか？
- プロジェクトマネージャーがエスカレーションしなければならなくなるまで、どの程度の変動が許されるのか？
この用語は PRINCE2に由来しますが、PIDは英国の公共機関、医療サービス、PRINCE2に厳密に従っていない企業でも広く使われています。
PIDが重要な理由
PRINCE2では、PIDをプロジェクトマネージャーとプロジェクト委員会の間の契約と位置付けています。委員会が合意した内容と、プロジェクトマネージャーが提供を約束した内容を記録するものです。実際には、優れたPIDから次のものが得られます：
- 明確な実施・中止の判断： 委員会は大まかなアイデアではなく、全体像に基づいてプロジェクトを承認します。
- ベースライン： 進捗、コスト、スコープ、便益を、承認された内容に照らして測定します。
- 例外による管理： 合意した許容範囲により、プロジェクトマネージャーはプロジェクトを日々運営し、限度を超えると予測された場合にのみエスカレーションします。
- 明確なガバナンス： 役割、意思決定権、報告ラインについて、問題が起きる前に合意します。参考： プロジェクトガバナンス.
- 継続性： 新しいチームメンバー、サプライヤー、委員会メンバーが、1か所でプロジェクトを理解できます。
- 終了時の参照資料： 最後に、委員会は提供されたものとPIDで約束されたものを比較します。
PRINCE2におけるPIDの位置付け
PIDはPRINCE2プロジェクトの2番目のステージである開始ステージで作成され、その後全体を通じて使われます。下表はPRINCE2のプロセスに沿ってその流れを示しています。
| PRINCE2のプロセス | PIDに対して行われること |
|---|---|
| プロジェクトの立ち上げ | PIDが作成される前に、委員会が開始ステージに進む価値があるかを判断できるよう、短いプロジェクト概要書と概略のビジネスケースを作成します。 |
| プロジェクトの指揮（開始の承認） | プロジェクト委員会が開始ステージへの投資に同意します。 |
| プロジェクトの開始 | プロジェクトマネージャーがマネジメントのアプローチ、プロジェクト計画、コントロール、詳細なビジネスケースを作成し、PIDに取りまとめます。 |
| プロジェクトの指揮（プロジェクトの承認） | プロジェクト委員会がPIDをレビューして承認します。その後ベースライン化されます。 |
| ステージ境界の管理 | プロジェクトマネージャーは必要に応じてPID（ビジネスケースやプロジェクト計画など）を更新し、次のステージの前に委員会がレビューできるようにします。 |
| プロジェクトの終了 | 最終的な成果を、当初のベースラインと承認された変更と比較するためにPIDを使います。 |
PRINCE2 7（PeopleCertが2023年に発行）では、7つのテーマの名称が次に改められました： プラクティス（ビジネスケース、組織、計画、品質、リスク、課題、進捗）。また、商業、サステナビリティ、デジタルとデータに関するマネジメントのアプローチが追加され、人に関する新しい章が導入されました。PIDは引き続き開始の中心に位置しています。
フレームワークを比較している場合は、次をご覧ください： PMBOKとPRINCE2の比較.
プロジェクト開始文書の内容
PRINCE2のガイダンスでは、PIDは次の各部をまとめたものと説明されています。PRINCE2以外でも、ほとんどのPIDテンプレートは見出しこそ異なるものの、同様の構成になっています。
| PIDのセクション | 含まれるもの |
|---|---|
| プロジェクトの定義 | 背景、目標、望ましい成果、スコープと除外事項、成果物、制約条件、前提条件、ユーザーとインターフェース |
| ビジネスケース | 理由、検討した選択肢、期待される便益と負の便益、コスト、期間、投資評価、主要なリスク |
| プロジェクトマネジメントチームの構成 | プロジェクト委員会、プロジェクトマネージャー、保証とサポートの役割。組織図で示すことが多い |
| 役割記述 | 各役割の責任と権限 |
| マネジメントのアプローチ | 品質、リスク、課題と変更、コミュニケーションなどの領域をどのように管理するか |
| プロジェクト計画 | ステージ、主要な成果物、マイルストーン、資源、コスト、期間 |
| プロジェクトのコントロール | ステージの境界、許容範囲、報告（ハイライト報告書など）、エスカレーション |
| 調整 | プロジェクトに合わせて手法をどのように調整したか、その理由 |
プロジェクトの定義
これはPIDの核心です。測定可能な プロジェクト目標、明示的な除外事項を含むスコープ記述書、受入基準付きの 成果物 の一覧、そして前提となる 制約条件 と前提条件を記述します。プロジェクトの後半に起こる多くの争いは、ここでの曖昧な定義に端を発しています。
PRINCE2 7におけるマネジメントのアプローチ
マネジメントのアプローチ（旧版では戦略と呼ばれていました）は、特定の領域をこのプロジェクトでどのように扱うかを説明するものです。PRINCE2 7では、次のような領域のアプローチを示しています：
- 品質： 標準、品質手法、責任、記録。
- リスク： 尺度、責任者、レビューの頻度を含め、リスクをどのように特定、評価、管理するか。参考： プロジェクトリスクマネジメント.
- 課題と変更管理： 課題と変更要求をどのように記録、評価、決定するか。
- コミュニケーション： どの情報を、誰に、いつ、どのように伝えるか。参考： コミュニケーション計画.
- 商業： サプライヤーと契約をどのように管理するか（PRINCE2 7で新設）。
- サステナビリティ： プロジェクトがサステナビリティ目標をどのように達成するか（PRINCE2 7で新設）。
- デジタルとデータ： データとデジタル技術をどのように扱うか（PRINCE2 7で新設）。
PRINCE2では便益マネジメントのアプローチも使います。これは、便益をいつどのように測定するかを示すもので、測定はプロジェクトの終了後に行われることが多くあります。
プロジェクトのコントロールと許容範囲
コントロールは、委員会が詳細を管理せずに主導権を保つ方法を説明します。プロジェクトをどのようにマネジメントステージに分けるか、どの許容範囲を適用するか、プロジェクトマネージャーがどの報告書をどの頻度で作成するか、いつ例外を提起しなければならないかです。許容範囲については以下で詳しく説明します。
PIDとプロジェクト憲章、ビジネスケース、計画書の違い
立ち上げ時の文書には重複するものがいくつかあります。下表はそれぞれの位置付けを示しています。
| 文書 | 目的 | 時期 | 承認者 |
|---|---|---|---|
| プロジェクト概要書（PRINCE2） | 開始ステージに進むかどうかを判断するための短い概要 | 立ち上げ | プロジェクト委員会 |
| ビジネスケース | 投資を正当化する。全期間を通じて最新の状態に保つ | 立ち上げ時に概略、開始段階で詳細化 | エグゼクティブまたはスポンサー |
| プロジェクト憲章 | プロジェクトとプロジェクトマネージャーを正式に承認する（PMBOK流） | 立ち上げ | スポンサー |
| プロジェクト開始文書 | プロジェクトの承認と管理のための完全なベースライン（PRINCE2） | 立ち上げ | プロジェクト委員会 |
| プロジェクトマネジメント計画書 | プロジェクトをどのように実行、監視、コントロール、終結するか（PMBOK流） | 計画 | スポンサー |
| 作業範囲記述書（SOW） | サプライヤーが行う作業を契約上記述したもの | 調達 | 発注者とサプライヤー |
違いを覚える最も簡単な方法： 憲章 は短く、プロジェクトが承認されたことを示します。 PID はより長く、何が承認され、どのように運営されるかを正確に示します。PIDにはプロジェクト計画が含まれますが、計画だけには含まれないビジネスケース、チーム構成、マネジメントのアプローチも含まれます。
A 作業範囲記述書 はさらに異なり、外部サプライヤーとの契約を統制するものです。一方、PIDはプロジェクトを内部的に統制します。
プロジェクト開始文書の書き方：9つの手順
以下の順序はほとんどのプロジェクトで有効です。PRINCE2ではこれらの手順は「プロジェクトの開始」プロセスで行われ、PRINCE2以外では開始フェーズを構成します。
- プロジェクト概要書または指示書を確認する。 背景、目標、概略のビジネスケース、スポンサーがすでに下した決定を確認します。また、次の結果が反映されていることを確認します： フィージビリティスタディ 。
- 調整について合意する。 規模、リスク、複雑さを踏まえてプロジェクトに必要な正式さの程度を決め、その決定を記録します。
- プロジェクトの定義を書く。 目標、スコープ、除外事項、成果物、受入基準、制約条件、前提条件、他のプロジェクトやシステムとのインターフェースを設定します。
- マネジメントのアプローチを定義する。 品質、リスク、課題と変更、コミュニケーション、その他の関連領域をどのように管理するかについて合意します。この時点で次を開始します： リスク登録簿 。
- プロジェクトマネジメントチームを編成する。 エグゼクティブまたはスポンサー、シニアユーザー、シニアサプライヤー、プロジェクトマネージャーを役割記述とともに指名します。 RACIマトリクス を使うと責任が明確になります。
- プロジェクト計画を作成する。 作業を成果物に分解し、ステージを定義し、工数、コスト、所要期間を見積もり、マイルストーンと依存関係を特定します。
- ビジネスケースを精緻化する。 詳細な計画を使ってコスト、期間、便益、リスクを更新します。役立つ場合は次を使いましょう： 費用便益分析 。
- コントロールと許容範囲を設定する。 ステージの境界、報告の頻度、時間、コスト、スコープなどの許容範囲、例外のエスカレーション方法について合意します。
- 取りまとめ、レビューし、承認を申請する。 各部の整合性を確認し、プロジェクト保証にレビューを依頼してから、次のステージの計画とともにPIDをプロジェクト委員会に提出します。
プロジェクト開始文書の例
以下の例は説明用に簡略化したものです。中規模の組織が顧客関係管理（CRM）システムを刷新する場合に、PIDの各部がどのような記述になるかを示しています。
| PIDのセクション | 記入例 |
|---|---|
| 背景 | 現在のCRMはベンダーのサポートが終了しており、新しい財務システムと連携できない。 |
| 目標 | 6月30日までにCRMを刷新する。有効な顧客レコードをすべて移行する。本番稼働前に営業・サービス部門のスタッフ85人全員を研修する。 |
| スコープ | 対象：選定支援、設定、データ移行、財務システム連携、研修。対象外：Webサイトとマーケティングオートメーション。 |
| 成果物 | 設定済みのCRM、移行・検証済みのデータ、財務システム連携、研修資料、サポートへの引き継ぎ。 |
| 制約条件と前提条件 | 予算は25万ポンドで固定。本番稼働は年度末を避けなければならない。財務システムのAPIが3月までに利用可能になることを前提とする。 |
| ビジネスケースの要約 | サポート切れのソフトウェアを運用するリスクを回避する。期待される便益は、手作業での再入力の削減と、営業マネージャー向けのレポートの改善。 |
| プロジェクトマネジメントチーム | エグゼクティブ：営業部長。シニアユーザー：カスタマーサービス責任者。シニアサプライヤー：CRMベンダーのアカウント責任者。プロジェクトマネージャー：社内。 |
| マネジメントのアプローチ | 品質：シニアユーザーがユーザー受入テストを承認。リスク：月次のリスクレビュー。変更：5,000ポンドを超える変更は委員会に付議。 |
| プロジェクト計画 | 4つのステージ：開始、設定と連携、移行とテスト、研修と本番稼働。 |
| 許容値 | 時間：前後2週間。コスト：前後5%。スコープ：必須要件は委員会の承認なしに削除できない。 |
| 報告 | 委員会への隔週のハイライト報告書。各ステージ境界でのステージ終了報告書。 |
| 調整 | 委員会は意思決定のたびではなく毎月開催。リスクと課題を統合した単一のログを使用。 |
各項目は、委員会が承認または異議を唱えられるほど具体的です。「顧客データを改善する」のような曖昧な項目では、委員会がプロジェクトに守らせる基準がありません。
許容範囲と例外による管理
許容範囲はPIDで最も有用な部分の1つであり、最も省略されがちな部分の1つでもあります。プロジェクトマネージャーが委員会に戻らずに意思決定できる、合意された限度のことです。
PRINCE2では、時間、コスト、スコープ、品質、リスク、便益などの領域に許容範囲を設定します。典型的な例：
| 領域 | 許容範囲の例 |
|---|---|
| 時間 | 本番稼働日の前後2週間 |
| コスト | 承認済み予算の前後5% |
| スコープ | Could-haveの機能は削除してよいが、Must-haveは削除できない |
| 品質 | 本番稼働時に許容される不具合のレベルを定義 |
| リスク | 委員会のレビューなしに、合意した影響度スコアを超えるリスクがないこと |
| メリット | 期待される便益は合意した割合の範囲で変動してよい |
許容範囲を超えると予測した場合、プロジェクトマネージャーは実際に超えるのを待たずに委員会に例外を提起します。これにより、委員会は必要な意思決定に集中でき、プロジェクトマネージャーはそれ以外のすべてについて明確な権限を持てます。当サイトの プロジェクト状況報告書 のガイドでは、これらの限度に照らして報告する方法を紹介しています。
小規模なプロジェクトやアジャイルのプロジェクトに合わせたPIDの調整
PRINCE2は手法を調整して使うことを前提としており、それはPIDにも当てはまります。短期の社内プロジェクトに40ページの文書は不要です。
- 小規模なプロジェクト： セクションを統合し、定義と計画は1ページにまとめ、品質、リスク、コミュニケーションについては書き直すのではなく組織の標準的なアプローチを参照します。
- アジャイルのプロジェクト： PRINCE2 AgileでもPIDを使いますが、ゴール、成果、許容範囲、仕事の進め方に重点を置きます。詳細なスコープは優先順位付きのバックログに置き、許容範囲は通常、時間とコストを固定したままスコープを柔軟に変えられるように設定します。
- 大規模またはリスクの高いプロジェクト： PIDはコントロールのための要約として保ち、詳細な計画、登録簿、アプローチは別の文書にリンクします。
PRINCE2のガバナンスとアジャイルな提供の組み合わせについて詳しくは、次をお読みください： PRINCE2とアジャイル.
PIDでよくある間違いとその回避方法
| 間違い | 代わりにすべきこと |
|---|---|
| 長いテンプレートをコピーしてすべてのセクションを埋める | 構成を調整し、セクションを短縮・削除した理由を記録する |
| 曖昧な目標とスコープ | 測定可能な目標を使い、除外事項を明示的に列挙する |
| 許容範囲がない、または許容範囲がゼロ | 例外による管理が機能するよう、現実的な限度について合意する |
| ビジネスケースを一度書いたきり忘れる | 各ステージ境界で更新し、プロジェクトにまだ価値があるか確認する |
| 役割の名前だけで説明がない | 意思決定権を含む短い役割記述を書く |
| PIDを承認のためだけの書類として扱う | 委員会の会議、ハイライト報告書、ステージレビューで活用する |
| 非公式に変更する | ベースライン化されたPIDは次を通じてのみ変更する： 変更管理 |
| 他の文書の内容を重複させる | リスク登録簿、計画書、契約書はコピーせずに参照する |
PIDの作成に使えるテンプレート
当サイトでは単一のPIDテンプレートは提供していません。内容の大部分は、いずれにせよ作成する文書にすでに含まれているためです。以下の無料テンプレートで主要なセクションをカバーでき、それらを組み合わせたりリンクしたりしてPIDを作成できます：
- プロジェクトブリーフテンプレート ：立ち上げ時の要約に。
- ビジネスケーステンプレート ：理由、選択肢、コスト、便益に。
- プロジェクト憲章テンプレート ：目標、スコープ、マイルストーン、役割を1か所に。
- プロジェクト計画書テンプレート ：ステージ、タスク、マイルストーンに。
- RACIマトリクステンプレート ：プロジェクトマネジメントチームと責任に。
- リスク登録簿テンプレート と コミュニケーション計画テンプレート ：中核となる2つのマネジメントのアプローチに。
PIDが承認されたら、次のステップはそれに沿って最初の提供ステージを運営することです。
このトピックの無料テンプレート
よくある質問
プロジェクト開始文書とは？
プロジェクト開始文書（PID）とは、プロジェクトとその管理方法を定義する情報の集まりで、プロジェクトの定義、ビジネスケース、チーム構成、計画、マネジメントのアプローチ、コントロール、調整内容を含みます。PRINCE2ではプロジェクト委員会が承認し、プロジェクトのベースラインになります。
プロジェクトマネジメントにおけるPIDは何の略ですか？
PIDはproject initiation document（プロジェクト開始文書）の略です。PRINCE2では、1つの文書でも関連文書の集まりでもよいため、project initiation documentation（プロジェクト開始文書一式）と呼んでいます。
PIDは誰が作成しますか？
プロジェクトマネージャーが、チーム、ユーザー、サプライヤー、専門家の意見を取り入れて取りまとめます。ビジネスケースにはエグゼクティブまたはスポンサーが責任を持ち、委員会に提出する前にプロジェクト保証がPIDをレビューすることがよくあります。
PIDは誰が承認しますか？
PRINCE2では、プロジェクト委員会が「プロジェクトの指揮」プロセスでプロジェクトを承認する際にPIDを承認します。PRINCE2以外では、通常はスポンサーまたはステアリングコミッティが承認します。
PIDはいつ作成しますか？
開始ステージの間、つまり委員会が開始ステージへの投資に同意した後、主要な提供作業が始まる前です。
PIDはPRINCE2でしか使われないのですか？
いいえ。この用語はPRINCE2に由来しますが、特に英国の公共部門を中心に、多くの組織が採用している手法にかかわらずPIDを使っています。
PIDとプロジェクト憲章の違いは何ですか？
A プロジェクト憲章 は、プロジェクトとそのプロジェクトマネージャーを承認する、短い上位レベルの文書です。PIDはより詳細で、ビジネスケース、マネジメントのアプローチ、コントロール、許容範囲、プロジェクト計画を加え、プロジェクトの完全なベースラインとして機能します。
PIDとプロジェクト計画の違いは何ですか？
プロジェクト計画は、ステージ、成果物、マイルストーン、資源、コスト、期間を扱います。PIDにはプロジェクト計画に加えて、プロジェクトの定義、ビジネスケース、チーム構成、マネジメントのアプローチ、コントロールが含まれます。
PIDはどのくらいの長さにすべきですか？
決まった長さはありません。リスクの低い小規模なプロジェクトなら数ページで済むこともありますが、大規模なプログラムでは、別の計画書や登録簿にリンクする相当量の文書が必要になることもあります。プロジェクトの規模とリスクに合わせて調整しましょう。
承認後にPIDを変更できますか？
はい。ただし変更管理を通じてのみ可能です。PRINCE2では通常、プロジェクトマネージャーがステージ境界でPIDを更新して委員会のレビューを受け、ベースラインの変更には委員会の承認が必要です。
アジャイルのプロジェクトにPIDは必要ですか？
PRINCE2 AgileでもPIDを使いますが、通常はより短く、ゴール、許容範囲、仕事の進め方に重点を置きます。詳細なスコープはPID自体ではなく、優先順位付きのバックログに置かれます。
PIDにおける許容値とは何ですか？
許容範囲とは、時間、コスト、スコープ、品質、リスク、便益などの領域について合意された限度です。その範囲内であれば、プロジェクトマネージャーはエスカレーションせずに行動できます。許容範囲を超えると予測される場合は、プロジェクト委員会に例外を提起します。
PIDと作業範囲記述書はどう違いますか？
PIDはプロジェクトを内部的に統制するもので、プロジェクト委員会またはスポンサーが承認します。 作業範囲記述書 は、外部サプライヤーが契約に基づいて提供する作業を記述するものです。