lean-startup について
lean-startupは、仮説検証と検証済みの学習を製品開発に取り入れる、スタートアップや製品チーム向けの方法論スキルです。MVP設計、実用的な指標、成長モデル、根拠に基づくピボット判断を扱います。
主な機能
- 01構築・計測・学習サイクルの計画
- 02リスク順の仮説検証
- 03MVPの選定と設計
- 04実用的な指標とコホート分析
- 05根拠に基づくピボット判断
活用シーン
- 01本格開発前の需要検証
- 02実験で使う指標の選定
- 03ピボットか継続かの評価
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ wondelai/ skills --skill lean-startupインストール後、Claude Code で/lean-startupを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/applications.mdassumptions.mdbuild-measure-learn.mdcase-studies.mdfive-whys.mdgrowth-engines.mdinnovation-accounting.mdmetrics.mdmvp-design.mdpivots.mdsmall-batches.md詳細
リーンスタートアップ手法
スタートアップの立ち上げと新製品の投入に向けた体系的なアプローチです。開発サイクルを短縮し、ビジネスモデルが実現可能かどうかを迅速に見極めます。
基本原則
起業はマネジメントの一形態です。 成功に必要なのは、完璧な計画やひらめきではありません。仮説を検証し、顧客から学び、迅速に反復するための体系的なプロセスです。ほとんどのスタートアップが失敗するのは、計画どおりのものを作れなかったからではなく、間違ったものを作ったからです。すべての計画を反証可能な仮説の集合として捉え、固定されたロードマップの実行ではなく、無駄をなくし、検証済みの学習を加速するために労力を費やしましょう。
スコアリング
目標:10/10。 5 つのクイック診断項目で計画、実験、または指標セットを評価します。回答が「はい」なら各 1 点、さらに検証ラダー(レベル 3 以上)のエビデンスで裏付けられている場合は各 2 点です。
- 9-10: 思い込みに基づく前提をすべて明示してリスク順に並べ、最もリスクの高いものを実際の MVP で検証し、実行可能な指標を定義し、構築前に明確なピボット基準を設定している状態です。
- 5-6: 仮説と MVP はあるものの、指標が虚栄の指標であるか、ピボット基準が未定義の状態です。データに基づく意思決定はできません。
- ≤3: ウォーターフォール的な考え方です。製品全体を先に作る、顧客に何が欲しいかを尋ねる、または製品と市場の適合性を確認する前に規模を拡大する、といった状態です。
現在のスコアと、次に改善すべきスコアが最も低い診断項目を示してください。
構築・計測・学習のループ
基本となるサイクルは、アイデア → 構築(製品)→ 計測(データ)→ 学習(知識)→ アイデアに戻るです。
重要な気づき: ループを逆方向から計画します。
- 何を学びたいですか?(検証する仮説)
- 学べたかどうかをどう判断しますか?(指標)
- 構築するものをどこまで最小化できますか?(MVP)
目標: ループ全体にかかる時間を最小限に抑えます。
実験を計画する際は、references/build-measure-learn.md を参照してください。逆算による計画手順、実験設計のテンプレート、製品タイプ別のループ例、構築や虚栄の指標にまつわるループの落とし穴が記載されています。
検証済みの学習
顧客が本当に求めているものは、機能リクエスト、アンケート、フォーカスグループではなく、実際の行動に基づく実験を通じて学びます(人は自分の行動を正確に予測できません)。顧客の「言うこと」ではなく、顧客が実際に「すること」を計測し、自分の前提を反証できる実験を行いましょう。エンゲージメントを伴わないダウンロードや登録といった、虚栄の指標による成果は学習ではありません。
検証ラダー:
| レベル | エビデンス | 強さ |
|---|---|---|
| 1 | 「顧客はこれを求めていると思う」 | 最も弱い(意見) |
| 2 | 「顧客はこれを求めていると言った」 | 弱い(表明された好み) |
| 3 | 「顧客が先行アクセスに登録した」 | 中程度(コミットメントは低い) |
| 4 | 「顧客が内金を支払った」 | 強い(実際のコミットメント) |
| 5 | 「顧客が積極的に利用している」 | 最も強い(明らかになった選好) |
目標: 規模を拡大して構築する前に、レベル 4〜5 に到達します。
最小実用製品(MVP)
最小限の労力で、検証済みの学びを最大化できる新製品のバージョンです。プロトタイプ(技術的な実現可能性を確認するもの)でも、ベータ版(品質を確認するもの)でも、最小市場投入可能製品でもありません。学習のための手段であり、多くの場合、驚くほど小規模で低品質なもので、通常は想像するよりずっと小さくなります。
MVP の種類:
| 種類 | 内容 | 使用するタイミング | 例 |
|---|---|---|---|
| コンシェルジュ | 自動化されているように見せかけた手動サービス | ソリューションに価値があるかを検証するとき | Food on the Table(手動での献立作成) |
| ウィザード・オブ・オズ | 自動化を装い、バックエンドは手動で運用 | 自動化が必要かを検証するとき | Zappos(在庫を持たず、小売店で靴を購入) |
| スモークテスト | 製品なしのランディングページと登録フォーム | 開発前に需要を検証するとき | Dropbox の動画(コンセプトを説明し、登録数を測定) |
| 単一機能 | 主要機能を1つだけ備える | どの機能が最も価値があるかを検証するとき | Twitter(ステータス更新のみ) |
| 寄せ集め | 既存のツールを組み合わせる | 独自開発の前にワークフローを検証するとき | Groupon(WordPress とメール) |
**設計上の問い:**最もリスクの高い仮説は何でしょうか?それを検証するために最低限必要なものは何でしょうか?検証できたかどうかを、どのように測定するでしょうか?
MVP の種類と規模を決める際は、references/mvp-design.md を参照してください。7種類の詳しい解説、種類選択の意思決定マトリックス、規模の下限と上限、MVP デザインキャンバスを確認できます。
飛躍への仮説
誤っていた場合に、ビジネスの失敗につながる仮説です。これらを特定し、リスクに応じて優先順位を付け(どの失敗が致命的になるか)、最もリスクの高いものから検証します。簡単なものから始めてはいけません。
| 仮説の種類 | 問い | 検証方法 |
|---|---|---|
| 価値仮説 | 顧客はこの問題を重要だと考えているでしょうか? | スモークテスト、コンシェルジュ MVP |
| 成長仮説 | 顧客はどのようにして私たちを知るでしょうか? | チャネルのテスト、紹介実験 |
| 継続利用仮説 | 顧客は再び利用するでしょうか? | コホート分析、エンゲージメント指標 |
| 収益化仮説 | 顧客は料金を支払うでしょうか? | 予約注文、価格テスト |
**例—Dropbox:**飛躍への仮説:「人々はファイル同期ツールをダウンロードして利用する」。検証方法:大規模なインフラを構築する前に、説明動画を公開する。結果:ベータ版の登録者リストが一晩で5,000人から75,000人に増加し、需要を検証できました。
仮説の整理と順位付けには、references/assumptions.md を参照してください。インパクトと不確実性のマトリックス、優先順位付けの採点テンプレート、仮説の種類ごとの検証方法、業界別の仮説一覧を確認できます。
イノベーション会計
従来の指標が機能しないときに進捗を測定する方法です。売上と顧客数はゼロから始まり、見栄えのよい指標は、意思決定につながらなくても好調に見えてしまいます。
1. ベースラインを設定する
現在の実態を、たとえゼロであったり、見栄えが悪かったりしても、正確に測定します。コンバージョンファネル(登録 → アクティブ → 継続 → 有料化)、エンゲージメント(DAU/MAU、セッション時間、使用された機能)、経済性(CAC、LTV、解約率)を測定します。
2. エンジンを調整する
実験を実施して、ベースラインの指標を改善します。価格の A/B テスト(月額 $9 と $19)、オンボーディング完了率、顧客獲得チャネル(SEO と有料広告と紹介)などが対象です。それぞれの実験で、検証済みの学びを通じた測定可能な改善を目指します。
3. ピボットするか、継続するかを決める
調整による改善が停滞したら、証拠に基づいて判断します(基準とピボットの種類については、以下の ピボットするか、継続するか を参照してください)。
ベースラインダッシュボードの構築には、references/innovation-accounting.md を参照してください。ファネル、コホート、経済性に関する指標のフレームワークを確認できます。
実行可能な指標と見栄えだけの指標
見栄えだけの指標は気分を良くしてくれますが、行動は変わりません。一方、実行可能な指標は意思決定を促し、原因と結果を明確にします。
| 見栄えだけの指標 | 問題点 | 実行可能な代替指標 |
|---|---|---|
| 登録者総数 | 常に増加し、背景がわかりません | 登録者からアクティブユーザーへの転換率(コンバージョン率) |
| ページビュー数 | 価値を示しません | ページ滞在時間、直帰率 |
| ユーザー総数 | 非アクティブユーザーや離脱ユーザーも含まれます | アクティブユーザー数(DAU、WAU、MAU) |
| ダウンロード数 | 利用されているとは限りません | DAU/ダウンロード数(アクティベーション率) |
| 収益 | 背景がわかりません | コホートあたりの収益、LTV/CAC |
実行可能な指標の3つの特徴: 実行可能(原因と結果が明確で、再現可能)、アクセス可能(シンプルで、誰もが理解できる)、監査可能(基礎データを確認できる)。
例: 見栄えだけの指標:「ユーザーが10万人います!」 実行可能な指標:「チャネルXのユーザーはチャネルYのユーザーより定着率が2倍です。Xに注力しましょう。」
コホート分析: 登録日ごとにユーザーをグループ化し、時間の経過に伴う行動を追跡します。プロダクトが実際に改善しているかを確認する唯一の方法です。
コホート表の作成や追跡する指標の選定には、references/metrics.md を参照してください。5段階のコホート分析ガイドと、リーンスタートアップの各段階に対応したAARRR(海賊指標)が掲載されています。
ピボットするか、継続するか
ピボットとは、プロダクト、戦略、または成長エンジンに関する新しい仮説を検証するために、体系的に進路を修正することです。
ピボットする場合: 実験を繰り返しても仮説が検証されない、反復を重ねても指標が横ばい、顧客のフィードバックがビジョンと矛盾する、または残された活動期間に対して進捗が遅すぎる場合です。継続する場合: 指標が改善している(たとえ緩やかでも)、明確な学びが得られている、調整によって正しい方向に進んでいる場合です。
ピボットの種類:
| ピボットの種類 | 変わるもの | 例 |
|---|---|---|
| ズームイン | 単一の機能がプロダクト全体になる | Instagram(Burbnの写真フィルター) |
| ズームアウト | プロダクトが単一の機能になる | Flickr(Game Neverendingの写真共有) |
| 顧客セグメント | 同じ課題、異なる顧客 | Groupon(社会活動プラットフォーム → 地域の割引情報) |
| 顧客ニーズ | 同じ顧客、異なる課題 | Potbelly(アンティークショップ → サンドイッチ) |
| プラットフォーム | アプリ ↔ プラットフォーム | YouTube(出会い系サイト → 動画プラットフォーム) |
| ビジネスアーキテクチャ | 高利益率・低販売量 ↔ 低利益率・高販売量 | Salesforce(ソフトウェア → SaaS) |
| 価値の獲得 | 収益化モデルの変更 | Android(有料 → 無料+アプリ収益) |
| 成長エンジン | バイラル型、粘着型、または有料型のモデル | Facebook(大学でのバイラル成長 → 有料広告) |
| チャネル | 顧客へのリーチ方法 | Salesforce(直接販売 → セルフサービス) |
| テクノロジー | 同じソリューション、異なるテクノロジー | Apple(Intel → ARMチップ) |
頻度: 成功するスタートアップは、プロダクトと市場の適合を達成するまでに、一般的に1~5回ピボットします。アンチパターン: 新しい方向性が根本的な課題を解決することを検証せずに「ピボット」することです。
データがピボットを示唆している場合は、references/pivots.md を参照してください。データに基づくピボットの兆候、体系的なピボット会議の議題、先行指標のほか、Instagram、Slack、YouTubeのピボット事例が掲載されています。
3つの成長エンジン
スタートアップが持続可能な形で顧客を獲得し、維持する方法です。まず1つのエンジンを選んで最適化し、その後、他のエンジンの追加を検討してください。 複数のエンジンを同時に動かすと、集中力と学びが分散します。
1. 粘着型成長エンジン
顧客維持主導型です。成長率 = 新規顧客獲得率 − 解約率。解約率、顧客維持コホート(30/60/90日)、DAU/MAUを追跡します。SaaS、サブスクリプション、ソーシャルネットワークに適しています。戦略:自然成長率が解約率を上回るまで、プロダクトを改善します。
2. バイラルエンジン
顧客が顧客を呼び込みます。バイラル係数 = (招待する人の割合)×(送信する招待の数)×(参加する人の割合)です。1.0を超えると、指数関数的で自律的な成長が見込めます。係数、バイラルサイクル時間、紹介のアトリビューションを追跡します。Dropbox、Hotmail、WhatsAppに適しています。戦略:製品そのものにバイラル性を組み込みます。
3. 有料エンジン
顧客獲得に投資します。LTV > CACが必要です(目標はLTV/CAC > 3x)。CAC、LTV、投資回収期間を追跡します。eコマースや従来型のビジネスに適しています。戦略:各顧客の利益で、さらに顧客を獲得できるよう最適化します。
エンジンを選択または調整する際は、references/growth-engines.mdを参照してください。解約率を下げる施策、Kファクターとバイラルループの設計、LTV/CACの最適化、チャネルの経済性をまとめた表、製品とエンジンのマッチングフレームワークが掲載されています。
5つのなぜ
根本原因分析:問題が発生したら、「なぜ?」を5回問い、その後、症状だけでなく、あらゆる階層に比例して投資します。
例—ウェブサイトがダウンした場合:
- なぜ? サーバーのメモリが不足しました
- なぜ? 新機能にメモリリークがありました
- なぜ? メモリ管理の観点からコードレビューが行われませんでした
- なぜ? インフラの変更に対するコードレビューのプロセスがありませんでした
- なぜ? チームの進行が速すぎて、プロセスを作る余裕がありません
比例した投資: バグを修正する(1)、メモリ監視を追加する(2)、コードレビューを導入する(3~4)、品質プロセスを構築するためにペースを落とす(5)。アンチパターン: レベル1で止めること。
セッションを進行する際は、references/five-whys.mdを参照してください。停止、解約率の急増、ローンチ失敗の3つの実例と、原因の連鎖が分岐する場合、責任追及に発展する場合、自分たちでは制御できない根本原因への対処方法が掲載されています。
小さなバッチ
小さなバッチで作業すると、フィードバックループが速まり、方向転換が容易になり、間違えた場合の無駄が減り、市場投入までの時間が短縮されます。
| 大きなバッチ | 小さなバッチ |
|---|---|
| 製品全体を構築してからローンチする | ランディングページを公開してから構築する |
| 四半期ごとにリリースする | 毎週または毎日リリースする |
| 12か月のロードマップを立てる | 6週間のサイクルで計画する |
| 一気に書き換える | 段階的にリファクタリングする |
継続的デプロイは究極の小さなバッチです。すべてのコミットをデプロイし、バグをすぐに検出し、継続的に学び、リリースごとのリスクを減らします。
リリース頻度を上げる際は、references/small-batches.mdを参照してください。継続的デプロイのパイプラインと前提条件、フィーチャーフラグの種類、段階的ロールアウトのチェックリスト、作業を分割する手法が掲載されています。
リーンスタートアップの実践:アイデアからスケールまで
フェーズ1—課題と解決策の適合: 顧客の発見、スモークテスト、コンシェルジュMVPを通じて、課題が存在し、顧客が関心を持っていることを検証します。指標:支払いまたは利用を約束する意思のある顧客。
フェーズ2—製品と市場の適合: MVPを構築し、利用データをもとに反復します。指標:高い定着率、オーガニックな成長、強いエンゲージメント。
フェーズ3—スケール: 成長エンジンとユニットエコノミクスを最適化します。指標:持続可能で収益性の高い成長。アンチパターン: フェーズ1~2を飛ばして、いきなりスケールに進むこと。
状況別:
- SaaSスタートアップ: スモークテスト(ランディングページ+メールリスト)→ 10人の顧客を対象としたコンシェルジュMVP → 単一機能のMVP → 定着率、NPS、機能の利用状況を測定 → コホートデータをもとに方向転換またはスケール
- 企業のイノベーション: イノベーション会計を本業の指標と分け、チームを四半期ごとの売上プレッシャーから守り、検証済みの学習マイルストーンに応じて段階的な資金提供を可能にする
- 製品機能: フィーチャーフラグの背後でデプロイする → 中核指標を使ってA/Bテストする → データをもとに廃止、反復、またはスケールする
状況に応じたプレイブック(SaaS、企業のイノベーション、機能)についてはreferences/applications.mdを、Dropbox、IMVU、Zappos、Grouponの全事例(失敗例を含む)についてはreferences/case-studies.mdを参照してください。検討中の賭けについて、実践例を確認できます。
よくある間違い
| 間違い | 失敗する理由 | 対処法 |
|---|---|---|
| 作り込みすぎる | 検証前に無駄が生じます | まずスモークテストかコンシェルジュテストを実施します |
| 顧客に尋ねる | 人は自分の行動を把握していなかったり、予測を誤ったりします | 意見ではなく行動を観察します |
| 見栄えだけの指標 | 気分がよくなるだけの数字で、意思決定につながりません | コホート、コンバージョン、リテンションを追跡します |
| 仮説がない | 予測しなければ、学びを得られません | 各実験の前に仮説を書きます |
| ピボットが遅すぎる | 事業継続のための資金を浪費します | あらかじめ明確なピボット基準を設定します |
| イノベーション会計を省略する | 改善しているかどうか判断できません | ベースラインを確立し、調整の取り組みを測定します |
| 時期尚早なスケール最適化 | プロダクトマーケットフィットの前に磨き込みます | まず学びを検証し、品質の向上は根拠が得られてから行います |
クイック診断
あらゆるプロダクト開発計画を監査します。
| 質問 | いいえの場合 | 対応 |
|---|---|---|
| 最もリスクの高い前提は何ですか? | 不安定な土台の上で開発しています | リープ・オブ・フェイスの前提を洗い出します |
| どのように検証しますか? | 推測に頼っています | その前提を検証するための MVP を設計します |
| どの指標で妥当性を確認または否定しますか? | 学びを得られません | 実行につながる指標を定義します |
| これより少ないもので検証できますか? | 作り込みすぎです | MVP をさらに縮小します |
| 実験が失敗したら、どうしますか? | ピボット基準がありません | ピボットのきっかけを事前に定義します |
参考資料
フレームワーク、研究、事例の詳細については、以下をご覧ください。
- 「リーン・スタートアップ」 エリック・リース著
- 「The Startup Way」 エリック・リース著(リーン・スタートアップを既存企業に適用)
著者について
エリック・リースは、起業家であり作家です。IMVU の共同創業者兼 CTO として、継続的デプロイと顧客開発の手法を開拓し、リーン・スタートアップの手法を確立しました。*「リーン・スタートアップ」*は30以上の言語に翻訳され、世界中のスタートアップ文化に影響を与えてきました。その後、Long-Term Stock Exchange(LTSE)を設立しました。