Home > book > 何のために開発するかを考える – リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだす

何のために開発するかを考える – リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだす

  • 2012-08-30 (木) 11:50
  • book
この記事の所要時間: 532

お盆休みに最近話題の「リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだす
」を読みました。Webサービス、システム開発を行う人間にとって示唆に富む内容だったのでご紹介。

ジャスト・ドゥ・イット型起業からの脱却

「とりあえず製品をリリースして様子を見よう」という方針で進むと、このような問題に悩まされがちだ。私はこの方針をナイキの有名なスローガンにちなんで「やってみよう(ジャスト・ドゥ・イット)」型起業と呼ぶ。

新しい製品やWebサービスの多くはこれまで世に無かったものなので、事前に市場調査を綿密にしていても、実際にリリースしてみないと反応が分からないことが多いです。とくに小規模のベンチャーでは市場調査などを行う人材がいない、リソースが割けないということもあり、まず作ってみようというジャスト・ドゥ・イット型で進めることが多くなります。

これはこれで一理あるのですが、闇雲に機能を実装してリリースしても「下手な鉄砲も数打ちゃ当たる」状態になり、上手くいかなかった場合(多くの場合はこうなる)に得られる学びも少なくなります。

私自身もこれまでいくつかWebサービスやアプリを作って来ましたが、多くはまさにジャスト・ドゥ・イット型の開発でした。時には上手くいくこともありましたが、次の手がうまく打てずに萎んでしまったり、工数をかけてじっくりと作ったわりに鳴かず飛ばずでうまくいかないということもありました。

もちろん、そんな簡単にヒットするものが作れないのは当然です。ただ、運を天に任せて、下手な鉄砲を撃ちまくるのでは、宝くじを買うようなものでいつまでたっても陽の目を見ることができません。

そこで、ジャスト・ドゥ・イット型に科学的手法を取り入れて、もう少し成功の確率を高めていこうというのがリーン・スタートアップです。

リーン・スタートアップとは

リーン・スタートアップは、トヨタのリーン生産方式に基いて考案されたもので、顧客にとってのメリットを提供するものに価値をおき、それ以外のものは全て無駄という考え方です。これは至極当たり前のように思えるのですが、サービスを作る側、とくにエンジニアやデザイナのようにもの作りをしている人間の場合、この点を見過ごしてしまいがちになります。

本来は顧客へ何らかの価値を提供するためにものを作るべきなのに、ものを作ることに重点が置かれてしまい、下手をすれば、ものができてからそれが顧客にどんな価値をもたらすのかを考える、という本末転倒な事態になることもあります。

あくまで重要なのは「顧客に価値を提供する」という点なので、それに寄与しないもの(自分たちが作ったものも!)は無駄なものとしていさぎよく捨てる覚悟が必要です。

仮説、構築、計測、学び

リーン・スタートアップでは、まず顧客にどのような価値を届けるか、届けるとどのような反応が返ってくるかという仮説を立てます。そしてその仮説を確かめるために製品を開発します。製品が完成したら、実際にリリースして計測を行ないます。計測で得られた結果、反応を見て、仮説が正しかったかどうかを検証します。そこで得られた学びを元に次の仮説を立てて、また製品を作っていきます。

この一連の流れを小さく早く回して、顧客の反応を確かめながら進んでいくのが特徴です。

つまり「ものを作る」というのはあくまで仮説を証明する手段にすぎません。よって仮説が証明できれば、機能自体は実装しない場合もあります。

極端なことを言えば、最も簡単に仮説を検証できるのは、顧客に直接聞くという手法です。その製品がターゲットとしている顧客にコンタクトを取って、提供しようとしている製品を話せばすぐにフィードバックを得ることができます。もちろん、実際にものが無いと想像できない場合も多いのですが、少なくともそれを欲している人がいるかどうかくらいは分かります。

本書では、仮説を証明するための必要最低限な製品をMVP(Minimum Viable Product)と呼んでいます。このMVPは仮説が検証できれば良いので、それ以外の機能や品質は不要です。

これは自分でもついやってしまうのですが、こういう機能なら今時はソーシャル連携するだろう、Ajaxになっていないといけないなど、機能の本質では無い余計なものまで作りこんでしまうことがあります。もし、その機能自体が誰からも必要とされていなから、そういった余計なものは全て無駄となってしまいます。

まずは仮説を立てる。そしてそれを確かめるために製品を作る。このアプローチがとても大事です。

開発の現場では当たり前のこと

この一連の流れは視点を変えれば、実は普段からシステム開発の現場ではやっていることと同じです。

例えば、不具合を修正する場合。

不具合の報告を受けて、現象が確認できたら、まずやることは原因を特定することです。原因を特定するには、ここが原因だろうという仮説を立てます。そしてそれを確かめるためにソースを読む、コメントアウトしてみる、テストを書くなどを行ないます。そして実際に動かして仮説が正しいかどうかを確かめます。原因が特定できれば次は修正方法を検討します。そして、修正を行ない、不具合が解消されているかを確かめます。

これはまさに「仮説、構築、計測、学び」のサイクルと同じです。そう考えるとごく自然にこのアプローチが理解できます。

何のために作るかを見つめなおす

やってはいけないことをすばらしい効率で行うことほど無駄なことはない。

有名なドラッガーの言葉が本書でも引用されているのですが、もの作りを行う人間が陥りがちな状況を的確に表しています。誰も求めていない製品を最高の品質で作っても事業としては意味を成さないのです。

自分たちが作っているものは誰のどんな問題を解決するのか、どんな価値が提供できるのか。事業を行う上でも、ものを作る上でもあらためて考えさせられる本でした。

この本ではさらにリーン・スタートアップを行う具体的な手法や実際の事例がふんだんに盛り込まれています。事例には、DropBoxやインテュイット、グルーポンなど馴染みのある企業が登場します。また、アジャイル開発や継続的インテグレーション、Railsなど開発現場で聞かれる単語も登場するなど、自分に近い話として読むことができました。おすすめです。

リーン・スタートアップの原点ともいえるトヨタのリーン生産方式に関する本です。

Pocket

follow us in feedly

Home > book > 何のために開発するかを考える – リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだす

検索
フィード
メタ情報

Return to page top