「KPI設計をお願いされたけど、どう設計すればいいのかわからない」
「KPIを設計したはいいけど、どう運用すればいいのかわからない」
KPIを設計・運用する上ではよくある悩みです。
今回は、Voicyでデータアナリストをしているたからっちが意識しているKPIの設計・運用方法について書いていこうと思います。
※設計時に意識していることに関しては、元メルカリのデータアナリストチームのヘッド樫田光さんが書かれているnoteを拝見して、「まさにこれを意識したい！」と思ったことを備忘録的に自分なりの解釈や例を交えながらまとめたものになります。 樫田さんのnoteはどれも非常に学びが多く実務に役立つ情報が多いので、ぜひ見ていただきたいです。 note.com
KPI設計時に意識していること5つ
KPI設計時に意識していること5つは以下の通りです。
- データ的な正しさ
- 定性的な正しさ
- 会社方針的な正しさ
- 計測のしやすさ
- 施策の考えやすさ
データ的な正しさ
1つ目は、データ的な正しさです。
例えば、ニュースアプリなどでサブスク会員数をKGIにおいてブレイクダウンしたKPIを設計した際に、そのKPIを上げることでサブスク会員数が増えるかどうか、というような観点を意識しています。
KPIを設計するということは、そのKPIを上げることで実際にゴールとしておいているKGIの指標も上がるという前提があります。
もちろん、複雑に様々な要素が絡み合ってKGIは動くことが多いので、実際は必ずしもKPIが動いたらKGIも連動して動くことばかりではありませんが、もしKPI設計段階でデータ的な正しさを見れるのであれば見ておきましょう。
意識：データ的に、そのKPIが動くことでKGIも動くかどうか
定性的な正しさ
2つ目は、定性的な正しさです。
先に見たデータ的な正しさだけで、うまく運用することは非常に難しいです。なぜなら、実際に施策を考えて動くのは人間だからです。
例えば、ニュースアプリのKPIを考えるデータアナリストが「アプリ上で特定のキーワードで検索しているユーザーのサブスク登録率が高いので、そのキーワードで検索するユーザー数をKPIにしましょう！」といった場合、企画や開発をするメンバーは動いてくれるでしょうか？
「そのキーワードで検索するユーザーは目的があってそのキーワードで検索しているはずなのに、その目的がない他のユーザーにもそのキーワードで検索してもらうことに意味があるのだろうか？」という声が聞こえてきそうです。（※もしかしたら意味があることもあるかもしれませんが）
企画を考えたり実際に開発をするメンバーの納得感が弱いまま施策を進めることは難しいです。
もし、そのデータアナリストの力が強くて周りのメンバー全員を説き伏せて進めたとしても、いずれうまくいかなくなる可能性の方が高そうです。
データ的な正しさは大切ですが、納得感という定性的な正しさも大切です。
意識：そのKPIを向上させることで、KGIが上がる納得感があるかどうか
会社方針的な正しさ
3つ目は、会社方針的な正しさです。
これはちょっと例が難しいですが、例えば、ニュースアプリを運営している会社があってメインのユーザー層が40代になっているとします。そして、今後のマーケット拡大を考えて20代や30代のユーザーを増やしていきたいという会社の方針があったとします。
その際にもし、データ的には40代のユーザーが多いことがわかっているので、40代によく読まれるような記事を増やすことが継続率にも効果がありそうということで、40代向けの記事数をKPIに置いたらどうでしょうか？
確かに40代の継続率は上がるかもしれませんが、今後会社が目指している20代や30代のユーザーを増やしていきたいという方針とは少しずれたKPIになってしまっています。
会社レベルのKPIは経営陣が設計し現場レベルのKPIはメンバーが設計するという場合もあるかと思いますが、その際は会社方針的な正しさがあるかどうかを意識できるとより良いKPIになります。
ただ多くの場合は、現場レベルでKPIを設計したとしてもさらに上のレイヤーに確認をしていることが多いと思うので、そこまでずれたものになることは少ないかと思います。
意識：会社の方針とも大きくずれていないかどうか
計測のしやすさ
4つ目は、計測のしやすさです。
例えば、とあるKPIを置いたとして、アンケートで回答を得て計測する必要がある場合を考えてみましょう。
そのアンケートが、気軽に取れるかつノイズが少なく精度の高い回答を得られるアンケートであればまだ良いですが、多方面に配慮しつつ頻度も半年に一度くらいしか取れずノイズも多いようなアンケートであれば、そのアンケート結果をKPIに使って運用を進めることは難しくなります。
計測をするデータアナリストも、アンケートを作成する他チームのメンバーにとっても負担が大きくなりあまり健全な状態ではありません。
できるだけ計測がしやすいKPIを設計するように心がけたいです。
意識：頻度よく、負担が小さく、正確に測れるかどうか
施策の考えやすさ
5つ目は、施策の考えやすさです。
例えば、ニュースアプリで継続率向上をKPIに置いていたとしましょう。
そして、上司やKPIの進捗を管理する他チームのメンバーからそのまま「継続率を上げるための施策を考えてください」と頼まれたらどうでしょうか？
（継続率を上げる施策？？？）
（ゲームだったらログインボーナスがあるし、それを自社のアプリにも追加して継続率向上を目指すか？？）
（プッシュ通知をたくさん打つか？？）
（あれ、継続率を上げる施策ってなんだっけ？）
と、なりかねないですよね。
継続率向上自体をKPIに置くことはそんなに稀なことではなく結構あることだと思いますが、その場合は、さらにブレイクダウンしたKPIを置くのがおすすめです。
例えば、継続率アップのためには、アプリ登録初日に〇〇を経験することが重要だと分かったので、アプリ登録初日の〇〇実行ユーザー数をKPIにする、などのイメージです。
そうすれば、アプリ登録初日に〇〇を実行してもらうにはどうすれば良いだろう？といったように、より具体的に施策を考えやすくなります。
施策の考えやすさを意識するとより活用しやすいKPIになります。
意識：そのKPIを置くことで、いくつかの施策が考えられるかどうか
ここまでが、KPI設計時に意識していること5つでした。
続いては、KPI運用時に意識していること3つについて書いていきます。
KPI運用時に意識していること3つ
KPI運用時に意識していること3つは以下の通りです。
- KPIの認識をメンバーで揃える
- KPIを定着させる
- KPIの見直し
KPIの認識をメンバーで揃える
1つ目は、KPIの認識をメンバーで揃えるです。
こちらに関しては、過去に自分の意識が足りなかった部分でもありますが、メンバーから課題感があることを教えてもらえたことで、気づけた部分でもあります。
KPIを追っていて施策を考える人が自分一人であれば問題はないかもしれませんが、ほとんどの場合は複数メンバーでKPIを追っているはずです。
そうであれば、同じようにKPIを追っているメンバーにもKPIの思想を共有し、同じ目線でそのKPIを追うことが重要です。
Voicyでは、以前までは主にデータアナリストとPdM間でKPIの認識を揃えて運用を行なっていましたが、当時は、PdMが施策を考えて実行していくような体制だったので特に大きな問題はありませんでした。
その後、開発メンバーのエンジニアも一緒になって施策を検討してく体制になったのですが、以前と同様にデータアナリストとPdM間でしかKPIの認識を揃えていなかったことで、開発メンバーとのズレが生じてしまう時期がありました。
開発メンバーとしては、同じKPIを追っていて施策も一緒に考えていくのに、KPIに対する理解もないまま進めていくことになってしまい当然納得感はありません。
幸い、その課題感を伝えてもらえたことで、今は認識を揃えてKPI運用を進められています。
意識：一緒にKPIを追っているメンバーの認識は揃っているか
KPIを定着させる
2つ目は、KPIを定着させるです。
KPIを設計し、メンバーの認識も揃えて、よし大丈夫！というわけではありません。定着しないとただの飾りになってしまいます。
定着させる方法としては、BIツールを使って可視化を行ない誰でも確認できるようにすることや、施策を検討する際にどのKPIを改善するために行うのかをあらかじめ共有したり、施策を行なった後もKPIに対してどうだったのかを共有したり、など様々な取り組みが必要です。
こちらに関しては、会社の体制によっても取りうる手段が異なりそうですが、ポイントとしてはKPIに触れる頻度を増やすことだと思います。
意識：KPIに触れる頻度が多く、定着しているか
KPIの見直し
3つ目は、KPIの見直しです。
ここは意外に抜け落ちてしまったり、いざ見直しをするときもかなり難しい部分ではありますが重要です。
すでにKPIを設計し運用している方は同じ経験をしている方もいるかと思いますが、実際にこういった経験をしてきました。
- KGIが変わった
- 施策をやってもKPIが動かない
- KPIは動いたけどKGIが動かない
KGIが変わったに関しては当前のことですが、そのKGIに見合ったKPIを設計し直す必要も出てきますので、KPIが適しているかどうか再確認しましょう。
施策をやってもKPIが動かないに関しては、KPIの抽象度が高すぎる状態かなと考えています。
例えば、先に例を出した継続率をKPIに置いた場合ですが、運用初期はそれでも問題はないかもしれません。
ログインボーナスを設けようとか、通知施策を打とうとか、最初はある程度施策も出てくるかと思います。
ただし、ある程度施策をやってもKPIが動かない状態になると、これ以上効きそうな施策が出てこないといった状況に陥る場合も出てきます。
そうなってくると黄色信号で、それ以上頑張って施策を考えてもKPIとの距離が遠すぎて具体的な施策が出てこなかったり、もし出てきてもまたKPIが動かなかったりということが起きやすくなります。
こういう時は、既存のKPIの抽象度を下げてより具体化するのも1つの手だと考えています。
例えば、継続率の例であったように登録初日に〇〇を経験することが重要だと分析で見出してその経験人数をKPIにするとか、通知施策を行なっても拒否しているユーザーが多いのでそもそもの通知許諾率を上げることをKPIにするなどのイメージです。
具体化することでまた違った見方ができるようになり、施策が考えやすくなるかと思います。
KPIは動いたけどKGIが動かないに関しては、これはハック的なKPI改善方法だった場合に起きやすいかなと思います。
例えば、ニュースアプリでサブスク会員数をKGIにおいて、KPIに記事閲覧数を置いたとしましょう。
その場合、記事閲覧数が重要なのですごい短い記事だけを表示するようにしたりとか、数秒ごとに別の記事が表示されるようにしたりとかのようなイメージです。
確かにそれで記事閲覧数は増えるかもしれませんが、ユーザー体験が向上してサブスク会員数も増えるのかは微妙なところです。（うまく要約されている短い記事を多く表示するようにするとかであれば、ユーザー体験向上に繋がりそうですが）
ハックを試すこと自体はありだと思っていますが、もしそれでKGIが改善しないのであれば、より本質的な改善を目指す方が良さそうです。
このように、KPIは決めて終わりではなく運用過程で見直しをすべきタイミングもあるので、その時はどこに課題がありそうか改めて確認してみたり、固執せずに思い切って変えてみることも必要になってきます。
まとめ
KPI設計時に意識していること5つ
- データ的な正しさ
- 定性的な正しさ
- 会社方針的な正しさ
- 計測のしやすさ
- 施策の考えやすさ
KPI運用時に意識していること3つ
- KPIの認識をメンバーで揃える
- KPIを定着させる
- KPIの見直し
偉そうにつらつらと書いてきましたが、私も色々なことで悩んでいて、うまくいかないことの方が多いです。
ただ、どうにか活路を開こうと様々な情報を吸収して、この記事を読んでいただいている皆様のようにアップデートをはかっています。
皆様のKPI設計・運用の参考に、少しでもなっていれば嬉しいです！
