正解を探すより、確かめられる形にする。

I. 計画より先に、学習できる状態をつくる

01. 正しい計画ができてから始める、という幻想

新規事業を考えるとき、調査は重要だ。しかし、十分に調査すれば失敗しない計画を作れるかといえば、そうではない。顧客はまだ存在しないサービスの使い方を正確に予測できるとは限らず、事業側も顧客の実際の行動を十分には知らない。私が最初に目指したいのは、完璧な事業計画ではなく、重要な仮説を現実で確かめられる状態をつくることだ。何を試せば、次の判断が変わるだろう。その問いから実行順序を決めたい。

02. 顧客の希望と、顧客の判断は違う

「こんなサービスがあれば使いたいですか」と聞くと、好意的な答えが返ってくることがある。しかし、それが実際の購入や継続利用につながるとは限らない。私は、希望を聞くことに加え、直近ではどう問題を解決したか、なぜその選択をしたか、何にお金や時間を使ったかを知りたい。行動には制約が表れる。予算、手間、周囲の承認、既存の取引関係。顧客の意思決定を理解するには、言葉だけではなく、その選択を生んだ条件を見る必要がある。

03. 最初は人がやればいい

ある買い手と売り手を結ぶ事業を考えるとする。初期からAIによるマッチングや自動見積もりを作るのは魅力的だ。しかし、何が適切なマッチングなのかをまだ理解していなければ、何を自動化するべきかも決まらない。まず買い手の条件を聞き、売り手の制約を確認し、人の手で組み合わせてみる。その過程で、どんな理由で選ばれ、どこで取引が止まったかを記録する。人力で行うことは必ずしも後退ではない。顧客の判断プロセスを学ぶ観測装置にもなる。

II. 仮説を小さくし、適切な実験を選ぶ

04. 仮説を小さく、検証できる形に変える

「市場にニーズがある」は大きすぎる仮説だ。例えば「この条件の企業10社のうち、3社以上が既存の手段に不満を持ち、試験導入の面談を希望する」のように、対象、行動、基準を設定すれば確認しやすくなる。ただし数字を恣意的に置けばよいわけではない。基準はコストや次の投資判断と結びつける。検証したいのは共感の有無だけではなく、実際に次の行動が起きるかどうかだ。

05. プロトタイプは議論を進める言語になる

口頭での説明が難しい場合、簡単な画面や資料があると、相手は具体的に反応できる。「ここで何を入力するのか」「この言葉は分からない」「この情報が先に欲しい」。そうした反応は、抽象的なアンケートでは得にくい。私はデザインやAIを用いた試作を、完成物の代用品ではなく対話のための道具として使いたい。美しいプロトタイプほど、完成しているという誤解を与える場合もある。何が仮で、何が検証対象かを明示することも大切だ。

06. 検証しないことも、意思決定である

すべての仮説を試す時間はない。重要なのは、外れたときの損失が大きいもの、今後の選択肢を大きく変えるものから検証することだと考えている。デザインの細かな差異より、そもそも買い手が費用を払うかの方が先かもしれない。システムの自動化より、取引成立までに誰がどの確認をしているかを知る方が先かもしれない。私は検証の優先順位も、事業の設計そのものだと考えている。

07. 学習して、更新して、進む

仮説が外れることは必ずしも失敗ではない。外れた理由が分かり、次の行動が変われば学びになる。一方で、何度調査しても意思決定が変わらないなら、検証としての価値は低い。私は「何が分かったか」だけでなく「その結果、次に何を変えるか」を記録したい。考える、試す、観察する、更新する。この循環を続けられることこそ、初期事業を前に進める能力なのだと考えている。

III. 実験の種類と終了条件を設計する

08. 検証には、段階がある

試すという言葉は便利だが、何を確かめるかによって方法は異なる。問題が存在するかを知りたければ、顧客が過去にどう行動したかを聞く。提案が魅力的かを知りたければ、具体的な資料を見せて反応を得る。購入の意思を確かめたければ、商談や有償の小さな実験を行う。継続利用を確かめるには、一定期間にわたる行動を見る必要がある。一回の好意的な反応を、すべての仮説が検証された証拠にはしたくない。検証対象と観測方法を対応させることが大切だと考えている。

09. AI導入前に知るべき業務の中身

