lean-startup

注記： このスキルは、原文の再現ではなく、独自の分析と解説を提供します。本書の中心的な考え方を現代のスタートアップの実践と統合し、フレームワークが時代遅れ、または不完全な点を明らかにし、隣接分野の視点も取り入れています。議論の全容と背景については、原著をお読みください。

リーン・スタートアップ

「リーン・スタートアップは、個々の戦術を寄せ集めたものではありません。新製品開発に対する、原則に基づいたアプローチです。」 - Eric Ries

このスキルを使うべきですか？

Are you building something under conditions of extreme uncertainty?
|-- YES --> Do you know who your customers are?
|   |-- NO  --> Start with Four Steps (Customer Discovery), use Lean
|   |           Startup for iteration speed within that process
|   +-- YES --> Do you have product/market fit?
|               |-- NO  --> THIS SKILL. Build-Measure-Learn loop.
|               +-- YES --> Use Crossing the Chasm for mainstream scaling
+-- NO  --> Are you optimizing an existing product in a known market?
            |-- YES --> Lean Startup principles apply (small batches,
            |           Five Whys) but you don't need the full framework
            +-- NO  --> Rethink what you're doing

---

中心となる洞察

ほとんどのスタートアップが失敗するのは、製品を作れないからではなく、誰も欲しがらないものを作るからです。 失敗に対する一般的な反応は、計画が不十分だった、十分に実行できなかった、または適切なビジョンがなかった、というものです。Riesは、真の問題は不確実性に対応するために設計されたマネジメントの枠組みがないことだと主張します。

スタートアップとは、極度の不確実性のもとで新しい製品やサービスを生み出すために設計された人間の組織です。 この定義は、ガレージで創業する起業家、企業内のイントラプレナー、政府機関のイノベーターのいずれにも当てはまります。

5つの原則

1. 起業家精神はどこにでもある - 不確実性のもとで何かを生み出す組織はすべて該当します
2. 起業家精神はマネジメントである - 単なる「クールな製品」ではなく、規律ある取り組みです
3. 検証による学び - 「多くのことを学んだ」ではなく、実証データに裏付けられた学びです
4. 構築・計測・学習 - アイデアを製品に変え、反応を計測し、方向転換するか継続するかを学びます
5. イノベーション会計 - 不確実性に対応する新しい会計手法により、イノベーターに説明責任を求めます

---

構築・計測・学習

基本となる活動のループです。このループを回る総時間を最小化します。

         IDEAS
        /      \
       /        \
  LEARN          BUILD
      \          /
       \        /
        DATA--PRODUCT
        (Measure)

重要な洞察： ループは「構築・計測・学習」の順に並んでいますが、計画は逆順に立てます。まず何を学ぶ必要があるかを考え、それを明らかにするデータを特定してから、そのデータを得るために必要なものだけを構築します。

「このループを回る総時間を最小化することに、力を注ぐ必要があります。」

飛躍的仮定

あらゆるスタートアップは、まだ検証されていない2つの仮定に基づいています。

仮定	問い	検証方法
価値仮説	製品は利用する顧客に価値を提供できるか？	エンゲージメント、継続率、支払い意欲
成長仮説	新しい顧客はどのように製品を知るのか？	バイラル係数、紹介率、口コミの追跡

どちらも仮定するのではなく、実証的に検証する必要があります。検証前に仮定を明確にするため、類似例（似た成功事例）と反例（似た失敗事例）を活用します。

「最も重要な仮定は、価値仮説と成長仮説の2つです。」

---

実用最小限の製品（MVP）

MVPとは、最小限の労力で構築・計測・学習のループを最速で回す方法です。 最小の製品ではありません。飛躍的仮定を検証するための、最小の実験です。

WHAT AN MVP IS:                    WHAT AN MVP IS NOT:
- A learning vehicle               - A crappy v1.0
- Tests one specific assumption    - The smallest feature set
- Designed to maximize learning    - A prototype to show investors
- May lack features, polish, UX    - A proof of concept
- Can be embarrassingly simple     - A demo

MVPの種類

種類	使用する状況	例
動画	価値提案の説明が難しい場合。構築前に需要を測ります	Dropbox：3分のデモ動画により、登録者数が一晩で5Kから75Kに増加
コンシェルジュ	価値を1人の顧客に対して一度に手作業で提供します	Food on the Table：CEOが1家族のために自らレシピを選び、買い物をしました
オズの魔法使い	フロントエンドを自動化し、バックエンドは手作業にします	Zappos：店舗の靴の写真を掲載し、注文が入ると購入して発送しました
単一機能	実際の利用を通じて、価値を生む要因を1つ検証します	Groupon：WordPressのブログとメールを使い、1都市で1日1件の案件を提供しました
スモークテスト	何も構築する前に需要を測ります	ランディングページと登録フォームを用意し、コンバージョンを計測します

