define-hypothesis

仮説

仮説とは、変更がユーザーの行動やビジネス成果にどのような影響を与えるかについて、検証可能な予測です。前提を、実験によって妥当性を確認したり否定したりできる明確な主張に変換します。適切に構成された仮説により、チームは検証されていない思い込みに基づいて機能を開発することを避けられ、成功の定義について共通認識を持てます。

使用する場合

• 問題を整理した後、解決策を確定する前
• 実験や A/B テストを設計するとき
• ユーザー行動についてチームメンバー間で異なる前提があるとき
• 機能に多くのエンジニアリングリソースを投じる前
• 方針を転換し、新しいアプローチを検証する必要があるとき

使用しない場合

• 実際の A/B テスト（バリエーション、サンプルサイズ、期間）を設計する段階にある場合 → measure-experiment-design を使用してください。このスキルでは何をテストするかを整理しますが、どのようにテストするかは扱いません
• 問題自体がまだ整理されていない場合 → まず define-problem-statement を使用してください
• 多数の前提やアイデアをディスカバリーの構造に整理したい場合 → define-opportunity-tree を使用してください
• チームが検証可能な主張をひとつ立てるのではなく、ビジネスモデルの全体像を必要としている場合 → foundation-lean-canvas を使用してください

手順

仮説の作成を依頼された場合は、次の手順に従ってください。

1. 信念を明示する 何が起こると考えているかを明確にします。「[対象ユーザー] に対する [アクション／変更] によって、[期待する結果] が得られると考えます」という構成を使用してください。介入内容を具体的にします。曖昧な仮説は検証できません。

2. 対象ユーザーを特定する この仮説が誰に当てはまるかを定義します。「ユーザー」についての仮説では範囲が広すぎます。初週の新規ユーザー、セッション数が 10 回以上のヘビーユーザー、再訪した離脱ユーザーなど、セグメントを指定してください。

3. 期待する結果を定義する どのような行動の変化や結果を期待していますか？可能な場合は、社内指標ではなく、ユーザーの行動（オンボーディングを完了する、購入する、7 日以内に再訪するなど）で表現してください。

4. 成功指標を設定する 期待する結果を直接測定する主要指標を選びます。状況を把握するための副次指標と、ほかの領域に悪影響が及んでいないことを確認するガードレール指標も含めてください。

5. 検証方法を記述する この仮説をどのように検証しますか？A/B テスト、ユーザーインタビュー、プロトタイプのテスト、コホート分析などがあります。サンプルサイズ、期間、統計的要件を具体的に示してください。

6. リスクと前提を記録する テスト結果以外に、この仮説を否定しうるものは何ですか？検証していないものの、真実だと仮定していることは何ですか？

出力形式

references/TEMPLATE.md のテンプレートを使用して、出力を構成してください。仮説ドキュメントを完成させるには、テンプレートのすべてのセクション（仮説の記述、背景と根拠、対象ユーザーセグメント、成功指標、検証方法、リスクと前提、タイムライン）を記入します。

品質チェックリスト

完成前に、次の項目を確認してください。

• 仮説が反証可能である（誤りだと証明できる）
• 成功指標に具体的な数値目標がある
• 対象ユーザーセグメントが明確に定義されている
• 検証方法が現実的で、期間が定められている
• 合格／不合格の基準が明確である
• 仮説が解決策の有効性を前提としていない

例

完成例については、references/EXAMPLE.md を参照してください。