エンジニアとビジネスサイドの対立を未然に防ぐ　正しいKPI設定＆分析用ログ設計のコツ

スタートアップエンジニアが知っておくべき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とは何なのか？」という点についてまずは意識を合わせたいと思います。

エンジニアにとってのKPIというのは、ストレートに言いますと「開発した機能をリリースして、どんな影響がユーザーに発生したか」。つまり、ユーザーの評価が直接反映されるものだと思います。

つまり、エンジニアもKPIは常に意識しないといけない、ということですね。自分たちがつくった機能がユーザーにとって良かったのか、あるいは、サービスにとってメリットがあったのかということは、スタートアップのエンジニアはモチベーションの1つとして持っていると思います。KPIは常に理解しなければいけないし、意識しないといけません。

はじめに結論をお話ししますが、今日お伝えしたいことは、「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を使ったりされている方って、いらっしゃったりしますか？　分析ではExcelを使ったりはするんですが、最初にもお話しましたとおり、ログがキモになります。「このログだけあれば大丈夫」ということを、まずお話したいと思います。

これは最低限なんですが、基本的には「いつ、誰が、何をしたか？」が取れていれば、ぶっちゃけ後でどうにかなります。

3番目の「iOSなのか、Androidなのか、あるいはWebのユーザーなのか？」も大事です。

4番目がアクションです。「ユーザーが何をしたか？」というところです。

おすすめとしては、後でサンプルを出しますが、アクションとサブアクションと、金額、特別なパラメータみたいなもの。このあたりを取っていればある程度なんとかなります。最後に「誰が？」というユーザーの属性的なものは、プレミア会員や性別など、そのへんがあればいいかなと思います。

プラスアルファで、UserAgentやリファラがあってもいいですね。例えば「どこのページを見た人が何のページを見たのか？」です。あと、インストール日や性別、あとはサービスに特有なレベルや、ランクなど、そのあたりもあれば非常に深い分析もできます。

ログを取る時迷ったら、「うちのサービスでユーザーは何をしてるのかな？」ということをイメージするといいですね。基本的に、ゲームでもソーシャルサービスでも、ユーザー登録をしてログインして、なにか画面を見て、写真撮ったり、お金払ったり。基本的にこの4つがメインのアクションになると思います。

実際にサンプル的に書いてみたんですが、日付、ユーザーID、OS、アクション、オプション、金額、属性、のログを作ってみました。このようなログ設計にするとExcelでも分析できますし、SQLを叩く時も、SELECT COUNTとGROUP BYで大まかな集計ができます。

ログ設計の3つのポイント

このログなんですが大事な3つのポイントをお話ししたいと思います。

まず1番、「迷ったら取る」ですね。取っていないと、そもそも分析や比較ができなくなります。なので取っておいたほうがいいんですが、そこで問題になるのが「お金がかかる」って話ですよね。「ログを取る量が増えるとお金がかかっちゃうね」と。そこはお財布と相談なんですが、ユーザー見えの機能レベルは最低限取ったほうがいいと思います。

かつ、取る時にポイントがあって、粒度が細かすぎると分析しづらくなってしまいます。そこで階層構造を意識してみてください。大項目、中項目、小項目というイメージです。

こんな感じですね。なんでこういうほうがいいかというと、ページIDなど、すごく細かい粒度のの分析は実はあまりしなくて、8割ぐらいは「何人がどのカテゴリのページを見たか？」の粒度、つまり大項目、中項目レベルで分析することがほとんどです。

機能追加をしやすくしておかないと地獄になる

次は、「誰が、いつ、何をしたか？」というところです。先ほどからお話ししているとおり、分析においては比較をすることが大切です。「新機能リリースした前なのか、後なのか？」「テレビCMの前なのか、後なのか？」「広告出した前なのか、後なのか？」。

昔アメーバでよくあったのが、「新しい機能リリースしました。分析してください」と言われたんですが、ログが出ていないということがけっこうありました。結局、比較ができないわけですね。その機能をリリースしたことで継続率が伸びたのか、課金が伸びたのか、まったくわからない。なので、大きな機能をリリースする時には、同時にログを出すようにしたほうがいいです。

加えて、ログの追加やログの集計をしやすく設計しないとダメです。スタートアップの場合、結構頻繁に機能追加があると思います。1週間に1つ2つと、リリース回数が多いと思うんですが、ログの追加をしやすくしておかないと、本当に地獄になってしまいます。

これ、地獄の絵です。いらすとやさん、なんでもあってすごいですね。

（会場笑）

ログの集計基盤ですが、自前でつくるのもいいと思いますが、時間がなければ、Google Analyticsなど、外部ツールを導入して、分析できる環境をつくる方が良いです。やはり自前で集計基盤を構築すると結構時間がかかります。サービスが拡大するまではお金を払って外部サービスで担保する、という選択もサービス改善にとって大事だと思います。

スタートアップエンジニアが大切にすべき3つのポイント

そろそろまとめになります。まとめも3点ございまして、1つ目は最初からお話ししていますとおり、「エンジニアもKPIを意識しよう」ということです。それがスタートアップの生きる道です。

やはり「自分たちでサービスをつくって成功しよう」というスタートアップエンジニアのみなさんだと思いますので、「本当につくっているものがユーザーに喜ばれてるのか？　ニーズに合ってるのか？」というところを、大事にしてほしいと思っております。

2つ目が、「分析は比較」ですね。「リリース前後でどう変わったのか？」。ここだけできれば、分析としては成り立ちます。

多変量解析など、難しい分析手法を使ったほうがいい場合もありますが、基本的には「リリースをした前と後で、継続率がどう変わったか？　売上がどう変わったか？　それはなぜか？」を掘り下げていく。非常に地道ですが、丁寧に見ていくことが大事だと思います。

最後は「大事なことにリソースをつぎ込みましょう」。最初にお話しした、「あるアクションをしてもしなくても、継続率一緒だよね」という場合に、「じゃあ、それって本当にやる必要あるのか？」という。

選択と集中と言いますが、本当に自分のサービスに必要なところに集中するために、分析やログを使って、選択と集中をしてもらえればと思います。

以上です。ご清聴ありがとうございました。

（会場拍手）