CHAPTER 01

Step 1 — 仮説を立てる

誰の・何の・どう解決するか。売上の出発点となる仮説設計。

Step 1: 仮説を立てる

売上は、神様の気まぐれで降ってくるものではない。「誰の・何の課題を・どう解決するか」を書ける言葉にしたとき、初めて検証できる対象になる。仮説が言葉になっていないと、ヒアリングしても何を聞けばいいかわからず、競合分析しても何を比較すればいいかわからない。Step 2以降の全プロセスが、この1章の精度に乗っかる。逆に言えば、ここを2時間かけて言語化するだけで、後の20時間が無駄に消えるのを防げる。

この章のゴールは「1枚の仮説シートを書く」こと。読み終わったら手を動かす設計にしている。

目次

  • [[#1. なぜ仮説から始めるか — 売上 = 仮説 × 検証回数|なぜ仮説から始めるか — 売上 = 仮説 × 検証回数]]
  • [[#2. 誰の課題か — ターゲット解像度の上げ方|誰の課題か — ターゲット解像度の上げ方]]
  • [[#3. 何の課題か — 課題の深さを測る(痛み・頻度・支払い意欲)|何の課題か — 課題の深さを測る(痛み・頻度・支払い意欲)]]
  • [[#4. どう解決するか — 解決案の幅出し(発散と収束)|どう解決するか — 解決案の幅出し(発散と収束)]]
  • [[#5. 仮説の評価基準 — 数字 / 実現可能性 / 自分の強み|仮説の評価基準 — 数字 / 実現可能性 / 自分の強み]]
  • [[#6. 仮説の書き方フォーマット(1枚仮説シート)|仮説の書き方フォーマット(1枚仮説シート)]]
  • [[#7. 軸X・軸Yそれぞれへの適用|軸X・軸Yそれぞれへの適用]]
  • [[#8. 演習 — 今の自分の仮説を1枚に落とす|演習 — 今の自分の仮説を1枚に落とす]]

1. なぜ仮説から始めるか — 売上 = 仮説 × 検証回数

概念

仮説とは「未検証の予測」のこと。「○○な人は、△△に困っていて、□□があれば払うはず」という1文。当たっているかは、まだわからない。当たっているかどうかを 検証可能な形 で書いたものが仮説。これに対して、「なんとなくAIで何か作りたい」は願望であって仮説ではない。

Steve Blankはこれを「起業は事業モデルを"探索"するフェーズであり、確立した会社が事業を"実行"するのとは別物」と定義した。スタートアップは仮説の塊で、それを科学実験のように一つずつ潰していく作業が、創業期の本業である(出典: Steve Blank "The Four Steps to the Epiphany")。

なぜ重要か

ここを抜くと、後の全工程が破綻する。具体的にこうなる。

  • ヒアリングが空振り: 「誰に何を聞くか」が定まっていないので、相手から有用な情報を引き出せない。世間話で終わる。
  • 競合分析が無意味: 何を比較すべきか軸が定まらないので、競合一覧を作っても判断に使えない。
  • 商品が作れない: 「誰のための、何の機能か」が言えないので、機能を足し続けて完成しない。
  • 売れない: 売り文句の主語と動詞が決まらないので、刺さらない。

Eric Riesは『リーン・スタートアップ』で、起業の本質を「Build-Measure-Learn(作る→測る→学ぶ)」のループとして定式化した。このループは、最初に作って測る対象=仮説がないと回り始めない(出典: theleanstartup.com / Lean Startup principles)。

どうやるか(手順)

  • 「売上=仮説の質×検証の回数」として捉える。当たり前のことだが、当たっていない仮説をいくら回しても売上は出ない。逆に当たっている仮説を1回も検証していなければ、確信が持てず動けない。
  • 今やっていることが「仮説の質を上げる時間」か「検証回数を増やす時間」かを毎日問う。それ以外の時間は、進捗に直結しない可能性が高い。
  • 1サイクル(仮説→検証→学習)を 4週間で1周 回す設計にする。1年12サイクル回せれば、Pieter Levelsの「12 startups in 12 months」型の打席数が確保できる(出典: levels.io / Indie Hackers podcast)。

よくある失敗パターン

  • 「アイデアを完璧に磨いてから検証したい」と思って、3ヶ月言語化に時間を使う(検証回数=0で終わる)
  • 「仮説が外れたら恥ずかしい」と思って、確実に当たりそうな小さな仮説しか出さない(当たっても売上が小さい)
  • 仮説を頭の中だけに持っていて、紙やファイルに書き出さない(検証できない/他人に相談できない)

今日できる1アクション

タイマーを15分にセットして、A4用紙またはマークダウンファイルに「今、自分が当てに行きたい仮説」を3個書く。3つとも「誰が」「何に困っていて」「自分は何を提供する」の3要素が入っていること。質は問わない。書き出すこと自体がスタート地点。

2. 誰の課題か — ターゲット解像度の上げ方

概念

「誰」を解像度高く描けないと、その後の全てが抽象に流れる。具体的には、年齢・職業・直近1ヶ月で困っていること・今お金を払っているもの・休日の過ごし方・ よく見ているSNS・口癖、までを 1人の実在しそうな人物像 として書ける状態がゴール。Nielsen Norman Groupはこれを「persona(ペルソナ)」と呼び、定性ヒアリングを通じて作るべきだとしている。ただし、最初の1枚は仮の人物像でいい。これを「proto-persona(仮ペルソナ)」と呼ぶ(出典: NN/g "3 Persona Types")。

なぜ重要か

人間は「みんなのため」のメッセージには反応しない。「これは自分のことを言われている」と思った瞬間に反応する。広告で言えば、「20〜60代の方へ」より「東京から実家に戻った元フリーランスエンジニアへ」のほうが、該当者の手は止まる。

Anthony Ulwickは25年のJTBD実践から「顧客が新しい解決策に乗り換えるのは、ジョブが20%以上うまく片付くと感じたとき」と整理している。20%を測るには、誰のどのジョブかを先に固定する必要がある(出典: anthonyulwick.com / Jobs-to-be-Done)。

どうやるか(5ステップ)

  • 想定顧客を1人選ぶ。複数の顧客像が思い浮かぶなら、最初は一番自分の身近にいる人(過去の自分・元同僚・実家の家族)を選ぶ。
  • その人の24時間を時系列で書く。起きる時間、最初に触るアプリ、通勤手段、昼食、夜に何をして寝るか。曖昧な部分は仮説で埋めて、後でヒアリングして検証する。
  • その人が直近30日で困ったことを5個書く。困りごとは仕事だけでなく、生活・健康・家族・人間関係・お金、まで広げる。
  • その人が今、毎月いくら何に払っているかを書く。サブスク・外食・交通・本・コーチング・サロン。支払い慣れているカテゴリの近くに、自分の商品を置けるかを確認する。
  • その人を1文で表せるラベルを作る。例: 「東京で年商1000万まで行ったが消耗して実家に戻った元フリーランスエンジニア、35歳、AIを使った再起動を模索中」。

ターゲット解像度のチェック質問

  • そのラベルだけ見て、知人の中で3人以上「あ、Aさんっぽい」と思い浮かぶか?(浮かばないなら抽象すぎ)
  • その人が今この瞬間、スマホで何を検索しているか具体的に書けるか?
  • その人が次の1万円を何に使うか、3つの候補を挙げられるか?

3問とも具体に答えられないなら、解像度不足。仮ペルソナのまま、5人に話を聞きに行く。NN/gは「5人ずつのローリングサンプルで、新しい発見が出なくなるまで」がペルソナ確定の目安としている(出典: NN/g)。

よくある失敗パターン

  • ターゲットを「個人事業主全般」のように広く取りすぎる
  • 自分が会いたい理想の顧客(優秀で予算がある人)だけを想定してしまう(現実には会えない)
  • ペルソナを作って満足してしまい、実在の人にヒアリングしない

今日できる1アクション

ノートかMarkdownに「ターゲット1人プロファイル」を、上記5ステップで書く。所要30分。書き終わったら、その人物像に近い実在の知人を3人リストアップする。Step 2で彼らにヒアリングする土台になる。

3. 何の課題か — 課題の深さを測る(痛み・頻度・支払い意欲)

概念

「誰」が定まったら、次は「何の課題か」。ただし、課題ならなんでもいいわけではない。Painkiller(鎮痛剤) になる課題と、Vitamin(ビタミン剤) になる課題は分けて考える。Y Combinatorの文脈で広く使われているこの分類は、「今すぐ・お金を払ってでも・解決したい」のがPainkiller、「あるといいよね」止まりがVitaminという区別をする(出典: Y Combinator界隈の議論 / ideatovalue.com)。

Y CombinatorのMichael Seibelはこれを「hair on fire problem(髪が燃えている問題)」と表現する。隣で友人の髪が燃えていたら、その人にとってはこの世のすべてがその火事に見える。そういう緊急性のある問題を探せ、と言う(出典: ycombinator.com / Startup School)。

なぜ重要か

Vitamin型の商品で売上を作るのは、Painkiller型より格段に難しい。理由は、Vitaminは購入を翌月に先送りできるから。Painkillerは今日決済する。月末に「今月はVitaminを買わない」という判断は気軽にされるが、Painkillerはそうならない。

個人事業主としてMVPで売上を作りたいなら、Painkillerの方向を狙うのが鉄則。Vitaminで売るには大資本のマーケが必要になりがちで、ソロプレナーとは相性が悪い。

課題の深さを測る3軸

  • 痛みの強さ(Pain): 解決しなかったら、本人にどれくらい困ったことが起きるか。
  • 強: 仕事が止まる / 健康を損なう / 信用を失う / 罰金が発生する
  • 中: 時間を無駄にする / 機会を逃す / イライラする
  • 弱: ちょっと不便 / なんとなく嫌
  • 頻度(Frequency): その痛みが、月に何回発生するか。
  • 強: 毎日 / 週に複数回
  • 中: 月に1〜数回
  • 弱: 年に数回 / 滅多にない
  • 支払い意欲(Willingness to Pay): その解決のためにすでに何かに払っているか。
  • 強: 月額/年額で何かに払っている(代替品が存在)
  • 中: 一時的に払ったことがある
  • 弱: 払う発想がない/無料で解決している

3軸すべてが「中以上」で交わる課題が、最も商品化に向く。「強・強・強」なら過密競合の可能性があるので、競合の質を別途確認する。

どうやるか(JTBDで掘る)

Clayton Christensenの Jobs to Be Done (JTBD) フレームを使う。「顧客は商品を買うのではなく、ジョブを片付けるために雇う」という捉え方。代表例として、マクドナルドのミルクシェイクのケースが有名(出典: HBS Online / christenseninstitute.org)。

McDonald'sでミルクシェイクの売上を伸ばす施策を考えていたチームは、味やフレーバーの調査で全然成果が出なかった。しかしChristensenが調査すると、ミルクシェイクの40%は朝、通勤客が「長い退屈な通勤を片手で持てるおやつで埋めるため」に買っていた。つまり、片付けたいジョブは「朝食」ではなく「通勤を退屈じゃなくする」だった。これがわかれば、ストローを細くして長く飲めるようにする、果肉を入れて飽きさせない、といった施策が見える。

このフレームをあなたの仮説にも適用する。「顧客は 何を片付けるため にあなたの商品を雇うのか?」を1文で書く。

よくある失敗パターン

  • 自分が作りたいものを「課題」だと勘違いする(技術ドリブンの罠)
  • 「市場が大きそうだから」と抽象的な業界課題に乗る(自分にしか掘れない深さがない)
  • Vitamin型を選んでしまい、売り込みに過度なエネルギーが必要になる

今日できる1アクション

Step 2で書いた「ターゲット1人プロファイル」の人物に対して、以下のテンプレートを埋める。

` [誰] は、 [いつ・どこで・何をしているとき] に、 [何の状況になる] と困る。 今は [代替手段] で対処している(または対処できていない)。 払っているのは [月額/単発/無料] で [金額]。 痛みの強さ: 強/中/弱 頻度: 強/中/弱 支払い意欲: 強/中/弱 `

ここまで書ければ、その課題が Painkillerか Vitaminか が肉眼で見える。

4. どう解決するか — 解決案の幅出し(発散と収束)

概念

ターゲットと課題が定まったら、「どう解決するか」の案を出す。ここで多くの人が、最初に思いついた1案に飛びついて作り始める。これがいちばんもったいない。Jake Knapp(Google Ventures)が『Sprint』でまとめている通り、発散(複数案を広げる) → 収束(評価軸で1つに絞る) の2段構えが、結果として速い。

なぜ重要か

最初の案は、ほぼ確実に「今までよく見ている解決策」の延長になる。それは大体、競合がすでにやっている。差別化されていない解決策で挑むと、価格競争に巻き込まれる。一方、3案以上出すと、自分でも予想していなかった角度が見つかることがある。それが自分の強みと交差する角度だったら、それが最初の勝ち筋になる。

Paul Grahamは『How to Get Startup Ideas』で、「最良のスタートアップアイデアは、創業者自身が欲しがっていて、自分で作れて、他人が価値に気づいていないもの」の3条件が揃ったところにあると書いた(出典: paulgraham.com/startupideas.html)。発散すると、この3条件の交差点に偶然たどり着ける確率が上がる。

どうやるか(発散4軸 + 収束3軸)

#### 発散: 4つの軸で案を広げる

同じ課題に対して、以下4軸で別々の解決案を出す。最低4案出ることが保証される。

  • 既存サービスの組み合わせ: 既にある複数のSaaS/サービスを組み合わせるだけで解決できないか。自分は「組み合わせ屋」になる。
  • AI/自動化での代替: 人がやっている作業をAIに置き換える。Claude/GPT/エージェントで何が代行できるか。
  • 完全新規プロダクト: 既存にない仕組み・UIをゼロから作る。スコープは大きいが差別化は最大。
  • コンテンツ/コミュニティ: モノを作らず、情報・人脈・経験を提供する。コンサル・コミュニティ・有料note・講座など。

軸X(個人ブランド)と軸Y(プロダクト)で、それぞれ4案ずつ出すと8案になる。最初は質より量。

#### 収束: 3つの軸で1つに絞る

8案を以下3軸で5点満点評価する。

| 評価軸 | 内容 | |------|------| | 課題適合度 | Step 3で定義した「痛み×頻度×支払い意欲」にどれくらい応えるか | | 自分の強み交差 | 自分のスキル・人脈・過去の経験を最大限に使えるか | | 4週間で検証可能か | 4週間以内にMVP/プロト/ヒアリング起点で「Go / No Go」が言える状態にできるか |

合計点が高い順に3つに絞り、最高点を主仮説、2位を待機仮説にする。3位以下は「休眠仮説」として記録だけ残し、当面はやらない。

Paul Grahamの "Schlep Blindness" を意識する

Paul Grahamは『Schlep Blindness』で、「面倒な作業(schlep)を要する課題は、みんなが避けて通るから、そこに大きな機会が残っている」と指摘した(出典: paulgraham.com/schlep.html)。ハッカーは特に「コードだけ書いて、人と話さず、面倒な交渉をせず、雑用をしないで済むスタートアップ」を夢想する。だが、ほとんどのビジネスは雑用の塊で、その雑用を引き受ける覚悟が、競合との差になる。

解決案を選ぶときに「面倒くさいから誰もやってない」を、減点要因ではなく加点要因として扱う。

よくある失敗パターン

  • 1案目に惚れ込んで他の角度を検討しない
  • 自分の好きな技術スタックから逆算してしまう(技術ドリブン)
  • 「面倒な作業」が含まれる案を、最初から候補から外してしまう
  • 8案出した後の収束で、評価軸を曖昧にして「直感」で選ぶ

今日できる1アクション

紙またはMarkdownを4分割し、上記4軸で各2案ずつ、計8案を書き出す。各案は1文(誰に・何を・どうやって提供する)で書く。終わったら、3軸の評価表を作って点数をつけ、主仮説と待機仮説を決める。所要60分。

5. 仮説の評価基準 — 数字 / 実現可能性 / 自分の強み

概念

仮説を1つに絞った後、それが実際に追いかける価値があるかを3つの基準で点検する。ここを雑にやると、4週間後に「やっぱりこの仮説は無理だった」と気付いて手戻りする。最低限の数字・実現性・強みの整合は、検証に入る前に確認しておく。

なぜ重要か

ソロプレナーの最大の制約は 時間 と 集中力。間違った仮説を4週間追いかけると、その4週間は他の仮説に使えない。年間12サイクル回せる前提で見れば、1サイクル外すと損失は「1/12=8.3%の年商」になる(Pieter Levels型の打席数モデルで考えるとそう見える / 出典: levels.io)。

評価3軸の具体

#### 軸1: 数字が成り立つか(LTV / CAC / 損益分岐)

最低限、以下の3つを概算で書く。精度より「桁が合っているか」を見る。

  • LTV(Lifetime Value): 顧客1人が生涯で払う金額の見積もり。例: 月額5,000円 × 平均継続12ヶ月 = 60,000円。
  • CAC(Customer Acquisition Cost): 顧客1人を獲得するのにかかるコスト。広告・営業時間・コンテンツ制作のいずれか。例: 1人獲得に20時間 × 時給換算3,000円 = 60,000円。
  • 目標売上を達成する顧客数: 月50万円目標なら、月額5,000円商品で 100人。獲得スピードと相性を見る。

LTV < CACになっていたら、原則ボツ。同等以下でも黄信号。LTVがCACの3倍以上が、ソロでも回せる目安(SaaS業界では LTV/CAC=3 が標準とされる)。

#### 軸2: 実現可能性(4週間で検証できるか)

「4週間で、買う/買わないがわかる状態」まで持っていけるか。具体的には、

  • ヒアリング3〜5人が実施可能か(知人経由でリーチできるか)
  • MVPまたはランディングページが、ノーコード or 1〜2週間の開発で作れるか
  • 決済導線(Stripe / Polar / 銀行振込)が用意できるか
  • 法務面の致命的リスクがないか(出会い系規制・特商法・資金決済法など)

1つでも「No」があれば、その仮説は今月の主仮説には向かない。待機仮説に降ろす。

#### 軸3: 自分の強み交差(unfair advantage)

これが他人ではなく自分がやる理由になっているか。Paul Grahamの3条件「自分が欲しい / 自分で作れる / 他人が価値に気づいていない」と照合する(出典: paulgraham.com/startupideas.html)。

  • 自分がその課題を、過去または現在抱えていたか
  • 自分のスキル(エンジニアリング・AI・運用)が、その解決策に直接効くか
  • 自分の人脈・経歴・物理的な居場所(関西・実家)が、他人より有利に働く点はあるか

1つも当てはまらなければ、それは他人の方が速くて安く作れる可能性が高い。

よくある失敗パターン

  • LTV/CACを「だいたい儲かりそう」で済ませて数字を書かない
  • 「やればできる」と過大評価して4週間検証スコープを引き受ける
  • 強みの交差を考えず、流行のテーマ(AIエージェント・ノーコードSaaS等)に飛ぶ
  • 競合がいないことを「機会」と捉える(実は需要がないだけ、というケースもある)

今日できる1アクション

Step 4で選んだ主仮説について、以下を埋める(所要30分)。

` LTV(概算): 月額 [円] × 継続 [ヶ月] = [円] CAC(概算): 1人獲得に [時間] × 時給換算 [円] = [円] LTV/CAC比: [ 倍] 目標月商 50万円達成に必要な顧客数: [ 人]

4週間で検証可能か(Yes/No理由付き):

  • ヒアリング3〜5人実施可能? [ ]
  • MVP/LP制作可能? [ ]
  • 決済導線準備可能? [ ]
  • 法務リスクなし? [ ]

自分の強み交差:

  • 自分が過去/現在に抱えた課題か? [ ]
  • 自分のスキルが直接効くか? [ ]
  • 自分の人脈/居場所が有利か? [ ]

`

このシートが埋まらないなら、Step 4に戻って別の仮説に切り替える。

6. 仮説の書き方フォーマット(1枚仮説シート)

概念

Step 2〜5の出力をまとめて、A4 1枚で書ける形にする。これが「1枚仮説シート」。Step 2(誰)・Step 3(何)・Step 4(どう)・Step 5(評価)の中身を、決まった枠に流し込む。1枚に収めることで、自分も読み返せるし、他人(ジョブズ・ヒアリング先・将来のクライアント)にも見せられる。

なぜ重要か

書き出していない仮説は、頭の中で勝手に変化する。書き出しておくと、4週間後に「自分が何を検証したかったのか」を確実に戻って確認できる。Steve Blankの Customer Discovery フェーズの本質は、「事業仮説を書き出し、外に出て検証し、データで修正する」という反復のサイクル(出典: steveblank.com / Customer Development)。書き出さない仮説は、修正できない。

1枚仮説シートのフォーマット

以下のテンプレートをそのまま使う。所要約60〜90分で1枚埋められる。

`

仮説シート vYYYY-MM-DD-NN

1. ターゲット(誰)

  • ラベル(1文): _____________________________________________
  • 年齢/職業/家族構成: _______________________________________
  • 直近30日の困りごと(5個): _______________________________
  • 毎月の支出パターン(主要3カテゴリ): ____________________

2. 課題(何)

  • 片付けたいジョブ(JTBD 1文): __________________________

「[誰] が [状況] のときに、[ジョブ] を片付けたい」

  • 痛みの強さ(強/中/弱): _____ 理由: _______________________
  • 頻度(強/中/弱): _____ 理由: _______________________
  • 支払い意欲(強/中/弱): _____ 理由: _____________________
  • 現在の代替手段: ___________________________________________
  • Painkiller / Vitamin の分類: _____________________________

3. 解決策(どう)

  • 解決案(1文): _____________________________________________
  • 4軸のどれか: 組み合わせ / AI自動化 / 完全新規 / コンテンツ
  • 競合3社と差別化ポイント: __________________________________
  • Schlep要素(誰もやりたがらない作業): _____________________

4. 評価

  • LTV: 月額/単発 [ ]円 × 継続 [ ] = [ ]円
  • CAC: [ ]時間 × 時給 [ ]円 = [ ]円
  • LTV/CAC比: [ ]倍
  • 月商50万円達成に必要な顧客数: [ ]人
  • 4週間検証可能か: Yes / No(理由: ________)
  • 自分の強み交差(3項目チェック): [ ][ ][ ]

5. 検証アクション(Step 2へ)

  • ヒアリング対象 3〜5人(実名・連絡経路):
  • ________________________________________________________
  • ________________________________________________________
  • ________________________________________________________
  • 競合10〜20社調査(リスト): ________________________________
  • 検証期限(4週間後の日付): __________________________________
  • Go/No Go判定基準(数値で1文): ____________________________

6. 仮説のリスク

  • 仮説が外れる最大要因は何か(1文): _________________________
  • その兆候が出たら、どう待機仮説に切り替えるか: _____________

`

仮説シート運用のコツ

  • 書き終わったらバージョン番号をつける: 仮説シート v2026-05-12-01 のように日付+連番。仮説が更新されたら新バージョンを作り、古いものは消さず履歴に残す。
  • 1枚に収める: 2枚目に逃げない。1枚に収まらないなら、まだ仮説が分解できていない。
  • 他人に見せる: ジョブズ・将来のリョウ(x-strategist)・ヒアリング相手の1人、に見せて「何を検証する仮説か10秒で理解できるか」を点検する。

よくある失敗パターン

  • 仮説シートを書いて満足し、Step 2の検証に進まない
  • 仮説シートを書き直さない(検証で得た情報を仮説に反映しない)
  • 「リスク」欄を空白にして、外れたときの待機策を考えない

今日できる1アクション

上のテンプレートをコピーして、自分の主仮説で1枚埋める。所要90分。書き終わったら、ファイル名に日付を入れて保存し、次のステップ(Step 2: 需要を確かめる)の入力ファイルとして使う。

7. 軸X・軸Yそれぞれへの適用

概念

2軸AI駆動戦略では、軸X(個人ブランド・コンサル/受託)と軸Y(プロダクト・グレーSNS)を並走させる。同じ「1枚仮説シート」のフォーマットを使うが、埋める中身が大きく異なる。混ぜないことが大事。

軸X / 軸Y の比較

| 観点 | 軸X(個人ブランド) | 軸Y(プロダクト) | |------|---------------|--------------| | ターゲット | コンサル/受託の発注企業の担当者 | エンドユーザー(個人) | | 課題タイプ | 業務効率化・AI実装の伴走・社内ナレッジ整備 | 既存サービスの未充足ニーズ・体験の改善 | | 代表的なJTBD | 「社内にAI実装の伴走者がほしい」「内製化したいが手順がわからない」 | 「既存サービスは○○が不便でずっと我慢している」 | | Painkiller / Vitamin | Painkiller寄りに設計する(時給コンサル / 緊急の困りごと) | Painkillerでないと売れにくい(個人課金の閾値が高い) | | 検証手段 | 既存人脈ヒアリング・商工会議所・補助金関連の接点 | 競合10〜20社分析・元ユーザーへのヒアリング | | LTV/CACの目安 | LTV高(数十万〜百万)/ CAC高(営業時間がかかる) | LTV低(月数千円)/ CAC低(プロダクト主導) | | 検証期限 | 4週間で1社の有料提案まで | 4週間でLP+課金導線+10ユーザー検証まで | | 強み交差 | エンジニア出身×AI実装経験×個人事業主目線 | 既存業界の経験/不満×ソロ運用のスピード | | 失敗の兆候 | ヒアリング3社でも温度が上がらない | LP訪問100→課金転換0% |

軸Xの仮説の書き方(例)

` ターゲット: 関西の中小企業(従業員10〜50人)で、AI導入を検討しているが 社内に伴走者がいなくて止まっている経営者 ジョブ: 「半年以内に、自社の業務にAIを1つ実装して、回し続けられる状態にしたい」 痛み: 強(競合に取られる/効率化できない焦り) 頻度: 強(毎月の業務で発生) 支払い意欲: 強(月10〜30万のコンサル予算は確保可能) 解決策: 月2回×3ヶ月の伴走コンサル + Claude Code環境構築 + 1業務の自動化納品 LTV: 30万×3ヶ月 = 90万 / 紹介で2社目 = 累計180万 CAC: 商工会議所/紹介経由で1社あたり20時間 強み交差: AI実装×個人事業主視点×関西の地縁 `

軸Yの仮説の書き方(例 / グレー領域への配慮)

軸Yはグレー領域(出会い・コミュニティ運営)を扱うため、外向きの発信ではジャンル名を伏せた抽象表現を使う。ただし、自分の仮説シートでは具体的に書く。

` ターゲット: [既存業界のサービスに不満を持つユーザー層] ジョブ: 「[現在の主要サービス] が [具体的な不満] を解消できないので、 別の選択肢を試したい」 痛み: 中〜強(直近で離脱経験あり) 頻度: 中(月1〜2回の利用シーン) 支払い意欲: 中(既存に月額数百〜数千円払っている) 解決策: [課題の核心に絞ったMVP]

  • 既存サービスから外した不要機能
  • 既存サービスにない[差別化機能]を1つ

LTV: 月額500円 × 継続6ヶ月 = 3,000円 CAC: 1人獲得30分(SNS集客 + 既存業界ユーザーリスト) 法務リスク: 出会い系規制法 / 特商法 / 資金決済法 / 児童保護(Step 4で別途調査) 強み交差: 既存業界経験 + AI運用 + ソロでの法務対応スピード `

両軸の依存関係

  • 軸Xの発信(X / Zenn)が軸Yの集客にも一部寄与する: 「AIで1人で会社を回す」発信は、軸Yの差別化(「個人が作るから速い・透明」)に繋がる。
  • 軸Yの収益が軸Xを支える: 軸Yがサブスク収益を持てば、軸Xでは無理に高単価案件を取らなくてよくなり、相手を選べる。

よくある失敗パターン

  • 軸Xと軸Yの仮説シートを1枚に混ぜて書く(ターゲットも課題も別なのに混在する)
  • 軸Xを諦めて軸Yに全振りする(またはその逆)。両軸は補完関係にあるので、片方ずつしか動かさないと全体最適にならない
  • 軸Yの法務リスクを「後で調べる」とラベルだけ貼って、4週間が過ぎる

今日できる1アクション

Step 6で書いた1枚仮説シートを、軸X用と軸Y用の2枚に分割する。両方を埋められないなら、今月は片方に絞ると決める。決めたら、もう片方は「休眠仮説」として日付付きで保存し、来月以降の候補に回す。

8. 演習 — 今の自分の仮説を1枚に落とす

演習の目的

ここまでの内容を読んで「わかった気になる」のと、実際に1枚仮説シートを埋めるのは別物。この演習を完遂しない限り、Step 1は完了しない。

演習スコープ

  • 所要時間: 連続2〜3時間(分割不可。中断すると思考の連続性が切れる)
  • 出力物: 1枚仮説シート(軸X版 1枚、もしくは軸Y版 1枚)
  • 期限: 演習開始から24時間以内
  • 検証: 完成後、ジョブズに見せて10秒以内に主旨が伝わるかチェック

演習の進め方(2〜3時間ブロック)

#### Block 1: ターゲット定義(30分)

  • 想定顧客1人プロファイル(Step 2の5ステップ)を埋める
  • 実在の知人を3人リストアップする(後でヒアリング先候補)

#### Block 2: 課題定義(30分)

  • JTBDテンプレートを1文で書く(「[誰] が [状況] のときに、[ジョブ] を片付けたい」)
  • 痛み・頻度・支払い意欲を 強/中/弱 で評価
  • Painkiller / Vitamin を判定

#### Block 3: 解決策の発散と収束(60分)

  • 4軸(組み合わせ/AI自動化/完全新規/コンテンツ)で各2案、計8案を出す
  • 3軸(課題適合度/強み交差/4週間検証可能性)で5点満点評価
  • 主仮説と待機仮説を決める

#### Block 4: 評価と数字埋め(30分)

  • LTV/CAC を概算
  • 月商50万円達成に必要な顧客数を計算
  • 強み交差の3項目をチェック

#### Block 5: 1枚仮説シートに統合(30分)

  • Section 6のテンプレートに全項目を流し込む
  • リスク欄(仮説が外れる最大要因)を必ず埋める
  • 検証アクション(ヒアリング対象3〜5人の実名)を書く

演習チェックリスト(これが全て埋まったらStep 1完了)

  • [ ] ターゲット1人プロファイルが書けている
  • [ ] JTBDが1文で書けている
  • [ ] Painkiller / Vitamin の判定がついている
  • [ ] 解決案を最低4案出した(できれば8案)
  • [ ] 主仮説と待機仮説が決まっている
  • [ ] LTV / CAC / 必要顧客数の数字が入っている
  • [ ] LTV/CAC比 が 1倍以上(できれば3倍以上)
  • [ ] 4週間で検証可能なスコープに収まっている
  • [ ] 自分の強み交差が3項目中2項目以上ある
  • [ ] ヒアリング対象3〜5人の実名がリストアップされている
  • [ ] 検証期限の日付が決まっている
  • [ ] Go/No Go判定基準が数値で書かれている
  • [ ] 仮説が外れる最大リスクと待機策が言語化されている

完了後のアクション

  • ファイル名: projects/00X-xxx/hypothesis-vYYYY-MM-DD-NN.md 形式で保存
  • ジョブズに「1枚仮説シート v○○ を書いた」と報告
  • Step 2(需要を確かめる)に進む。仮説シートをStep 2の入力ファイルにする

演習を完走できなかった場合

  • 2時間ブロックを確保できなかった → 今週中に再スケジュール
  • 8案出ない → ターゲット定義が抽象すぎる → Block 1に戻る
  • 数字が埋められない → 競合の価格帯を15分検索してから戻る
  • ヒアリング対象が3人見つからない → ターゲットが現実離れしている → Block 1に戻る

詰まった場合のリカバリ手順を、最初から手元に持っておく。詰まること自体は失敗ではない。詰まった地点を記録せずに諦めることが失敗。

参考資料

本章で引用した一次情報。すべて2024〜2026年時点でアクセス可能なオンラインソース。書籍は出版元の公式ページ・著者本人サイトを優先した。

  • [Steve Blank — Customer Development (公式タグページ)](https://steveblank.com/tag/customer-development/) — Customer Discovery / Validation の原典。Lean Startup運動の出発点
  • [Steve Blank — The Four Steps to the Epiphany (PDF: Stanford)](https://web.stanford.edu/group/e145/cgi-bin/winter/drupal/upload/handouts/Four_Steps.pdf) — 四段階モデルの教科書PDF(Stanford公開教材)
  • [Eric Ries — The Lean Startup: Principles](https://theleanstartup.com/principles) — Build-Measure-Learn / Validated Learning の公式定義
  • [Clayton Christensen — Jobs to Be Done (Christensen Institute)](https://www.christenseninstitute.org/theory/jobs-to-be-done/) — JTBD理論の本家解説。ミルクシェイクのケース含む
  • [Anthony Ulwick — Jobs-to-be-Done Framework](https://anthonyulwick.com/jobs-to-be-done/) — 25年のJTBD実践から派生したODI(Outcome-Driven Innovation)の解説
  • [Rob Fitzpatrick — The Mom Test (公式サイト)](https://www.momtestbook.com/) — ヒアリング3原則(相手の生活を聞け / 過去の具体行動を聞け / 自分のアイデアを売り込むな)
  • [Paul Graham — How to Get Startup Ideas](https://www.paulgraham.com/startupideas.html) — 「自分が欲しい / 自分で作れる / 他人が気づいていない」の3条件
  • [Paul Graham — Schlep Blindness](https://paulgraham.com/schlep.html) — 「面倒な作業」が機会になる視点
  • [Nielsen Norman Group — 3 Persona Types](https://www.nngroup.com/articles/persona-types/) — Lightweight / Qualitative / Statistical ペルソナの作り分け。proto-persona を許容
  • [Nielsen Norman Group — Personas vs. Jobs-to-Be-Done](https://www.nngroup.com/articles/personas-jobs-be-done/) — ペルソナとJTBDの併用方針
  • [Pieter Levels — Indie Hackers Podcast (#043 / 公式書き起こし)](https://levels.io/indie-hackers-2/) — 「顧客が現れるまで作らない」「12 startups in 12 months」のソロプレナー手法
  • [Vitamin vs Painkiller — startup framing (Idea to Value)](https://www.ideatovalue.com/insp/nickskillicorn/2024/09/are-you-selling-vitamins-or-painkillers/) — 必須品/嗜好品の二分とその応用
  • [HBS Online — Jobs to Be Done: Real-World Examples](https://online.hbs.edu/blog/post/jobs-to-be-done-examples) — McDonald's ミルクシェイクほか実例集(Harvard Business School)

章末注

書籍版を持っている場合は紙の原典を読むのを推奨する。特に以下は売上ロードマップ全体に効く。

  • Rob Fitzpatrick『The Mom Test』(2013年初版 / 短く、強い)
  • Eric Ries『The Lean Startup』(2011年 / 古いが核は不変)
  • Clayton Christensen『Competing Against Luck』(2016年 / JTBDの本家による1冊)
  • Steve Blank & Bob Dorf『The Startup Owner's Manual』(2012年 / 検証チェックリストが圧倒的に詳しい)

5年以上前の書籍だが、原則部分は2026年現在でもほぼそのまま有効。ただし、各書籍が前提とするマーケティングチャネル(SEO / SNS / 広告プラットフォーム)の挙動は当時と異なるため、章末の「実行手段」部分は最新情報で補完すること。

学習目標

  • 「誰の・何の・どう」を1文で書ける
  • 仮説の良し悪しを3つの基準(数字 / 実現可能性 / 強み交差)で判定できる
  • 軸X(個人ブランド)・軸Y(プロダクト)の仮説を別々に立てられる
  • Painkiller / Vitamin の判定がその場でできる
  • JTBDフレームで顧客が「何を片付けたいか」を1文で書ける

成功基準

  • 自分の2軸それぞれに1枚仮説シートが書き上がる(または1軸に絞る判断ができている)
  • 「この仮説は弱い/強い」をその場で判定できる
  • Step 2(需要を確かめる)に渡せる検証アクション(ヒアリング対象3〜5人の実名)が決まっている
  • 4週間後のGo/No Go判定基準が、数値で1文書けている

次のステップ

Step 1完了 → [Step 2: 需要を確かめる](./02-demand-validation.md)

Step 2では、書いた1枚仮説シートを使って、3〜5人のヒアリング・10〜20社の競合分析・Go/No Go判定までを4週間で回す。