連載
» 2012年07月06日 00時00分 公開

プログラマのためのリーン・スタートアップ入門(2):リーン・スタートアップが示す「5つの原則」

「リーン・スタートアップ(Lean Startup)」に、いま世界中の起業家たちが注目している。本連載では、スタートアップに興味のあるプログラマ向けに、リーン・スタートアップについて解説。

[倉貫義人,ソニックガーデン]

 第1回「リーン・スタートアップが生む価値――“Just do it!”の無駄を省く」では、リーン・スタートアップがなぜ必要なのか、誰にとって価値があるものかについて解説しました。

 第2回では、「リーン・スタートアップが示す5つの原則」について、リーン・スタートアップならではの特徴的なキーワードである「MVP」「ピボット」をふまえながら解説します。

原則1:アントレプレナーはあらゆるところにいる

アントレプレナーの定義

 リーン・スタートアップにおける「スタートアップ」の定義は、不確実な状況の中で、新しい製品やサービスを創出する使命を持った組織のことを指します(第1回の「定義」参照)。そして、ここで働く人すべてを「アントレプレナー」と呼びます。

 アントレプレナーというと、起業、独立、会社を作る……といったことをしなければならないのかと思いがちですが、必ずしもそうではありません。むしろ、新しい事業を起こす使命をもつアントレプレナーは、大きくなってしまった企業の中にこそ、求められているのかもしれません。

製品ではなく、ビジョンにコミットする

 また、エンジニアであっても、スタートアップにいれば、アントレプレナーシップを求められます。ただ良いものを作ることにフォーカスするのではなく、「スタートアップが持つビジョンを実現させることにコミット」しなければ、成果を出すことはできないからです。

原則2:起業とはマネジメントである

 リーン・スタートアップの提唱者 エリック・リースの著書『リーン・スタートアップ』の中で、「起業とはマネジメントである」という訳で紹介されている原則です。しかし、原書では“Entrepreneurship is management.”=「アントレプレナーシップとはマネジメントである」であり、起業そのものとは少しニュアンスが異なります。

スタートアップ=作り出す組織

 スタートアップとは、製品そのものではなく、それを作り出す組織のことです。組織を作るためには、マネジメントが必要です。

 そして、不確実な状況の中で新しい製品やサービスを作れる組織を構築することは、従来のマネジメントでは不可能なのです。

従来のマネージャに代わるのがアントレプレナー

 そのため、リースは「アントレプレナーシップは、スタートアップという組織を構築するためのマネジメントである」と言っています。従来の組織をマネジメントするためにマネージャが必要なように、イノベーションを求められる組織をマネジメントするためには、アントレプレナーが必要なのです。

共通化できる経験を蓄積する

 スタートアップが成功するためには、アイデアが必要です。しかし、どんなに優れたアイデアがあったとしても、方法がまずければ成功しません。アイデアは一般化できませんが、方法は共通化できます。

 「マネジメントである」という言葉には、「共通化できる経験を蓄積する」という意味合いが込められています。リーン・スタートアップという手法を学ぶことで成功の確率を高めることができるのです。

原則3:検証による学び

 スタートアップという組織は、「持続可能なビジネスを作る方法を学ぶために存在している」ということを示す原則です。この「学び」という要素が、リーン・スタートアップを理解する上で非常に重要なポイントになってきます。

リーン生産方式における考え方

 リーン生産方式の考え方では、生産活動のうちで価値を生み出す部分と無駄な部分を分け、

  • 顧客にとってのメリットを提供するもの=価値
  • それ以外=すべて無駄

 としています。非常に明快です。

スタートアップにおける考え方

 しかし、スタートアップでは、少し意味が変わってきます。なぜならば、スタートアップにおいては、最初から顧客が見つかっているわけではないからです。顧客を見つけていくことが、スタートアップの活動になります。

 スタートアップという、顧客が誰なのか分かっていない状況では、その顧客が何に価値を見いだすかも分からない、ということが起こります。そうであれば、先ほどの価値と無駄の区別はできなくなってしまいます。

学びにつながらないものは、すべて無駄

 どこに顧客がいるのか探していく状況においては、「活動中の科学的な検証から得られる学び」こそが重要になってくるのです。そこでリーン・スタートアップでは「学びにつながらないものはすべてが無駄である」と考えます。

原則4:構築−計測−学習

 スタートアップの活動は、以下の3つから構成されます。

  • アイデアを顧客に届けられる製品にすること=構築
  • 製品を使った顧客からの反応を計測すること=計測
  • 計測したデータから方向転換するかどうかを学ぶこと=学習

 この3つの活動を繰り返し繰り返し行うことで、正解に近づけていくのがリーン・スタートアップです。フィードバック・ループの繰り返しを、素早く、無駄なく、回転させることこそが、リーン・スタートアップの肝になります。

