rackhub
lean startup
fluxflex

Rackhubに見るリーンスタートアップの実践手法

次の記事

クラシファイド広告のジモティーが1.5億円をKDDIなどから調達

編集部註:この記事を書いてくれた久保渓氏(@keikubo)は、サンフランシスコで活動するfluxflexのCEOで、面倒なサーバー構築の手間を削減した環境構築済みの開発サーバーを提供する『Rackhub』を運営している。今回はRackhubの開発、運営経験からどのようにリーンスタートアップの手法を取り入れているのかについて説明してもらった。

エリック・リースのリーンスタートアップでは、構築(Build)-計測(Measure)-学習(Learn)というフィードバックループを、スタートアップにおける重要なサイクルだと位置づけている。具体的には、スタートアップが取る一つ一つの行動に対して、まずその行動によって期待できる効果を仮説として定義し、適切なデータを収集し、定義した効果が得られたかどうかをデータを基に検証するという一連のステップを何度も繰り返すことになる。

しかし、仮説の定義、データの収集、データの検証というそれぞれのステップを、実際に自分自身のサービスに適用するのは大変難しい。

なので、今回は筆者が運営するRackhubの実例をユースケースとして紹介することで、読者の方に具体的なリーンスタートアップの適用方法を考える上での一つの指針を提供したいと思う。

Rackhubとは?

筆者が運営するRackhubは、一言で言うと『環境構築済みのVPS』で、今年の3月から少しずつテストを開始し、5月に正式ローンチしたばかりの新サービスだ。

サーバー環境や開発環境の構築というのはとても大変で、今まではHerokuやfluxflexのような独自仕様の固まりかつブラックボックスなサービスにすべてを任せるか、数日かけて一からVPSやEC2などのサーバー上に自分で構築するしか方法がなかった。

Rackhubは、そのようなサーバー環境の構築作業に面倒さを感じている開発者がターゲットで、ベストプラクティスが詰まった設定済みの開発サーバーを提供している。

たとえば、Rubyであればrvmが、Perlであればインストールが面倒な大抵のCPANモジュールが、またPythonであれば初期状態からpythonbrewがインストール済みとなっている。さらに、MySQL, Apache, Nginx, MongoDB, Erlangなども最初からある程度きちんと設定された状態で準備されている。

またRackhubのユーザーは、コラボレーター機能によって知り合いを簡単に自身が所有するRackに招待することができるため、共同作業や複数人開発にも向いている。

これらのサーバー(Rackhub上ではRackと呼んでいる)を、紙コップのようにすぐに使い始めることができ、思う存分遊び、簡単に捨てられる、取り回しの良さがサービスの魅力だ。

現在のところRackhubは、サービスの持続的な成長を描くために、まずはコアなユーザー体験を作り込む作業に注力しており、下で紹介するさまざまな手法を用いてサービス改善を進めている。

まずはコホートグラフによる検証

まず、サービス改善のためのデータの収集・検証においては、The Lean Startupの第7章で紹介されているコホート分析を使用するのが一般的だ。

コホート分析では、サービスのコアと密接に結びつく重要なユーザー行動を定義した上で、そのデータを定期的に収集してサービス改善の正当性を検証する手助けとする。

定義するデータは、RackhubではDave McClureが彼のブログで提案しているAARRRを使用している。AARRRとは、サービス運営上重要になる以下の5つのユーザー行動の頭文字を取ったものである。

  • Acquisition: 登録する
  • Activation: 使い始める
  • Retention: 使い続ける
  • Revenue: お金を払う
  • Referral: 友達に広める

この5つの指標の重要度はサービスによって違いがあるが、RackhubではRetentionとRevenueを特に重要視し、ユーザーがサービスを使い続けようとしているか、そしてお金を払い続けようとしているかを常に注視している。

具体的にRackhubでは、上記の5つの指標を以下のように定義している。また実際にこの定義したデータを集計して図に示したのがその下のグラフである。

  1. Acquisition: 登録ユーザー(グラフ上では緑)
  2. Activation: クレジットカード登録ユーザー(グラフ上では薄オレンジ)
  3. Retention: 試用rack所有者とコラボレーター(グラフ上ではオレンジ)
  4. Revenue: 課金ユーザー(グラフ上では薄水色)
  5. Referral: コラボレーターがいる課金rack所有者(グラフ上では水色)

3月の第二週に緑色のAcquisition以外が40パーセント付近まで落ち込んでいる地点がRackhubの一般公開日で数値の基準点となる。

新機能の追加やマーケティングの実施等のスタートアップのあらゆる行動は、このグラフのどこかの色を拡大させるであろうという仮説のもとに、意図を持って提供され検証される。

例えば、3月末に一度Rackの在庫が切れ新規Rackの受付を停止したことによりRevenueユーザーが激減した。Revenueの割合は新規受付を再開したらまた増えるだろうという仮説を持っていたが、それはきちんとグラフにも現れている。

5月第一週には、ログイン後のダッシュボードページにあるRackのリストにメンバー一覧をアイコンで表示する機能追加を行った。これによってコラボレーター機能の存在が推されることで、ReferralとRetentionの割合が拡大するという仮説を持っていたが、確かにRetentionは拡大したが、ページがごちゃごちゃになり見にくくなったとRackをすでに所有しているユーザーからは不評で動線が曖昧になったこともあり、実際にRevenueの割合が極端に減ってしまった。結果として、この機能はすぐに取り下げた。

5月第二週には、プレスリリースを打ってトラフィックを増やせば、単純にRackhubに興味を持ったユーザーの流入が増えることでグラフのそれぞれの割合は維持しながらユーザー数がスケールするだろうという仮説を持っていくつかプレスリリースを打ってみた。しかし、結果はRevenue, Retention, Activationが落ち込み、試してもくれない単なる登録ユーザーが増えるだけの結果に終わり失敗だった。

