one-pager-prd

1ページPRD

使用しないケース： 詳細な技術設計ドキュメント（代わりにADRを使用）、包括的なプロダクト戦略（1ページには高レベルすぎます）、ユーザー調査の統合（別の形式を使用）、ローンチ後の振り返り（代わりにポストモーテムのスキルを使用）。

ワークフロー

このチェックリストをコピーして、進捗を記録してください。

One-Pager PRD Progress:
- [ ] Step 1: Gather context
- [ ] Step 2: Choose format
- [ ] Step 3: Draft one-pager
- [ ] Step 4: Validate quality
- [ ] Step 5: Review and iterate

ステップ 1：コンテキストを収集する

課題（ユーザーの不満、それを裏付けるデータ）、提案するソリューション（大まかなアプローチ）、対象ユーザー（ペルソナ、セグメント）、成功基準（目標、指標）、制約（技術、ビジネス、スケジュール）を特定します。一般的な課題の種類については、一般的なパターンを参照してください。

ステップ 2：形式を選ぶ

迅速な承認が必要なシンプルな機能の場合 → resources/template.mdの1ページ形式を使用します（1ページ、箇条書き）。詳細な要件が必要な複雑な機能やプロダクトの場合 → resources/template.mdの完全なPRD形式を使用します（1～2ページ）。執筆のガイダンスと構成を確認する場合 → 課題の捉え方、指標の定義、スコープの手法について、resources/methodology.mdを確認します。

ステップ 3：1ページPRDを作成する

one-pager-prd.mdを作成し、課題の説明（ユーザーの不満と、今取り組む理由）、ソリューションの概要（何を作るのか）、ユーザーペルソナとユースケース、定量的な指標を含む目標、対象範囲内のフローと対象範囲外の項目、制約と前提、解決すべき未解決の質問を記載します。簡潔にまとめます。1ページ形式なら1ページ、PRDなら1～2ページに収めてください。

ステップ 4：品質を検証する

resources/evaluators/rubric_one_pager_prd.jsonを使って自己評価します。課題が具体的でユーザー中心か、ソリューションが詳細になりすぎず明確か、指標が測定可能で目標値があるか、スコープが現実的で境界が明確か、制約が認識されているか、未解決の質問が特定されているかを確認します。最低基準：平均スコア ≥ 3.5。

ステップ 5：レビューして改善する

ステークホルダー（PM、デザイン、エンジニアリング、ビジネス）と共有します。課題の捉え方、ソリューションのアプローチ、スコープの境界、成功指標についてフィードバックを集めます。意見をもとに改善します。詳細設計や開発に進む前に、明示的な承認を得てください。

一般的なパターン

課題の種類別

ユーザーの不満（最も一般的）：

• パターン： ユーザーがXをできず、Yの不便が生じる
• 例： 「ユーザーは複数のフィルターで検索できず、項目を見つけるのに10回以上クリックする必要がある」
• 検証方法： ユーザーインタビュー、サポートチケット、回避策を示す分析データ

競争上のギャップ：

• パターン： 競合には機能があるが自社にはなく、それが顧客離れにつながる
• 例： 「競合は一括操作を提供しています。解約したユーザーの20％がこれを理由に挙げました」
• 検証方法： 解約分析、競合分析、受注・失注に関するインタビュー

戦略的機会：

• パターン： 市場の変化により、新しい機能を提供する機会が生まれる
• 例： 「リモートワークの急増 → 非同期コラボレーション機能が必要」
• 検証方法： 市場調査、初期顧客の関心、トレンド分析

技術的負債／スケーラビリティ：

• パターン： 現行システムが拡張に対応できず、成長を妨げている
• 例： 「ユーザー数が10万人を超えるとデータベースクエリがタイムアウトし、成長が阻まれている」
• 検証方法： パフォーマンス指標、システム容量分析

ソリューションの複雑さ別

シンプルな機能（数週間）：

• 要件が明確で、スコープが小さい
• 例：CSVへのエクスポートボタンを追加する
• 1ページ形式： 課題、ソリューション（1文）、指標、制約

中規模の機能（数か月）：

• 複数のユーザーフローがあり、ある程度の複雑さを伴う
• 例：通知機能付きのコメントシステム
• PRD： 詳細なフロー、エッジケース、段階分け（MVPとv2）

大規模な取り組み（四半期単位）：

• 部門横断的で戦略性が高い
• 例：モバイルアプリのローンチ
• 複数ページのPRD： フェーズに分割し、それぞれに独自の1ページ形式を作成する

ユーザーセグメント別

B2B SaaS：

• 重視する点：ROI、管理者向け制御、セキュリティ、連携
• 指標：導入率、価値実現までの時間、NPS

B2C コンシューマー：

• 重視する点：使う楽しさ、使いやすさ、口コミで広がる可能性
• 指標：日次アクティブユーザー数、継続率の推移、紹介数

エンタープライズ：

• 重視する点：コンプライアンス、カスタマイズ、サポート
• 指標：契約金額への影響、導入の成功率、エンタープライズ NPS

