薬局事業のプロダクト開発プロセス- KPI の設定とモニタリング編

MICIN 土屋です。

MICINでは色々な仕事を担当しているのですが、最近のメインの仕事は薬局向けプロダクト「クロンお薬サポート」のTechPM的な仕事です。

今回の内容

今日は「最近の薬局向けプロダクトの開発工程に関して共有したいな」と思って記事を書き始めたのですが、開発工程にたどり着く前の、KPIやら何やらの部分だけでも記事1 本分くらいの長さになりそうでしたので、 2本に分けて記事を書くことにしました。

1本目の今回は「 KPI設定とモニタリングをどうやっているか？ 」に関する話になります。

これがないと「どの task を優先して実施するべきか？」の判断ができず、開発工程上進まなくなる（というか後から「その作業本当に意味あるの？」となってしまう）ので、ここを認識合わせることは非常に大切だと思っています。

※注意
この記事は、自分自身の考え方の整理と社内への共有、そしてMICINに興味持っていただいている方々に「クロンお薬サポートはこんな感じでモノづくりしている」ということをお伝えしたいという目的で記載しています。よって、既にKPIの設定やモニタリングをやっている方には当たり前の話かもしれませんし、もっと良い方法もあるかもしれません。そういう方は是非弊社に入っていただいて、知見の共有していただけると嬉しいです！

KPI に関して

KPIの決定

KPI は本当に重要な指標です。
当たり前の話に聞こえるかもしれませんが、これは単なる「重要そうな利用統計値」ではなく「このプロダクトは何を実現・達成したら成功したといえるのか？」を表す数字そのものだからです。（逆にそのように設定されていないのはまずいです！）

では「クロンお薬サポートが何を目指しているのか？」というと、現時点では「オンライン診療 curon経由でのお薬サポート利用率」です。つまり、弊社の別プロダクトである、オンライン診療サービス curon から、そのままクロンお薬サポートを利用していただくユーザーの数を最大化する事を目標としています。

「なぜそれが重要だと判断したか？」の背景も説明可能なのですが、これについては社内の背景等などあるので、今回の記事には書かずにおきます。

KPI のTree化

「どうすれば KPI を改善できるのか？」

これを科学的にやろうとすると KPI を分解・構造化する必要があると考えています。
そこで、決めた KPI を構造化したKPI Tree を作っています。

完全に内部の資料なので、超縮小したものでイメージだけお伝えできればと思いますw

作る際に重要だと思っている事はこんな点です。

1. 下位項目と上位項目の数値的な関係が明確になっている事

例えば「売上=単価x利用者数」みたいに、掛け算した結果が上の項目になるよ、とかそういう意図です。
これをしないと、行うべき「介入」が 最も大切な KPI にどう影響与えるかが見えづらく、企画やCXでのフォロー等のアクションに対する評価が難しくなり、適切な試行錯誤ができない状態になります。

2. 下位項目の切り口でも現状の利用状況データやプロダクトの性質、目指す方向を加味する事

例えば「『利用者数』の下位をどう作るか？」に関しては、プロダクトの性質や方向性によって内容を変えるべきだと思います。下記の様に、分け方の例は非常に沢山ありますが「なぜそう分けたのか」を明確に説明できる必要があると思っています。

• 「売上=単価x利用者数」
• 「利用者数」を分解する場合、「無料プラン」と「月額有料プラン」がある場合、「利用者数=無料プラン+月額有料プラン」と分解すると良いかもしれない。
• 「有料プラン」は更にこんな分解があるかもしれない複数料金プランがある場合それぞれで分ける
• • 利用状況で1ヶ月にX回以上と分ける
  • 利用回数TopXの利用者で分ける
  • 特定の機能の利用者で分けるetc...

3. 細かく作りすぎない

これは個人的な意見というか工数的な問題が絡んでいる可能性があるかもしれないのですが。。。

KPI tree で分解した各項目に関しては、統計情報をひと目で見れるようなDashboard を用意する必要があると思っています。そうしないと1番目に話をしている「介入」の効果について、誰でも簡単に把握することができなくなるからです。

というわけで、 KPI Treeの項目に関して集計して可視化するのですが、細かく深く作りすぎると、機能変更で過去に作ったchart が無意味になる事が多そうで、メンテが辛いかなと思いますw

KPI の可視化

弊社では現状、分析用途にGoogle Bigquery、可視化のためにredash を利用しています。
redash でquery を実装、Bigquery に日次でquery を発行しDashboardを更新しています。

（画像はredash のサイト から拝借したものです。実物は未公開。）

Dashboard のchart は KPI の各項目を表しています。
複数のタイプのユーザーがお薬サポートを利用する場合、色分けをし積み上げ棒グラフに刷るような事は視認性が高まるので個人的には好きです。

ある項目に関して深堀りしたい場合は個別にそれに関する調査を行います。そしてDashboard化する事はしていません。
他の重要な数字の視認性が下がるためです。アクセスするとすぐに開いて、ザーッと見れる。これがDashboard の目的だと思っています。

まとめ

開発プロセスの話をする予定でしたが、「優先順位調整」の話の前にまずは「優先度とは？」の話が必要になるし、実施後の反応を見る際に「何をどうやって見るの？」を説明する必要があります。
つらつら書いていたら長くなりそうな予感しかしなかったので、まずはこの話を先にしました。

ポイントはこんな感じです。

• KPI は「このプロダクトは何を実現・達成したら成功したといえるのか？」を表す数字
• KPI はどんな要素で構成されているのか？をサービスの実情を反映しながら構造化し、KPI Treeを作る
• KPI Tree の各項目の把握、介入での変化を把握するためにコンパクトなDashboardを用意する

次回、開発プロセスの話をする予定ですw