「やってみなきゃわからない」を口実にする人が、いちばん遅い
新規事業は不確実性が高く「やってみなければわからない」のは確かです。だから試してみることは重要です。
しかし、「やってみなければわからない」とは、「考えずに動け」ではなく、
「最小の実験で、最大の学びを回収すること」と考えるべきです。
急ぐあまり、とりあえずプロダクトを作り始めたり、とりあえず体制を作ったが、思ったように事業が立ち上がらず、一方で撤退やピポッドの判断が遅れて資金を溶かす、という事例はスタートアップでは非常によくある話です。
素早く試すことと検討することについて、どうバランスをとるべきなのでしょうか。今回はこの問題について自分自身の事業経験・失敗経験も踏まえて考察していきたいと思います。
最後に1分で実験設計が固まるチェックリストも付けましたので、ぜひ最後までお読みください。
この記事は「paiza Advent Calendar 2025」の最終日の記事です。このブログが良いなと思ったら、noteやXをフォローしてくれると嬉しいです。
■はじめに
12月17日に、高輪ゲートウェイで開催されていたMUFGスタートアップサミットに行ってきました。
「成功を引き寄せるイノベーション ～"日本流"ベンチャークライアントモデルの挑戦～」というセッションで登壇者が、「新規事業はやってみなければわからないので、多くの検証サイクルを回す必要があり、その仕組み化が重要」という話をしていました。
「やってみなければわからない」というと、計画だなんだと、うだうだ考えるより、まず行動しよう、という話になりがちです。
しかしこのセッションでは「やってみなければわからない」=「失敗する可能性も高い」ので、沢山試せるように計画してからチャレンジしようぜ、という視点で語られていて、なるほどなと思いました。
■「やってみなければわからない」の正しい意味
不確実性の正体は「未来が見えない」ではなく「仮説立ての情報不足」
重要なのは「作業量」ではなく「検証からえられた学び」
よって「やってみる」とは「実験し、学習をすること」を意味する
「やってみなければわからない」という言葉は色々な意味合いで使われることがあるため、最初にこの言葉が指している正しい意味合いについて考えてみたいと思います。
まず「やってみなければわからない」は「不確実性」の話をしていますが、なんとなく「未来がわからない不確実性」と考えがちですが
しかし不確実性の対象を「未来」においてしまうと、「考えても未来はわからないからやるしかない」ため、「下手な鉄砲も数打ちゃ当たる方式」の作業量重視のやや乱暴な行動になってしまいます。
これだと新規事業においては成功確率は一向に上がらず時間ばかり浪費してしまいます。
ここでいう【不確実性】は何かというと、「正しい仮説を立てるため情報が不足している」ということです。つまり不確実性の正体は「未来が見えない」ではなく「情報が足りていない」であり「仮説が未検証」ということです。
「やってみる」というのは方法論（How）であり、目的・ゴールではありません。本質的な問いは「どうしたら望む結果（売上・利益）に早くたどり着けるか？」です。
つまり最も重要な問いは「どう素早く正しい仮説にたどり着けるか？」「仮説の軌道修正をおこなうための学びを、どうしたら素早く得られるか？」です。
よって「やってみる」とは「実験により仮説を検証し、その結果から学習をすること」を意味します。
まとめると「やってみなければわからない」＝「仮説を正しく立てる情報が足りないので、素早く何回も実験して学習し、軌道修正し、仮説を確からしいものにしようぜ」ということになります。
■アンチパターン：遅い人の「4つの欠落」
「やってみなければわからない」から、とりあえず行動をしていしまうケースでは、「実験により仮説を検証、学習し、仮説の軌道修正を行う」観点から次の4点が欠落していると言えます。
検証仮説がない or シナリオになってない
検証ポイント/指標と合格要件がない
検証期限、いつ決めるかがない
意思決定者が手を動かさず学習してない
これらをまとめると「検証計画がない」とも言えます。この4つがないと、着手は早くても、その後の学びがはっきりしないため意思決定が遅くなり、結果として全体が遅くなります。
検証スピードが遅いと、それだけ時間とコストを浪費することになり、実験回数、学びの回数を増やせず、結果として正しい仮説にたどり着くまでに多くの時間がかかるため「遅く」なります。
「やってみなきゃわからない」を口実にして考えない人が、いちばん遅い理由がこれです。
書籍「リーン・スタートアップ」の文脈だと、進捗の単位は「作った量」ではなく、実験でえられた『検証による学び（validated learning）』という整理がされています。
また同書の中では単なる「学び」と「検証による学び」は区別して書かれています。単なる「学び」を下記のように痛烈に批判しています。
あいにく「学び」というのは遂行を失敗したときの言い訳としてもよく使われる。約束した成果が出せなかった時、管理職はその一言で言い逃れようとする。
つまり「やってみなければわからない、やれば学びが得られる」という発言が仮説・指標・期限を捨てる免罪符になっている場合、それは思考停止のサインであり、黄色信号なのです（…ものが言えなくなりそうですが自戒も込めて）。
新規事業において考えない行動は、最速に見えて最遅なのです。
※既に検証されている方法論を試す場合はこれに当たりません。その場合は一旦数をこなせば量が質に転換します。
まとめる、実験は「やってみなければわからない」ので、実験をするための検証仮説を立て、検証ポイント/指標の明確化、検証期間の設定をおこない、なるべく多くの実験をコンパクトに行いながら仮説を修正するのが重要、ということになります。
■数多く検証サイクルを回す仕組み化の要点
学習速度を上げるために重要な検証項目とその詳細は下記になります。
課題とゴールの明確化
新規事業で解決しようとしている課題はなにか？
最終的にどのようなビジネスモデル、出来上がりの形にしたいのか？成立要件の仮説
ビジネスが成立する要件の仮説はどのようなものか？
どのようなシナリオでビジネスが成功すると考えているのか？検証ポイント/指標と合格要件
ビジネスが成功するために「成立していなければならない重要な前提事項」はなにか？
その重要事項は何の指標で測れ、合格/不合格はどう判定できるか？検証期限といつ結論を出すか
いつまでに結論を出すか？
結論を出すのに最低限の期間はどの程度か？継続可否判断ライン
この条件なら撤退、この条件なら投資というラインがはっきりしているか？意思決定者が手を動かし学ぶ
人任せにしていて詳細を知らないとなると学びに繋がらないため、意思決定者が仮説を立て、手を動かして実験を行い、学びを得ているか？
よくある誤りは、指標が多すぎたり、検証がただのプロダクト開発になってしまうことです。検証ポイントを絞らないと何を実験しているのかがぼやけ、結果に対し複数の要因が絡んでしまうため学びが得られなくなります。
また、とりあえずやってみようといいつつ、人にやらせていて意思決定者が自ら動かないと何の学びも得られないため、仮説検証→修正のサイクルが回らず時間を浪費してしまいます。
ポイントは、小さく考え、小さく実験し、素早く学びを得て、すぐに仮説を修正する、ということです。すぐ動いても、考えすぎてもダメなのです。
ここからは、これまで自分が20以上の事業検討をおこない、実際に10サービスを展開した経験から、具体事例をベースに失敗/成功事例で解説を行います。
■具体例①失敗事例
事例：採用時の企業向けプログラミング・スキルチェックサービス
B2Cで展開していたプログラミング・スキルチェックサービスを、エンジニア採用時や社内のスキルアセスメントとして企業向けにB2B2Cサービスとして展開しようというもの。
ゴールと成立要件仮説
B2C向けのpaizaプログラミング・スキルチェックを企業内のスキル把握や、採用時に使いたいという企業の声があった。事業として成立する価格で売れるか？、そもそも本当にニーズがあるか？最小実験
実際に値付けをし、数社程度に商談をしてみて一定の率、数量で売れるかどうかを実験。
→この際は実際に売るために事前に簡単なプロダクトを作ってしまい、時間とコストをかけてしまったのがプロセスとしての失敗ポイント指標
事業が成り立つライン（もしくは将来改善する見込みがあるレベルのライン）での商談販売率になるか？検証期限
約1ヶ月で5社ほどと商談し、1件でも契約が取れるか？結果
軽くヒアリングすると欲しいと言われるが、実際にアセスメントを受ける開発現場に聞くと、エンジニアの稼働時間をテスト時間に割きたくないと嫌がられ、反対され、ほとんど売れなかった。学び
あったらいい、欲しいと言ってる人（人事部）と、実際に使う人（テストをさせる開発部）がずれており、それぞれニーズが異なった。ほしいと言っている人事部の課題感もそこまで切迫したものではなかった。
実験の際はプロダクトを作る必要はなく、◯月リリース予定などとし営業資料だけ作り販売する形のほうが検証速度が早く学びも早く得られた。
ここで重要なのは、企業向けのスキルチェックサービスのニーズがあるという仮説が間違っていたことではなく、仮説検証する前にプロダクト開発をしてしまったことです。
新規事業はやってみなければわからず、仮説の間違いはつきもののです。「仮説を間違ったのは誰のせい」などということは極めて馬鹿げています。重要なのはミニマムに素早く実験し数多く学ぶことです。
実験を素早く回す意味で、「やってみなければわからない」と、とりあえずプロダクトを先に作ってしまったのは思考停止しており、検証に時間とコストが掛かりすぎており、失敗でした。
■具体例②成功事例
事例：企業向けプログラミング学習サービス展開
個人向けプログラミング学習サービスのpaizaラーニングを企業で使いたいという話があったので、転職サービスなどと分離した形での企業向けに学習サービスを提供しようというもの。
失敗事例①を経験していたので、プロダクトを作らず商談し、売れてから作ることが出来たのが成功ポイントです。
ゴールと成立要件仮説
B2C向けで展開していたpaizaラーニングを、企業側で研修として使いたいという声があった。事業として成立する価格で売れるか？、そもそも本当にニーズが有るか？（①と極めて似ている内容です）最小実験
実際に値付けをし、数社程度に商談をしてみて一定の率、数量で売れるかどうかを実験。
→①の失敗を経験しているので実際に売れ、契約されるまでは開発に着手せず、営業資料と商談のみで実験を行った。指標
事業が成り立つライン（もしくは将来改善する見込みがあるレベルのライン）での商談販売率、販売数量になるか？検証期限
約2ヶ月で5社ほどと商談し、数十名以上の契約が取れるか？結果
最初に引き合いがあった企業に対し数百アカウント（数百万円）単位での販売契約が成立。半年後のローンチという話で商談していたため、契約成立後に急いで開発を行った。学び
B2Bはプロダクト開発は先に行わなくても良い。営業資料やプロトタイプでも販売は可能だし、半年後リリースのものでも販売はできる（設計を事前にある程度詰めておくことは必須）。
採用人事ではなく、研修側も所管する責任者と話をできたことや、B2Cで既に多くの研修コンテンツがあり、開発範囲が限定的だったことも大きかった。
paizaの立ち上げ時も2回ピポッドしており、検討したビジネスモデルは約10個あり、実際に検証したのは3つで、その最後に検証したビジネスモデルがpaizaでした。それでもpaizaにたどり着くまで1年ほどかかっています。
最初の実験は撤退まで半年程かかりましたが、2個目のものは検討と簡単な初期ヒアリング段階の2ヶ月ほどでの撤退、paizaを検証していたときは検討・ヒアリングに約1.5ヶ月、実験検証期間は2ヶ月と、だんだん検証プロセスも洗練されていきました。
それでも事業を始めたあとに①の失敗をしてしまっているので、今回の話は自戒も込めてまとめています。
■まとめ
スタートアップだから「とりあえず、やってみなければわからない」というので、深く考えずに感覚だけでやりはじめると爆死しがちです。
最小の実験で最大の学習が得られるように、ゴールを明確にし、検証仮説を立て、検証ポイント/指標、撤退ラインを明確にしたうえで期限を決め、ミニマムに意思決定者自らが実験する、これにつきます。
ポイントをまとめると下記です。
「行動量＝スピード」は幻想
スピードは「学習効率」で決まる
学習効率は「仮説・指標・期限」で上がる
最後に1分で確認できる検証前のチェックリストをまとめておきました。
ご活用ください。
■検証前のチェックリスト（保存版）
課題とゴールは明確になっているか？
ビジネスが成立する検証仮説はどのようなものか？
ビジネス成功の重要な検証ポイント/指標は何で、合否ラインは明確か？
ミニマムな検証期限になっているか？無駄な作り物はないか？
継続可否判断ラインは、ハッキリしているか？甘くないか？
実験は意思決定者が手を動かし、現場で学ぶ設計になっているか？
普段は生成AIの記事を書いてますが、「paiza Advent Calendar 2025」の記事なので、少し趣向を変えて久しぶりに新規事業ネタを書いてみました。
最後までお読みいただきありがとうございました。この記事が良いなと思ったら、ぜひnoteやXをフォローしてください。
ちなみに、paizaはITエンジニア向け国内最大の転職・就職・学習プラットフォームです。（paiza.jp）よかったら使ってみてください。
「スピード＝行動量ではなく、学習効率」というまとめに強く共感しました。 とりあえず作る・とりあえず体制を組む、が一番コストの高い選択になる、という点はまさに現場あるあるですね。 検証前チェックリストは、事業だけでなく個人の取り組みにも使えると思いました。保存版ですね。