リーン・スタートアップの成り立ち フィードバックループの図

 最初のアイデアを形にするまでに相当の時間をかけてしまうと、もし次の計測で得た結果が残念なものだった場合、ダメージが非常に大きくなります。よって、アイデアを製品にするまでの時間や資金を最小限にし、早めに顧客からのフィードバックを受けて改善していくことで、成功に近づけていきます。

MVP(minimum viable product:実用最小限の製品)

 フィードバック・ループの最初となる「構築」で使うのが、「MVP(minimum viable product)」というキーワードです。フィードバックループを素早く回転させるためには、最初の「構築」を終わらせて「計測」に進まなければいけません。

 しかし、多くの新規事業の担当者は、1周目の第1歩であるはずの「構築」をしっかりした形にしたい、あれもこれもと盛り込みたいと考えて、この最初の「構築」に時間をかけすぎてしまいがちです。そもそも、「最初の構築は時間のかかるもの」だと思い込んでいます。

最初の「仮説の検証」が重要

 大切なのは、最初の「仮説の検証」ができることで、それができれば最初の「構築」としては良いのです。その事業仮説を検証するためのものをMVPと呼びます。構築よりも検証、検証よりも学びが大切になるので、構築自体は必要最小限の労力で済ませることを考えます。

 誤解されがちですが、MVPはデザインや技術的課題を解決するためのプロトタイプではありません。仮説を検証できればいいので、必ずしも動く製品を作る必要はありません。逆に、検証からの学びができなければ、MVPとして成立しません。

 例えば、Webサイトを用意し、申し込みフォームから新規登録の入り口を作ったとします。受付先がメールで届いて、裏側で人が返信をする仕組みだとしても、ユーザーが申し込むかどうかを検証する目的であれば、これをMVPと呼べます。

 書籍ではMVPを「コンシェルジュMVP」と呼んでいますが、日本のIT現場で昔から言われている「運用でカバー」というものです。製品開発だけを考えたら「運用でカバー」は避けたいと思うかもしれませんが、検証からの学びを考えたら、正しいことなのです。

品質は大丈夫?

 MVPにおいて、品質の問題を気にする人もいるでしょう。完ぺきに作り込んでいない状態で、ユーザーに見せるのは抵抗がある……という気持ちは分かります。しかし、スタートアップにおいて顧客が誰か分かっていない状態では、何が品質なのかも分からないはずです。まずは、顧客を見つけることです。本当に必要だと思う顧客であれば、品質について言及してくれるはずです。

 MVPは、想像しているよりも小さいものだと思うくらいでちょうどいいはずです。検証しようとする学びにつながらないものは、なくていいのです。

原則5:革新会計(イノベーション・アカウンティング)

 この原則も、言葉としては少々突飛な印象を受けます。従来の管理会計では、スタートアップに対する正しい評価ができないため、それに代わる評価基準を設けることが必要だということを示す意味で、管理会計に対するカウンター・ワードとして革新会計という言葉が生まれたのでしょう。

価値仮説

 スタートアップでは最初に、「提供する製品やサービスが本当に価値のあるものかどうか」を確認していく活動を続けます。その仮説を「価値仮説」と呼んでいます。

 価値仮説は、累計的な売上高や利益率などからは検証できません。そのため、製品やサービスに合った革新会計のためのKPIを設定する必要があります。分かりやすく言えば「売れるかどうか」を検証するための数字です。

成長仮説

 そして「価値仮説」が正しいことを検証できたら、次はそれが持続的に拡大していくかどうかを検証しなければいけません。それが「成長仮説」です。「より多くの顧客に拡大するためのエンジンは何か」を発見するプロセスで使う、評価軸を設定するのです。こちらは「もうかるかどうか」を検証します。

リーン・スタートアップの成り立ち ピボット

ピボット(方向転換)

 「価値仮説」と「成長仮説」を検証していく中で、学びの中から間違いに気付くことがあります。その時に行うのが「ピボット(方向転換)」です。

 ピボットとは、ビジョンを変えず、製品のチューニングだけでは改善しない場合に行う戦略転換のことです。

 第3回では、実践編としてソニックガーデンでの実際の事例をもとに、ピボットの概念について詳しく解説します。

筆者プロフィール

ソニックガーデン

倉貫義人

倉貫義人

ARC(Agile/Ruby/Cloud)を得意とするソフトウェア企業「SonicGarden」代表。大手SIerにてプログラマやマネージャとして経験を積んだのち、2009年に「SonicGarden」を立ち上げる。また、日本XPユーザグループの代表をつとめるなど、アジャイルの普及を行ってきた。現在は「心はプログラマ、仕事は経営者」がモットーに、アジャイルソフトウェア開発とリーンスタートアップを自ら実践中。

ブログ:http://kuranuki.sonicgarden.jp/



Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。