Lean Startup と ARC(Agile/Ruby/Cloud) について

5/12 クラウドEXPOのIIJさんのブースにて、「今、なぜアジャイルが注目されるのか～クラウド環境での素早いスタートアップ～」と題してお話させていただきました。

いつものアジャイルのWhyの話、プロセス視点の話のあとに、新ネタとして Eric Ries さんのLean Startup の話を入れました。そして、その基盤として、ARC(Agile/Ruby/Could)につなげました。（今、Ericさんはなんと、ボルチモアで開催されている Railsconf のキーノーターとして話しているのですね！）

いくつかキーとなるスライドを紹介します。

これは、下にScrumのループを示し、その上に「？」を描いています。「製品バックログはどこから来て、出荷可能ソフトウェアはどこへいくの？」という問いに答えようとしています。

ここはScrum的にいうと、「プロダクトオーナーの仕事」なんですが、ここはとても難しい。「？」の中に誰がいるのだろう？これが、ぼくの問題提起です。

Eric Ries は、この部分が「顧客開発」だという。facebookをはじめとするWebのSNSのようなビジネスを考えると分かりやすいでしょう。どんな機能がウケるだろうか？どんな人が使うだろうか？「この機能を作ればユーザが増える」はあくまで仮説であり、それを検証しながら、顧客に関する知識を学習しながら進もう。製品開発のループに顧客開発のループも合わせて取り込もう、というのです。

これは、Ericオリジナルの絵です。開発のところにXPが書いてあるのがうれしいですね。Ericは、Kent Beck と Mary Poppendieck の本を参照しており、「LeanStartup という名前を考えるとき、"Extreme Startup"にしようか"Agile Startup"にしようかとも迷った」と発言しています。左側に問題：Unknown とありますが、もし、もし問題がKnownであれば、すなわち、開発対してバックログを定義（！）してあげることができれば左側が Known になり、それはAgileのみで解決できるのだ、と言っています。しかし、「売れる機能」が「定義」できないのであれば、仮説を回して顧客に関する知識を蓄えていくことを、全体のループに入れるのです。それが、Lean Startupです。そして、これだけではありません。ここには、まだまだ掘るべきプラクティスが隠されています。

このループをより洗練して書いたものです。顧客に関するデータの取得まわりに新しい知識群（アジャイルにものもの無かったもの）が加わっています。

例えば、「ABテスト」があります。画面やボタン配置など、二つのパターンを作って、どちらが人気があるか（ユーザが好むか）を仮説検証するのです。

以前、DeNAの方と話をしたときに、最近のゲームでは、この種のユーザ行動の分析をかなり真剣にやる、と言っていました。Ericは、そのような分岐コードをわざとプロダクトの中に仕掛けることにも言及しています。そして、「コホート分析」、のように、ユーザの群（コホート）が、どのようにマネタイズまでのなかで脱落するかを分析すること、もプラクティスに入れています。製品開発と顧客開発をつなぐ「計測」(MEASURE)の部分です。また、「開発」（BUILD）の側にも、「クラスタ免疫システム」のように、新しいビルドをクラウドに配備する際、一気に欠陥が広がらないような手法をプラクティスとして追加していたりもします。

最後にMarket-by-Numbers.comのBrant Cooperさんの図解が絶妙だったので、ここで引用します。（Brantさんのブログには、このほかにも、たくさんの Lean Startup に関する図解があります。）

右側に解決サイド、すなわち、製品開発側のループが書かれ、左側に問題サイド、すなわち、顧客開発側のループが書かれています。そして、それらを仮説検証で「バリデーション」しながら、ビジネス全体をスタートアップさせるのです。「作ってそれを売る」(Product-Out)、でなく、「市場分析したものを作る」(Market-In)でもない。これらはどちらも、大きな仮説を立ててそれを実装するアプローチといえるでしょう。右を正しいと見るか、左を正しいと見るか、という違いです。現代では、良いものが売れる、というのが過信だとみんなが気付いているだけでなく、さらに、マーケット分析で売れるものが分かる、ということも過信だということに気付いています。だから、双方をブートストラップのように、細い価値流でリーンつなぎ、ループが回ったら、そこにリソースを足していく。この仮説検証を繰り返して太らせていく、という手法です。

シリコンバレーでは、スタートアップを買収する際に、右側の成果である「製品」に価値をつけることと同じくらい、左側の成果である「顧客リスト」を見ることの方が多いように思います。「何がビジネスの資産か」という視点で考えても、この両方を「育てて」いく、リーンスタートアップはとても頷ける手法なんだと思います。

さて、このような開発とビジネスの形に合ったプラットフォームとはなんでしょう？製品もどんどん変化する、スピードをあげる、初期投資を小さく、あとでスケールする。いま、Agile/Ruby/Coudの組み合わせがスタートアップの基本要素の組み合わせとして注目されているようです。

• Aglie
  顧客参画と繰り返し。フィードバック。
• Ruby (on Rails)
  開発者に優しい。生産性とスピード。
• Cloud
  小さな初期投資。スケールアウト。
• +Lean Startup
  ＋ムダなく顧客開発の流れを作る。

ぼくはこの流れが徐々に加速していくのだと思っています。ぼく自身はRubyプログラマではないし、クラウドのビジネスを扇動している訳でもありません。ぼくはずっとAgileサイドにいて、この方法が新しい形でビジネスと結びつくことが、とってもうれしい、そんな感想です。

例えば、これは、以前ぼくが書いた、「新製品開発」（ハードも含む）の文脈でのLeanとAgileの関係です。（英語のフルの文章がこちらのブログにあります。）ここで、Maryが言う、From Concept To Cash という価値流の中で、ITが担う役割の部分にAgileを持ってくるという発想をしています。これは、開発が一直線なんですね。この部分も含めてループにしてしまうのが、Lean Startup の発想であり、Webサービスの分野ではむしろそちらが当たり前と言える時代なんでしょう。Value Stream ではなく、Value Loop という感じでしょうか。

@JoshuaKerievskyは、twitterで "The management wrapper that #agile needed wasn't #scrum or #lean - it was #LeanStartup" という発言をしていて、なるほど！と思ったのはぼくだけでないはずです。

話の全体を表現しているマインドマップをつけます。このブログは、当日あまり時間を取れなかった LeanStartup の部分を掘り下げて書いたものです。

また、スライド全体をつけます。