その次の週の5月第三週には、既にRackhubを使用したことがあるRRR層(Retention, Revenue, Referral)に属するユーザーに個別に招待状を送付して第一回Rackhub座談会を開催した。これによって運営側のサービスコンセプトが伝わることでコラボレーター機能の利用率が増加し、RetentionとReferralが拡大するだろうという仮説を持っていたが、結果はAcquisition以外の4つの項目すべてが拡大し、仮説以上の好結果が得られた。

このように、新機能の追加やUIの変更だけでなく、イベントの実施やプレスリリースの送付などのあらゆるスタートアップのアクションは、期待する効果を仮説として定義し、データを収集し、データを基に仮説の正否を検証される。これによって、直感に頼ったり声の大きい人の意見に偏って従ったりすることがなくなり、客観的な指標を基に明確な意思を伴ったサービス改善が継続的に行えるようになるのがリーンスタートアップの大きなメリットだ。

コホートグラフの問題点

データの収集において上記で示したAARRRを基準としたコホートグラフは優秀ではあるが万能ではない。まず、Acquisitionにさえ至らなかったユーザーが抱えている障壁を知ることはできない。そしてRevenue/Referralまですでに至ってしまったユーザーが、継続的に満足しお金を払い続けようとしているのかそれとも飽きてきているのかを把握するのも難しい。

そこでRackhubでは、Acquisiton以前のユーザーに対してはA/Bテストを使用し、Revenue/Referral以降のユーザーに対してはユーザーインタビューを行うことで、サービス改善の手助けとなるデータを収集して仮説の検証に役立てている。またそれらに加えてRackhubでは、Acquisition以前からRvenue/Referral以降までのすべてのフェーズを横断的に見るために、Mixpanelを補助的に利用している。

細かいUXの改善にはA/Bテストが有効

A/Bテストとは、サイト内の文面やボタンの色や配置、動線等を複数パターン用意し同時並行して検証することで、推計的有意性を検証するウェブサービスの改善において一般的な手法である。

A/Bテストを簡単にするサービスとしては、OptimizelyGoogle Website Optimizerが有名だ。

たとえば下の表は、Google Webiste Optimizerを利用してRackhubのトップページをテストした際に、見出し部分の文面をいくつかのパターンに変えながら検証した結果である。検証は、新規訪問者のサインアップ率によって計った。

基準となったオリジナルのバージョンでは下のスクリーンショットの通り、見出し部分には『最先端で最適な環境を求める開発者のためのホスティングプラットフォーム』という文面を掲載していた。

見出し部分をいくつかのパターンを試しながらテストしてみて、もっとも評価が高かった見出しは、『あなたのための、クラウド上のlocalhost。 10秒で使える設定完了済みの開発サーバー 』という文面だった。単純にこの見出し部分を変更しただけで、サインアップ率がほぼ倍になった。ちょっとした細かい文面の変更ではあるが、それでも結果には大きな違いが出ているのがわかる。

見出し部分の変更の以外にも下のスクリーンショットのように、ボタンの色を赤、灰色、シルバーの3色でどれが一番クリック率が高いか計測したり、ボタンの配置をヘッダーや本文、サイドバーなど場所を変えながら試してみたりと、A/Bテストは細かいUXの改善の際に効率の良い手法である。

ユーザーインタビューによる検証方法はまだ模索中

今回紹介している手法はほとんど定量分析(quantitative analysis)であるが、ユーザーインタビューは定性分析(qualitative analysis)である。ユーザーインタビューは特に時間がかかるもので、プロダクトがない状態や実際に使用してもらっていない状態での仮定の話ではなかなか否定的な意見を言ってもらえないという問題がある。また、否定的な意見をもらった場合でも、本当にその人がターゲットユーザーなのかどうかを知ることは難しい。

そのような問題を抱えているので、Rackhubではユーザーインタビューは、実際にRackhubでRackを起動して利用したことがあるユーザーや、特にお金を払ったことがあるユーザーの意見を拾い上げることに限定して行っている。課金ユーザーは特に、Rackhubの魅力を理解した上で自分なりの意見を持っており、提案する改善点も具体的な場合が多いので、定性分析が非常に有益だと感じている。

実際に先ほど上で紹介したRackhubの座談会では、Rackhubを使ったことがあるがすでに使用を止めてしまったユーザーや、お金を払いつつも満足していないユーザーの率直な意見を聞くことができ、サービス改善の指針として大変大きな意味を持った。

加えて、定型的なユーザーに対する質問集のようなものを用意し、メールやアンケートフォーム、対面などに関わらず構造的インタビューを実施することもある。

ただやはり、統計的な定量分析に比べインタビューなどの定性分析は、データの検証に自分自身のバイアスがかかることも多く、RackhubではまだまだRevenue/Referralユーザーの声を適切にサービス改善につなげる方法を模索中である。

曖昧さや属人性を排除する

リーンスタートアップで重要視されているのは、コホート分析にしてもA/Bテストにしても、曖昧な直感を盲目的に信じるのではなく、データをきちんと定義し、0/1もしくはtrue/falseでスタートアップが取る一つ一つの行動を検証していくことで、スタートアップをサイエンスにしていく取り組みだ。

仮説を具体的に定義し、データを収集し、それを検証する一連のループは、スタートアップのチームメンバー全員が同じ判断基準に沿って物事を考えるきっかけを与えてくれるので、議論から曖昧さや属人性を排除することができ、本当にユーザーに取って利益のあるプロダクトを開発することに集中させてくれる効果がある。