AIエージェントの構想を聞くと、何を自動化できるかをすぐ考えたくなる。しかし業務の判断基準が人によって異なる場合、最初に必要なのはAIの性能比較ではなく、現場でどのように判断が行われているかを知ることかもしれない。熟練者はどこを見て例外を判断しているか。失敗したとき誰が修正するか。記録に残らない交渉や確認は何か。それらを整理してから、AIが担う部分、人が承認する部分、ルールで固定する部分を分ける。技術の選択は、業務を理解した後の設計判断であるべきだと考えている。

10. 実験を終える条件も決める

私は何かを始めるときだけでなく、止める条件も考えておきたい。顧客の反応が一定水準を下回ったら提案を修正する。ある期間試しても必要な条件が成立しなければ対象市場を変える。想定していた課題が存在しないなら、機能を作らない。こうした基準は冷たく聞こえるかもしれないが、限られた資源を別の可能性に振り向けるために必要だ。検証の成果は、必ずしも前進の承認ではない。進まないという判断ができることにも価値がある。

11. 最初の実験は、最も立派なものではなくてよい

プロダクトを作るとき、完成度の高い画面を先に見せたくなることがある。しかし、その画面が答えるのは主に「使えそうか」「理解できそうか」であって、「本当にお金を払うか」「継続して使うか」とは別の問いだ。私は検証したい不確実性ごとに、実験方法を変える必要があると思っている。ニーズの存在を知りたいならヒアリング。提供価値の伝わり方を確かめたいなら説明資料や簡易LP。実際の意思決定を見たいなら、申込や見積依頼など負担のある行動。操作性を確かめたいならプロトタイプが向いている。いきなり開発しても、その結果がどの仮説への答えなのか分からなければ、学習は進まない。小さな実験ほどよいのではない。答えたい問いに対して、最も軽い実験を選びたい。

IV. 行動・人力・AIから学ぶ

12. 「欲しい」という言葉と「使う」という行動

新しいサービスの構想を話すと、多くの人が好意的な反応を返してくれる。それ自体はありがたいが、「面白いですね」は需要の証明ではない。たとえば、仕入れを支援するサービスなら「使ってみたいですか」だけでなく、直近でどのように仕入れ先を探し、何日かけ、どんな情報を比較し、何を理由に見送ったかを聞きたい。そして、次の商談や紹介に進む意思があるかを確かめる。行動を伴う判断には、言葉だけの賛同と異なる情報がある。ただし、反応の強さは相手の状況にも左右される。早期の協力者の熱量がそのまま市場全体を代表するわけではない。定性調査の目的は、都合の良い声を集めることではなく、仮説がどの条件で成立し、どの条件で崩れるかを見つけることだ。

13. 人力オペレーションを、学習のために設計する

最初に人が対応するという方法は、単に開発費を節約するためではない。例えば買い手から希望条件を聞き、候補となる商品や事業者を探し、条件をすり合わせる作業には、判断の連続が含まれている。予算の上限を先に見るのか、納期を優先するのか、最低発注量が合わなければ代替案を出すのか。人が行った判断を記録して初めて、自動化する際に何が必要かを議論できる。一方、人力だからこそ成立する過剰な配慮もある。担当者が毎回特別対応しているなら、利用者の満足度だけを見ても事業として持続可能かは分からない。必要時間、例外対応、成約率、繰り返された判断を記録し、どこが共通化できるかを見極めることが重要だ。人力検証は、最初から運用上の限界も観察してこそ意味がある。

14. 検証を始める前に、やめる条件を書く

実験を始めるとき、人は成功の兆しに注目しやすい。何人かが好意的に反応すれば、仮説が正しかったように感じることもある。だから私は、可能な範囲で、どの結果なら継続し、どの結果なら見直すかを先に置きたい。例えば対象者へのヒアリングで、想定した課題が繰り返し確認できなければ、顧客セグメントを変える。紹介から具体的な商談につながらなければ、価値提案や取引条件を見直す。もちろん、初期段階では統計的に確かな判断ができないこともある。数値だけで機械的に中止するのではなく、その数値がどの判断を支えるかを説明できるようにする。大切なのは、前進したい気持ちに合わせて基準を後から変え続けないことだ。失敗が分かる実験は、失敗した事業より価値がある場合がある。

