melech-market-validation

市場検証

まず、ユーザーが実際に抱えている機会から始めます。前提がまだ定まっていない場合は、確実性を捏造せずに整理を支援します。検証可能になったら、妥当性の評価から、ユーザーが入手できる最も強い現実世界の証拠まで、段階的に検証します。調査、熱意、インタビュー、あるいは単一のパイロットを、市場検証済みと取り違えないでください。

このスキルには、相互に関連する2つのモードがあります。

• 整理 — 次に有用なプロダクトまたは市場仮説が見えるまで、まだ定まっていない機会を明確にし、捉え直します。結論を出すことは必須ではありません。
• 検証 — 暫定的な仮説を、顧客、行動、商業面の証拠に照らして検証し、明確な市場判断が可能になるまで進めます。

ユーザーが完全な検証を求めている場合、次の条件を満たして初めて作業は完了です。

1. 仮説を反証可能にする
2. 判断を左右するすべての主張について、賛成・反対双方の証拠を整理する
3. アクセスが可能な場合は、一次情報または行動に基づく証拠で、最も重要な証拠の不足を補う
4. 判明していることと、依然として単に妥当と思われることを区別する
5. 進める／方向を変える／保留する／中止するという明確な判断を出す

顧客や実験の場がチャットの外にあるため、市場検証は複数のセッションにまたがる場合があります。作業を最初からやり直さずに再開できるよう、更新し続ける検証ブリーフを1つ維持してください。

まず適用範囲を確認する

ユーザーの考えがどの段階にあるかに応じて、このスキルを選択します。

ユーザーの状況	使用するもの
具体的な解決策を求めているが、実際のニーズに応えていない可能性がある	まず実際のニーズを抽出します。このスキルは使いません
まだ定まっていないプロダクトまたは事業の機会があり、検証可能な市場前提を見つけたい	ここで整理し、有用であればその後検証します
顧客／課題／価値に関する具体的な仮説があり、現実がそれを裏付けるか知りたい	検証の取り決めから始めます
市場の裏付けがある方向性があり、関係者間で共有できる開発コンセプトが必要	開発可能なコンセプトの整理に進みます。このスキルは使いません

重要な要素が明確になる前に、定まっていないアイデアを無理に検証の取り決めに当てはめないでください。逆に、顧客や商業面の証拠が判断を左右する段階で、1つの仮説が固まった後もアイデア出しを続けないでください。

検証モデル

検証は、合格か不合格かを示す単一のバッジではありません。主張ごとに証拠の状態を記録します。

• 裏付けなし — 主張されているが、意味のある証拠がない
• 妥当性あり — 信頼できる二次情報または一次情報の兆候によって裏付けられている
• 行動による裏付けあり — 対象顧客が、課題、回避策、乗り換え、または関連する行動を繰り返し示している
• コミットメントによる裏付けあり — 想定する購入者が、金銭、署名済みのパイロット、調達にかける労力、データへのアクセス、または相応の時間といった、希少なリソースを投じている

市場判断を左右することが多い主張は次のとおりです。

1. 顧客と状況 — 接触可能なセグメントが、特定のきっかけとなる状況に遭遇している。
2. 課題 — その状況が、頻繁で深刻、またはコストのかかる結果を引き起こしている。
3. 既存の需要 — 人々がすでに、前進するために金銭、時間、リスク、または政治的資本を投じている。
4. 購入者と予算 — 成果に責任を持ち、変化に資金を出せる意思決定者を特定できる。
5. 提案の適合性 — 提案する価値と提供形態が、行動を促すほど現状の代替手段を上回っている。
6. リーチ可能性 — セグメントを繰り返し見つけ、関与するための信頼できる経路がある。

前に進む前に、すべての主張についてコミットメントレベルの証拠が必要なわけではありません。必要なのは、判断を覆す可能性が最も高い主張についての証拠です。

エンドツーエンドのワークフロー

0. オープンな前提を形にする

ユーザーが検証可能な仮説ではなく、機会、目標、市場に関する疑問、または漠然とした製品アイデアを持っている場合に、このステップを使います。最初のアイデアは契約ではなく、変更可能な前提として扱います。

簡潔な作業用マップを維持します。

• 目標 — ユーザーが望む成果
• 関係性 — 既存製品に関する機会、独立した製品、隣接製品、または意図的に未決定
• 前提 — 現在の顧客、状況、問題、製品の形、価値を生み出す仕組み。未確定の点も含めます
• 証拠と緊張点 — 観察された事実、ユーザーの主張、推論、矛盾、重大な未知の要素
• 次の意思決定 — 次に何をすべきかを最も大きく左右する選択

その意思決定に関わる不確実性だけに取り組みます。状況に応じて、次のことを行います。

• ユーザーにしか答えられない質問を、1〜3個だけ尋ねる
• 関連する製品、リポジトリ、または一次情報を調べる
• ユーザー、代替手段、競合、市場状況、実現可能性を、重要度に応じて調査する
• 大きく異なる前提の形を1〜3個比較する

既存のコードが証明するのは実現能力であり、ニーズではありません。公開されている不満や機能リクエストからは、仕組みや表現を把握できますが、広がりや支払い意欲は判断できません。

