FiNCにおけるデータ分析グループの役割の変化
～FiNC から FiNC Technologiesへ～
こんにちは。FiNCデータ分析グループの坂本です。私はFiNCの初期フェーズからかかわっており、FiNCデータ分析グループのなかで最古参のメンバーです。初期フェーズから参画しているため、アプリの成長とともにいろんな経験をしてきました。
ご存知の方も多いと思いますが、FiNCは予防ヘルスケアにおける世界一のテクノロジーカンパニーを目指すため、2018年10月1日から社名をFiNCからFiNC Technologiesに変更しています。
データ分析グループの役割も、FiNC時代とFiNC Technologies時代で当然変わってきています。このポストでは、FiNCデータ分析グループの歴史を振り返りながら、データ分析グループの役割にどのような変化があったのか、フェーズごとに紹介していきます。
① プロダクトリリース前
分析グループの役割：リリース後に計測するKPIの策定・分析基盤の構築
プロダクトをリリースする前に分析メンバーは必要なの？と思う方も多いと思われますが、私は必要だと考えています。実際、メルペイさんはプロダクトリリース前にデータ分析チームを組織し、分析ツールの選定などを行っています( Mercari Engineering Blog:プロダクトのリリース前から新ダッシュボード「Looker」の導入に踏み切ったわけ )し、当社も現在のFiNCアプリがリリースされる前に私は参画しています(※)。 では、このフェーズで参画した分析メンバーは何をするのでしょうか？それは、主に下記の2つです。
- リリース後に計測するKPI策定
- そのKPIを見える化する分析基盤の構築
それぞれ詳しく書いていきます。
※現在のFiNCアプリの前に旧FiNCアプリというものがありました。厳密にいうと、私が参画した時点では旧FiNCアプリは存在していました。
リリース後に計測するKPI策定
プロダクトの成功指標であるKPIを策定します。といっても抽象的でわかりづらいと思いますので、もう少し具体的に説明します。プロダクトの初期リリースされるプロダクトは、「仮説検証が可能な最小構成な仕様」のプロダクトです。そして、それらの仮説は多くの場合、文章で定義されています。分析メンバーの仕事の一つは、それらの仮説を数値に落とすというものです。
例えば当社の場合、プロダクトの初期リリース時には下記のような仮説がありました。
- パーソナライズされた健康情報をアプリで提供することで、ユーザーは健康的な生活習慣が身につく
- 健康という目的があるので、パーソナライズに必要なライフログ(体重・食事など)を、ユーザーは積極的に継続的に入力する
そのため、アプリの初期フェーズでは、
- パーソナライズされた会話を楽しめるFiNCちゃん
- 興味関心やライフスタイルに合わせた健康記事
- ライフログ(歩数・体重・食事)を記録できるような仕組み
といった機能などが搭載されていました。
https://company.finc.com/news/8335
ではこのような場合どのようなKPIを置くのが適切でしょうか？ITサービスはその特性上、どんな数字でも計測することができます。その中で適切なKPIを設定することは分析メンバーの非常に重要な仕事です。ここでは、FiNCが初期フェーズで置いていたKPIの一つを紹介します。
FiNCには体重入力の機能があると先ほど紹介しました。すると、日ごとの体重入力ユーザー数・その平均体重・平均減少率・体重入力時刻など様々な数値を集計することができます。様々な数字を集計できるからこそ、本当に適切なKPIを設定する必要があります。当時重要視していた指標は、初入力率と継続入力率です。初入力というのは、体重を一度でも入力したユーザーの割合、継続入力率というのは一度体重を入力したユーザーが継続的に体重を入力する割合です。なぜこの指標をKPIとして採用したのでしょうか？それは、この数値が仮説を検証するのに適した指標だからです。
上のほうでも紹介しましたが、仮説の一つに、「パーソナライズに必要なライフログ(体重・食事など)を、ユーザーは積極的に継続的に入力する」という仮説がありました。この仮説を検証するためには、平均体重や入力時刻などは関係ありません。本質的に重要なのは、体重入力機能を使ってもらえるのか・使い続けてもらえるのかということです。そこで、それらを端的に表す、初入力率と継続入力率を採用しました。
このように、様々な数字が計測可能な中で、本質的に注目すべきKPIを設定することが重要です。このフェーズでこれをやっておかないと、リリースしてからすべての意思決定が後手後手になります。
KPIを見える化する分析基盤の構築
KPIは定義するだけでは見えません。プロダクトからログをとり、何らかの方法で可視化する必要があります。プロダクトリリース前には、その仕組みを構築する必要があります。
こちらもFiNCの例を紹介します。FiNCではクライアント(アプリ)の操作ログ・サーバー側のログなどをすべて匿名化したうえで、Redshiftというデータベースに集約しています。Redshiftに集約するという意思決定を行ったのはこのフェーズでした。サードパーティ製の計測ツールを使用してもよかったのですが、FiNCの場合はアプリ・モールなど、サービスをまたがった分析を行う必要があるため、自前で分析基盤を構築することにしました。
ここで、分析基盤の紆余曲折を紹介します。分析基盤構築時に、ログをRedshiftに集約するということはすんなり決まりました。しかしながら、それを見える化するサービスは紆余曲折がありました。
現在は Redash を採用しているのですが、そこに行きつくまでには、エンジニアインターンが作った自前のサービス・PowerBIといった変遷がありました。というのは、分析基盤構築当時、 Redash はFiNCが求めるレベルの権限管理ができませんでした。そこで、見える化サービスも自前で構築するという意思決定をしました。
そこで、当時データの可視化に強いインターン生を巻き込んで、社内Webサービスを作成しました。社内ではKPI Visualizerと呼んでいました。KPI Visualizer は社内の要件を満たしており便利だったのですが、プロダクトがリリースされて数か月で提供終了としました。というのは、増え続けるデータ量に対して、適切にキャッシュする仕組みや効率的にクエリを管理する仕組みが乏しく、そのメンテコストが膨大になることが予測されたからです。
そのような背景があり、KPI Visualizer のあとは Microsoft の PowerBI を使用しました。PowerBI は権限管理やキャッシュの仕組みがあり、個人的には気に入っていたのですが、(当時) SQLに方言があり、クエリをメンテできる人が限られてしまいました。そうこうしているうちに、 Redash が進化を重ね、FiNCの要件にあうようになったので、現在は Redash を使用しています。
このように、分析基盤の選定に関して、社内の要件・予想されるデータ量・メンテナンスコストなど、考えることはたくさんあります。それらを加味して分析基盤を構築しておくことが重要です。
まとめ
プロダクトリリース前には、上記の2つのテーマ両方とも扱えるデータアナリストを1人採用しておくことをおすすめします。おそらくその会社で初のデータ分析メンバーとなると思いますので、採用する側がデータ分析に詳しくない場合もあると思います。そんな場合には、企画とエンジニアの2人で面接し、プロトタイプやコンセプトを見せて
- どのようなKPIを設定しますか？
- それを見える化するための基盤はどう構築しますか？
というようなことを聞けば判断できると思います。このフェーズで重要なのは、プロダクトの仮説に寄り添い、数値面からゼロイチを支えるデータ分析メンバーが必要であるということです。
② プロダクトリリース直後
分析グループの役割：必ず正しい数値を報告すること・今後のグロースのポイントを見つけること
さぁ、いよいよ本番です。本番リリース後のデータ分析グループの役割は何でしょうか？それは今後のサービスを拡大させることです。そのためにはまず、必ず正しい数字をを報告する必要があります。
必ず正しい数字を報告する
このフェーズにおいて、CEO含め、企画チームはなるべく早く仮説検証をしたいと思っています。自分たちの仮説通りの数字が出ているのか、そうでないなら早く手を打ちたいと思っています。このような背景から、データ分析グループが出す数字には注目が集まっています。当然、データ分析グループが出す数字は必ず正しい必要がありますが、このフェーズだからこそのむずかしさがあります。
というのは、あるはずのログがない・回数が入っているカラムのはずなのに[0,1]しか入ってないといったエンジニアリング的な問題、LEFT JOIN すべきところを INNER JOIN しているなどといったクエリの問題など、様々な問題が複合的に発生するからです。また、定性的なサービス感もまだ醸成されていないので、「なんとなくおかしいなぁ、この数字…」というような直感が働きづらいことも正確な数字を報告するための難易度を上げています。そのため、同じ内容を異なる方法で集計する・集計した他の数字と妥当性を比較するなど、細心に業務を行う必要があります。
今後のグロースポイントを見つける
さぁアプリのデータがたまってきたところで、いよいよ考えるべきは「リリースしたサービスをどうやって伸ばすか」ということです。もう少し具体的なことをいうと、「どのような使い方をしているユーザーがより定着しやすいか」というマジックナンバーを見つけることです。
https://ja.wikipedia.org/wiki/%E6%B1%BA%E5%AE%9A%E6%9C%A8
たとえば、TwitterやFacebookであれば「X人以上つながりを持ったユーザーは継続率が高い」などの示唆があることでしょう。それのFiNC版を見つけることが重要です。そのような数字を見つけていく作業では、単なるクロス集計や仮説検証ではなく、重回帰分析や決定木分析などを用いて探索的にマジックナンバーを探していくことが重要です。FiNCでも初期からこのような分析を行い、継続率を高めるための体験設計に活かしています。
まとめ
このフェーズでは、絶対に正しい数字を報告すること、今後のグロースポイントを見つけることが重要だと紹介しました。そのため、分析体制としては2名いることが望ましいと考えています。重回帰分析や決定木分析などができる人と、SQLをかける人の2人体制です。こういう体制を敷いていれば、お互いのクエリをレビューしあうことができ、レポートの品質も担保することができます。
③ プロダクトグロースフェーズ
分析グループの役割：各企画で正しくPDCAを回し、その考え方をチームに定着させること
①や②のフェーズで、プロダクトの基礎的なKPIも正しく報告され、どのような体験がユーザーの成功につながるかが明らかになっています。このフェーズは、「じゃぁこういう施策をやればあがるんじゃないか」といったような施策をバンバン打っていくフェーズです。そんな中でのデータ分析グループの役割は、「企画メンバーが定量的な意思決定ができるように導く」という役割です。
各企画で正しくPDCAを回すこと
このフェーズでは、たくさんの企画が出てくると思いますが、「なぜそれをやるのか」や「目的とするKPIは何か」や「振り返るべき項目は何か」といったことの検討が甘いまま実装に入ってはいけません。なぜなら検討が甘い施策は、成果がでない、もしくはまぐれあたりで成功の再現性がないからです。
https://ja.wikipedia.org/wiki/PDCA%E3%82%B5%E3%82%A4%E3%82%AF%E3%83%AB
このフェーズでのデータ分析グループの役割は、「各企画で正しくPDCAを回す」ということです。具体的には、
- 企画の前提や内容のレビュー(企画の相談に乗る)
- 施策終了後に振り返る文化の醸成
といったようなことです。そのためには、「企画メンバーから信頼されるくらいのプロダクトへの理解」・「外様(社内コンサル)ではなく企画と一体に仕事しているというマインド」・「企画メンバーと一緒にアイディアを出していけるアイデア力」 などが必要になってきます。これらのスキルを使って、企画メンバーが定量的な意思決定ができるように導いていきます。
データ分析グループをスケールさせること
上記のように定量的な意思決定を導いていると何が起こるでしょうか？それは、「データ分析グループがいないと意思決定が進まない」ということです。そうです、データ分析グループのリソースがチームのボトルネックになってしまうことがあります。
そのため、データ分析グループをスケールさせるということが必要です。具体的には、
- 施策のPDCAは企画メンバーがダッシュボードを見ながら進められる状態を整備する
- 必要であれば企画メンバーにクエリの書き方を教える
(教えやすいようなテーブル構造になっていることは非常に重要) - 定量的観点からの意思決定の啓蒙 (相談に乗る時に答えを提示するのではなく、考え方を導いていく)
といったような活動です。
このような活動でチームの分析レベルを向上させ、データ分析グループの工数をかけなくても定量的な意思決定ができる企画チーム作りをしていきます。そうすることで、データ分析グループが取り組むべき課題に時間を割くことができるようになります。
まとめ
ではこのようなフェーズではどのようなチーム作りをすればよいでしょうか？私は各事業ドメインに1人分析担当を置くべきだと考えています。というのは、このフェーズにおいては数値的な情報だけではなく、各事業ドメインに即した知識や経験も加味しながら意思決定することが必要だからです。FiNCでも、アプリ(全体・トライ・ライフログ) やモールといったように各ドメインごとに分析担当を置いています。
また、データ分析グループがスケールすることで、クエリを書く人が増えます。そうすると分析環境に負荷がかかったり、クエリ結果に即時性が求められるようになったりします。そのようなことに対処するために、分析基盤エンジニアもいたほうが良いでしょう。FiNCにももちろん、分析基盤メンバーが在籍しています。
④ 技術ドリブンで、データから新しい価値を生み出す
分析グループの役割：技術をもとにして、データから全く新しい価値を生み出す。
お待たせしました。ここからが、FiNC Technologiesにおける挑戦です。
これ以前のフェーズでの分析グループの役割は、定量的な面からプロダクトをグロースすることでしたが、このフェーズでは企画メンバーがその役割を担っていることでしょう。
また、データ分析グループは、より高度な相談や、プロダクト戦略レベルの相談が主になってきていると思います。企画チームと一緒に仕事をしてきたということで、企画チーム(プロダクトマネージャー)に転身している分析メンバーもいることでしょう。ちなみに、FiNCでも分析からプロダクトマネージャーになったメンバーがいます。
では、このフェーズにおけるFiNCデータ分析グループの役割とはなんでしょうか？それは、「より高度なデータ活用を行い、事業に貢献する」ということです。ある会社では離職率を下げるためにデータ活用をしたいかもしれませんし、その他の会社では営業やマーケティングにデータ活用をしたいかもしれません。このように、自社 ×データ で何を実現できるか考え、領域問わずチャレンジしていくことが求められます。
たとえばFiNCでは
FiNCでは、プロダクトにいくつかAIが搭載されていますが、それらはまだまだ発展途上です。たとえば、下記のように「あなたに合ったラクに続けられるメニューを厳選してお届け」というコンセプトがありますが、このコンセプトを体現するアルゴリズムはもっと洗練できると思っています。
もう少し詳しくいうと、「どのようなユーザー」に「どのようなメニュー」を「どのようなタイミング」で届けるのか、ということを最適化できると考えています。
一例として、「睡眠前に行うと効果的なストレッチ」というコンテンツ一つをとっても、ユーザーごとに睡眠時刻は異なります。当然、このコンテンツを届ける時刻も異なってしかるべきです。また、睡眠前といってもすでにベッドに入ってしまってからコンテンツが送られてきても遅いわけです。ユーザーごとに最適なタイミングが異なるのであれば、ユーザーごとに異なる時刻にコンテンツを届けるべきです。
このように、コンテンツを届ける時刻一つでも非常に繊細なパーソナライズが求められることが分かっていただけたでしょうか？実際は、配信時刻だけではなく、運動強度・生活習慣・体形・職業なども考慮しながら適切なコンテンツを選択するということも重要です。
また、これを実現するための説明変数は何か？学習アルゴリズムはなにを採用するか？どういうデータ構造のデータを持つ必要があるのか？良いアルゴリズムかどうかをどう評価するのか？といったようなことも考えながら進めていく必要があります。
FiNC Technologies のデータ分析グループはあなたをもとめています
FiNC Technologies の データ分析グループはいまちょうど④に本格着手したばかりというフェーズです。上記のような、コンテンツ時刻最適化問題などに取り組み始めています。
また、上記の課題をうまく解決したとしても、今度は新しい課題がいくつも出てくるでしょう。それは画像解析かもしれませんし、自然言語処理かもしれません。そのような課題を一緒に成長しながら、一緒に解いていくメンバーを募集しています。まずは、オフィスに来ていただき、いろいろな課題について、カジュアルにディスカッションなどできれば最高です。ヘルスケアで世の中を一緒に変えていきませんか？
