この記事の内容
仮説検証のフレームワークは数が多く、どれから手を付けるかで迷いがちです。ただ、役割で並べてみると、実際に要るのは多くありません。事業まるごとを1枚に置く枠、ひとつの仮説を割る枠、回す単位を決める枠。この3つで、たいていの場面は足ります。フレームワークは考えるための道具ではなく、頭の中にあるものを書き出して、抜けを見つけるための枠です。 この記事では、リーンキャンバス、課題仮説と解決仮説の分解、リーンスタートアップのループを、いつ・どの順で使うか、どの枠に何を書くかで整理します。手順そのものは別の記事に譲り、ここは枠の話に絞ります。
この記事について
書いているのは、作る側です。ハコブネを運営する株式会社Walkersは、受託と自社事業で累計300件の開発に関わり、200社以上の事業づくりを支援してきました。監修は取締役の池田龍一です。
一般論ではなく、実際にやったことの中身で説明します。この記事に出てくる数字は、すべて公開済みの自社・支援先の事例から引いています。出典は記事の最後にまとめました。
フレームワークは「書く枠」として使う
フレームワークを開くと、考えが整理されるような感覚があります。実際に起きているのは、頭の中にある前提を紙の上に出して、並べて、抜けを見つけることです。この順に効いてくるので、枠が埋まったことと、仮説が正しいことのあいだには関係がありません。
枠の価値は、埋まったマスではなく、埋まらなかったマスのほうにあります。書けない枠があるということは、そこが確かめられていない場所だということです。そこから当てに行けば、検証の順番は自動的に決まります。
もうひとつ、枠は人と共有するときに効きます。同じ枠を見ながら話すと、どこの話をしているのかが揃います。ハコブネの新規事業立ち上げゼミも、現状整理から立ち上げる対象を1つに決め、コンセプト、顧客、MVPを作って動かす、改善、リリース、集客設計という順番で進みます。枠は、この「いま何の話をしているか」を固定する役割を持ちます。
使う順番は、粗い枠から細かい枠へ
3つの枠は並列ではなく、粗さが違います。使う順番も、粗いほうからです。粗い枠から順に使うと、細かい枠に何を書けばいいかが自動的に決まります。
- リーンキャンバス（粗い）：事業まるごとを1枚に置く。どこが空いているかを見る
- 課題仮説と解決仮説（中くらい）：空いていた1か所を、確かめられる単位に割る
- リーンスタートアップのループ（細かい）：割った1つを、何回で回すかを決める
逆から入ると、手戻りが増えます。ループから始めると、何を回しているのかが決まらないまま作りはじめることになりますし、解決仮説から始めると、誰のどんな困りごとに対する解決なのかが後から出てきます。
3つとも毎回使うわけではありません。2周目以降は、多くの場合いちばん細かいループだけを回します。リーンキャンバスに戻るのは、当てた結果が大きく外れて、前提から見直すときです。
リーンキャンバス：事業まるごとを1枚に置く
リーンキャンバスは、事業の前提を1枚に並べる枠です。課題、顧客セグメント、独自の価値提案、解決策、チャネル、収益の流れ、コスト構造、主要指標、圧倒的な優位性といった項目が並びます。
書くときのコツは、埋めることを目的にしないことです。全部のマスに何か書くのは30分でできますが、それは前提を並べただけで、確かめたことにはなりません。埋まらない枠こそ、いま確かめに行くべき場所です。
書く順番も、左上から順にではありません。先に書くのは、課題と顧客セグメントの2つです。この2つが決まっていないと、他のマスは全部「誰に対しての話か分からない前提」になります。次に、その課題に対する解決策と、どう届けるかのチャネル。お金まわりの2つは、前の4つが定まってからで間に合います。
1枚に置く効き目は、方向そのものを見直すときに出ます。個人が運営するサービスの有料版として作られたサカチムプラスは、当初、検索サイトとしての機能を強化する方向が想定されていました。ところが対話を重ねるなかで、価値があるのは検索ではなく「チーム専用ホームページの質」のほうだという結論になり、方向が変わっています。結果として配色は100種類が実装され、既存のサカチムには164チームが登録しています。価値提案の枠を書き直す、という種類の変更です。
課題仮説と解決仮説：ひとつの塊を2つに割る
ここがいちばん効く枠です。「このサービスは売れるか」という塊は、そのままでは確かめられません。次の2つに割ると、確かめられる形になります。
- 課題仮説：誰が、どんなときに、何に困っているか。困りごとが実在するか
- 解決仮説：その困りごとは、この方法で解けるか。解けたときに人は使い続けるか
順番は課題が先です。課題仮説が外れているのに解決仮説を作り直すのは、いちばん時間を溶かす直し方です。 使ってもらえない理由が「作りが悪いから」ではなく「そもそも困っていないから」だった場合、作り直しは何周やっても届きません。
割ったあとは、書く内容も変わります。課題仮説で書くのは、過去に起きた具体的な場面です。前回いつ困ったか、そのとき何をして解決したか、いくら払ったか。未来の意思ではなく、過去の行動を書きます。解決仮説で書くのは、こちらが提供する形と、当たりと判断する数字です。
一文の粒度を揃えるのに使えるのが、Who・When・What・Where・How・Whyの6つです。株式会社Walkers代表の渡邊敦司は、公開しているポストで、この6つを埋めると新規事業のコンセプトになると書いています。課題仮説に要るのは、このうちWho・When・Whatの三つです。残りの三つは、解決仮説の側で埋まっていきます。
リーンスタートアップのループ：回す単位を決める
リーンスタートアップのループは、構築・計測・学習の3つを繰り返す枠です。名前のとおり構築から並んでいますが、ループは構築から考えると回りません。計測から逆に設計します。
設計の順番は、こうなります。まず、何を測れば判定できるのかを決める（計測）。次に、それを測るには最低限どこまであればいいのかを決める（構築）。最後に、どの結果が出たら何を次に変えるのかを決めておく（学習）。この順で設計してから、構築・計測・学習の順に実行します。
この逆算をやると、作るものは小さくなります。2026年8月23日のハッカソンで運営が作った記録アプリのBENLOGは、確かめる仮説を「うんちを育てるためなら、人は毎日トイレを記録するのか」の一点に絞り、合格ラインを7日後の継続率40%、30日後20%、1日平均3.5件と置いていました。これは検証の前に置いた目標値で、実測の数字ではありません。記録アプリには通知も共有もグラフも付けられますが、この3つの数字を測るだけなら、そのどれも要らないということになります。
ループの結果は、作るかどうかの判断だけでなく、作る順番の判断にも使えます。UPSTA JapanのApoLinkは、日程調整と決済が一体になったビジネスマッチングのサービスです。テストマーケでマッチング機能への反応が良いことが分かったため、開発の途中で作る順番を組み替え、それでも予定どおりリリースしています。開発は2ヶ月半、リリースから1ヶ月半で会員は200人弱です。全部を作り終えてから反応を見ていたら、この組み替えはできませんでした。
枠を使っているのに進まないときの3つ
枠を埋める時間のほうが長い。 いちばん多い型です。枠を書き直す時間が、外に出て確かめる時間を上回ったら、そのフレームワークは止まっています。 判断の目安は単純で、今週その枠を根拠に誰かに当てたかどうかです。
枠に合わせて事業を歪めている。 マスが空いていると落ち着かないので、埋まる話を書いてしまう状態です。優位性の枠に、実際には持っていない強みを書く。収益の枠に、確かめていない価格を書く。空欄のまま「未検証」と書いておくほうが、次に何をするかがはっきりします。
粒度が混ざっている。 事業まるごとの話と、画面ひとつの話を、同じ枠の中で並べてしまう状態です。粗さの違う話が同じ枠に入ると、議論が噛み合わなくなります。いま3つのうちどの枠の話をしているのかを、先に口に出してから始めると混ざりにくくなります。
よくある質問5選
質問1フレームワークは、どれか1つに絞ったほうがいいですか？
役割が違うので、3つを使い分けるほうが実務的です。ただ、毎回3つとも開く必要はありません。1周目は事業まるごとを置く枠から入り、2周目以降は回す単位の枠だけを使う、という形が現実的です。前提から見直すときだけ、粗い枠に戻ります。
質問2リーンキャンバスは、埋まらないマスがあってもいいのですか？
空欄があるほうが普通です。空欄は、そこが確かめられていないという印なので、次にどこへ当てに行くかの手がかりになります。むしろ全部埋まっている1枚のほうが、確かめていない前提を書いただけになっていないか見直したほうがいいです。
質問3課題仮説と解決仮説は、どちらから確かめますか？
課題からです。困りごとが実在しないところで解決策を磨いても、使われない理由は変わりません。課題が確かめられてから解決仮説に進むと、外れたときに「作りが悪かったのか、そもそも要らなかったのか」で迷わずに済みます。
質問4社内の新規事業でも同じ枠が使えますか？
使えます。社内の場合は、枠の役割がもう一つ増えて、関係者のあいだで「いま何の話をしているか」を揃える道具になります。粒度が混ざった議論が長引きやすいので、どの枠の話かを先に決めてから始めると進みやすくなります。
質問5枠を書いたあと、実際に回す手順はどうすればいいですか？
この記事は枠の話に絞っているので、1周を何日で回すか、各ステップの完了条件、記録の残し方は別の記事にまとめています。仮説検証のやり方の記事を続けて読んでください。枠で書き出した一文と合格ラインを、そのまま1周目に持ち込めます。
この記事について
池田は、ITとノーコードの事業開発・教育事業の立ち上げを経て2021年にWalkersを共同創業。100件以上のシステム開発に携わり、要件がまだ固まっていない案件や、他社から引き継いだ開発の立て直しを担当しています。
株式会社Walkersは、AI駆動開発・ノーコード開発のシステム開発会社です。累計開発実績300件、200社以上の支援、自社メディアの累計100万PV。受託開発と並行して、自社でも複数の新規事業を立ち上げています。
この記事で触れた事例の出典
最終更新：2026年9月16日