毎回のやり取りで、まとめ、捉え直し、有意義な選択肢、次の意思決定など、価値を提供します。ヒアリング項目を並べるだけにはしません。前提が変わった場合は、次のようにします。

1. 新しい形を一文で示す
2. 変わらず有効な点を維持する
3. 無効になった点、または不確実になった点を明示する
4. マップを更新し、最初からやり直さずに続ける

ユーザーが方向性の確認だけを望んでいる場合は、現時点で最も有力な形、それを裏付ける証拠、残る緊張点、次に有効な一手を示して終了します。検証結果を無理に作り出してはいけません。顧客、コストのかかる状況、現在の代替手段、購入者、提案する価値が検証できる程度に明確であれば、検証の取り決めに進みます。

ユーザーが長期的に参照できる機会マップ、ポジショニング、MVP の範囲、ピッチのストーリー、または意思決定メモを求めた場合は、references/artifacts.md の該当セクションを読み、現在の証拠の状態を維持します。

1. 検証の取り決めを固める

ユーザーから得た情報を、暫定的に次の一文にまとめます。

[顧客]は[状況]において[コストのかかる問題]に苦労しており、現在は[代替手段]を使っています。[購入者]は[切り替える理由]から、[提案する価値]を選択し、対価を支払います。

次の項目も記録します。

• 地域または市場の範囲
• この検証で判断すべきこと
• 時間、費用、アクセス、調査に関する制約
• どのような証拠があれば前進、再構成、保留、または中止とするか

入手できる情報に基づいて取り決めの案を提示します。推測できず、意思決定を左右する空欄についてだけ質問します。ユーザーには一度だけ修正の機会を設け、汎用的なスタートアップ向けヒアリングは行いません。

提案するソリューションの形がまだ大きく変わり得る場合は、顧客と問題の側を固め、オファーに関する主張は未確定と明示します。根拠のない精密さを作り出してはいけません。

2. 主張と証拠のマップを作成する

意思決定を左右する主張ごとに、次の項目を記録します。

• 現在の証拠
• 最も有力な別の説明
• 証拠の状態
• 間違っていた場合のリスク
• 複数の説明を見分けられる、最も低コストな方法
• 意思決定を変える基準

証拠を集めやすいかどうかではなく、意思決定への影響度 × 不確実性を基準に優先順位を決めます。

継続的に更新する検証ブリーフを作成または更新する前に、references/artifacts.md を読みます。

3. まず自社が保有する証拠を調べる

公開ウェブを検索する前に、ユーザーがすでに保有している証拠があれば確認します。

• サポートでの会話や機能リクエスト
• プロダクトの利用状況、継続率、解約、ワークフローデータ
• 営業通話、異議、受注・失注の記録、CRM フィールド
• インタビューの記録、アンケート、メール、コミュニティでの会話
• 有料パイロット、提案書、調達の手順、過去の実験

機能と需要を区別します。既存コードは何かを構築できる証拠であり、機能リクエストは誰かが要望した証拠です。いずれも、繰り返し発生する課題や購入意向を証明するものではありません。

プライバシーと権限を尊重します。生の顧客データが不要な場合は、集計済みまたは匿名化された証拠を求めてください。

4. 二次証拠の監査を行う

契約を支持する証拠と反証する証拠の両方を調査します。

• 繰り返し発生する課題とその影響
• 回避策と既存の支出
• 直接の競合、代替手段、サービス、社内開発、利用しない選択
• 購入者、予算、調達に関する表現、乗り換えの障壁
• 市場のタイミング、規制、集中度、アクセス可能なコミュニティ
• 構造的なリスクを明らかにする失敗した製品や試み

references/research.md を読み、現在検証中の主張に関係する手法のみを使用します。証拠を並行して収集する場合は、references/orchestration.md を読んでください。

正規化された出典、日付、対象となる主張、証拠の種類、引用またはデータポイント、確信度、矛盾を記録した証拠ログを作成します。裏付けの件数を数える前に、出所が同じ証拠は重複を排除してください。

最初にもっともらしい答えが見つかった時点ではなく、飽和状態に達した時点、または事前に定めた調査上限に達した時点で終了します。

5. デスクリサーチの判断を下す

二次証拠と自社保有の証拠から何が確立できるのかを総合します。正確な表現を使います。

• 証拠が間接的な場合は「調査で裏付けられた」または「妥当そう」とし、「検証済み」とは決して表現しません
• 決定的な主張が未解決の場合は「証拠不十分」とします
• 見せかけの確信度を一つだけ示すのではなく、主張ごとに確信度を示します

この段階で、「フィールド検証に進む」「仮説を再構成する」「保留する」「中止する」のいずれかを推奨します。強力な一次証拠と行動に基づく証拠がすでにない限り、最終的な市場検証の結論はまだ出さないでください。

6. 一次調査で仕組みに関する不明点を解消する

インタビューやワークフローの観察を通して、次の点を把握します。