15. AIに置き換える前に、誰の責任かを考える

AIを使えば、ヒアリング内容の要約、条件の整理、候補の提示、文章の下書きなどを効率化できるかもしれない。しかし、AIが提案した内容を誰が確認し、間違いが起きたら誰が対応し、利用者へどのように説明するかは別に設計する必要がある。特に人材や取引のように、本人の機会や金銭に影響する判断では、便利さだけで自動化範囲を決めたくない。定型的に整理できる部分と、関係者の事情を踏まえた判断が必要な部分を分ける。さらに、AIが返した結果を修正できる導線や、重要な判断を人が追える記録を残す。技術の役割は人間の判断を消すことではなく、良い判断に必要な情報を扱いやすくすることにもある。新技術を取り入れるほど、設計思想を先に問う必要があると感じる。

V. 学習を次の仕様へ変える

16. 仮説検証を「安く試すこと」だけにしない

小さく試すことは有効だが、少額で実験できるものが常に最優先とは限らない。企業の採用、医療、金銭、個人情報のように、利用者へ大きな影響を与える領域では、実験にも相応の準備が必要になる。顧客への約束が守れない可能性があるなら、まず提供範囲や例外対応を限定するべきだろう。私は、検証に必要な速度と、利用者に対する責任を両方見たい。初期の実験だから許されることと、初期だからこそ慎重であるべきことを分ける。プロトタイプで済ませられる問いと、実際の運用体制がなければ試すべきでない問いは異なる。速く学ぶことが、他者の不利益を軽く扱う理由になってはならない。

17. 結果が悪かったとき、何を更新するのか

実験の結果が期待を下回ったとき、「アイデアが悪かった」とすぐ結論づけることはできない。対象ユーザーの選定が間違っていたのか、価値提案が伝わらなかったのか、価格条件が合わなかったのか、検証の方法自体が適切ではなかったのか。私は学習したことを、顧客、課題、解決策、提供方法、収益構造のどこに属するかに分けたい。例えば同じ価値を求める人がいても、使う頻度が低ければサブスクリプションには向かないかもしれない。それは顧客課題の不存在ではなく、収益モデルの不一致だ。実験が失敗したという一言で複数の仮説をまとめて捨てないことが、次の試行を良くする。

18. 検証を続ける組織のリズム

一度のヒアリングやプロトタイプ制作で、事業の不確実性がすべて解消することはない。私は、新しく得た情報が誰に届き、次の判断にどのように反映されるかまで設計したい。顧客の声が営業担当の手元で止まれば、開発の優先順位は変わらない。開発上の制約が経営者に伝わらなければ、実現できない約束が残る。検証結果は長い資料にまとめるだけでなく、「何が分かったか」「何が覆ったか」「何を変えるか」を短く共有する。そして一定の間隔で仮説と実行を見直す。学習速度は調査の量だけでは決まらない。学んだ内容を次の行動へ変換する速さによっても変わる。

19. プロトタイプから得るべき答えを混ぜない

私は試作品を見せたときの感想を、そのまま需要の証明として扱わないようにしたい。「分かりやすい」と「使いたい」は違う。「使いたい」と「継続的に料金を払う」も違う。たとえば、画面を触って迷わなかったことは操作性に関する学びであり、その価値に顧客がお金を払うかは別の検証が必要になる。実験ごとに答えられる問いの範囲を先に決め、得られた情報をその範囲で解釈する。そうすれば一つの好意的な反応に過度な期待をかけずに済む。試作品は未来のプロダクトを演出するためでなく、まだ知らないことを発見するために使いたい。

20. 初期検証の記録から、次の仕様を生み出す

顧客ヒアリングで同じ要望が三度出てきても、そのまま機能に追加するとは限らない。私はまず、その要望が生まれた背景を比較したい。共通する困りごとがあるのか、別々の問題を同じ言葉で話しているのか。たとえば「もっと検索しやすくしてほしい」という声の背後には、検索条件の不足ではなく、候補の信頼性を判断できない問題があるかもしれない。発言を要望リストへ移すだけでなく、判断の条件、発生頻度、代替手段、実際に取った行動を一緒に残す。そうすれば、次の仕様が誰の何を変えるためのものか説明しやすい。