pm-release-plan

リリース計画／憲章（実践的フレームワーク：ロードマップ → リリース）

ロードマップがリリース計画を導きます。ロードマップは計画であり、確約ではありません。リリース憲章は、何を提供するかを定めた署名済みの合意書です。../pm-copilot/references/framework.md を参照してください。

MVPを正しく定義する： 「新製品のうち、チームが最小限の労力で最大限の検証済みの学びを得られるバージョン」。MVPは最小限の機能の集合ではありません。初日から顧客の最重要課題を実用的に解決する、本物の製品でなければなりません。完成した「V1.0」をMVPと呼ぶのは、ウォーターフォールへの逆戻りです。

中核となる手法

要件をテーマにまとめます。 テーマとは、ペルソナ、製品目標、技術的な決定、戦略、ロードマップとの整合性、または目標指標を共有する、優先順位付けされた課題のまとまりです。テーマによって、リリースに際立った特徴と一貫性が生まれます。

原則：すべてのものを70％提供するのではなく、何かを100％提供します。

リリースの内容を具体化するには、テーマ／要件ごとに3つの観点を使います：規模・難易度・確信度。大きな項目は、課題を分割して小さくします。

見積もりの段階（詳細が増すほど確信度が高まります）： リリース → Tシャツサイズ（S/M/L） → イテレーション → ストーリーポイント → 日 → 日次の更新。 プロダクトマネジメントは、あらゆる段階で質問に答えられる体制を整えます。最終的な見積もりは開発チームが行います。

市場投入の時期とスケジュールの方向性： 日付主導型のリリースでは、開発は日付に向けて進めます（市場投入時期に向けて反復します）。マーケティング、営業、オペレーションはその日付を起点に逆算して進めます。コンテンツ主導型のリリースでは確定した日付はありません。その代わりに、ローンチのきっかけとなる終了条件を定義し、条件を満たした時点で市場投入までのカウントを開始します。

変更の調整要素（三角形の制約）： スコープ・スケジュール・リソース。どれを計画の軸とするか、また変更をどのように吸収するかを事前に決めます。

ユーザーへのヒアリング（一括で質問）

1. 製品、バージョン、プロジェクト名。
2. リリーステーマ — 全体をまとめるメッセージ（ペルソナの目標／主要な機能／課題のまとまり）。
3. 優先順位付けされた要件のうち、対象範囲に含まれるものはどれですか？（既存のMRD/PRDがあれば、そこから取得します）
4. 日付主導型ですか、コンテンツ主導型ですか？ このリリースは目標日／市場投入時期に左右されますか。それともコンテンツに基づきますか（テーマが完了した時点でリリースしますか）。どちらも等しく妥当です。日付主導型の場合のみ、目標日または市場投入時期を尋ねます。「日付はありません」も正当な回答です。その場合はコンテンツ主導型のリリースであり、入力漏れではありません。
5. 主要なマイルストーン — コード完了、ベータ、最終QA、本番環境へのリリース、GA。
6. 変更の調整要素 — 実情が明らかになったとき、スコープ、スケジュール、リソースのどれを柔軟に調整しますか？

成果物テンプレート — リリース憲章

# Release Charter — <Product> <Version>

**Company:** <company>  ·  **Feature / Product:** <name>
**Author:** <author>  ·  **Date created:** <date>  ·  **Version:** <version>
**Project Name:** <project>   **Release Theme:** <theme>
**Schedule:** <date-driven: <target date / market window> · or content-driven: ships when <exit criteria> are met>

## Themes
- **<Theme 1>** — <what it delivers and why (persona/goal/strategy it serves)>
- **<Theme 2>** — <…>

## Deliverables (what we have agreed to deliver)
Based on requirements document **<MRD/PRD name + version>**.
### <Theme 1 / Group name>
- <requirement / capability>  — size: <S/M/L>, confidence: <low/med/high>
- <requirement / capability>
### <Theme 2 / Group name>
- <requirement / capability>

### Major milestones
| Milestone | Target date |
| :--- | :--- |
| Code complete | |
| Beta release | |
| Final QA | |
| Release to production | |
| General availability (GA) | |

## Change plan
| Driver | What will drive the plan? | How will you deal with change? |
| :--- | :--- | :--- |
| Scope | | |
| Schedule | | |
| Resources | | |

## Signatures
*This document lists what we have agreed to deliver. By signing below, I acknowledge
that this is the current plan and that I will inform product management and project
management if the plan changes.*

| Name | Title | Date | Signature |
| :--- | :--- | :--- | :--- |
| | Product Manager | | |
| | Project Manager | | |
| | Development Manager | | |
| | QA Lead | | |

成果物の作成

../pm-copilot/references/artifact-output.md に従ってください。入力内容を確認し、Markdownか.docxかを尋ね、.md を作成します。依頼があれば、実行環境に標準搭載されているドキュメント作成機能を使って .docx に変換します。その後、次の段階として、この憲章に沿って状況を報告するための pm-stakeholder-communication の設定と、目標時期に向けた市場投入の準備を行う pm-launch-plan を提案します。