[開発手法] プログラマのためのリーンスタートアップ入門

リーンスタートアップは、2008年にアメリカの起業家・エリックリース氏が提唱したマネジメント手法らしい。ウェブサイトなどで「リーンスタートアップ」という言葉を目にすることが多いので、プログラマ向けに解りやすくまとまっている以下のサイトから予備知識を入れておく。

「プログラマのためのリーン・スタートアップ入門」最新記事一覧 – ITmedia Keywords
http://www.atmarkit.co.jp/ait/kw/prog_leanstartup.html

この手法自体を評価する術を僕は持ち合わせていないが、記事中には納得させられたくだりが幾つもあった。僕自身、これまでいわゆる「スタートアップ」と呼ばれる組織に関与したことが何度かあったが、失敗した経営者がやるべきだった事柄を的確に指摘している箇所も少なくない。

以下、覚え書きとして引用しておく。

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

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

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

スタートアップの活動は、以下の3つから構成されます。
– アイデアを顧客に届けられる製品にすること=構築
– 製品を使った顧客からの反応を計測すること=計測
– 計測したデータから方向転換するかどうかを学ぶこと=学習
この3つの活動を繰り返し繰り返し行うことで、正解に近づけていくのがリーン・スタートアップです。フィードバック・ループの繰り返しを、素早く、無駄なく、回転させることこそが、リーン・スタートアップの肝になります。

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

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

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

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

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

ピボットにおいて重要な点は、「軸足」を置いて方針転換をするということです。事業が当初考えていた仮説と違っていたからといって、まったく違う事業を始めてしまうと、また最初の仮説に戻ってしまうため、前に進めません。

片足を置いたまま、もう片方の足の位置を変えるのが、ピボットの肝です。そのためにはブレないビジョンが必要です。

その他の参考サイト

リーンスタートアップまとめ – NAVER まとめ
http://matome.naver.jp/odai/2131171854325173701

“Lean Startup Japan” | 新規事業を成功させる4つのステップ
http://leanstartupjapan.org/