nkjmkzk.net

powered by Kazuki Nakajima

Archive for 12月, 2014

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

僕はエリック・リースが書いたリーンスタートアップという本が出版された2年半ほど前、この本を読んですぐに「この考え方はForce.com, appexchangeとの相性が抜群だな」と感じました。

その後しばらく適当なチャンスがなかったのですが、今回12/4に開催されたSalesforce Would Tour東京にて、とあるセッションを担当することになり、「はっ、これは、」と思い出し、ようやくリーンスタートアップとForce.comというテーマでプレゼンをすることができました。その内容をこちらにまとめておこうと思います。

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

「限られた滑走路の中で、無駄をなくして成長のエンジンを最速でチューニングするための方法論」

runway

1行で言えば、これだと思っています。

リーン・スタートアップは元々は「ジャストインタイム方式」や「一個流し」に代表されるトヨタ生産方式に端を発しています。トヨタはこれらの生産方式で高効率に高品質な車を量産することに成功したわけですが、それ生産方式がリーン生産方式としてMITで焼き直され、さらに製品の製造のみならずスタートアップを成功させるための方法論としてまとめられたのがこのリーン・スタートアップです。

リーンというのは「贅肉をそいだ」とか「無駄をはぎとった」という意味で用いられており、スタートアップがおこなう努力からとにかく徹底的に無駄を省くことがこの方法論の幹になっています。

著者のエリック・リースは、スタートアップとは「とんでもなく不確実な中で新しい製品やサービスを生みださなければいけない人的組織」と定義しています。さらにつけ加えれば、とんでもなく不確実な中でも、金と時間は確実に限りがある環境、だと思います。大企業であれば一つの部門で多少まわり道をしたとしても、事業が揺るぐことはそうそうありませんが、スタートアップは大企業に比べて財政的、時間的余裕が桁外れに少ないことがほとんどで、まわり道はGame Over(倒産)に直結します。

そんな中、無駄な活動をすべて省き、限られた時間内で離陸できるように成長エンジンの加速に集中することがリーン・スタートアップの核心であると僕は理解しました。

挑戦の要

起業する人であれば、誰しもビジョンがあり、そのビジョンを実現させるための仮説を明示的あるいは暗黙的にでも持っているはずです。この仮説のことを挑戦の要と呼んでいます。この仮説が事実となれば事業は成功する、ただしそうでなければスタートアップは戦略の変更を余儀なくされる、そういうものが挑戦の要です。

リーン・スタートアップのファーストステップはこの挑戦の要を、出来る限り分解した形で書き出すことです。

フィードバック・ループ

feedback loop

構築 – MVP

挑戦の要が設定できたら、いよいよ製品・サービスの開発を開始します。多くの人は製品を最初に公開する際に「市場に失望されたくない」と思っているのではないでしょうか。そうなるとビジョンをより完璧に実現するためのかなりリッチな製品を開発する必要がでてきます。

しかし、リーン・スタートアップでは必要最低限の製品(MVP – Minimum Viable Product)をリリースすることを提唱しています。これは、さんざん機能を詰め込んだ製品をリリースした場合、最もベースとなる仮説が間違っていたらそのすべての苦労が水の泡、つまり無駄に終わってしまうからです。

MVPの考え方とは、あくまでも挑戦の要を検証する単位で製品をリリースしていき、仮説をひとつずつ検証しながら進んでいくことを意識したものです。仮説が誤っているかもしれない状況でその仮説に基づいてさらなる仮説を検証するのは「無駄」という考え方です。

計測 – コホート分析・スプリットテスト

MVPをリリースしたらその結果を入手し、判定しなければなりません。仮説はあっていたのか、間違っていたのか。この製品で成長のエンジンはチューニングされたのか、されなかったのか。これを正しく判断するための方法をリーン・スタートアップでは「革新会計」と呼んでいます。

革新会計のミソは、かくあるべき目標数値を定め、現状を真摯に観察することにあります。あたり前の話のようですが、実際の現場では全体の右肩上がりの数字にごまかされ、真に成長を意味する数字が観察されていないことが多々あると著者は説いています。

