name: draft-project-charter description: > スコープ、ステークホルダー、成功基準、および初期リスク登録簿を定義する プロジェクト憲章を作成します。アジャイルおよびクラシック手法の両方に対応し、 問題の記述、RACIマトリクス、マイルストーン計画、スコープ境界を網羅します。 新しいプロジェクトの開始、非公式な開始後のスコープ正式化、詳細計画前の ステークホルダーの整合、または発見から実際のプロジェクト作業への移行時に使用します。 locale: ja source_locale: en source_commit: 6f65f316 translator: claude-opus-4-6 translation_date: 2026-03-16 license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: project-management complexity: basic language: multi tags: project-management, charter, scope, stakeholders, raci, risk-register

プロジェクト憲章の作成

詳細計画の開始前に、プロジェクトの境界、ステークホルダーの合意、および成功基準を確立する構造化されたプロジェクト憲章を作成します。スコープ、RACI割り当て、マイルストーン計画、および初期リスク登録簿を網羅する包括的な文書を作成し、アジャイル、クラシック、またはハイブリッドなプロジェクト手法に対応します。

使用タイミング

• 新しいプロジェクトまたは取り組みの開始時
• 非公式なプロジェクト開始後にスコープを正式化する場合
• 詳細計画の開始前にステークホルダーを整合させる場合
• 実行中のスコープ決定のための参照文書を作成する場合
• 発見・アイデア出しから実際のプロジェクト作業への移行時

入力

• 必須: プロジェクト名と簡単な説明
• 必須: 主要なステークホルダーまたはスポンサー
• 任意: 既存の文書（提案書、概要書、メール）
• 任意: 既知の制約（予算、締め切り、チームの規模）
• 任意: 手法の好み（アジャイル、クラシック、ハイブリッド）

手順

ステップ1: プロジェクトの背景を収集し、憲章テンプレートを作成する

既存の文書（提案書、メール、概要書）を読み、プロジェクトの背景を理解します。プロジェクトが対処するコアな問題や機会を特定します。後続のステップで入力される構造化テンプレートを使って憲章ファイルを作成します。

PROJECT-CHARTER-[PROJECT-NAME].md というファイルを次のテンプレートで作成します:

# Project Charter: [Project Name]
## Document ID: PC-[PROJECT]-[YYYY]-[NNN]

### 1. Problem Statement
[2-3 sentences describing the problem or opportunity this project addresses]

### 2. Project Purpose
[What the project will achieve and why it matters]

### 3. Scope
#### In Scope
- [Deliverable 1]
- [Deliverable 2]

#### Out of Scope
- [Exclusion 1]
- [Exclusion 2]

### 4. Deliverables
| # | Deliverable | Acceptance Criteria | Target Date |
|---|------------|---------------------|-------------|
| 1 | | | |

### 5. Stakeholders & RACI
| Stakeholder | Role | D1 | D2 | D3 |
|-------------|------|----|----|-----|
| | | | | |

*R=Responsible, A=Accountable, C=Consulted, I=Informed*

### 6. Success Criteria
| # | Criterion | Measure | Target |
|---|-----------|---------|--------|
| 1 | | | |

### 7. Milestones
| Milestone | Target Date | Dependencies |
|-----------|-------------|--------------|
| | | |

### 8. Risk Register
| ID | Risk | Likelihood | Impact | Severity | Mitigation | Owner |
|----|------|------------|--------|----------|------------|-------|
| R1 | | | | | | |

*Likelihood/Impact: Low, Medium, High*
*Severity = Likelihood × Impact*

### 9. Assumptions and Constraints
#### Assumptions
- [Key assumption 1]

#### Constraints
- [Key constraint 1]

### 10. Approval
| Role | Name | Date |
|------|------|------|
| Sponsor | | |
| Project Lead | | |

PC-[PROJECT]-[YYYY]-[NNN] の形式（例: PC-WEBSITE-2026-001）でドキュメントIDを記入します。現在の状況、ギャップ、およびその影響を説明する問題の記述（2〜3文）を書きます。何を達成するかを説明するプロジェクト目的の記述（1段落）を書きます。

期待結果： 憲章ファイルがドキュメントID、問題の記述、および目的を記入した状態で作成されている。問題の記述は具体的で、測定可能なギャップを説明している。

失敗時： プロジェクトの背景が不明確な場合、憲章の上部にある QUESTIONS セクションにスポンサーへの具体的な質問を記録します。既存の文書が矛盾している場合、OPEN ISSUES セクションに矛盾点を記録し、ステークホルダーによる解決のためにフラグを立てます。

ステップ2: スコープの境界を定義する

プロジェクトスコープに含まれるものと含まれないものの明示的なリストを作成します。各成果物に具体的な受け入れ基準を付けて、スコープ内成果物を3〜5件書きます。スコープクリープを防ぐために、スコープ外の項目を3〜5件書きます。各成果物の受け入れ基準と目標日を付けて、成果物テーブルに入力します。

期待結果： スコープセクションにスコープ内とスコープ外のリストがバランスよく含まれている。成果物テーブルには、具体的でテスト可能な受け入れ基準を持つ3〜5件のエントリが含まれている。目標日は現実的で論理的な順序になっている。

失敗時： 成果物が曖昧な場合、具体的な出力物を持つ小規模な成果物に分解します。受け入れ基準が欠如している場合、「この成果物がどのように完了したことを示せるか？」と問います。目標日が利用できない場合、TBDとマークし、マイルストーン計画セッションのためにフラグを立てます。

