epic-hypothesis

目的

エピックを、if/then 構造を用いた検証可能な仮説として定義します。アクションやソリューション、対象となる受益者、期待する成果、成功の検証方法を明確にします。前提を明示し、軽量な実験（「小さな発見の取り組み」）を定義し、開発に本格的に着手する前に測定可能な成功基準を設けることで、プロダクト開発における不確実性の管理に役立てます。

これは要件仕様ではありません。出荷を確約した機能ではなく、検証する仮説です。

入力

特に効果的な情報： 現時点でどのような形でも構わないので、イニシアチブやエピックのアイデアをご用意ください。一文だけでも十分です。 あると役立つ情報： 対象ユーザー、期待する成果、その測定方法（このスキルを使って、これら3つを明確にできます）。

呼び出し時に渡された内容（スキル名の後に続くテキスト、貼り付けられたコンテキスト、追加された ARGUMENTS: 行など）は、すでに回答済みの情報として扱います。内容を活用し、該当する項目については再質問しません。

何も用意できていなくても大丈夫です。 このスキルでは、イニシアチブの内容と対象者を尋ねたうえで、一緒に if/then 仮説を作成します。

呼び出し例： Frame as an epic hypothesis: adding usage-based alerts so account admins catch overages before invoice shock.

主な概念

エピック仮説フレームワーク

Tim Herbig の Lean UX 仮説形式に着想を得た構成は、次のとおりです。

If/Then 仮説：

• もし私たちが [対象ペルソナのためにアクションやソリューションを提供したら]
• 対象： [対象ペルソナ]
• そうすれば私たちは [望ましい成果や達成したいジョブを実現できる]

小さな発見の取り組みとしての実験：

• 次の方法で前提を検証します：
  • [実験1]
  • [実験2]
  • [必要に応じて追加]

検証指標：

• [期間]以内に次のことが確認できれば、仮説は妥当だと判断します
• 観察する内容：
  • [定量的に測定可能な成果]
  • [定性的に測定可能な成果]
  • [必要に応じて追加]

この構成が効果的な理由

• 仮説主導： 自分たちの考え（誤っている可能性もあること）を明示せざるを得ません
• 成果重視： 「そうすれば私たちは」という表現により、機能の提供ではなくユーザーのメリットを重視します
• 実験を優先： 開発に本格的に着手する前の、軽量な検証を促します
• 反証可能： 明確な成功基準により、望みの薄いアイデアを早期に取りやめられます
• リスク管理： エピックを確約ではなく、賭けとして扱います

反パターン（これは何ではないか）

• 機能仕様ではありません： 「5つのグラフがあるダッシュボードを作る」は機能であり、仮説ではありません
• 確約ではありません： 仮説は否定される可能性がありますし、否定されるべきです
• アウトプット重視ではありません： 「第2四半期までに機能Xをリリースする」では要点を見落としています。成果は達成できたでしょうか？
• 実験を省くものではありません： 実験を省いていきなり開発に進むなら、仮説を検証していることにはなりません

この方法を使う場面

• 機能の初期検討段階（ロードマップへの本格的な組み込みを決める前）
• 新機能のプロダクトマーケットフィットの検証
• バックログの優先順位付け（仮説が検証済みのエピックを優先）
• ステークホルダーの期待値管理（作業を約束ではなく実験として位置づける）

この方法を使わない場面

• 十分に検証済みの機能（需要をすでに実証している場合は、ユーザーストーリーの作成に進みます）
• 些細な機能（小さな変更を過度に複雑化しないでください）
• 実験が実施できない場合（まれですが、検証前に確約せざるを得ないこともあります）

---

適用

全項目を記入するための構成は template.md を使用してください。

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

エピック仮説を作成する前に、次の情報が揃っていることを確認してください。

• 問題の理解： どのようなユーザーの問題に対処するのでしょうか？（skills/problem-statement/SKILL.md を参照）
• 対象ペルソナ： 誰にメリットがありますか？（skills/proto-persona/SKILL.md を参照）
• Jobs-to-be-Done： どのような成果を達成しようとしていますか？（skills/jobs-to-be-done/SKILL.md を参照）
• 現在の代替手段： ユーザーは現在、何をしていますか？（競合製品、回避策、何もしないこと）

