KPIは「シンプルに作る・王道なモデルを使う・みんなで作る」のが良い
- このnoteは「モバイルアプリマーケティングアドベントカレンダー2021」の7日目の投稿です！
- 面白かったら是非ハッシュタグ「#アプリマーケアドベント 」を付けてシェアをお願いします！
はじめに
こんにちは。Retty分析MGRの平野です。
今回はKPIについての記事です。
良いKPIの作り方に関しては既に語り語り尽くされている領域だと思うものの、失敗エピソードはあまり語られていない気がします。
また、KPI設計と言っても、組織・事業のフェーズによって難しさが変わると思っていて、良いKPIを作り続けるのは難しいと感じています。
そこで、この記事では過去のKPI設計の失敗事例をベースに学びを紹介したいと思います。
記事の三行まとめ
・KPI設計の失敗事例として「複雑にし過ぎる」「モデルを発明」「ステークホルダーと一緒に作らない」を述べた。
・失敗からの学びとして「シンプルに作る」「王道を使う」「みんなで作る」を述べた。
・つまり、KPIは「シンプルに王道なモデルをみんなで作る」が良い。
話の背景：プロダクト全体のKPI設計を担うことに
Rettyの上場前後くらいから分析チームがプロダクト全体のKPI設計を担うようになりました。
以前までのRettyのKPI設計は、各チームがKPIを立てるボトムアップなアプローチが多かったものの、上場前後のフェーズに入ってからは、売上からトップダウンにKPIを立てるように変わったのです。理由としては事業計画の精度が求められるようになったからです。
元々分析チームでもKPI設計は担っておりましたが、あくまで派遣先のチーム内目標を起点としたKPIでした。それが、プロダクト全体のKPI設計に範囲が拡大したのです。
さて、上記のような背景で、ここから分析チームがプロダクト全体のKPI設計をすることになったのですが、数々の失敗を犯してきました。
ここから本編では、実際の失敗エピソードから3つご紹介します。
失敗①：複雑にし過ぎる
KPIツリーを作る際に階層はいくつにしてますか？
またセグメントはいくつにしてますか？
KPIはシンプルにと、頭で分かっていてもついつい複雑にしてしまいます。
私は過去に、最大で指標60個、Aセグメント17個、Bセグメント5個と掛け合わせると5100要素のKPIツリーを作ったことがあります・・笑
当然ですが、運用し続けられませんでした。
複雑なKPIは現場に理解浸透されず混乱を招きました。
また、些細なアップデートにおいても修正コストが高く、保守できないものとなりました。
なぜこうなってしまったか振り返ると、次の理由があったと思います。
・現場チームの粒度まで考慮したかった
・そもそも「使いやすさ」の観点がなかった
現場チームの粒度まで考慮したかった
冒頭の背景に書いた通り、各チーム単位でのKPI設計からプロダクト全体のKPI設計と見る範囲が増えたものの、KPIの粒度も変わらず現場の視点で作っていました。
複数のチームを跨ぐKPIを作る場合、チームごとに見たい切り口（セグメント）や指標は様々です。何も考えずに連携すると、各チームから沢山要望が上がってきます。
全てのチームの要望を汲み取ってしまうと当然複雑化するのですが、当時は全て完璧に汲み取る網羅性の高いKPIを作ることに全集中していました。
そもそも「使いやすさ」の観点がなかった
これも大きかったと思います。
本質的に事業・プロダクトが成長するためのドライバーを見つけることに執着してしまい、KPIの使いやすさの観点がなかったのです。
KPIはみんなが何にフォーカスすべきかを示す羅針盤のような存在です。
みんなにとって使えない羅針盤ではKPIの意味を成しません。
以前までは一つのチームでのKPIと関わる人も多くなく、頑張って伝えれば理解できていたのもあって、使いやすさの観点を甘く見てました。
学び：シンプルに作る
この失敗からの学びは「シンプルに作る」です。
以前までは精巧さ正しさを追求すべきと考えていた私ですが、上述した通り、全く理解されず羅針盤として機能しませんでした。
一人で事を成すなら良いかもしれませんが、Rettyのようにワンプロダクト/ワンチームの会社では、みんなで進む必要があります。
みんなで進むのにシンプルであることは必須であると、今回の失敗で身に沁みました。
とはいえ「シンプルに作る」は、当たり前のようで案外難しいです。
なので、シンプルに作るための私なりのポイントを添えておきます。
point
・むやみにセグメントは切らない。切るとしても最初は最大3つまでに留める。
・モニタリングKPIは3〜5つくらいに留めておく。（例：入り口指標・中間指標・出口指標）
むやみにセグメントは切らない。切るとしても最初は最大3つまでに留める。
セグメントごとにKPI・施策が変わるので、ついついセグメントは切りたくなってしまいます。ただ、運用経験があまりない時期に、セグメント5つ、10つと増やしてしまうと複雑で管理しきれなくなります。
そのためKPI運用の初期は、セグメントを切らないが良いと思ってます。
組織として慣れてきた頃にセグメントを増やすようにしましょう。
セグメントに関しては以下の記事がおすすめです。シンプルにすることの重要性も説かれており非常に勉強になりました。
モニタリングKPIは3〜5つくらいに留めておく。（例：入り口指標・中間指標・出口指標）
KPIも見ようと思えばいくらでも見れますが、みんなで数値意識を高めるなら3つくらい、多くて5つくらいが限界だと思っています。
細かいKPIは、分析チームやPMなど一部メンバーだけ把握しておくようにしておくと良いと思います。
失敗②：モデルを発明
ここでいうモデルとはKPIツリーの形のことです。
過去に私は王道なモデルを使わずに、新たにモデルを発明したことがります。理由はいろいろあるのですが、大きい理由として新しい戦略を展開する上で、既存のモデルでは当てはまらないと思ったからです。
しかし、発明したモデルは、KPI目標を立てづらいこと、現場が混乱しやすいデメリットが発生し、使うのを途中で辞めました。
デメリット発生背景
Rettyを長く運営してきて見るべき指標は大体決まっていました。
長らく見ている指標は、みんなの中で基準値が出来上がります。このくらいの数値が高い普通低い、施策でこれくらい上がれば良い普通悪いなどのものさしのことです。
しかし、今回新たなモデルを採用することで、今まで出てこなかった指標だらけになりました。
そうなると当然、長年培ってきた指標の数値感覚がなくなります。結果、施策の数値試算が難しくなってしまったのです。
数値試算が難しくなると、当然KPIの目標が立てづらくなります。各現場が本当にこの目標で良いのだろうかと、不安や混乱を生んでしまいました。
学び：王道を使う
この失敗からの学びは「王道を使う」です。
Webサービスのモデルは抽象化すればほとんど同じだと思います。
なので、Google検索すれば王道のモデルが出てくるはずです。
発明せず、素直に王道を使いましょう。
失敗③：ステークホルダーと一緒に作らない
この記事をご覧のみなさんはデータアナリストが多いのでしょうか？
データアナリストの皆さん、ちゃんとPMなどKPIに関わる人（ステークホルダー）と話してますか？
私は過去に、ステークホルダーとちゃんと話さず進めたことで、みんなにとって納得感のないKPIを作ってしまったことがあります。
具体的には以下のすり合わせが足りませんでした。
・指標やセグメントの選定と定義
・KPI目標を立てるための試算
指標やセグメントの選定と定義
とくに定義は案外見落とすことが多いのではないでしょうか？
データアナリストの無意識な前提から計測定義をしたものの、ステークホルダーとしては別の計測方法を想定していることも多々あります。
指標セグメント一つ一つの計測方法に対しても、すり合わせは怠ると後々手戻りに繋がるので気をつけたいです。
少し脱線しますが、指標やセグメントの計測方法のズレ問題は、分析チームがガバナンスを取れると根本的な解決に向かうと思います。社内で指標ごとの計測定義がずれないように、公式定義を作っていきましょう。
KPI目標を立てるための試算
前提としてRettyでは、KPIの使いみちとして次の2つに集約されます。
この話は①の用途にあたります。
①目標：KGIを達成するために試算をしてKPI目標を決める
②モニタリング：月単位でのKPIモニタリング
①は言い換えると、KGI達成への山の登り方とも言えます。
山の登り方に対してズレが生じると、施策に一貫性がなくなります。
やりがちなのは、データアナリストの肌感で作って、ステークホルダーには確認だけで終えてしまうケースです。
試算は、確認を取るだけだとちゃんと理解することが難しいと感じています。なので理想は、一緒に試算できると良いと思います。
ステークホルダーによっては、忙しく時間が取れない人が居ると思いますが、実際に目標を追うPMは、しっかり巻き込んで作ったほうがいいでしょう。
学び：みんなで作る
この失敗からの学びは「みんなで作る」です。
これは納得感の醸成だと思っています。KPIは論理的に正しいパターンは沢山あります。但し、納得感に正解はなく、みんなKPIに対して色んな考えを持っています。
ちゃんと、それぞれの考えや前提を話した上で最適なKPIを創り上げていく、このようなステップを踏む必要があると失敗を通して学びました。
参考
納得感を作る上で参考になる記事を貼っておきます。
おわりに
3つの失敗から学んだことは「シンプルに作る・王道を使う・みんなで作る」でした。
つまり、KPIは「シンプルに王道なモデルをみんなで作る」のが良いんだと思います。たぶんこれはGoogle検索すれば沢山出てくるような内容で、常にこれができていれがKPI設計はさほど難しくないんだと思います。
ただ、それでも多くの方がKPI設計に悩むのは、失敗事例でご紹介したさまざまな背景があるからだと思います。
今回の失敗エピソードを共有することが、少しでも今後のKPI設計に役立てれば幸いです。
宣伝
Meetyやってますー！カジュアルに話しましょう！
トピックは、情報交換、雑談、キャリア相談など、なんでもOKです！
スタチャというグロースをテーマにPodcastやってます！聴いてくださいー！
この記事が気に入ったらサポートをしてみませんか？