mcpField
L
lean-startup

lean-startup

github.com/wondelaiマーケティング・グロース2.5k5.8k 回インストール7 週間前に更新
リポジトリ

lean-startup について

lean-startupは、仮説検証と検証済みの学習を製品開発に取り入れる、スタートアップや製品チーム向けの方法論スキルです。MVP設計、実用的な指標、成長モデル、根拠に基づくピボット判断を扱います。

主な機能

  1. 01構築・計測・学習サイクルの計画
  2. 02リスク順の仮説検証
  3. 03MVPの選定と設計
  4. 04実用的な指標とコホート分析
  5. 05根拠に基づくピボット判断

活用シーン

  1. 01本格開発前の需要検証
  2. 02実験で使う指標の選定
  3. 03ピボットか継続かの評価

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/wondelai/skills --skill lean-startup

インストール後、Claude Code で/lean-startupを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
applications.md
assumptions.md
build-measure-learn.md
case-studies.md
five-whys.md
growth-engines.md
innovation-accounting.md
metrics.md
mvp-design.md
pivots.md
small-batches.md

詳細

リーンスタートアップ手法

スタートアップの立ち上げと新製品の投入に向けた体系的なアプローチです。開発サイクルを短縮し、ビジネスモデルが実現可能かどうかを迅速に見極めます。

基本原則

起業はマネジメントの一形態です。 成功に必要なのは、完璧な計画やひらめきではありません。仮説を検証し、顧客から学び、迅速に反復するための体系的なプロセスです。ほとんどのスタートアップが失敗するのは、計画どおりのものを作れなかったからではなく、間違ったものを作ったからです。すべての計画を反証可能な仮説の集合として捉え、固定されたロードマップの実行ではなく、無駄をなくし、検証済みの学習を加速するために労力を費やしましょう。

スコアリング

目標:10/10。 5 つのクイック診断項目で計画、実験、または指標セットを評価します。回答が「はい」なら各 1 点、さらに検証ラダー(レベル 3 以上)のエビデンスで裏付けられている場合は各 2 点です。

  • 9-10: 思い込みに基づく前提をすべて明示してリスク順に並べ、最もリスクの高いものを実際の MVP で検証し、実行可能な指標を定義し、構築前に明確なピボット基準を設定している状態です。
  • 5-6: 仮説と MVP はあるものの、指標が虚栄の指標であるか、ピボット基準が未定義の状態です。データに基づく意思決定はできません。
  • ≤3: ウォーターフォール的な考え方です。製品全体を先に作る、顧客に何が欲しいかを尋ねる、または製品と市場の適合性を確認する前に規模を拡大する、といった状態です。

現在のスコアと、次に改善すべきスコアが最も低い診断項目を示してください。

構築・計測・学習のループ

基本となるサイクルは、アイデア → 構築(製品)→ 計測(データ)→ 学習(知識)→ アイデアに戻るです。

重要な気づき: ループを逆方向から計画します。

  1. 何を学びたいですか?(検証する仮説)
  2. 学べたかどうかをどう判断しますか?(指標)
  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)、メモリ監視を追加する(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 をさらに縮小します
実験が失敗したら、どうしますか?ピボット基準がありませんピボットのきっかけを事前に定義します

参考資料

フレームワーク、研究、事例の詳細については、以下をご覧ください。

著者について

エリック・リースは、起業家であり作家です。IMVU の共同創業者兼 CTO として、継続的デプロイと顧客開発の手法を開拓し、リーン・スタートアップの手法を確立しました。*「リーン・スタートアップ」*は30以上の言語に翻訳され、世界中のスタートアップ文化に影響を与えてきました。その後、Long-Term Stock Exchange(LTSE)を設立しました。

コメント