MVPの品質に関する懸念

「顧客が誰なのか分からなければ、品質とは何かも分かりません。」

顧客は、あなたが想像している品質の側面など気にしません。MVPを構築してリリースし、品質とは何かを顧客の意見ではなく行動から把握しましょう。

イノベーション会計

従来の会計では、スタートアップを測定できません。収益はほぼゼロです。予測は机上の空論です。イノベーション会計はその代替手段となります。

3つの学習マイルストーン

1. ESTABLISH THE BASELINE
   |-- Build an MVP
   |-- Get it in front of real customers
   +-- Measure current state of the engine (conversion, retention, revenue)

2. TUNE THE ENGINE
   |-- Run experiments to improve metrics from baseline toward ideal
   |-- Each experiment tests one assumption
   +-- Track whether changes actually move the numbers

3. PIVOT OR PERSEVERE
   |-- Is tuning working? Are you making progress toward the ideal?
   |-- YES --> Persevere. Keep tuning.
   +-- NO  --> Pivot. Change strategy fundamentally.

虚栄の指標と実用的な指標

虚栄の指標	実用的な指標
登録総数（累計）	コホートごとの登録数
総収益（総額）	コホートごとの顧客あたり収益
ページビュー数	ステップごとのコンバージョン率
「ヒット数」	コホートごとの継続率
登録ユーザー数	アクティブユーザー数／登録ユーザー数

優れた指標に必要な3つのA：

1. 行動につながる - 明確な因果関係を示します。Xを変えると、指標Yが動きます。
2. 理解しやすい - 社内の誰もが理解できます。累計ではなく、コホートレポートを使います。
3. 監査可能 - データを実在する人々までたどれます。数値の背後にいる顧客と話しましょう。

---

ピボットか、継続か

ピボットとは、製品、戦略、成長エンジンに関する新たな基本仮説を検証するために設計された、体系的な軌道修正です。失敗ではありません。スタートアップを強靭にする仕組みです。

ピボットミーティング

定期的（月次または四半期ごと）に開催します。製品開発チームと経営陣の両方が参加します。次の点を確認します。

1. 実験によって、指標は理想のモデルに近づいていますか？
2. 投じた時間とリソースに見合う進捗はありますか？
3. 自分たちの前提について、何を学びましたか？

10種類のピボット

ピボット	説明
ズームイン	1つの機能が製品全体になります
ズームアウト	製品全体が、より大きな何かの1つの機能になります
顧客セグメント	同じ製品で、顧客を変えます
顧客ニーズ	同じ顧客で、課題を変えます
プラットフォーム	アプリケーションからプラットフォームへ（またはその逆へ）切り替えます
ビジネス構造	高利益率／低販売量と低利益率／高販売量を切り替えます
価値の獲得	収益化の方法（収益化モデル）を変えます
成長エンジン	バイラル、継続利用、有料の成長モデルを切り替えます
チャネル	流通の仕組みを変えます
テクノロジー	同じ解決策で、テクノロジーを変えます

ランウェイ ＝ 残されたピボットの回数

「ランウェイの真の尺度は、スタートアップに残されたピボットの回数です。」

資金が尽きるまでの月数ではありません。資金が尽きる前に、より多くの仮説を検証できるスタートアップは、1つの賭けに資金を使い果たすスタートアップよりも、ランウェイが長いのです。

---

3つの成長エンジン

すべてのスタートアップの成長は、1つの主要なエンジンによって支えられています。1つに集中しましょう。

エンジン	仕組み	主要指標	成長する条件
継続利用型	高い継続率。既存顧客が使い続けます。	解約率	新規顧客の獲得数 ＞ 解約数
バイラル型	顧客が利用の副産物として、さらに多くの顧客を獲得します	バイラル係数（k）	k ＞ 1.0（各ユーザーが1人を超える新規ユーザーを呼び込む）
有料型	顧客を採算の取れる形で獲得するために資金を使います	LTV 対 CPA	LTV ＞ CPA（顧客生涯価値が顧客獲得コストを上回る）

「スタートアップは飢えるのではなく、溺れるのです。」- 成長戦略を同時に追い求めすぎることで。

成長エンジンの選択

Is your product inherently shareable / visible to non-users?
|-- YES --> Test VIRAL engine first
+-- NO  --> Do customers use it repeatedly (daily/weekly)?
            |-- YES --> Test STICKY engine first
            +-- NO  --> Test PAID engine first

Important: engines eventually run out. When they do, pivot or find a new engine.

---

小さなバッチ

トヨタ生産方式に由来します。バッチが小さいほど、学習が速くなり、無駄なリソースが減ります。

