少し前、スタートアップのための実践的なデータ分析といった趣旨であるLean Analyticsという本を読みまして、これが素晴らしかったのです。

lean analytics

「僕みたいな小規模のアプリだと、たいしたデータ量もないんだし、分析なんて参考にならんでしょ、初期段階はユーザーフィードバックだけでOK!」と以前は思ってたんですが、間違ってました。

直接ユーザの声を聞く定性的なフィードバック、データを使った定量的な分析、アプリをよいものに改善していくのには、どちらもすごく大切で、おろそかにできないなと最近は実感しております。

ポールグレアムも、ちゃんと計測しろみたいな事を言ってましたね。

Webのマーケティング担当者からすると当たり前の事かもしれないけど、とりあえずLeanとつけるバズワードに乗っかろうと思います。

Lean Analyticsってどんな本?

数々のスタートアップを経験してきたAlistairさんとBenさんが、スタートアップのための実践的なデータ分析において、どう見るか、どう改善につなげるかを、様々な例を上げながら説明していく本。

リーンスタートアップで有名になったエリックリースも監修してる。

僕は、ABテストを事あるごとにしてたら意思決定が遅くなるし、そもそも、重要なビジネス上の方向性やUIの方針なんて、データを見て多数決で決めるものじゃないだろうと思っております。

まず人間が考える仮説があって、それを検証したい時にABテストが、そのコストに見合うだけの時間と労力が取れるならやればよくて、とりあえず意見が分かれたら、なんでもデータで判断しようという姿勢はよくないという考えなのです。

でも、この本は、ちゃんと、そういう部分もしっかり書いている。大きな視点や仮説は人間の頭で考えるべきであり、データにとらわれてはいけないという本で、凄くよかった。

とても印象的だった文章が、ここ。

データは中毒性があり、すべてを分析したくなるかもしれない。でも、実際に私たちがする事のほとんどは、無意識であり、経験や実践が土台になる。

実際に、精密な分析より、経験や知恵に頼る事は道を開く鍵にもなる。

結局のところ、毎朝、着ていくパンツは何にするかをABテストしていたら、いつまでたっても家から出られない。

リーンスタートアップへの批判として、あまりにもデータドリブンすぎるという意見があるが、ある意味、的を射ている。

大きな視点を持たずに、データだけで意思決定をするのは危険だ。データに捕われるのではなく、データを参考にするようにしないといけない。

ちなみに、Lean StartupもRunning Leanも邦訳が出ているけど、この本は出てないのが残念なところ。

細かい説明や実際の例も豊富なんだけど、すべて紹介していたらきりがないので、重要だと思った部分を4つ書いてみる。

虚構の数字(Vanity Metrics)に注意

見てて気分はよくなるけど、それを見て、何をどう改善すればいいのかが分からない、実際の行動につながらないのが虚構の数字。

ダウンロード数や、アクティブユーザー数などは増えると喜んじゃう分かりやすい数字だけど、それに惑わされてはいけない。

例えば、ダウンロード数だけ見ても、それは何が原因でダウンロードが増えたかが分からないと、どう改善すればよいかもわからない。

ダウンロード数が多くても、ほどんとの人は起動してすぐに離脱しているかもしれない。

アクティブユーザー数であっても、時間がたてば自然と増えていくものなので、それだけでは参考にはならない。

数字を見た時は、これを知って、自分はなにか改善に繋がる行動をできるかどうか。ここを常に意識する。

注意する虚構の数字の例として、ヒット数、PV、ユニークビジター数、Like数やフォロワー数、ダウンロード数などがあげられてた。

行動につながる数字(Actionable Metrics)を見る

実際の行動に繋がらない数字より、それを知って、なにか改善に繋がる行動が起こせる数字を見る。

その一例として、全体数よりも、割合(パーセンテージ)をあげてます。割合はシンプルで、比較できて、取りやすい。

例えば、ユーザ登録が必要なサービスで、その部分のUIを改善してアップデートしたら、以前のバージョンと新しいバージョンで、総数ではなくて、パーセンテージがどう変わったかを比較する。

これは別に数字とかだけじゃなくて、いろいろな事に繋がるなと思った。

なにかを研究したり調べたりする時に、最終的にふーんとだけにならず、実際の行動が変わるかどうか、変わったか、ここを結構意識するようになった。

改善すべき指標は、重要なもの一つに

サービスが初期段階か成熟期かで、重要な指標が変わる。

例えば、会員登録のステップを改善したい段階なら、そこだけに集中する。アプリへの定着率や購入率など、いろいろな部分に手を出さずに一つに絞って改善する。

今現在どこが一番重要な部分かを考え、一つに絞る。

でも、最初はどこが一番重要なのかも検討がつかないですよね。

なので最初は仮説から入るしかないし、いろいろな指標をチェックしたり、全方位でフィードバックを聞くしかない。

自分は、アプリのステージによって、どこを優先してアップデートするかを意識して開発するようになりました。

例えば、最近出した音声文庫という青空文庫読み上げアプリでは、”まずは、初めてアプリを開いた人が、どんな小説を読めばいいかを助けるオススメ部分を強化する。”という点に絞ってアップデートしました。

想像もしてなかった事への気づき

製品を開発している時に重要な、2つの要素。

1 自分が知らないと知っている事
2 自分が知らないと、自分でもまだ知らない事

例えば、1の例だと、自分がそれを知らないけど、重要だと分かっていて知りたいと思っている事。

アプリを使い続けてもらっている割合とか、ユーザ登録や有料版へのコンバージョン率など、どうしたらそれらを改善できるか。

こういうのは自分の頭の中で重要だと思っていて、知りたいと分かっている。

2は、重要なんだけど自分がまだ想像もしてないことで、まだ気づいてない事。頭の中で想像もしてないから、自分からは調べたりはせず偶然発見するしか道がないもの。

これはデータ分析に限らず、ユーザーフィードバックからでもひょんな事から想像もしなかった事を発見する時は多い。

例えば、僕のVoicepaperだと当初は自分が読みたい本を耳で家事洗濯中に聞きたいから作ったんだけど、アプリのフィードバックでいろいろな使い方がされている事がわかったりした。

自分で書いた文章の誤字チェックに使ってますとか、英語学習に耳で聞きながら読んでますとか、青空文庫の小説を聞いてますとか、数々の驚きの発見が。

こういう偶然の発見が発生しやすいような状況に持っていくのがとても大切なので、そういう意味でも、とにかく早くリリースして学びながら改善するのは大事だなと思っています。

英語ではLearning by shipping とか言うらしい。カッコいい。

アプリでの実践

というわけで、勉強した事を参考に、どうアプリの改善に繋げていったかを今度の勉強会で話す予定です。

ボトルネックをどう発見して、UIを改善して、どう検証したかの話。間違っていた数々の直感の話。

ユーザーフィードバックを出来るだけ聞いて、リリースしながら学んでいくために気をつけている事とか。

僕のアプリは特に有名でもないしスタートアップでもないですが、この発表では、本を読めば分かる事ではなく、実際に体験した実例を中心に話したいと思っています。もしよければ。

「Lean Analyticsとアプリの話」(9月6日金の勉強会)

参考記事

アプリに組み込むヘルプサービス、Helpshiftがいい
iPhoneアプリのクラッシュレポートCrashlyticsが最高すぎる
一番リスクの高い部分から始める


*家計簿読み上げのアプリ作ってます。自己紹介と過去ログはこちら