革新会計等は説明なし

1. リーン・スタートアップにつ
いて

2. リーン・スタートアップの概要

3. リーン・スタートアップとは
スタートアップを成功させるために考え出されたメソッドの集合

4. 「スタートアップ」の定義は？
スタートアップとは、とてつもなく不確実な状態で新しい製品やサービスを創り出さ
なければならない人的組織である。起業したての人々だけを指すものではない
● 起業した人々
● 大企業で新規プロダクト開発に関わるチーム
● 政府機関で新たなサービスを生み出そうとするチーム
● 我々

5. 根底に流れる考え方
● 思い込みに基づき開発を進めると、高確率でユーザーが望んでいないものが出
来上がる。なので、事実に基づき開発する。
● 構築-計測-学習のフィードバックループをできる限り高速に回す
○ 仮説を立て、それを検証できる必要最低限の実験を準備する（MVP）
○ 実験を行い、効果を計測する
○ 実験結果から仮説を検証し、次の仮説を立てる
● 必要に応じてピボット（大きな方針転換）する
● その結果、最短距離でユーザーが真に価値を感じる製品、サービスを提供する

6. 今までの開発との比較
今までの開発 リーン・スタートアップ
ユーザーが真に求めているもの
1 年かけて作ったの
に、誰も使ってくれな
い・・・
立ててた仮説が間
違っていた！
全然ちがう！
お、ユーザーの反
応がよくなってき
た！
みんなが使ってくれ
るプロダクトになっ
た！

7. 顧客にフォーカスする

8. 顧客の立場で考える
● 解決するべき問題を顧客の立場から見ようとしないことが多くて驚かされる
● 似たような商品があふれている市場に類似商品を投入しようと計画していたグ
ループもそうだった。どういう問題に直面しているのかと尋ねたところ、「市場シェ
アを十分に取れていないこと」だと返ってきた。失笑を禁じ得ない。その会社の
市場シェアなど顧客は気にしない。顧客が考えるのは、その商品で自分の暮ら
しが良くなるかどうかだけだ

9. アマゾンの例
● アマゾンは、顧客にとってなにが問題であるのかをまず特定し、そこからさかの
ぼる形で考えていく。
○ 現状のソリューションはどういうものであるのか、さらには、新しいソリュー
ションならいままでよりはるかによく問題が解決できるのはなぜなのか。こ
れらがのっている「プレスリリース」の記事を開発する前に書く。もし、うまく
書くことができないのであれば、その製品やサービスに作る価値はない
● 問題を顧客の視点できっちり把握できるまで製品の開発は行わない。そうしなけ
れば、学びに集中することなどできはしない

10. 仮説について

11. ● ユーザーは A を課題として認識している
● ユーザーは A を解決できるならお金を払っても良いと思っている
● A はこのプロダクトによって解決できる
● ユーザーはこのプロダクトを我々から買ってくれる
普通の製品開発は多くの仮説に基づいて行われる
本当に？

12. よくある失敗パターン
ちょっと待ってくれ。
いま気づいたんだが、このプロ
ジェクトは 2 年も前から進めてい
るのに、最終的に買ってくれる人
が本当にいるのか、よくわかって
ないんじゃないか？
・・・・

13. ● ユーザーは A を課題として認識している
○ ユーザーインタビューでみんなが口を揃えて言っている
● ユーザーは A を解決できるならお金を払っても良いと思っている
○ 簡単な機能を公開したところ、課金してくれる人がいた
● A はこのプロダクトによって解決できる
○ 利用状況を計測したところ、70 % のユーザーが毎日使ってくれている
● ユーザーはこのプロダクトを我々から買ってくれる
○ すでに課金している人がいる
仮説ではなく事実に基づいて製品開発を行おう
よし！！！

14. 仮説をはっきりさせる
● プロジェクトが成功するためには、どの仮説が真でなければならないのか。その
仮説は顧客についてのものか、パートナーについてのものか、競合他社につい
てのものか
● 解決しようとしている問題を顧客が本当に抱えており、その問題を解決したいと
強く願っている（そのためならお金も払う）という証拠はあるか
● 顧客が解決策に望むことについて、本当にわかっているのはなにか

15. シンプルにする
● 「自分が解決しようとしている問題が本当に世間で問題とされていることなの
か、人々から話を聞いて確認するのは難しいが、この確認は必要不可欠な作業
である。私は、次のようなシンプルな問い三つで鍵を握る仮定を検証することに
している」
○ みんな抱えているはずだと思っている問題は、本当に人々が抱えている問
題なのか
○ その問題に、みな、いまはどう対処しているのか
○ 自分のやり方は、いまやられている対処方法より優れているか
● ただし、やりすぎはよくない。要となる仮説なのではないかと誰かが思ったもの、
すべてについて調べたくなるかもしれないが、事業計画に書かれた主張のうち、
成功や失敗に最大級の影響を与えるものに限るべきだ

16. MVP

17. MVPとは
● Minimum viable product （実用最小限の製品）の略
● フィードバックループをできる限り高速に回すためのもの
● 従来の製品開発は長い時間をかけてじっくりと開発し、完璧な製品を目指すが、
MVP は目的が学びのプロセスを始めることであってそれを終えることではない
● プロトタイプやコンセプト検証と違い、MVP は製品デザインや技術的な問題を解
決するためのものではない。基礎となる事業仮説を検証するためのもの
● MVP を提供した結果を何をもってどのように評価するのかも重要（提供するだ
けでは意味がない）

18. MVP の例（動画型 MVP）
● ドロップボックスは製品開発と並行して、顧客にとって何が重要なのかフィード
バックを得ようとした。なかでも重要なポイントとなったのは「優れた体験を提供
できれば顧客は我々の製品を使ってみてくれるか」という要になる問いの検証
だった
● これを検証するため、技術がどういう感じで働くのかを示す 3 分ほどのシンプル
なデモ動画を作成した
● 効果は劇的で、ベータ版の予約リストが 1 日で 5,000 から 7,5000 に増えた。
これにより開発中の製品を顧客が欲しがるという要の仮説に裏付けが得られた
○ ただ閲覧数がのびただけではなく、予約リストへの登録という具体的な行動
がともなっていることも重要

19. MVP の例（コンシェルジュ型 MVP）
● 自分や家族の好みに合わせて 1 週間の献立と食材のリストを作ってくれるフー
ド・オン・ザ・サービスの場合、システムを構築する前に人間の手で同等のサー
ビスを提供することにした
● 近くのスーパーでサービスを利用してくれる人を募集し、CEO とバイスプレジデ
ントが献立を考え、対価として本格的に提供された場合と同等のサービス料を
受け取った
● これにより実際にシステム開発を行う前に様々な学びを得ることができた
○ サービスに価値を感じてくれる人がいて、お金を払ってくれること
○ それらの人々は他にどのようなニーズを持っているか
○ etc…