こんにちは！データサイエンス室（以下、DS室）の山本です（@__Y4M4MOTO__）です。
弊社では「Yappli Analytics」というアプリ運用のためのデータ分析ダッシュボードを提供しています。ダッシュボードでは、アクティブユーザーや新規ユーザー数の推移、プッシュ通知の開封率など様々なデータを確認できます。その中でも特徴的なものが「ベンチマーク機能」です。
「ベンチマーク機能」では、900以上（2025/12/17時点）のYappli製アプリの中で、自アプリのパフォーマンス（平均アクセス回数、翌日リピート率など）を四分位（Highest/High/Low/Lowest）で可視化し、他のアプリと比較できるようにしています。これにより、自アプリのパフォーマンスが他のアプリと比べてどうなのかを把握することができます。
今回、このベンチマーク機能のスコア算出を、全Yappli製アプリからではなく、同じ業種のアプリ同士で比較できるように改善しました。
自分はこの改善プロジェクトの旗振り役を担当したので、プロジェクトの振り返りと得られた知見をまとめてみたいと思います。
プロジェクト背景
ベンチマーク機能は昨年に新登場した機能です。前述の通り、約900アプリの中での自アプリのパフォーマンスを相対的に把握することができ、アプリのプラットフォーマーならではな機能でした。
しかし、機能をリリースしてしばらくすると、「全アプリからではなく、同じ業種のアプリ同士で比較するようにしてほしい」という要望が寄せられるようになりました。理由は同じ業種のアプリ同士で比較しないと、目指す方向が異なるアプリも含まれてしまい比較結果が参考になりづらいからです。例えば、一般消費者向けのアパレルアプリと従業員向けの社内アプリではアプリの運用目的は異なりますし、パフォーマンスとして重視する指標も異なります。これらのアプリが混ざった状態で自アプリのパフォーマンスが「Low」と言われても、本当にパフォーマンスが低いのか、本来比較対象でないアプリが混ざってるから低くなっているだけなのかがわかりません。そのため、ベンチマーク機能がより活用されるためには、同じ業種のアプリ同士で比較できるようにする必要がありました。
プロジェクト体制と当時の弊社の組織構造（抜粋）
このプロジェクトのメンバー（以下、PJメンバー）は次のように構成されていました。
- DS室: 2人（私含む）
- プロダクトマネージャー（PdM）: 1人
- プロダクトデザイナー（PdD）: 2人
また、プロジェクトメンバーというわけではありませんでしたが、カスタマーサクセスマネージャー（CSM）2人に協力してもらい、プロジェクトのSlackチャンネルで密にやり取りをさせてもらっていました。
今回のプロジェクトを進めるにあたって様々な部署と連携しました。部署同士の関係性がわかるよう、以下に弊社の組織構造を簡単にまとめます。
（以下、CS本部）] セールス&マーケ統括本部 事業推進部 カスタマーサクセス部[カスタマーサクセス部
（以下、CS部）] ディレクション部 %% root --> 開発統括本部 開発統括本部 --> DS室 開発統括本部 --> PdM 開発統括本部 --> PdD root --> ビジネス統括本部 ビジネス統括本部 --> カスタマーサクセス本部 カスタマーサクセス本部 --> カスタマーサクセス部 カスタマーサクセス本部 --> ディレクション部 ビジネス統括本部 --> セールス&マーケ統括本部 ビジネス統括本部 --> 事業推進部[事業推進部 ※]
※ 事業推進部はビジネス統括本部配下の各部署を後方支援するための部署です。Salesforceの管理などはこの部署が行なっています。
プロジェクトのポイント：アプリ業種カテゴリの定義
このプロジェクトを遂行するにあたって、特にポイントとなったのは ベンチマーク機能で使用する業種カテゴリの決定 です。
カテゴリのデータ元の選定
ベンチマーク機能で使用する業種カテゴリ（以下、アプリ業種カテゴリ）は、既存の分類を使わず新たに定義することにしました。理由は、既存の分類がアプリの業種カテゴリとして使うには不十分だったためです。
既存の分類として有力だったのはSalesforceに登録されている取引先企業の業界分類でした。しかし、企業の属する業界が必ずしもアプリの業種カテゴリと一致しないことがありました。例えば、アパレルの企業だからといって必ずしもアパレルアプリを出しているわけではなく、従業員向けの組織エンゲージメントアプリを出しているケースもあります。このような背景から、既存の分類がアプリの業種カテゴリとして使うには不十分と判断し、新たにカテゴリを定義することにしました。
カテゴリ定義の流れ
カテゴリ定義は次の流れで行いました。
- PJメンバーでカテゴリの草案を作成 1
- CSMの2人協力してもらい、CS部内で草案をベースにカテゴリ定義
- 出来上がったカテゴリ定義をPJメンバーでブラッシュアップ
CS部内でカテゴリ定義を行なってもらうにあたって、次の点を伝えました。
- 既存の分類ではなく新たにカテゴリを定義する理由
- 1カテゴリに20以上のアプリが含まれるようにし、小さすぎるカテゴリは作らないようにすること
「1カテゴリ20アプリ以上」の制約を設けた理由は、1カテゴリにアプリが一定数以上ないと十分な比較が行えないからです。
逆に、それ以外の「どのようなカテゴリが必要か？」といった部分は全面的にお任せしました。日々お客様のアプリ運用と向き合っているCSMの方々の方がより適切なカテゴリを定義できると考えたからです。
カテゴリ管理・運用方針の策定
カテゴリ定義と並行して、定義したカテゴリをどう管理・運用するかを検討しました。検討の際には、ステークホルダーとして、CS部、ディレクション部の各部長と事業推進部でSalesforceの管理を担当しているメンバーを巻き込んで話し合いを行いました。
最初に検討した案は、Salesforceでカテゴリを管理・運用し、そのデータを引っ張ってくる形でYappli Analyticsへ適用する案でした。
この案は理想的ではありますが、次の懸念点がありました。
- Salesforceオブジェクトへの改修とビジネス側の既存の業務フローの変更が必要であり、そのための調整で多大な時間が必要になること
- 調整できたとしても、Yappli Analyticsという「プロダクト」のデータのマスタが「ビジネス部門」の管理下にあることで、プロダクト都合での改修にビジネス側との調整が必要、あるいはその逆の状況が発生し、双方身動きが取りづらくなってしまう恐れがあること
このため、次の案としてSalesforceではなくYappli Analytics側で独自に管理・運用する案を検討しました。Yappli Analyticsではスプレッドシートを用いて「どの顧客がどのアプリのデータを見ることができるか」のアクセス制御を行なっています。
このスプレッドシートに列を1つ追加するような形でアプリ業種カテゴリを管理・運用する、というのが検討した案です。この案であれば、前述の懸念点を払拭できます。また、すでに施行されているYappli Analyticsの権限追加フローに組み込む形でアプリ業種カテゴリの登録フローを実装できるため、運用負荷も少なくできます2。
しかし、この案で合意は取れませんでした。理由は、ビジネス活動（主にCS活動）の面でアプリ業種カテゴリはやはりSalesforceのデータと連携しておきたい、という要望があったからです。アプリ業種カテゴリはYappli Analyticsのベンチマーク機能のために定義したものですが、CS活動においても有用なデータであるため、Salesforceのデータ連携して活かしたい、という動機でした。
この部分について、話し合いの中で次のことがわかりました。
- CS本部でCS活動のための新ツール（Salesforce連携）の導入を事業推進部と協力して行なっている最中であり、その中で併せてアプリに着目した業種カテゴリを定義する予定だったこと
- そのカテゴリ定義は我々がYappli Analyticsのベンチマーク機能で使用するアプリ業種カテゴリとほぼ同じになること
そこで、次の2フェーズに分けて進行することで最終的に着地しました。
- 一旦はYappli Analyticsの権限台帳でアプリ業種カテゴリを管理・運用する
- その後、新ツールの導入がある程度進んだ段階でSalesforceへ移管する
リリース後の反応と得られた気づき
顧客・CSMからの反応
ベンチマーク機能の数値が業種ごとに出るようになったことで、やはり顧客・CSMからはポジティブな反応が寄せられました。また、改善されたベンチマーク機能を元に早速アプリの改善に取り組んでいる顧客・CSMもいてくださり、改善した甲斐があったなと感じました。
得られた気づき：レポートラインを意識することの重要性
今回のプロジェクトでは「ベンチマーク機能の改善」と「ビジュアルアップデート」という2つの改修を同時に進めました。さらに、改修に関わるステークホルダーも組織図の縦横に幅広くなりました。そのため、途中で「誰に確認を取れば良いのか」というレポートラインがわからなくなり、それによって進捗内容に認識齟齬が生じて手戻りしてしまうこともありました。
このことから、事前に「これについてはこの人から合意が取れればOK」といったレポートラインを明確にしておくことが重要だと痛感しました。また、合意を取る相手が本部長クラスの方だとPJメンバーで直接合意を取りに行くのが難しい（スケジュール合わせ等）こともあるため、その場合は配下の方を巻き込んでその方を通じて合意を取る、などの工夫も必要だと感じました。
結び
この記事では、Yappli Analyticsのベンチマーク機能改善とビジュアルアップデートのプロジェクトについて、プロジェクト遂行のポイントや得られた知見をまとめました。ステークホルダーが多岐に渡り、悩んだ場面も多々ありましたが、最終的に顧客・CSMからポジティブな反応をいただくことができ、Salesforceとのデータ連携への展望やYappli Analyticsの立ち位置の明確化（→詳細）といった今後の発展に繋がる副産物も得ることができたので、良かったと思っています！
ここまでお読みいただきありがとうございました！