コンテキストが不足している場合： まず、発見インタビューや問題の検証に取り組んでください。

---

Step 2: If/Then 仮説を作成する

テンプレートに記入します。

### If/Then Hypothesis

**If we** [action or solution on behalf of the target persona]
**for** [target persona]
**Then we will** [attain or achieve a desirable outcome or job-to-be-done for the persona]

品質チェック：

• 「If we」が具体的であること：「製品を改善する」ではなく、「タスクが割り当てられたときにワンクリックで Slack 通知を送信する」
• 「For」が明確なペルソナであること：「ユーザー」ではなく、「3 つ以上の分散チームをまとめるリモートのプロジェクトマネージャー」（skills/proto-persona/SKILL.md を参照）
• 「Then we will」が成果を示していること：「ユーザーが通知を受け取る」ではなく、「ユーザーがタスクの割り当てに 50％速く対応する」

例：

• ✅ 「トライアルユーザー向けにワンクリックの Google Calendar 連携を追加すれば、30 日以内にアクティベーション率が 20％向上します」
• ✅ 「1000 件以上のアイテムを管理するパワーユーザー向けに一括削除機能を提供すれば、整理作業にかかる時間を 70％削減できます」
• ❌ 「ダッシュボードを作れば、ユーザーはそれを使うでしょう」（曖昧で、測定できません）

---

Step 3: 小さな発見実験を設計する

エピック全体を構築する前に、仮説を検証するための手軽な実験を定義します。

### Tiny Acts of Discovery Experiments

**We will test our assumption by:**
- [Experiment 1: low-cost, fast test]
- [Experiment 2: another low-cost, fast test]
- [Add more as necessary]

実験の種類：

• プロトタイプ＋ユーザーテスト： クリック可能なプロトタイプで機能を模擬し、5～10 人のユーザーでテストします
• コンシェルジュテスト： 少数のユーザーに機能を手動で提供し、価値を感じるか確認します
• ランディングページテスト： 機能を紹介し、登録数や関心度を測定します
• Wizard of Oz テスト： 自動化されているように機能を提示し、裏では手動で実行します
• A/B テスト（実施可能な場合）： 簡易版と対照群をテストします

品質チェック：

• 迅速であること： 実験は数か月ではなく、数日から数週間で実施できるものにします
• 低コストであること： エンジニアリングで一から構築するのは避け、プロトタイプ、手動のプロセス、または既存のツールを使います
• 反証可能であること： 仮説が 誤り だと証明できる実験を設計します

例：

• 「一括削除の操作フローを Figma のプロトタイプで作成し、パワーユーザー 5 人でテストする」
• 「トライアルユーザー 10 人に Slack 通知を手動で送り、応答時間を追跡する」
• 「UI に『この機能をリクエスト』ボタンを追加し、クリック率を測定する」

---

Step 4: 検証指標を定義する

成功の基準と評価期間を明確にします。

### Validation Measures

**We know our hypothesis is valid if within** [timeframe in days or weeks]
**we observe:**
- [Desirable quantitative, measurable outcome]
- [Desirable qualitative, measurable outcome]
- [Add more as necessary]

品質チェック：

• 現実的な期間であること：「6 か月以内」（遅すぎる）や「3 日以内」（短すぎる）ではないこと
• 定量的な指標が具体的であること：「ユーザーが増える」ではなく、「アクティベーション率が 20％上昇する」
• 定性的な指標が観察可能であること：「ユーザーが気に入っている」ではなく、「ユーザー 10 人中 8 人が、この機能にお金を払いたいと答える」

例：

• ✅ 「4 週間以内に、次の結果を確認します。」
  • 「アクティベーション率が 40％から 50％に上昇する（定量的）」
  • 「調査対象のトライアルユーザーの 75％が、連携によって時間を節約できたと回答する（定性的）」
• ❌ 「1 年以内に、次の結果を確認します。」
  • 「収益が増える」（曖昧すぎて、期間も長すぎます）

---

Step 5: 実験を実施して評価する

• 実験を実施する： プロトタイプを作成し、テストを実施して、データを収集します
• 結果を測定する： 検証指標を達成できましたか？
• 判断する：
  • ✅ 仮説が検証された： ユーザーストーリーの作成に進み、ロードマップに追加します
  • ❌ 仮説が否定された： エピックを取りやめるか、別の仮説に方向転換します
  • ⚠️ 結論が出なかった： 追加の実験を行うか、検証指標をより明確にします