大きなバッチ	小さなバッチ
すべてを作ってからテストする	1つ作り、すぐにテストする
不具合が後から見つかり、修正に費用がかかる	不具合が早期に見つかり、修正が安く済む
フィードバックサイクルが長い	フィードバックサイクルが短い
満足感がある（生産的に感じる）	落ち着かない（進みが遅く感じる）
デススパイラル：手戻りが積み重なる	継続的なフロー：手戻りにすぐ対応できる

「小さなバッチで作業する最大の利点は、品質上の問題をはるかに早く発見できることです。」

大きなバッチのデススパイラル

大きなバッチは効率的に見えますが、デススパイラルを引き起こします。バッチが大きいほどテストに時間がかかり、手戻りが増え、「遅れを取り戻す」ために次のバッチはさらに大きくなり、テストにさらに時間がかかります……

プル型で進める（トヨタのジャストインタイムから）

仕掛かり作業は在庫です。スタートアップでは、開発済みでも検証されていない機能が仕掛かり作業にあたります。次の実験に必要なものだけを開発しましょう。

---

5つのなぜ

大野耐一氏のトヨタ生産方式を応用した手法です。あらゆる技術的な問題の根底には、人間に関する問題があります。

手法

「なぜ？」を5回問いかけて、症状から根本原因をたどります。各段階で原因に見合った投資を行います。小さな問題には小さな修正を、根深い原因にはより大きな投資を行います。

5つの責め（アンチパターン）

5つのなぜがうまくいかないと、責任のなすりつけ合いになります。これを防ぐには、次のことを実践してください。

• 問題の影響を受けた全員が会議に参加する
• 立場の上の人から「こんなミスを簡単に起こせる状態にしてしまったのは、私たちの責任です」と認める
• 悪い人ではなく、悪いプロセスに焦点を当てる
• 5つのなぜを進行する担当者を任命する
• 狭く具体的な問題の種類から始める
• 既存の「しがらみ」の問題から始めない

---

意思決定ツリー

「MVPは何にすべきか？」

What do you need to LEARN?
|-- "Do customers want this at all?"
|   +-- Smoke test (landing page) or Video MVP
|-- "Will customers pay for this?"
|   +-- Concierge or Wizard of Oz (deliver manually, charge real money)
|-- "Can we build the technology?"
|   +-- Technical prototype (not an MVP - engineering risk, not market risk)
+-- "Which features matter?"
    +-- Single-feature MVP + split testing

「方向転換すべきか？」

Are experiments moving metrics toward the ideal?
|-- YES, meaningfully --> Persevere. Keep tuning.
|-- YES, but very slowly --> Investigate. Are you out of easy optimizations?
|   |-- YES --> Consider pivot
|   +-- NO  --> Keep tuning, but set a deadline
+-- NO --> Have you exhausted experiment ideas for current strategy?
          |-- YES --> PIVOT. Change a fundamental hypothesis.
          +-- NO  --> Run more experiments, but set a time box.

After pivoting:
- Acceleration test: is the new direction producing faster learning?
- If MVP cycles aren't getting shorter, something is still wrong.

「虚栄の指標を使っていないか？」

Does this metric go up and to the right no matter what you do?
|-- YES --> It's vanity. Switch to cohort-based or per-customer metrics.
+-- NO  --> Can you trace a specific change to movement in this metric?
            |-- YES --> It's actionable. Keep it.
            +-- NO  --> Probably vanity. Test with a split experiment.

---

重要な数値と経験則

数値	ルール
2	検証すべき大きな仮説（価値＋成長）
3	学習の節目（基準値、調整、方向転換か継続か）
3	成長エンジン（粘着型、バイラル型、有料型）
1	一度に注力するエンジンの数
>1.0	バイラル成長に必要なバイラル係数
LTV > CPA	有料型エンジンが機能するための条件
5	根本原因分析で問いかける「なぜ」の回数
10	ピボットの種類
50	IMVUでの1日あたりのデプロイ数（継続的デプロイ）

---

よくある失敗パターン

パターン	仕組み	対策
失敗を達成する	誰も検証していない計画を見事に実行する	初日から構築・計測・学習のループを回す
虚栄の指標	ダッシュボードの数値は右肩上がりでも、ビジネスは成長していない	コホート分析、実行可能な指標、スプリットテスト
早すぎる最適化	問題の存在を検証する前に機能を調整する	まずMVPをリリースし、基準値を確立してから最適化する
大きなバッチによる死のスパイラル	大規模リリース、遅いフィードバック、再作業の累積	小さなバッチ、継続的デプロイ
学習の演出	証明するデータがないのに「多くを学んだ」と言う	イノベーション会計を導入する。学びは将来の行動を変えなければならない
成功の演出	見栄えをよくするため、都合のよい指標だけを選ぶ	3つのA：実行可能（Actionable）、アクセス可能（Accessible）、監査可能（Auditable）
方向転換が遅すぎる	現在の戦略への感情的な執着が方向転換を遅らせる	確かなデータをもとに、方向転換か継続かを定期的に検討する
方向転換が早すぎる	実験からデータが得られる前に方向転換する	期間を設定し、判断する前に実験を完了する
機能量産工場	進捗の代わりに機能をリリースする	すべての機能を仮説と指標に結び付ける

