リーンスタートアップとは？MVPと検証の進め方

ー この記事の要旨 ー

1. リーンスタートアップとは、最小限の試作品（MVP）で仮説を検証し、顧客の行動から学びながら事業を改善していく事業開発手法です。
2. 中核となる構築-計測-学習ループの進め方や、MVPを製品の縮小版ではなく仮説検証の道具として設計する考え方を整理します。
3. さらに、不確実性や検証コスト、意思決定速度などから自社への適用可否を判断する基準と、最初の一周を回す実務手順まで解説します。

リーンスタートアップは「作る前に確かめる」ための事業開発手法

リーンスタートアップとは、最小限の試作品（MVP）を先に市場へ出し、顧客の反応を計測して仮説を修正していく事業開発の手法です。本記事では、構築-計測-学習ループとMVPの進め方に加えて、この手法を自社で回せるかどうかを判断するための基準まで扱います。

新規事業やスタートアップの現場でこの言葉を耳にしたとき、多くの人が最初に受け取るのは「小さく早く作る」という印象です。

ただし、この理解のままで始めると、試作品を作ること自体が目的になり、何を確かめたのか誰も説明できない状態に陥ります。手法の核にあるのは開発速度ではなく、事業計画に含まれる思い込みを、最も安いコストで事実に置き換えていく設計思想です。

この手法が広まった背景には、新規事業の不確実性という問題があります。従来型の事業計画は、市場規模や顧客ニーズを事前に調査で固め、そこから逆算して製品を作り込みます。しかし前例のない事業では、調査の前提そのものが外れていることがあり、完成した頃に「誰も欲しがっていなかった」と判明します。

リーンスタートアップが目指すのは、製品を効率よく作ることではなく、作るべき製品が何かをできるだけ早く見つけることです。この前提の誤りを完成前に見つけるための組み立て方だと考えると、全体像が捉えやすくなります。

なお、事業の前提を整理する段階では、仮説そのものの筋の良し悪しが検証の効率を左右します。仮説の立て方については、関連記事『仮説思考とは？』で詳しく解説しています。

「リーン」という言葉が指しているもの

語源はトヨタ生産方式にある

リーン（lean）は「ぜい肉のない」「ムダのない」という意味の英語です。この語がビジネス用語として定着したのは、マサチューセッツ工科大学の研究チームがトヨタ生産方式を分析し、リーン生産方式として体系化したことに始まります。在庫を抱えない、必要な分だけ作る、問題は現場で即座に止めて直すという考え方が、その中核にありました。

この製造業の思想が新規事業へ橋渡しされる過程には、もう一段の系譜があります。スティーブ・ブランクは、スタートアップを「再現可能な事業モデルを探索する組織」と位置づけ、製品開発と並行して顧客側の仮説を検証していく顧客開発モデルを示しました。

エリック・リースは、この顧客開発の考え方とリーン生産方式のムダの排除を接続し、まだ製品も顧客も定まっていない新規事業の領域へ体系として持ち込みました。2011年に刊行された著書『リーン・スタートアップ』が、その体系をまとめたものです。リースは自身が関わったIMVUというサービスの立ち上げ経験を通じて、作り込んだ製品が使われないという失敗から、この考え方に至っています。

ムダとは「使われない機能」ではなく「学べなかった時間」

ここで誤解されやすいのが、ムダの定義です。製造業でのムダは在庫や工程の重複を指しますが、新規事業でのムダは少し違います。

リーンスタートアップにおけるムダとは、顧客について何も学べないまま費やされた時間と資金のことです。

たとえば半年かけて機能を10個実装したとして、そのうち顧客が価値を感じたのが1個だったなら、残り9個分の期間はムダだったことになります。同時に、その1個が当たりだと分かるまで半年かかったことも、それ自体がムダです。

この視点に立つと、「小さく作る」のは節約が目的ではなく、学ぶまでの時間を縮めるためだと分かります。

構築-計測-学習ループが手法の背骨になる

リーンスタートアップの実行単位は、構築-計測-学習ループと呼ばれる反復サイクルです。アイデアから試作品を構築し、市場での反応を計測し、得られたデータから学習して次の判断を下す。この一周を可能な限り速く、何度も回します。

3つのフェーズが担う役割

実行する順序は構築から始まりますが、設計する順序は逆になります。何を学びたいかを先に決め、そのために何を計測するかを決め、最後に何を構築するかを決めます。この逆算ができていないと、作ったあとで測るものを探すことになります。