そして現状の観察には「コホート分析」なる手法が多くの場合適切なパフォーマンスを示すことができるとされています。コホート分析とはある一定セグメントを抽出し、そこだけでの数値をまとめていく分析手法です。もっと簡単に言えば、累積ユーザー数をしめすグラフではなく、単月での増加ユーザー数をしめすようなグラフがコホート分析、ということになります。これをみることで多くのITスタートアップで計測すべき、ユーザーの増加率をつぶさに観察することができ、累積数値の増加のような虚構の数字に惑わされることがなくなる、というわけです。

また、MVPをリリース後に製品を最適化・拡張した場合に、その拡張自体のフィードバックを純粋に計測するにはスプリットテストが用いられます。これは特定顧客にのみ新機能を提供し、機能を提供しなかった顧客グループとの反応差分を確認して、製品拡張のインパクトをテストするというものです。

学習 – 製品最適化・戦略転換(ピボット)

フィードバック・ループの最後のステージでは、計測で得られた結果をもとに製品の最適化が必要かどうか、あるいは仮説が正しかったかを判断し、場合によっては戦略から転換しなければならないかを決断します。


さて、長くなりましたがフィードバック・ループの一連のステージを説明してきました。 ここで重要なのは、このループをできる限り速くまわることです。

例えばあるスタートアップの滑走路が残り12ヶ月だったとします。そのときにこのフィードバック・ループを1周するのにもし10ヶ月かかってしまい、さらにその学習結果ピボットが必要だと判断された場合、そのスタートアップはおおよそ詰んだものと考えられます。もし、2ヶ月で最初の1周をまわっていたら、あと5回は最適化とピボットの余力が残っています。なのでこのループを速くまわることがスタートアップが成功するためには不可欠である、というのがリーン・スタートアップの極めて重要なポイントです。

Force.com + appexchangeでフィードバック・ループをどうまわすか?

MVPの開発

構築のステージをまずみていきましょう。 この記事を呼んでいただいているほとんどの方にとってMVPとはなんらかのアプリ開発(とりわけクラウド型の)を意味すると思います。その場合、最終的にユーザーに価値をもたらすのはアプリの機能であって、インフラではないはずです。

Force.comは「フルマネージド」なアプリケーションPaaSです。優劣の問題ではなく、特性として、Force.comはユーザーが自由にインフラ構成を変えれるようなPaaSではなく、冗長性、拡張性、対災害、セキュリティ(インフラの)といった面において完全にSalesforceが面倒を見てくれます。逆にユーザーがこれをカスタマイズすることはできません。

ただ、前述の通りスタートアップがユーザーに直接価値を提供できるのはアプリの機能であり、限られた金、時間、人を投資するのはアプリであるべきでしょう。そういう観点ではフルマネージドなForce.comはその他面倒なことをスタートアップから取り去ってくれるうってつけのプラットフォームと言えます。

また、Force.comはいわずもがなクイックにアプリを開発することに非常に長けた開発環境です。それは下記3点から導かれると僕は考えています。

  • ノンプログラミング開発
  • モバイルUI自動生成
  • API自動生成

Force.comはそもそもプログラミングをおこなわずしてアプリを作成することができるという点で極めてユニークなPaaSです。ドラッグ&ドロップと設定作業だけでかなりパワフルなアプリを作成することができます。要件がハマれば、いかにHTML, js, php, javaなどにとんがったプログラマーでも、このノンプログラミングの開発スピードにはちょっとかないません。

しかもこのノンプログラミングで開発されたアプリは自動的にモバイル対応します。iPhoneやAndroid端末でアクセスするとあら不思議、モバイルに最適化されたUIがあらわれます。シングルコードであらゆるデバイスに対応するレスポンシブはHTML5界隈では欠かせない手法になっていますが、このノンプログラミング開発では「レスポンシブ」という言葉さえ意識する必要がありません。勝手にモバイル対応UIが生成されるのです。

s1

ただし、こういったUIフレームワークを使うということはある程度規約・制約に縛られることになります。なのでUIに細かな要件が続出してきた場合、ノンプログラミング開発だけで対応するのは難しくなるというもの事実です。

ここで重要なのは、今作っているのはMVPであって、製品の最終形ではないということです。

あくまでもMVPは仮説を検証するものであり、それをベースに顧客からフィードバックを得ることが最大の目的です。そういう意味では、UIフレームワークを使って素早く基本機能を構築し、それをベースにユーザーから正しいUIの姿をヒアリングしてから最終UIの開発に着手しても遅くはないはずです。もしかしたら、「このままでOK」というケースもあり得ます。そうした場合にガッツリUIをコーディングしていたら「無駄」になっていまいます。常に無駄を最小限にすることを意識するのがリーン・スタートアップです。

