アイデアを話したら、友人が褒めてくれた。名前も決まり、サイトのイメージも浮かんできた。
ところが、いざ見本を渡すと、その後の反応がない。「忙しくて、まだ見ていない」と言われる。
企画が悪かったのだろうか。それとも、声をかける相手や、届け方が違ったのだろうか。
ここで機能を足す前に、確かめたいことがある。相手は何に困っていて、その困りごとに今どう対応しているのか。そして、こちらが作ったものは、その生活のどこに入るのか。
この記事では、海外の起業家向けの考え方を材料に、FORWARD BASIS独自の「一週間の検証フロー」を組み立てる。これはPaul Grahamや『The Mom Test』が提示した標準手順の再現ではなく、複数の考え方を実行単位へ翻訳した編集提案である。
目的は一週間で事業の成功を証明することではない。次に作る理由を、想像だけで決めないことだ。
早い段階だからこそ、手間をかけて知れることがあるポール・グレアムは2013年のエッセイで、初期の事業では利用者を個別に見つけ、利用を手助けするような、人数が増えるとそのまま続けにくい活動を勧めている。Airbnbが初期に利用者を訪ね、掲載内容の改善を助けた例も紹介している。出典：Paul Graham「Do Things that Don’t Scale」
また、ロブ・フィッツパトリックの『The Mom Test』の公式紹介では、偏ったフィードバックを避け、顧客との会話から学び、実際の購入につながるかを見極めることが扱われている。出典：著者公式の書籍紹介
ここまでの二つは情報源側の主張である。以下の質問、曜日ごとの進め方、30分の作業枠は、それらを参考にFORWARD BASISが組み立てた独自案であり、原著で検証されたプログラムではない。
通して使うのは、「海外のビジネス情報を短く聴ける音声サービス」という仮想例だ。まだアプリはなく、短い音声と出典一覧を作れる段階を想定する。
月曜日：誰の、どの場面を助けるかを決める「ビジネスに興味がある人」では、対象が広い。その中には長い本が好きな人も、ニュースをほとんど必要としない人もいる。
まず仮説を、「通勤中に海外の仕事の話題を知りたいが、自分で英語の長い動画を探す時間を取りにくい人」まで具体化する。
これは実在する需要を確認したという意味ではない。これから話を聞く相手を選ぶための仮説である。
次に、その条件に近そうで、試作について話を聞いてよい相手を三人ほど探す。人数は実施しやすさのための目安だ。三人の意見で市場全体が分かるわけではない。
依頼するときは、売り込みではなく、普段の情報収集について聞きたいこと、所要時間、断ってよいことを伝える。無差別な大量送信ではなく、相手が参加を選べる形にする。
火・水曜日：欲しいかどうかより、実際にあった場面を聞く会話の冒頭から長い企画説明をすると、相手はその案への感想を求められていると受け取るかもしれない。まず聞きたいのは、こちらの案を知る前の日常だ。
聞くこと 音声サービスでの質問例 確かめたい点
直近の場面 最近、仕事に関する情報を探した 実際に必要とした場面があるかのはいつ？
現在の方法 そのとき、何を開いて、どう探し すでに使っている手段た？
具体的な不便 探す途中で困ったことや、やめた 不満の内容と重要さことは？
対処 困った部分をどうやって解決し 時間や手間をかけているかた？
利用場面 普段、音声を聴くのはどんなと 提案が入る時間や状況き？
一人十五分程度から始め、話が具体的なときには、その場面をもう少し詳しく聞く。「こういう機能があれば便利ですよね」と答えを誘導しないようにする。
相手が「特に困っていない」と言ったなら、それも大切な結果だ。説明を重ねて困っていると言わせても、検証にはならない。
メモには、相手の発言と自分の解釈を分けて残す。録音したい場合は先に許可を取り、不要な個人情報は集めない。
木曜日：全部入りではなく、困りごと一つに答える見本を作る会話の中で「短さよりも、何を根拠に話しているか分からないのが困る」という声が出たとする。これは説明用の仮想的な反応である。
その場合、最初に増やすのは音声の本数ではなく、出典の確認しやすさかもしれない。短い音声に、要点と原資料へのリンクを添える。発言と解説を分ける。これで、聞いた後に根拠へ進める見本になる。
試作品で省くものは、立派な会員画面や、ジャンルを細かく選ぶ機能などだ。省かないのは、事実確認と、何を提供するかの明確さである。
一度に多くを変えず、会話で出た不便にどう答えたかを自分で説明できる大きさにする。
金曜日：感想を集めるだけでなく、使う場面を確かめる参加に同意した相手へ見本を渡す。ここでは「最高ですよね」ではなく、実際に聴けるタイミングで試してもらう。感想を求める時期も相手と相談しておく。
聞いた後には、どんな場面で使ったか、途中で分かりにくかった箇所はあったか、普段の情報源と比べて何が違ったかを聞く。
さらに、次の回も受け取りたいかを尋ねる。ただし、受け取りたいという返事を、そのまま利用や購入と同じに数えない。
好意的な感想、実際に使ったこと、繰り返し使ったこと、有料でも申し込んだことは別の記録にする。無料の見本への反応だけでは、支払ってもらえるかまでは分からない。
週末：「伸ばす」より先に、何を変えるか決める一週間の終わりには、次の表のように観察と判断を分ける。ここがFORWARD BASISの検証フローで最も重要な部分だ。少ない反応を市場全体の結論へ膨らませず、「何を見たか」と「そこから何を仮説として置くか」を分ける。以下は想定例であり、実績ではない。
観察したこと すぐには言えないこと 次に確かめる案
褒められたが、未利用だった 需要がある／ないという結論 受け取り方や利用する場面が合っていたか聞く
聴いたが、説明が難しいと言われ 音声サービス全体が不要という結 同じテーマで説明の順番を変えるた 論
次の回も実際に聴いてくれた 有料でも継続するという結論 何が再利用の理由だったか聞く
人によって求める内容が違った 全機能を作るべきという結論 優先する相手と用途を絞る
少人数の反応なので、数字を立派な成功率へ変換する必要はない。誰が、どの条件で、何をしたかの記録を残すほうが、次の変更理由を説明しやすい。
返信がないことも、理由までは分からない。忙しかったのか、必要なかったのか、届いていないのかを混同しない。合意した範囲で確認し、返事を何度も迫らないようにしたい。
忙しくても検証を止めない、一日30分の基本枠毎日使える作業時間が短いなら、次の枠を出発点にする。
• 五分： いま分からないことを一つ決める。
• 十五分： 話を聞く、見本を直す、利用後の反応を確認する、のどれかを行う。
• 十分： 実際の発言・行動と、自分の解釈、次の確認事項を記録する。
見本の制作や根拠確認は、この枠だけで終わらないこともある。そのときは完成基準を下げず、制作日を増やす。一週間という区切りに合わせて、事実確認を省略しないことだ。
十分しか取れない日は、未確認の仮説を一つ整理し、次の面談準備や修正箇所の特定だけ行う。十分で需要の有無を判定するのではなく、次の検証へつなぐ短縮版である。
自動化するのは、繰り返す意味が見えたところからAIで台本や編集作業を助けることは、この試作と両立する。すべてを手で作らなければ学べない、という話ではない。
ただ、何を相手が必要としているか分からないまま大量に出力すると、制作量だけが増えることも考えられる。最初は、相手がどこで困り、何を気に入ったのかを確認できる形を残したい。
個別のやり取りで同じ依頼や作業が繰り返され、その提供が相手の役に立つと分かってきたら、その部分を自動化する理由ができる。
「いいアイデアだね」という言葉は、嬉しい出発点だ。でも、そこで確かめられたのは、まだ相手の感想である。
次に必要なのは、壮大な完成図をもう一枚描くことより、誰かの一日に入る小さな見本を届けること。その経験があれば、次に作るものを少し具体的に選べる。
SOURCE / 原典
この記事の出典
本文の事実確認に使用した原典です。FORWARD BASIS独自の解釈・整理は本文内で区別しています。