構築フェーズでは、検証したい仮説に対応する最小限の形を作ります。ここで作るものは製品そのものである必要はなく、仮説を確かめられれば紙の資料でも手作業でも構いません。

計測フェーズでは、作ったものを実際の顧客に当て、行動を観測します。感想を聞くのではなく行動を見るという点が重要で、「良いと思う」という発言と「お金を払う」という行動の間には大きな隔たりがあります。「欲しい」と答えた人が申し込まない一方で、何も言わずに繰り返し使う人がいる、という形で差が出ます。

学習フェーズでは、計測結果を仮説の採否に翻訳します。仮説が支持されたなら次の仮説へ進み、否定されたなら方向転換を検討します。3つのうち最も抽象度が高く、最も飛ばされやすいのがこのフェーズです。

ループの回り方は「アイデア→製品→データ→アイデア」

3つのフェーズは、それぞれの出力が次の入力になる形でつながっています。

各フェーズが何を受け取り、何を渡すのかを整理すると、次のようになります。

学習の出力である「次の仮説」が、構築の入力へ戻ります。この戻りの一本が働いて初めて、サイクルとして閉じます。

どこか一つが欠けると循環が止まり、作りっぱなし・測りっぱなしの状態になります。とくに省略されやすいのが、学習から構築へ戻る部分です。

「学習」を成立させる条件

学習フェーズが機能するかどうかは、構築に入る前の準備で決まります。何を確かめるのかという仮説と、どの数値がどうなったら支持・棄却と見なすのかという基準を、事前に文章にしておく必要があります。

この事前合意がないと、出てきた数字を後から都合よく解釈する余地が生まれます。登録者が想定の半分だったとき、「立ち上がりだから」と続行することも、「需要がない」と撤退することも、どちらも言えてしまう状態です。

基準を先に決めておくことが、この解釈のブレを防ぎます。

MVPは製品の縮小版ではなく仮説検証の道具

MVP（Minimum Viable Product／実用最小限の製品）は、リーンスタートアップの中で最もよく知られ、最も誤解されている概念です。MVPの目的は、売ることではなく学ぶことにあります。この一点を外すと、以降の設計判断がすべてずれていきます。

「小さい製品」と考えると設計を間違える

MVPを「機能を削った廉価版」と捉えると、何を削るかの判断が「重要度の低い順」になります。しかし本来の判断軸は、確かめたい仮説に必要かどうかです。

仮説の検証に不要なら、たとえ重要な機能でも入れません。逆に、仮説の核心に関わる部分は、たとえ手間がかかっても手を抜けません。

この違いは実際の設計に直結します。「この価格で買う人がいるか」を確かめたいなら、必要なのは決済が通ることであって、製品が動くことではありません。実際に、申し込みボタンを押すと「準備中です」と表示される形の検証も、需要の観測手段として成立します。

代表的な3つの型

MVPには、確かめたい仮説の種類に応じて使い分けられる型があります。

いずれも共通しているのは、作り込みを後ろへ回している点です。裏側が人力であっても、顧客が受け取る体験が仮説どおりなら、検証としては十分に機能します。

どこまで削っていいかの線引き

MVPの設計で最も判断に迷うのが、削りすぎと削り足りないの境界です。

削ってはいけないのは、顧客が価値を感じる瞬間そのものです。料理宅配なら料理が届くこと、学習サービスなら学べたと感じることが、それに当たります。この部分を削ると、反応が悪かったときに「価値がなかった」のか「体験が壊れていた」のかを区別できず、検証が成立しません。

一方で削ってよいのは、繰り返し使うための機能、規模が大きくなってから必要になる仕組み、見た目の完成度です。管理画面、パスワード再設定、決済の自動化などは、初回の検証では人力や仮の対応で置き換えられます。

この線引きを対象ごとに整理すると、次のようになります。

判断に迷ったときは、「これを省いた状態で、顧客が価値を受け取れるか」を問いにすると整理しやすくなります。受け取れるなら削れる部分であり、受け取れないなら残す部分です。

なお、試作の速度そのものを高める工夫については、関連記事『ラピッドプロトタイピングとは？』にまとめています。

検証結果の読み方と方向転換の判断

計測してデータが出たあと、それをどう読むかで結論が変わります。ここが手法の実行上、最も属人的になりやすい箇所です。

見かけの数字と判断に使える数字

