ハロー、CTOです。今日は地味KPIの話をしようと思います。 我々のようなインターネット事業者は常にプロダクトの売上や利益といった数字に対して一喜一憂し、その改善に笑顔し、時には涙を流しながらプロダクトの運営をしています。その中で効果的に組織で事業を伸ばしていくためにKPIのようなものを設定することは一般的なことかと思います。 その中でも当たり前に計測しているもの（インフラパフォーマンスや事業数値）を除いて「良くて当たり前」「下がったらまずい」といったある種、計測していることすら時に忘れてしまうような地味〜〜な数値たちもあり、これを私の中ではこっそり「地味KPI」と捉え、まさに地味に優先度設定し可視化や改善をしています。今回はプロダクトの安定性に関する地味KPIをご紹介します。
隠れている大事な地味KPI
そもそもの地味KPIの目的はチームのデリバリを加速し、意思決定の質を上げプロダクトの安定性を良くするためです。 あえて「プロダクトの安定性」と書いたのは「システムの安定性」はすでにMTBFとMTTRのような一般的な指標や、APIのレスポンスタイムやサーバのパフォーマンスなどすでにクラウドベンダが定義しているレベルで当たり前に計測されている一方で、プロダクト・アプリケーション固有な計測しておくべき安定数値はあまり言及されないためです。 プロダクトの質によって「ユーザーさんが正しく使えているか」といった問に対してE2EやUTなどでケアする以外にも地味KPIをしっかり設定して、これをモニタリングし、デリバリの正しさを常に保証することで対内外にプロダクトの安定性を伝えることができます。
例えば
地味KPIはプロダクトや見るべき職責で様々な指標があります。 例えばECを例にしたときに、売上やDAUなどは直接事業に関わる事が多く、変動の検知はデイリーで見て気づきやすくもありますが、一方で例えば「お気に入り機能が利用されているかどうか」などは即日常に計測されているKPIに影響はないですが中長期的・間接的にKPIや問い合わせに影響を及ぼし、主KPIから見えにくいサービスからの離脱を生みます。 サブスクのサービスにおいても一部の機能が使えない等で、即時離脱や休会に利用はないがボディブローのようにじわじわとユーザーさんや運用に悪影響を及ぼす数値の低下は一定数存在します。
レアジョブにある地味KPI
1. レッスンルームの接続率
弊社のレアジョブ英会話のプロダクトで、レッスンをするためのレッスンルームという機能があります。 レッスンルームはSPAで動いており、クライアントアプリケーションのためその挙動が正しく動いていたかなどをシステム上把握しにくい事が多いです。 特に接続が実施できたかどうか、などは顧客環境によっては明確に失敗することもあり、100%稼働が期待値ではありません。一方でもし保証している環境内で不具合が起きていて、接続に失敗している場合などは適切に検知し対策を打つ必要があります。またこれはリリースをしなくてもWebRTCのようなブラウザ依存が強い技術を使っており、ブラウザ自体のアップデートやリリースにでも地味KPIが変動します。 弊社ではこの接続率をWebRTCの接続のプロセスで発生するイベントを記録し、レッスン時間帯毎・日時・月次・顧客ごとにredashで可視化、それをnodeで書いたbotで自動でchatworkに投稿し、大きく変動があればスレッドの参加者にメンションを飛ばす仕組みを入れています。どのセグメントで切ってもほぼほぼ99%を超えてくる数値ですが、時折異常値を出すこともあり、これにより異常を早期に検出し対応することができてきました。
この仕組があるおかげでリリース後の最低限の動作保証や、ブラウザなどの変更による外部影響も早期に検出できるので強気にリリースやトライができます。
2. 検索実施数
検索の利用は弊社でもかなり多く、毎月数十万レッスンを提供する弊社では同じように講師検索の機能利用数も非常に多いです。 一方でレッスンの予約数のようなクリティカルな機能は問題があればCSへの問い合わせですぐ気づくことはできますが、検索は導線も多く特定箇所や条件で使えなくてもすぐ検知ができません。 また講師の開講状況やトレンドにも依存はしますが、全体の傾向は常にある程度は一定なので、変化があれば不具合や不整合などが原因だとわかります。この悪化は問い合わせでなく離脱に直結することもあり、地味に見逃せません。
検索ページのリニューアルを実施した際も効果測定の観点だけではなくて安定性の観点でこのモニタリングを実施したりもしていました。
まとめ
これらの地味KPI管理は正直やらなくてもなんとかなります。プロダクトは複雑に絡み合っており、特定領域がダメでも他の手段ややり方である程度成立させることはできるからです。またケースによっては主KPIから逆算で問題に気づくこともできます。 一方で計測しにくい不具合を早期に気づいたり、リリースを保証しデリバリの速度や頻度を上げやすくなったり、短期ではわからないが中長期的に主KPIに影響のある事象に気づけるなどまさに地味だけどとても大事な成果を得ることができると思っています。 マネジメント観点でもチームの管理するプロダクトを定量的に改善を計測できるのでおすすめです。 なんとなく大丈夫だと思っていても、計測して傾向を時系列で見てみるとこれまで見えてこなかったユーザーさんやプロダクトのインサイトに気づくことが多いのでぜひ。
Let's 地味！