ステップ3: ステークホルダーを特定し、RACIを割り当てる

プロジェクトに影響を受ける、貢献する、または意思決定権を持つすべての個人またはグループをリストアップします。組織内での役割を含めます。以下を使用して各ステークホルダーを各成果物にマッピングするRACIマトリクスを作成します:

• R (Responsible: 実行責任者): 作業を行う人
• A (Accountable: 説明責任者): 最終的な意思決定権者（成果物ごとにAは1人のみ）
• C (Consulted: 相談対象者): 意思決定前に意見を提供する人
• I (Informed: 情報提供対象者): 進捗について情報を受け取る人

各成果物にはA（説明責任者）が必ず1人いて、かつR（実行責任者）が少なくとも1人いることを確認します。

期待結果： ステークホルダーテーブルに役割を持つ5〜10人がリストされている。RACIマトリクスの各成果物列にAが1人いる。RまたはAが欠けている成果物や、複数のAがいる成果物がない。スポンサーが最終承認のAである。

失敗時： ステークホルダーリストが不完全な場合、組織図と発見フェーズからの会議出席者を参照します。複数のAが特定された場合、意思決定権の明確化のためにスポンサーに問題をエスカレーションします。Rが存在しない場合、成果物を未割り当てとしてフラグを立て、リソース割り当てが必要であることを示します。

ステップ4: 成功基準とマイルストーンを定義する

SMART形式（Specific、Measurable、Achievable、Relevant、Time-bound）を使用して、測定可能な成功基準を3〜5件書きます。各基準は定量化可能な尺度と目標値に結びつけるべきです。先行マイルストーンへの依存関係と目標日を持つ、プロジェクトの主要な段階または成果物の完成を表す4〜6個の主要マイルストーンを定義します。

期待結果： 成功基準テーブルには具体的な尺度（例：「システム稼働時間」を「%可用性」で測定し、目標「99.5%」）を持つ3〜5件のエントリがある。マイルストーンテーブルには現実的な目標日を持つ論理的なプロジェクトフェーズが示されている。依存関係が明確に記録されている。

失敗時： 成功基準が曖昧な場合（例：「品質を改善する」）、ベースラインと目標値を持つ測定可能な成果として書き直します。マイルストーン日が非現実的な場合、最終締め切りから逆算して見積もり期間とバッファを使用します。依存関係が循環論理を生み出す場合、マイルストーンの順序を再構成するか、競合するマイルストーンを分割します。

ステップ5: 初期リスク登録簿を作成する

プロジェクトの成功に影響を与える可能性のある5〜10件のリスクを特定します。各リスクについて、可能性（低/中/高）と影響（低/中/高）を評価し、深刻度を計算します。各リスクに対して具体的な軽減戦略を定義し、監視と対応に責任を持つリスクオーナーを割り当てます。スコープ、スケジュール、リソース、技術、および外部の各カテゴリに少なくとも1件のリスクを含めます。

期待結果： リスク登録簿にスコープ、スケジュール、リソース、技術、および外部のリスクをカバーする5〜10件のエントリがある。各リスクには可能性、影響、および深刻度が評価されている。軽減戦略は実行可能かつ具体的である。各リスクには割り当てられたオーナーがいる。

失敗時： リスクリストが不完全な場合、スコープ境界、依存関係、ステークホルダーリスト、および仮定を潜在的な失敗ポイントとして確認します。軽減戦略が一般的な場合（「注意深く監視する」）、具体的に指定します：何を監視するか？どのくらいの頻度で？何がアクションのトリガーになるか？リスクオーナーが引き受けない場合、一時的にプロジェクトリードに割り当てて、スポンサーにエスカレーションします。

バリデーション

• 憲章ファイルがドキュメントIDとともに作成されている
• 問題の記述が具体的で測定可能である
• スコープにスコープ内とスコープ外の項目がある
• RACIマトリクスがすべての成果物をカバーしている
• 成功基準が測定可能である（SMART）
• 少なくとも5件のリスクが軽減戦略とともに特定されている
• マイルストーンに目標日がある
• 承認セクションが含まれている

よくある落とし穴

• 境界のないスコープ: スコープ外の項目を明示せずにスコープ内の項目をリストすると、スコープクリープにつながります。常に行わないことを定義します。
• 曖昧な成功基準: 「パフォーマンスを改善する」は測定不可能です。すべての基準を、ベースラインと目標値を持つ数値に結び付けます。
• 欠落したステークホルダー: 見落とされたステークホルダーは後から現れてプロジェクトを妨げます。組織図と以前のプロジェクトのコミュニケーションを参照します。
• チェックボックスとしてのリスク登録簿: 実行可能な軽減計画なしにリスクをリストするだけでは、偽の安心感を与えます。各リスクには具体的な対応戦略が必要です。
• 過度に詳細な憲章: 憲章はマップではなく羅針盤です。2〜4ページに収めます。詳細な計画は後で行います。

関連スキル

• create-work-breakdown-structure — 憲章の成果物をワークパッケージに分解する
• manage-backlog — 憲章のスコープを優先順位付きバックログに変換する
• plan-sprint — 憲章の成果物から最初のスプリントを計画する
• generate-status-report — 憲章のマイルストーンに対して進捗を報告する
• conduct-retrospective — 実行後に憲章の仮定を見直す