登録者数の累計、総ダウンロード数、SNSのフォロワー数といった指標は、時間が経てば必ず増えます。増え続けるため成長しているように見えますが、仮説の採否には使えません。リースはこの種の指標を虚栄の評価基準と呼び、判断に使える指標と区別しました。

判断に使えるのは、集団ごとに切って比較できる数字です。今週登録した人のうち翌週も使った割合、という形にすると、施策の前後で比較でき、良くなったのか悪くなったのかが分かります。この切り方をコホート分析と呼びます。

登録数だけを追っていると、翌月の利用率が落ちていても気づけません。見る数字を切り替えることが、判断を誤らないための最初の一手になります。

仮説を棄却するラインを先に置く

検証を始める前に決めておくべきなのは、「どうなったら諦めるか」です。この基準を事前に置かないと、結果が出たあとで基準のほうが動きます。

実務では、次の3点を検証開始前に文章にしておく形が扱いやすくなります。ひとつは支持と見なす数値の水準、ひとつは観測する期間または対象数、ひとつは基準に届かなかった場合に取る行動です。

3点目まで決めておくことで、「そのときに考える」という先送りを防げます。

方向転換の判断は「何を変えるか」を特定してから

ピボットとは、これまでの学びを保持したまま、事業の方向を転換することを指します。全部をやり直すことではなく、確かめた結果を土台にして、仮説の一部を差し替える行為です。

転換の判断が必要になる典型は、複数回の検証を経ても指標が動かないときです。ただし、動かない原因が仮説にあるのか、届け方にあるのか、体験の質にあるのかを切り分けないまま方向転換すると、次も同じ場所で止まります。

転換の前に確認したいのは、顧客セグメントを変えるのか、解決策を変えるのか、課題そのものを変えるのかという3択です。どれを変えるのかが言語化できていない状態での転換は、方向転換ではなく単なる作り直しになります。

反復の設計そのものでつまずいている場合は、関連記事『イテレーションとは？』を参照してください。

この手法が自社で機能するかを判断する

リーンスタートアップは、あらゆる事業に等しく効く手法ではありません。前提となる条件が揃わない環境では、形だけを導入しても回りません。

機能しやすい条件

この手法が効きやすいのは、不確実性が高く、検証コストが低く、修正が利く領域です。顧客が誰かも、何が課題かも定まっていない状態で、小さく試して確かめられる事業が該当します。デジタルサービスの新規立ち上げは、この条件を満たしやすい典型例です。

意思決定の面では、検証結果を見てから次を決められる裁量が現場にあることが条件になります。次の一手が上位の承認待ちで数週間止まるなら、ループは回りません。

機能しにくい条件

反対に、次のような条件下では適用に慎重さが必要です。

ひとつは、最小の試作品でも安全性や法令上の要件を満たす必要がある領域です。医療機器、金融商品、食品などがこれに当たり、「まず出して確かめる」が制度上できません。この場合は、市場に出す前の段階で検証する設計へ組み替える必要があります。

ひとつは、一回の失敗が取り返しのつかない損失につながる事業です。設備投資が大きい製造業、既存の主力ブランドを使う新製品などでは、試すこと自体のコストが高くなります。

ひとつは、意思決定の周期が年単位で固定されている組織です。年度予算で枠が決まり、変更に稟議を要する構造では、週単位で回すことを前提としたループと周期が噛み合いません。

適用可否を確かめる問い

導入を検討する際は、次の観点を順に確認すると判断しやすくなります。

すべてが満たされない場合でも、導入を諦める必要はありません。満たされない項目に対して、上の対応欄のような組み替えを先に用意しておくことが実務的な進め方になります。

日本企業で導入するときにぶつかる組織の壁

大企業の新規事業部門でこの手法を導入したとき、最も多く報告される摩擦は、手法そのものではなく組織側の設計に起因します。

稟議の周期と検証の周期がずれる

構築-計測-学習ループの利点は、短い周期で判断を重ねられることにあります。ところが、次の実験に進むたびに決裁が必要な運用では、周期が承認速度に律速されます。週次で回すつもりが月次になり、学習の速度が10分の1になります。

これを回避する運用として使われるのが、事前の枠承認です。個別の実験ごとに承認を取るのではなく、「この予算枠と期間の中では、現場が実験の内容を決めてよい」という形で権限を先に渡します。

承認の対象を実験内容から枠の設定へ移すことで、周期のずれを吸収できます。

年度予算と検証の非同期

