物語形式のガイド。AIが単純な疑問をどう研究、プロトタイプ、検証、ローンチ計画へと段階的に変えていくかを示します。

マヤは「スタートアップを始めたい」わけではない。小さくて、ただ繰り返される煩わしいことを二度と起こしたくないだけだ。
毎週月曜、チームのステータス更新は五つの異なる形式で届く—箇条書き、段落、スクリーンショット、中途半端な考えの断片。彼女はそれをリーダーが読める形にまとめるのに1時間かけている。難しい仕事ではない。ただ…不必要なのだ。
数ヶ月後、その疑問がしぶとく残った:
なぜこれが繰り返されるのだろう?
最初、マヤは大抵の人と同じように振る舞った:文句を言い、肩をすくめ、別のスプレッドシートを作った。
しかし今回は立ち止まり、苛立ちを手がかりとして扱った。この問題が毎週、複数の人に発生しているなら—もしかすると「マヤのチームだけ」の問題ではないかもしれない。パターンとして理解する価値がある。
ここが転換点だ:"これはイライラする" から "これは他の人もお金を払ってでも解決したい問題かもしれない" へ。解決が華々しいからではなく、痛み(困りごと)が一般的だからだ。
マヤはAIアシスタントを開き、正直で雑なプロンプトを書いた:
「ステータス更新を何度も書き直すのはもうイヤだ。ここにシンプルなプロダクトアイデアはある?」
AIは光るアプリのコンセプトを吐き出す代わりに、明確化の質問を投げかけた:
マヤは答え、三つの問題を同時に解こうとしていたことに気づく。ひとつが際立った:乱れた更新を一貫した読みやすい週次ブリーフにすること。
AIはマヤの思考を構造化し—問題を整理し、仮定を表面化し、それらをテストする方法を提案した。だが、重要な決定はマヤがする:どの痛みに注力するか、どのトレードオフを許容するか、「よくなる」とは誰にとってどういう状態か。
サイドキックは案を下書きできる。ビルダーが決める。
好奇心はしばしばぼんやりした文になる:「なぜこんなに難しいのか?」や「もっと良い方法はある?」 マヤのノートでは面白いだけで、行動に移せるほど明確ではなかった。
そこで彼女はAIに、煽りではなく辛抱強い編集者のように振る舞うよう頼んだ。目的はアイデアを増やすことではない。問題を明確にすることだ。
彼女は雑な考えを貼り付けて頼んだ:
「これを一文の問題文に書き直して。次に、初心者向け、ビジネス向け、感情に正直なバージョンをそれぞれ3つ出して。」
数秒で、評価できるほど具体的な選択肢が手に入った。彼女は摩擦を実際に名指しするものを選んだ—機能ではなく摩擦だ。
問題文例: 「Xをしようとする人は、Yの瞬間で行き詰まり、Zという結果を引き起こす。」
次にAIは場面を作らせた:
これにより「誰でも」だった対象が具体化する(例:「新任チームリード、週次報告の30分前」)。
AIはテスト可能な形で短い仮定リストを提案した:
最後に、彼女はスプレッドシートなしで「よくなる」とは何かを定義した:
成功指標: 「初めてのユーザーが、助けを求めずに10分以内に行き詰まりから完了まで到達できること。」
これで疑問は単に面白いだけでなく、テストする価値があるものになった。
マヤの好奇心には問題がある:ノイズが多い。 “MVPを計画する手伝い” で検索すると、テンプレート、コース、ノーコードツール、意見が山のように出てきて、何も一致しない。
そこで彼女はAIにもっとシンプルな依頼をした:「既にあるものをマップして、製品を買わないで人々が代わりに何をしているかを教えて。」
数分でAIはスペースを次のように分類した:
これは判定ではない—単なる地図だ。アイデアがどこに当てはまりそうかを見る手助けになる。
次に彼女は表を頼んだ:「主要オプション、典型的な価格、欠点、よくある不満。」
| オプションの種類 | 一般的な価格帯 | よくある不満 | 欠けている点 |
|---|---|---|---|
| 講座 | $50–$500 | 一般的すぎて応用が難しい | あなたの文脈に合った次の手順の案内 |
| テンプレート | $10–$100 | 見た目は良いが結果が変わらない | フィードバックループと説明責任 |
| コーチ/コンサルタント | $100–$300/hr | 高価で品質が不安定 | 手頃で一貫したガイダンス |
| コミュニティ | $0–$50/mo | ノイズが多くシグナルが少ない | 構造化されたプロンプトとチェックポイント |
AIは次の厳しい質問を投げかけた:「これが単なる既存のものの別バージョンでなく、本当に違うものにする要素は何か?」 これがマヤを、あれもこれもではなく「より速い明確化と少ない判断」を目指す角度に押しやった。
最後にAIは、カスタマーディスカバリーで検証すべき主張をハイライトした:「人々は講座が嫌いだ」「テンプレートは機能しない」「コーチングは高すぎる」—有用な仮説だが、実際のユーザーが確認するまで仮説である。
好奇心は頭の中で群衆を作る:学生、マネージャー、フリーランサー、親、創業者。AIのサイドキックは彼ら全員のための機能を喜んでブレインストーミングするだろう—そしてそれがプロジェクトが静かに膨らむ原因になる。
解決法はシンプル:現実の状況にあるリアルな一人を選び、最初のバージョンはその人のために作る。
「多忙なプロフェッショナル」のようなステレオタイプの代わりに、AIに具体的な文脈を使ってペルソナを描かせる:
ペルソナ例:
各ペルソナを「Xのとき、私はYが必要、だからZがしたい」の形式で2–3のユーザーストーリーに変えるようAIに頼む。
マヤの場合:「クライアントが散らかったメモを送ってきたとき、私はきれいなブリーフが必要だ。そうすれば毎回全て読み返さずに自信を持って対応できる。」
ここで難しい選択をする:バージョン1の主要ユーザーを一人選ぶこと。
良いルールは、痛みが最も明確で小さな勝利に最短で到達できるペルソナを選ぶことだ。そして**1つのメインのやること(job-to-be-done)**を定義する—最初のバージョンが提供すべき単一の成果。その他は「後で」にする。
好奇心あるビルダーは頭の中にプロトタイプと強い意見を持ち、ひとつ大きなリスクを抱えている:既に信じていることを確認するような聞き方で人にインタビューしてしまうことだ。
AIはカスタマーディスカバリーを速くするが、真の利点は“よりクリーンにする”こと:誘導的でない質問、明確なノート、どのフィードバックが重要かを判断しやすくすることだ。
良いディスカバリー質問は物語を誘う。悪い質問は許可を求める。
AIにあなたの質問を誘導語や仮定を取り除いて書き直させよう。例えば:
使えるプロンプト例:
Rewrite these interview questions to avoid leading language or assumptions.
Make them open-ended, focused on past behavior, and easy to answer.
Questions: ...
(このコードブロック内の内容は翻訳せず、そのまま使ってください)
スピードは構造から生まれる。AIに10回繰り返せるシンプルなフローを下書きさせよう:
さらに、ノート取りテンプレートも生成して、文字起こしの海に溺れないようにする:
AIに、あなたの厳密な対象が集まる場所をブレインストーミングさせ、今週実行できるチャネルを2つ選ぶ:ニッチなSlack/Discord、LinkedIn検索、Redditコミュニティ、ミートアップリスト、または知人の紹介など。
目標は「たくさんのインタビュー」ではなく、一貫した質問での10の関連ある会話だ。
「いいね」といった好意的な反応はナイスだがシグナルではない。シグナルは:
AIにノートを Signal / Maybe / Noise とタグ付けさせてもよいが、最終判断はあなたが下す。
数回の会話の後、好奇心あるビルダーはいつもの問題に直面する:ページいっぱいのノート、十二分な「多分」コメント、そして自分が聞きたいことだけを聞いているのではという恐れ。
ここでAIが真価を発揮する—洞察をでっち上げるのではなく、散らかった会話を行動可能な形に変える。
まずは生のノートを一つのドキュメントにまとめ(インタビュー1件ごとにセクション)、それをAIに投入して各発言を簡単なバケツにタグ付けしてもらう:
目標は完璧な分類ではなく、再訪可能な共有マップを作ることだ。
次にAIに繰り返し出るパターンを要約させ、かつ矛盾点をハイライトさせよう。矛盾は金脈だ:異なるユーザータイプ、異なる文脈、あるいは一貫しない問題を示すことが多い。
例えば:
「新しい設定をする時間がない」
…は次と共存し得る:
「もし週に2時間節約できるなら、習得するかもしれない」
AIはこれらを並べて表に出してくれるので、あなたが意味のない平均値をとってしまうのを防げる。
次にテーマを「トップ3の問題」に変換する。各問題に対して:
平易な問題の記述
それを経験する人(役割/文脈)
1–2の証拠となる引用
例フォーマット:
これにより正直でいられる。引用が見つからなければ、それはあなたの仮定かもしれない。
最後にAIに学んだことに基づく判断を助けてもらう:
まだ確実性は要らない—次に取る現実的な一手があればよい。
この段階でビルダーはノートに洞察が溜まり、「それもやろう」と頭の中で多くの機能を思いつく。ここでAIが最も役に立つのは、機能を追加することではなく、出荷できるほどに切り詰める手助けだ。
一つのアイデアを延々議論する代わりに、AIに5–7のソリューションスケッチを作らせ、それぞれを**工数(S/M/L)対インパクト(S/M/L)**でランク付けさせる。
シンプルなプロンプト例:「この問題を解決する7つの方法を列挙し、それぞれに工数(S/M/L)とインパクト(S/M/L)を見積もり、理由を説明して。」
完璧さは求めていない—ただ明確な先頭候補が欲しい。
MVPは「完全版の最小バージョン」ではない。特定の人にとって一つの意味のある結果をもたらす最小のバージョンだ。
AIはその成果をテスト可能な約束として言い表す手助けをする:
成果が曖昧なら、MVPはまだ fuzzy だ。
フィーチャークレープを避けるために、AIに「v1にないもの」リストを作らせよう:
このリストは新しいアイデアが出てきたときの盾になる。
最後にAIに繰り返し言えるメッセージを下書きしてもらう:
これでMVPは小さく目的が明確になり、プロトタイプに進める状態になる。
プロトタイプはプロダクトがただの説明から「実際に振る舞う何か」になる場所だ。完璧でもフルビルドでもない—クリックしたり読んだり反応できるくらい具体的であればよい。
AIにMVPを画面ごとのアウトラインに翻訳させよう。コアバリューを証明する短い道筋を目指す。
例えば、こう投げると良い:
You are a product designer. Create a simple user flow for a first-time user.
Context: [what the product helps with]
MVP scope: [3–5 key actions]
Output:
1) Flow diagram in text (Screen A -> Screen B -> ...)
2) For each screen: title, primary CTA, and 2–4 lines of copy
Keep it friendly and clear for non-technical users.
(このコードブロック内の内容は翻訳せず、そのまま使ってください)
そこから紙のラフや簡単なクリックモックを作れる。目標は、初見で10秒以内に「分かる」ことだ。
多くのプロトタイプが失敗する理由はコピーが曖昧だからだ。AIを使って次を下書きしよう:
プロトタイプを声に出して読んでも意味が通れば良い状態だ。
全部を作る前に、約束を説明するランディングページを用意し、2–3のプロトタイプ画面を見せ、明確なCTA(「アクセスをリクエスト」や「ウェイトリストに参加」)を置こう。まだ作られていない機能をクリックしたらフレンドリーなメッセージを出し、メールを取る。
AIはランディングページ、FAQ、シンプルな価格案内(プレースホルダーで /pricing など)を書くのを手伝ってくれる。
あなたが探すべきはお世辞ではなく、コミットメントだ:クリック、サインアップ、返信、そして実際の意図を示す具体的な質問。
検証は「これがうまくいくかもしれない?」から「誰かが行動するほど気にかけているのか?」に変わる瞬間だ。目標は完璧な製品ではなく、最小限の努力で価値の証拠を得ること。
機能を作る代わりに決断を促すテストを選ぶ:
AIはばらばらなアイデアを端的なオファーに変える手助けをする:見出し、短い説明、利点、マーケっぽくないCTA。
何かを送る前に「成功」が数字で何を意味するかを書き出す。虚栄メトリクスではなく、意図のシグナル。例:
測れないなら学べない。
AIに特定の一人に向けた見出し+CTAを10ペア作らせ、2つ選んでテストしよう。一方は「時間節約」に寄せ、もう一方は「ミスを避ける」に寄せる、など同じオファーで角度を変える。
テスト後、AIに何が起きたかを要約させる:人々が何をクリックしたか、何を質問したか、何が混乱を招いたか、何を無視したか。最後はシンプルな判断:続ける/変える/止める と次に試す1文。
「デベロッパー語」を話さなくてもビルドを計画できる。必要なのは明快さだ:ローンチ時に製品が何をするか、何を後回しにするか、どう動作を確認するか。
ここでAIはブレインストーミングをやめ、慎重なプロジェクトパートナーのように振る舞う。
AIにアイデアを Must-haves(必須), Nice-to-haves(あると良い), Later(後で) の簡単なビルドプランに変えてもらう。必須は約束を直接果たす機能だけを残して極端に小さく保つ。
次に各必須機能の「定義完了(definition of done)」を1ページで作らせよう。例プロンプト:
AIに次を作らせる:
これで外注先や開発チームに余計な推測の余地を与えない。
他の人と一緒に働くなら、AIに役割分担を書かせよう:誰がスクリーンをデザインするか、誰がバックエンドを作るか、誰がコピーを書くか、誰がアナリティクスを設定するか、誰がQAを担当するか。たとえ一人が複数を兼ねても、帽子を名前で分けることで抜け漏れを防げる。
ビルド前にAIに短い質問リストを作らせよう:どのデータを収集する?どこに保管する?誰がアクセスする?ユーザーはどう削除できる?ここで法的文書を作る必要はない—ただ後で驚かないための確認だ。
非技術者(または速く動きたい人)は“バイブ・コーディング”プラットフォームが役立つ場合がある。例えば、Koder.ai はあなたが平易に書いた仕様をチャットで受け取り、ウェブ/バックエンド/モバイルの動くアプリに変え、実際にテストしながらスナップショットやロールバックで繰り返せる。
実務的利点はコードが魔法のように出ることではなく、「ディスカバリーで学んだこと」から「誰かに見せられる動くバージョン」へのループが短くなることだ。後でより従来のパイプラインに移すならソースコードのエクスポートで道は開ける。
ローンチ日は台本なしで舞台に立つような緊張であってはならない。ディスカバリーを経て小さく有用なMVPを作ったなら、次の仕事はそれをただ分かりやすく説明し、初期ユーザーが試しやすくすることだ。
AIを実務的なプロジェクトマネージャーのように使い、散らかったノートを整然としたリストに変えよう。あなたが本物だと決めるのはあなただ。
「十分に良い」チェックリスト例:
ディスカバリーで出た疑問(「私のワークフローで動く?」「セットアップにどれくらいかかる?」「データは安全か?」)を取り、AIにトーンを合わせてFAQ回答を書かせよう。
そして正直に編集する。不確かな点があればそう言い、計画を説明する。
AIに次のシンプルなアウトラインを作らせよう:
最初の告知は人間味を保とう:「私たちが作ったもの、それが誰のためで、次に何をテストするか」です。
現実的なローンチウィンドウを設定し(小さくてもよい)、最初の勝利を定義する:アクティブユーザー10人、オンボーディング完了5件、または有料トライアル3件など。AIは進捗を手伝えるが、価値を証明するゴールはあなたが決める。
ローンチ後、好奇心あるビルダーはAIから“卒業”するのではない。AIの使い方が変わるだけだ。
初期はスピード(下書き、構造、プロトタイプ)を助ける。後期はリズムを保つ:パターンに気づき、継続性を守り、小さな判断をストレス少なく行う手助けをする。
シンプルなカデンツを設定しよう:ユーザーに話す、1つだけ小さな改善を出す、何が起きたかを書き留める。AIはそのループを静かに支えるアシスタントになる。
習慣の例:
サイドキックを有用に保つために線引きをする:
モメンタムが落ちたら、シンプルなスクリプトに戻る:
こうして好奇心はプロダクトになり、プロダクトは習慣になる。