---

Step 6: ユーザーストーリーに変換する（検証された場合）

仮説が検証されたら、エピックをユーザーストーリーに分解します。

### Epic: [Epic Name]

**Stories:**
1. [User Story 1 - reference `skills/user-story/SKILL.md`]
2. [User Story 2]
3. [User Story 3]

---

例

エピック仮説の詳しい例は examples/sample.md を参照してください。

短い例：

**If we** provide one-click Google Calendar integration
**for** trial users managing multiple meetings
**Then we will** increase activation rate from 40% to 50%

---

よくある落とし穴

落とし穴 1：仮説が成果ではなく機能になっている

症状： 「ダッシュボードを作れば、ダッシュボードができます」

結果： 成果ではなく、アウトプットを説明しています。これでは何も検証できません。

対処法： ユーザーが得る成果に焦点を当てます。「リアルタイムのタスク状況を表示するダッシュボードを作れば、PM が状況確認を依頼する時間を 50％削減できます。」

---

落とし穴 2：実験を省略する

症状：「機能全体を構築して、仮説を検証します」

**結果：**検証する前に、構築すると決めてしまっています。これは仮説ではなく、機能の提供を約束している状態です。

**対策：**数か月ではなく、数日から数週間で実施できる軽量な実験（プロトタイプ、コンシェルジュテスト、ランディングページ）を設計します。

---

落とし穴 3：検証指標が曖昧

症状：「ユーザーが満足していれば、妥当だとわかります」

**結果：**成功基準が主観的で、測定できません。

対策：「アンケート回答者の 80％が、この機能を 5 点満点中 4 点以上と評価する」や「応答時間が 50％短縮する」など、具体的で反証可能な指標を定義します。

---

落とし穴 4：非現実的な期間設定

症状：「6 か月以内に収益が増えれば、妥当だとわかります」

**結果：**意思決定に活用するには時間がかかりすぎます。その頃には、すでに構築し終えています。

**対策：**2～4 週間の検証サイクルを目指します。その期間内に測定できない場合は、年間収益ではなくアクティベーション率など、先行指標を選びます。

---

落とし穴 5：エピックを確約事項として扱う

症状：「すでに CEO にリリースすると伝えたので、検証しなければなりません」

**結果：**実験は形だけのものになり、結果にかかわらず構築することになります。

**対策：**確約する前に、エピックを仮説として位置づけます。ステークホルダーが確実性を求める場合は、未検証の機能を構築するリスクを説明します。

---

参考資料

関連スキル

• skills/problem-statement/SKILL.md — 仮説では、妥当性が検証された課題に取り組む必要があります
• skills/proto-persona/SKILL.md — 「for [persona]」セクションを定義します
• skills/jobs-to-be-done/SKILL.md — 「then we will」の成果を明確にします
• skills/user-story/SKILL.md — 検証済みのエピックをユーザーストーリーに分解します
• skills/user-story-splitting/SKILL.md — 検証済みのエピックをストーリーに分割する方法です

外部フレームワーク

• Tim Herbig、『Lean UX Hypothesis Statement』 — if/then 形式の仮説の起源
• Jeff Gothelf、Josh Seiden、『Lean UX』（2013） — 仮説主導のプロダクト開発
• Alberto Savoia、『Pretotype It』（2011） — アイデアを検証する軽量な実験
• Eric Ries、『The Lean Startup』（2011） — Build-Measure-Learn サイクル

Dean の取り組み

• Backlog Epic Hypothesis Prompt（Tim Herbig のフレームワークに着想を得たもの）

来歴

• https://github.com/deanpeters/product-manager-prompts リポジトリの prompts/backlog-epic-hypothesis.md を基にしています。

---

スキルの種類： コンポーネント 推奨ファイル名： epic-hypothesis.md 推奨配置先： /skills/components/ 依存関係： skills/problem-statement/SKILL.md、skills/proto-persona/SKILL.md、skills/jobs-to-be-done/SKILL.md を参照します 使用元： skills/user-story/SKILL.md、skills/user-story-splitting/SKILL.md