年度単位で予算と目標が確定する構造では、期の途中で仮説が否定された場合の行き場がなくなります。予算は付いているが仮説は死んでいる、という状態で年度末まで走り続けることになりがちです。

この対策として有効なのは、予算の一部を段階配分にすることです。全額を期首に確定させず、検証の節目ごとに次段階を判断する形にすると、否定された仮説に資金が張り付き続ける事態を避けられます。

撤退が決まらない構造

やめる判断は、多くの場合、始める判断より難しくなります。関わった人数が増えるほど、これまでの投資が惜しくなるほど、撤退の議論は先送りされます。

構造的な対処は、撤退基準を開始時に決め、判断する人と判断する時期を指定しておくことです。検証の担当者自身が撤退を判断する設計にすると、当事者性が働いて基準が甘くなるため、判断者は別に置くほうが機能します。

失敗を早期に扱える組織づくりについては、関連記事『フェイルファストとは？』で詳しく解説しています。

「時代遅れ」と言われる理由の内側

近年、この手法に対して「もう古い」という評価を見かけることがあります。この言説の中身を分解すると、手法の陳腐化ではなく、適用の誤りが原因になっている場合がほとんどです。

3つの誤用パターン

ひとつ目は、MVP至上主義です。仮説を立てないまま試作品を作り、出したあとで「反応が悪かった」と結論する形です。何を確かめるかが決まっていないため、結果から学べることがなく、作り直しを繰り返します。

ふたつ目は、検証の形骸化です。検証というプロセスは実施されているものの、結果に関わらず既定路線が進むケースです。この場合、検証は意思決定ではなく承認材料の収集になっており、ループとして機能していません。

みっつ目は、方向転換の乱発です。指標が伸びないたびに対象や解決策を変え、どの仮説も検証しきらないまま迷走する形です。棄却基準が事前にないと、この状態に陥りやすくなります。

誤用の共通構造

3つのパターンに共通しているのは、学習フェーズの欠落です。構築と計測は目に見える作業なので実行されますが、学習は文章と判断だけの工程であるため、省略しても進んでいるように見えます。

「時代遅れ」という評価の多くは、学習を欠いた構築-計測の反復に対する評価であり、手法そのものへの評価ではありません。導入を検討する際に見るべきは、この学習の工程を組織が実行できるかどうかです。

アジャイル開発・ウォーターフォールとの位置づけ

似た文脈で語られる開発手法との違いを整理しておくと、適用範囲の判断を誤りにくくなります。

アジャイル開発との違いは対象領域

アジャイル開発は、決まった製品をどう作るかに関する開発の方法論です。対してリーンスタートアップは、そもそも何を作るべきかを決めるための事業構築の方法論です。

両者は対立するものではなく、階層が異なります。リーンスタートアップで方向を定め、アジャイル開発で作る、という併用が実務では一般的です。

ウォーターフォール型計画との違いは前提

ウォーターフォール型の事業計画は、要件を先に確定し、順に工程を進めます。前提が正しければ効率的で、要件が明確な領域では今も有効です。

違いは、前提の扱い方にあります。ウォーターフォール型は前提を所与とし、リーンスタートアップは前提を検証対象とします。

したがって、前提が固まっている事業では前者が、前提そのものが疑わしい事業では後者が適します。どちらが優れているかではなく、不確実性の度合いで選ぶ性質のものです。

最初の一周を回すための実務手順

概念の理解から実行へ移るとき、最初の一周をどう設計するかが分かれ目になります。

検証を始める前に書き出す3項目

着手前に、次の3つを短い文章にしておきます。

第一に、最も外れたら困る前提を1つ選びます。複数の仮説を同時に検証すると、結果の原因が特定できなくなるため、1周につき1つに絞ります。書き出す形は、「誰が」「どんな課題を抱え」「どう解決すると考えるか」を1文にまとめる形が扱いやすくなります。

第二に、その前提を確かめる最小の方法を決めます。ここで「製品を作る」以外の選択肢を先に検討することが、コストを抑える分岐点になります。

第三に、支持・棄却の基準と観測期間を決めます。「2週間で申し込み率が3%を超えたら次へ進む、下回ったら課題設定を見直す」という粒度まで具体化します。

一周の進め方

準備ができたら、次の順で回します。

まず、決めた方法で最小の形を作ります。期間は数日から2週間程度を目安とし、これを超えるようなら検証範囲が広すぎる可能性があります。