そして最終的に完全にスクラッチからUIを開発する場合、Force.comはそのまま利用することができます。

現在モダンなHTML5アプリはSPA (Single Page App/Architecture)で設計されていることが多く、こういったアプリはjavascriptからバックエンド(多くの場合クラウドデータベース)にajaxコールをおこなうため、バックエンド側はAPIの整備が必須になります。

spa-api Force.comはデータベースのテーブルを作成した時点で自動的にそのテーブルに対するREST APIが有効になります。つまり基本的なデータベース操作であれば、APIは勝手に作成されるため開発者が作る必要はないのです。そのため、スタートアップ企業はこういったバックエンド側の開発作業から解放され、差別化要素となるUIに開発リソースを集中させることができます。資源が限られたスタートアップ企業であればこういった恩恵は大きいと思います。

CRMによるコホート分析とappexchangeによるスプリットテスト

コホート分析とは、売り上げやユーザー数の累計データではなく、ある一時点での新規売り上げ、新規ユーザー数を定期的に観察する分析方法で、スタートアップの成長エンジンが正しくチューニングされたかどうかを計測するのに有用な分析手法だとされています。

Force.com上でアプリを開発し、appexchangeにアプリを公開する場合、通常1ユーザー15000円/月のSales Cloud(CRM)のライセンスが2ユーザー分無料で提供されるのですが、このCRMを利用するとコホート分析をすぐにおこなうことができます。というのも、appexchangeとはアプリケーションを公開するマーケットプレイスであると同時に、誰がアプリのデモを試したのか、誰がインストールしたのか、誰がアクティベートしたのか、というような情報をフィードバックする仕組みを備えており、このフィードバックが自動的に先ほどのCRMに入ってくるのです。

appexchange feedback

つまりappexchangeにアプリを公開すると黙っていてもフォードバックのデータが蓄積され、それをCRMのレポート機能がすぐにコホート分析することができます。

また、appexchangeはスプリットテストをおこなう仕組みも備えています。スプリットテストとは、個別の機能拡張がユーザーにどのような影響を与えたのかを正確に計るために、1機能ごとにその新機能を組み込んだバージョンと組み込んでいないバージョンを同時提供し、1つのユーザーグループは新機能あり版、もう一つのユーザーグループは新機能なし版を使ってもらい、その反応の差分をみるという計測方法です。

split test

スプリットテストをおこなうには複数のバージョンを同時提供する必要がありますが、通常Webサービスは同じドメインで提供されるため、提供元は一カ所となり、ユーザー毎にバージョンを切り替えるのは簡単ではありません。

しかし、Force.comはWebサービスであるものの、ユーザー毎に専用の環境を提供するマルチテナント方式を採用しています。このため、開発者は能動的にユーザーをグループ分けして異なるバージョンを提供するということが簡単にできてしまいます。そして先ほどのコホート分析でそれぞれのユーザーグループの反応を計測することができるわけです。

ちなみに、Force.com上で開発したアプリを無償で提供する場合、appexchangeへの公開を含むすべてのプロセスで一切費用はかかりません。出展費用も、プラットフォーム費用も。全く出費することなくMVPを開発してマーケティングをおこなうことができるのです。ちょっとびっくりするようなスキームですが、ほんとの話です。

製品最適化と戦略転換(ピボット)

このステージではプラットフォームは利用しません。これまでに計測で得られた結果をもとに、組み込んだ新機能が正しかったのかどうか、製品を修正することが必要なのか、あるいは仮説・戦略そのものがあっていたのかどうかを見極めて、必要に応じて最適化と転換をおこなう決断をおこないます。


いかがでしょうか。

冒頭にも書きましたが、僕はリーン・スタートアップを知ったときにこの考え方はForce.comでの開発哲学に通ずる部分が多く、Force.comとappexchangeを利用することで、手作りする部分を少なくし、フィードバックループを速くまわすことができるはずだと考えています。リーンスタート・アップのコンセプトにSalesforceのアプリケーションPaaSは最適なお供でだと思います。

summary

ご興味をもたれた方はSalesforce丸の内オフィスで毎月開催しているappexchangeスタートアップトレーニングに是非参加してみてください。

without comments

Written by 中嶋 一樹

12月 8th, 2014 at 11:34 am