社内ツール：

• 重視する点：効率の向上、チームでの導入
• 指標：削減できた時間、タスク完了率、従業員満足度

ガードレール

課題：

• 具体的で、曖昧でないこと： ❌「ユーザーは検索機能の改善を望んでいる」→ ✓「ユーザーは検索を3回試して失敗すると離脱する（セッションの30％）」
• ユーザー中心であること： 社内の目標ではなく、ユーザーの課題に焦点を当てます（「エンゲージメントを高めたい」は目標であり、課題ではありません）
• 検証済みであること： 仮定ではなく、データ（分析、インタビュー、サポートチケット）を根拠として示します

ソリューション：

• 大まかに記述し、詳細を指定しすぎないこと： 何をするかを説明し、どのように実現するかは設計やエンジニアリングの裁量に任せます。
• 反証可能であること： 関係者が異議を唱えたり、代替案を提示したりできるだけの明確さを持たせます
• スコープに適していること： 1ページの文書でUIを設計しません。「フィルターパネル」とし、「チェックボックスで複数選択できるドロップダウンメニュー」とまでは指定しません

指標：

• 測定可能であること： 定量化できる必要があります。❌「UXを改善する」→ ✓「完了までの時間を5分から2分に短縮する」
• 先行指標と遅行指標： 両方を含めます（先行指標：導入率、遅行指標：収益への影響）
• ベースラインと目標： 現状と目標を示します。「NPSを40から55に引き上げる」

スコープ：

• 明確な境界： 対象範囲と対象外を明示します
• MVPと将来： 必須事項と、あると望ましい事項を分けます
• ユーザーフロー： 主要な正常系とエッジケースを説明します

制約：

• 現実的であること： 技術的負債、依存関係、スケジュール上の制限を認識します
• トレードオフ： 何を犠牲にするか（スピードと品質、機能とシンプルさ）を明示します

危険信号：

• 課題を探しているソリューション（ユーザーのニーズではなく、優れた技術だからという理由で作られた）
• 曖昧な指標（ベースライン、目標、期間がない）
• スコープの膨張（すべてが「必須」になっている）
• 制約への言及がない（非現実的な楽観）
• 未解決の質問がない（深く検討していない）

クイックリファレンス

リソース：

• resources/template.md - セクションごとのガイダンス付きのワンペーパーおよびPRDテンプレート
• resources/methodology.md - 課題の設定手法、メトリクスツリー、スコープの優先順位付け、明確な文章の書き方
• resources/evaluators/rubric_one_pager_prd.json - 品質基準

出力： one-pager-prd.md（課題、ソリューション、ユーザー、目標／メトリクス、スコープ、制約、未解決の質問を含む）

成功基準：

• 課題が具体的で、データや調査による検証がある
• ソリューションの大まかなアプローチが明確である（方法ではなく、何をするか）
• メトリクスが測定可能で、ベースラインと目標値がある
• スコープの対象範囲と対象外の境界が明確である
• 制約が認識されている
• 未解決の質問が特定されている
• ステークホルダーの承認を得ている
• ルーブリックのスコアが3.5以上である

迅速な判断：

• シンプルな機能で、迅速な承認が必要ですか？ → ワンペーパー（1ページ、箇条書き）
• 複雑な機能で、詳細な引き継ぎが必要ですか？ → 完全版PRD（1～2ページ）
• 複数のフェーズがありますか？ → フェーズごとにワンペーパーを作成
• 戦略的な取り組みですか？ → ワンペーパーから始め、必要に応じて複数ページに拡張

よくある間違い：

1. 課題が漠然としすぎている（「エクスペリエンスを改善する」）
2. ソリューションが詳細すぎる（UIコンポーネントを指定する）
3. メトリクスがない、または測定できないメトリクスを設定している
4. スコープの拡大（「対象外」セクションがない）
5. 制約を無視している（非現実的なスケジュール）
6. 検証がない（データではなく仮定に基づいている）
7. ステークホルダーではなく、自分のために書いている

重要な洞察： 簡潔さは明確さを生みます。1～2ページで説明できないなら、十分に検討できていません。ワンペーパーはコミュニケーションツールであると同時に、思考のためのツールでもあります。

形式のヒント：

• 段落ではなく箇条書きを使う（読みやすくする）
• 課題から始める（ソリューションを提案する前に、その正当性を示す）
• 可能な限りすべてを定量化する（形容詞より数値）
• スコープの境界を明示する（誤解を防ぐ）
• 未解決の質問を明らかにする（深く検討したことを示す）

ステークホルダーに合わせた調整：

• 経営幹部向け： ビジネスへの影響、メトリクス、必要なリソースを重視する
• エンジニアリング向け： 技術的な制約、依存関係、段階的な進め方を示す
• デザイン向け： ユーザーフロー、ペルソナ、成功基準を示す
• 営業／マーケティング向け： 競争上の位置づけ、顧客価値、ローンチ時期を重視する