次に、実際の対象者に当てて行動を観測します。ここで意見を聞くだけで終えないことが重要です。「使いたい」という発言と、実際の申し込みや利用の行動は別のデータとして扱います。

最後に、事前に決めた基準と照らして採否を判断します。基準に届かなかった場合、何が外れていたのかを1文で書き残します。この記録が次の周回の出発点になります。

記録として残すもの

一周ごとに、検証した仮説、実施した方法、観測された数値、下した判断の4点を残します。この記録が蓄積されると、事業の判断根拠が個人の記憶から組織の資産へ移ります。

着手前に確認する5点

実際に始める前に、次の5点が揃っているかを確認してください。

• 検証する仮説は1つに絞れているか
• 支持・棄却の数値基準を書き出したか
• 観測する期間または対象数を決めたか
• 発言ではなく行動を観測する設計になっているか
• 基準に届かなかった場合の次の行動を書いたか

このうち一つでも空欄があるなら、着手より先にそこを埋めるほうが、結果的に早く回ります。

事業モデル全体を一枚で整理したい場合は、関連記事『リーンキャンバスとは？』にまとめています。

 リーンスタートアップでよくある疑問

リーンスタートアップとリーン生産方式は同じものですか。

思想の起源は共通していますが、対象が異なります。リーン生産方式は既に確立した製品の製造工程からムダを省く手法であり、リーンスタートアップは製品も顧客も未確定な状態で、学びを得るまでの時間を短縮する手法です。

MVPは必ずソフトウェアでなければいけませんか。

そうではありません。紙の資料、手作業でのサービス提供、既存ツールの組み合わせなども、仮説を確かめられるならMVPとして成立します。確かめたい仮説に対して十分かどうかが唯一の基準です。

顧客インタビューだけでは検証になりませんか。

インタビューは課題の解像度を上げる用途では有効です。ただし、購買や継続の意思を確かめる場面では、発言と行動が乖離しやすいため、行動を観測する手段と組み合わせる必要があります。

小さな会社や個人でも使えますか。

使えます。むしろ資源が限られている環境ほど、確かめてから作る順序の効果が大きくなります。決裁の周期が短いぶん、大組織より回しやすい面もあります。

リーンスタートアップは時代遅れですか。

手法そのものが古いというより、適用の誤りが「時代遅れ」という評価につながっています。仮説を立てずに試作品を作る、検証結果が意思決定に反映されない、棄却基準がないまま方向転換を繰り返すという3つの誤用が典型です。学習の工程を実行できる体制があるかどうかが、今も有効に使えるかの分かれ目になります。

社内の新規事業でも導入できますか。

導入できますが、承認の周期、予算の配分方式、撤退の判断者という3点を事前に設計しておく必要があります。この3点を手つかずのまま手法だけを導入すると、形骸化しやすくなります。

検証を何周すれば十分ですか。

回数では決まりません。事前に立てた重要な前提が、事実によって支持または棄却され、次の投資判断ができる状態になったときが一区切りです。

まとめ

リーンスタートアップは、作ってから確かめるのではなく、確かめながら作るための事業開発の手法です。中核は構築-計測-学習ループにあり、MVPはそのループを回すための道具として位置づけられます。

導入の可否を判断するときは、不確実性の高さ、検証にかかるコスト、意思決定の速度、撤退基準の有無、法令上の制約という5つの観点を確認してください。満たされない項目があっても、対応の形を先に決めておけば運用できます。

明日から始めるなら、最も外れたら困る前提を1つ書き出し、それを確かめる最小の方法と、支持・棄却の基準を1枚にまとめるところからです。

作るものを決める前に、確かめることを決める。この順序が守られている限り、この手法は今も有効に機能します。

新規事業の検証を前に進めるために読みたい記事

MVPを作っても、次に何を確かめるべきかが見えないまま止まることがあります。事業設計と検証の視点を補う記事をまとめました。

• 新規事業の立ち上げ方｜撤退基準から決める進め方
  　事業立ち上げを構想から形にする実務手順
• バリュープロポジションとは？3つの要素と作り方
  　顧客に選ばれる価値提案を言語化する設計法
• プロトタイピング思考のやり方｜仮説検証を回す5ステップ
  　試作から学びを得るまでの検証手順
• デザインスプリントとは？5日間で課題を解決するフレームワーク
  　5日間で課題検証を進める設計法
• アジャイルとスクラムの違いとは?使い分け基準と失敗パターン
  　開発手法を状況で使い分ける判断軸