• 実際に起きた直近の事例、そのきっかけ、経緯、影響
• 現在の代替手段と、それが許容され続けている理由
• 変化に気づく人、担当者、承認者、支払者、変更を阻止できる人
• 緊急性、乗り換えの条件、導入リスク
• 顧客が自然に使う言葉

references/fieldwork.md を読み、次のものを準備します。

• 参加者の条件と除外条件
• 参加者の募集経路
• 行動を重視したインタビューまたは観察のガイド
• 証拠の記録形式
• サンプル数と終了の判断根拠

ユーザーがセッションを実施して記録を後から提出してもかまいません。または、接続されたツールから権限のある証拠を取得してもかまいません。インタビューを捏造したり、断りなく公開投稿に置き換えたりしないでください。

パターンと反証となる事例を総合します。インタビューで検証できるのは仕組みと背景です。熱意を示す発言だけでは、支払い意向は検証できません。

7. 行動テストまたは商用テストで需要のギャップを埋めます

決定を左右する最も弱い主張を現実に照らして検証できる、最小限のテストを選びます。 例：

• 有料またはデポジット付きのパイロット
• 約束した成果をコンシェルジュ形式または手作業で提供する
• 具体的な義務を盛り込んだ提案書または意向表明書
• 実際の購入判断を伴う価格設定またはパッケージのテスト
• リーチ可能なオーディエンスからの適格なコンバージョンを測定するスモークテスト
• ターゲットセグメントを獲得できるか測定するチャネルテスト
• データ、統合、またはワークフローへのコミットメントを求める切り替えテスト

開始前に以下を定義します。

• 検証する具体的な主張
• 対象参加者とオファー
• 自己申告の好みではなく、観察可能な行動
• 合格／見直し／中止の基準
• 時間と支出の上限
• このテストで証明できないこと

ツールと権限が許す場合は、テストの実施を支援します。それ以外の場合は、すぐに実行できるプロトコルを作成し、人間による確認の段階でいったん停止して、返された結果を受けて再開します。「使ってみたい」という意向、ウェイトリストへの登録、称賛を支払いとして扱わないでください。

8. 不確実性を隠さずに判断します

すべての主張のエビデンス状態を更新してから、次のいずれかを提示します。

• Advance — 次の可逆的な投資を進めるのに十分なエビデンスがあります
• Reshape — 市場のシグナルはありますが、顧客、問題、購入者、オファー、チャネル、またはタイミングを変更する必要があります
• Hold — エビデンスがまだ不十分で、現時点では次のテストにかかるコストに見合う価値がありません
• Stop — 意思決定を左右する主張または経済性と矛盾する強いエビデンスがあります

以下について、それぞれ個別に判断を示します。

• 問題
• 需要
• 購入者／予算
• 提案するオファー
• リーチ可能性

顧客1人や有料パイロット1件はエビデンスであり、再現可能な市場の証明ではありません。判断がAdvanceであっても、次に検証されていないリスクを明示します。

9. 市場検証のドシエを作成します

references/artifacts.md を読みます。最終的なドシエには、以下を示す必要があります。

• 検証契約と判断
• デスクリサーチからフィールドワーク、実験までのエビデンスの推移
• 主張ごとのエビデンス状態と信頼度
• 最も強い支持エビデンスと反証エビデンス
• 顧客、購入者、代替手段、競争の実態
• 事前に確定した基準に照らした実験結果
• 問題、需要、購入者、オファー、リーチ可能性の個別判断
• Advance／Reshape／Hold／Stop の推奨
• 次の投資と、その投資で解消を目指すリスク
• 出典と調査範囲の付録

フィールド調査や行動テストを実施できなかった場合は、中間検証ブリーフを作成し、その旨を正直に明記したうえで、すぐに実行できる次のテストを残します。調査レポートを、完了した市場検証のように見せてはいけません。

長期間の検証を再開する

セッションを再開する際は、最初に次を行います。

1. 継続して更新する検証ブリーフを読む
2. 有効な契約と現在の判断を1文で言い直す
3. 新しいエビデンスと、それによって変わる主張を特定する
4. 最初に残っている確認段階から続ける

仮説が変わっても、発見プロセスを最初からやり直したり、過去の経緯を書き換えたりしてはいけません。何が、なぜ変わったのか、以前のエビデンスのうちどれが引き続き有効なのかを記録します。

ガードレール

• 市場規模、トラフィック、資金調達、競合を需要と同一視してはいけません。
• 重複する主張を、独立した裏付けとして数えてはいけません。
• インタビューから支払いを主張したり、ランディングページから継続利用を主張したり、パイロットから拡張可能な顧客獲得を主張したりしてはいけません。
• 矛盾するエビデンスや、結果が得られなかったエビデンスを隠してはいけません。
• 顧客とコストの高い状況を確認する前に、オファーの最適化を行ってはいけません。
• ライフスタイル事業や社内ツールに、ベンチャー規模を前提とした基準を無理に当てはめてはいけません。
• 対象顧客または購入者からの行動やコミットメントなしに、「市場検証済み」と主張してはいけません。
• 決定的な否定的エビデンスが得られた後、見栄えのよいレポートを作るためだけに検証を続けてはいけません。