---

現代における意義（2011 --> 2026）

今もリーン・スタートアップが当てはまる領域

• プロダクト・マーケット・フィット前のあらゆるスタートアップ
• 新しい事業領域を検証する企業のイノベーションチーム
• ハードウェアや物理的な製品（サイクルが長い場合）
• 開発中のものがうまくいくかどうか分からない、あらゆるチーム

時代遅れになっている点

• AIネイティブ製品 - フィードバックループは、Riesが想定していなかった方法で自動化できます
• PLG／バイラル優先の製品 - MVPの概念は広く理解されています。より難しい問いは、どう流通させるかです
• 急成長を目指すVCモデル - 「残りの資金調達期間＝あと何回ピボットできるか」は、「一気に急成長しなければ失敗」というプレッシャーと相いれません
• ノーコード／ローコード - MVPの構築コストが非常に低くなった今、ボトルネックは製品開発ではなく、ユーザーの獲得です

Riesが今も変わらず正しいと示したこと

• 進捗の単位は機能やコードではなく、検証された学びである
• 構築・計測・学習が基本のループである
• MVPは小さな製品ではなく、実験である
• 虚栄の指標は陥りやすい落とし穴である
• ピボットは、行き当たりばったりの迷走ではなく、仮説を体系的に変更することである
• ほぼすべての状況で、大きなバッチより小さなバッチのほうが優れている
• 根本原因への投資を原因に見合ったものにするための、5つのなぜ

---

補足ファイル

• frameworks.md - Build-Measure-Learnの詳細な解説、信念の飛躍を伴う仮説、MVPの選定、イノベーション会計のマイルストーン、虚栄の指標と実用的な指標、ピボットのカタログ、成長エンジンの仕組み、小さなバッチ、Five Whys、イノベーション・サンドボックス、適応型組織
• cases.md - IMVU（創業の経緯と継続的デプロイ）、Zappos（Wizard of Oz型MVP）、Dropbox（動画によるMVP）、Groupon（MVPの起源）、Grockit（イノベーション会計）、Votizen（指標に基づく3回のピボット）、Wealthfront（プラットフォームへのピボット）、QuickBooks（大企業の変革）、IGN Entertainment（Five Whys）、SGW Designworks（物理製品の小さなバッチ）
• examples.md - MVP選定ワークシート、イノベーション会計の設定テンプレート、ピボットか継続かを判断する会議用テンプレート、成長エンジン診断、Five Whysセッション用テンプレート、コホート分析テンプレート、Build-Measure-Learnサイクルの計画表
• integration.md - Four Stepsとの関係（Lean Startupはその直接の後継）、Mom Testとの関係（学習フェーズでの会話手法）、Crossing the Chasmとの関係（Lean Startupはプロダクト・マーケット・フィットで止まる）、$100M Offersとの対立（検証優先とオファー優先）、全体の実行順序

---

本書の適用範囲について

• 出版年： 2011年
• 事例： 主に2004〜2010年のテック企業（IMVU、Dropbox、Groupon、Zappos、Votizen）が取り上げられています。今では誰もが知る企業もあれば、ピボットした企業や倒産した企業もあります。
• 実証的な基盤： 著者のIMVUでの経験と、コンサルティング／アドバイザリーの経験です。統計的な研究ではなく、逸話的な事例研究です。Ries自身もこの点を明確に認めています。
• 特に優れている領域： 創業初期のスタートアップ、企業内イノベーション、何かを世に出すべきかを検証するあらゆるチームです。
• 弱い領域： プロダクト・マーケット・フィット達成後のスケーリング、マーケットプレイスの動向、MVPの手法が危険になり得る深層インフラ製品（医療機器、航空機ソフトウェア）です。本書は顧客との話し方を詳しく扱っておらず（Mom Testを参照）、市場タイプについても触れていません（Four Stepsを参照）。
• 思想的系譜： Steve BlankのFour Steps to the Epiphanyとトヨタ生産方式（大野耐一）の直接の後継です。RiesはBlankの教えを受け、IMVUでCustomer Developmentを実践しました。Build-Measure-Learnのループは、BoydのOODAループから多くを得ています。