Meetup」の第2回が開催されました。スタートアップのエンジニアが求めるナレッジをキャッチアップ・共有し、F.O.Xの持つノウハウを公開することで業界をさらに盛り上げることを目的としている本イベント。今回は、F.O.Xのエンジニア2名が登壇し、トークセッションを行いました。はじめに登場した遠藤圭一氏は「スタートアップの分析用ログ設計について」というテーマでプレゼンテーションを展開。サービスの状態を正しく認知し、成長させるためのKPI設定と分析用ログの設計手法について知見を披露しました。遠藤圭一氏(以下、遠藤):みなさん、こんばんは。今日はお越しいただきありがとうございます。それでは私から、「スタートアップのKPIと分析用ログについて」を発表させていただきます。軽く自己紹介なんですが、私は遠藤圭一といいます。2012年にサイバーエージェントに中途で入社しました。サイバーエージェントには「サービスを100個つくるぞ」と言っていた時期がありまして、その時期の入社になります。その後アメーバに所属してまして、アナリストやiOSエンジニア、ビッグデータなどをやってました。2014年、アドテクをやりたくなったのでCyberZに異動してきまして、そちらでもビッグデータやiOS/AndroidのSDK周り、新規事業開発などを担当してました。スキルセットとしては、スライドにあるようなものを触ってきました。今日のアジェンダですが、大きく4点お話させていただきます。1つが、「エンジニアにとってKPIが必要な理由」。その後に「KPI設計の具体例と分析例」をお話しまして、次に「ログ設計のポイント」。最後に軽く「まとめ」をしまして、30分ぐらいで終わるかなと思っております。3、4年前なんですけど。(会場挙手なし)遠藤:やっぱりいないですよね(笑)。「アメーバで100個アプリをつくるぞ」って言っていた時期で、ペットの写真を投稿する「パシャッとmyペット」というアプリとか、あと「ミルチョ」というゆるキャラっぽいアプリとか、「アメーバ大喜利」というお笑いネタを投稿するアプリとか。いったサービスをたくさんつくってたんですが、こうしたサービス改善のアナリストをやっていました。今日はエンジニア寄りの方が多いと思うんですけども。KPI、もしかすると、なんかプロデューサーとかビジネスの人が、「KPIどうなの?」と言っていたり、ありますよね。「ちょっとうるせーな」とか、「数字ばっかり」とか、「KPIの意味わかってんのか」みたいな、そういうことがあると思います。「では、エンジニアにとってKPIとは何なのか?」という点についてまずは意識を合わせたいと思います。エンジニアにとってのKPIというのは、ストレートに言いますと「開発した機能をリリースして、どんな影響がユーザーに発生したか」。ユーザーの評価が直接反映されるものだと思います。エンジニアもKPIは常に意識しないといけない、ということですね。自分たちがつくった機能がユーザーにとって良かったのか、あるいは、サービスにとってメリットがあったのかということは、スタートアップのエンジニアはモチベーションの1つとして持っていると思います。KPIは常に理解しなければいけないし、意識しないといけません。はじめに結論をお話ししますが、今日お伝えしたいことは、「KPIを意識するのがスタートアップエンジニアの生きる道だよ」ということです。意識しないとどうなるかというと、お金がつきてしまって、サービスがクローズになってしまいます。サービスのゴールの達成のための「KPI大事ですよね」というところです。エンジニアとビジネスが対立しないためにでは、アジェンダにありました「KPI設定と分析」「ログの設計」について、具体的にお話したいと思います。......あ、ちなみに今回裏目標がありまして、いらすとやさんのイラストをなるべくちりばめるというのが裏目標です。(会場笑)けっこうこんな感じで、ゆるい感じで出てきますので、微笑んでいただければいいかなと思います。それで、サービス改善にありがちな失敗なんですが、これはたぶんみなさんあると思うんですが「あれもやりたい」「これもやりたいと」闇雲にリリースや開発を求められることが、エンジニアにとってはよくあると思います。その結果どうなるかというと、アメーバでもありましたが、ありがちなパターンとしてビジネスサイドとエンジニアサイドが対立してしまう。「あれ、つくれ」と、「いや、でも、そんなんつくれねーよ」みたいな感じでバチバチしてしまう。このパズルが合わない感じですね。「じゃあ、ビジネスとエンジニアでKPIを一緒に追いかけるにはどうしたらいいか?」ということで、分析。「ログが必要ですよね」という話になります。したの?」「いや、そんなログ出してません」ということが往々にしてよくあります。ビジネスサイドもエンジニアサイドもお互いに歩み寄りが必要で、ログを出すにはエンジニアサイドもKPIを理解していれば、「あ、出せますよ」みたいに、そういう感じでサラッと言えるので、お互いに幸せかなと思います。言うと、「いつ、誰が、何をしたか?」というログだけ出ていれば、ほぼ、8割ぐらいの分析ができます。カラム的には、日時、ユーザーID、OS/端末、アクション名、ユーザーの属性的なやつ。このへんがあれば、だいたいできます。このあたりは後で詳しく触れますので、少々お待ちください。ユーザーIDとユーザアクションが取れている前提で話をしていきます。適切なKPIとは何か?では、「適切なKPIとは?」ということです。ビジネス寄りの話になってしまうので眠くなるかもしれませんが、ここは大切なところなのて聞いてもらえればと思います。ソーシャルメディアサービスを開発しているというスタートアップがあった場合、どういったものをKPIにすればいいか、という例を用いてお話ししたいと思います。ゴールとしては、「日本No.1のDAUを誇るメディアをつくるぞ」と。「日本No.1のDAUがあれば広告で儲けることもできるし、たくさんのユーザーに使ってもらえていいじゃない」というところですね。そのサービスにはどういった機能があるかというと、会員登録して、チュートリアルを見て、フレンド申請をして、写真や日記を投稿して、スタンプの課金をするとか、あるいは個人メッセージを誰かに送れるなど、そうしたサービスを想定してもらえればと思います。「DAUはどうしたら増えるのか?」ということを考えます。ここで分解をしていきます。この分解という作業、エンジニアさんは得意な人が多いと思います。DAUとは何で構成されているかというと、その日登録したユーザー、つまり新規ユーザか、その日より前に登録したユーザー、つまり既存ユーザかの2種類に分かれています。新規ユーザーを増やす場合どうしたらいいかというと、こんな感じですね。テレビCMを打ったり、口コミを増やしたり、広告を出したり、というところです。サービスがおもしろいとたぶん寄ってくるだろうと。した中毒性のある人をどんどん増やしていけばいい、ということですね。「では、このDAUを増やすために、KPIは何を追えばいいのか?」というところです。DAU自体はKPIとしてあまり適切じゃなくて、非常に追うのが難しいです。わかりますかね?はい、「継続率」です。この絵は我慢している様子で中毒性を表しています。「なぜ継続率を追うのがいいか?」というところなんですが、ユーザーが定着しないとDAUは増えないんですね。これは架空のサービスなのですが、DAUはどんどん増えています。これをみて、「すごい伸びてるサービスじゃん」と思ってしまうんですが、よくよく色分けを見てみると、下の薄い青の部分は、全部当月の新規ユーザーです。広告を出して、どんどんユーザーを入れてるんだけども、先月のユーザーや過去のユーザーが定着してくれない。この場合、継続率を上げてユーザを定着させることが大事です。アクション別の継続率を分析するでは、どう使うかということで、3点事例を紹介したいと思います。1つ目が、アクション別の継続率です。先ほど「アクションのログに取りますよ」と言いましたが、「どのアクションが継続率に影響があるか?」を見ていきます。これは逆に言えば、「ユーザーに何をしてもらえば、継続率が高くなるか?」ということです。ここから数字がいくつか出てきます。これを見ると、起動した人のうち1,000人中900人は会員登録をしてくれてるので、「けっこういいじゃん」と思ってしまうのですが、写真投稿が少ないですよね。写真投稿してくれる人の翌日の継続率は80パーセントです。この場合、写真の投稿をさせるための改善をすることで継続率を伸ばしていきます。逆パターンとして、「アクションしなかった継続率ってどうなの?」が気になります。特定のアクションをした/しないで、なにか違いはあるでしょうか?先ほどのフレンド申請のところくを見てみると、フレンド申請をした人の継続率は40パーセントでした。しない人も40パーセントです。別にユーザがアクションをしてもしなくても継続率に関係しません。いうことは、プロデューサーから「フレンド申請、もっと良くしていこうよ」と言われても、「いやいや、継続率が一緒なので、ここをがんばって開発しなくてもいいですよね」という話ができます。いった話をするためにログが大事ですよね。ログがあって比較できれば、「してもしなくても一緒なら、他の機能を直そうよ」って言えますね。継続率を使ってユーザー層を分析する次に、継続率を使ってユーザー層を見てみます。継続率が取れてると、DAUやMAUの構成がわかってきます。MAUというのは、「月にいたユーザーのUU」です。これも架空のサービスですが、1月にリリースしたサービスで10月までのMAUの推移を示しています。9月、10月でだいぶ伸びていますね。2月、3月の継続率は20パーセントぐらいだと思ってください。下の薄い青い部分は、広告で集客した新規ユーザーです。新規がぜんぜん残らなくて、全体のMAUが伸び悩んでいますね。「それじゃあいかん」ということで、4月、5月で広告を停止して、サービス改善に注力しました。その結果、6月に継続率は50パーセントに上がりました。この後、5、6、7、8月で既存ユーザーの割合がどんどん増えています。この状態になれば、新規ユーザーが増えても、ユーザーが定着してくれます」。そこで、9月、10月で広告を再開、例えばテレビCMを打ったとします。その結果、ユーザーがどんどん増えていきました。継続率の改善が、DAUやMAUの上昇に非常にメリットがある、ということがわかります。KPI設定の3つのポイント先ほどの3つを踏まえて、KPI設定のポイントです。プロデューサーからKPIと言われた時に、このポイントに合っていなかったら「ちょっとおかしいんじゃないの?」って思ってみてください。1つ目が「コントロールできること」ですね。最初に、「DAUはコントロールできない」というか、「KPIとしては難しい」といいましたが、DAUというのは結局ユーザー次第で結果の話なので、サービス側でのコントロールが難しいところがあります。継続率であれば「どういったユーザーが継続してくれるか、くれないか?」といった分析ができます。そのうえで施策を打ち出し継続率を改善することができるので、KPIとして追いやすいものになります。2つ目は「計測できること」です。比較できるということです。なにか新しい機能をリリースした前後で、「継続率が変化したよね」とわかれば、比較ができるようになります。継続率が下がっちゃった場合は、すぐに過去の機能に戻すという選択もぜんぜんアリです。その切り分けができるか素早くできるかどうかが非常に大事です。3つ目が、DAUに対する継続率のように、ゴールとつながっている指標を選ぶ必要があります。適切なKPIを選ぶことはけっこう難しくて、KPIとサービスのゴールがぜんぜん違っていたりすることもあります。この状態だと、サービスにとってもエンジニアにとっても残念な開発が増えてしまいます。「僕たちは何をつくってて、何をユーザーに提供しているのか?」ということをしっかり認識することが大事かなと思います。どのようにログを設計すべきか?次は「分析とログ設計について」です。「KPIって大事だよね」という話をしたうえで、「エンジニアサイドとして、ログ設計はどうしたらいいのか?」というところを、お話できればと思います。「分析用のログはどう使われるのか?」というところです。分析ではExcelを使ったりはするんですが、最初にもお話しましたとおり、ログがキモになります。「このログだけあれば大丈夫」ということを、まずお話したいと思います。これは最低限なんですが、基本的には「いつ、誰が、何をしたか?」が取れていれば、ぶっちゃけ後でどうにかなります。3番目の「iOSなのか、Androidなのか、あるいはWebのユーザーなのか?」も大事です。4番目がアクションです。「ユーザーが何をしたか?」というところです。おすすめとしては、後でサンプルを出しますが、アクションとサブアクションと、金額、特別なパラメータみたいなもの。このあたりを取っていればある程度なんとかなります。最後に「誰が?」というユーザーの属性的なものは、プレミア会員や性別など、そのへんがあればいいかなと思います。プラスアルファで、UserAgentやリファラがあってもいいですね。「どこのページを見た人が何のページを見たのか?」です。あと、インストール日や性別、あとはサービスに特有なレベルや、ランクなど、そのあたりもあれば非常に深い分析もできます。ログを取る時迷ったら、「うちのサービスでユーザーは何をしてるのかな?」ということをイメージするといいですね。基本的に、ゲームでもソーシャルサービスでも、ユーザー登録をしてログインして、なにか画面を見て、写真撮ったり、お金払ったり。基本的にこの4つがメインのアクションになると思います。実際にサンプル的に書いてみたんですが、日付、ユーザーID、OS、アクション、オプション、金額、属性、のログを作ってみました。BYで大まかな集計ができます。ログ設計の3つのポイントこのログなんですが大事な3つのポイントをお話ししたいと思います。1番、「迷ったら取る」ですね。取っていないと、そもそも分析や比較ができなくなります。取っておいたほうがいいんですが、そこで問題になるのが「お金がかかる」って話ですよね。「ログを取る量が増えるとお金がかかっちゃうね」と。そこはお財布と相談なんですが、ユーザー見えの機能レベルは最低限取ったほうがいいと思います。取る時にポイントがあって、粒度が細かすぎると分析しづらくなってしまいます。