新米データサイエンスチームのこれまでとこれから

はじめに

株式会社オズビジョンにてエンジニア8年目のテラシマユウコ (@terra_yucco) です。
通常開発の他、オフショア開発のブリッジエンジニアや運用保守作業、企画のためのデータ出しなども担当させてもらっています。

ここまで雑多なキャリアを積んできた私ですが、今期、新設部署「データサイエンスチーム」にも兼務で配属されました。
今回のこの記事では、そもそもなぜこのチームができたのか、一介のPHPエンジニアにすぎない私がなぜ配属されたのか、配属されてから何をやってきたのか、これから何をやっていきたいのかを書いていきたいと思っています。

お時間がない方は「まとめ」をお読みください。

なぜこのチームができたのか

オズビジョンのメインプロダクトはポイントサイト「ハピタス」です。
ポイントサイトのモデルである「アフィリエイト」は、商材にもよりますが、ユーザの行動から一定の期間をおいて運営側に収益が入ります。そのため、ビジネスとしてやっていくには、何月にどれくらいの売上が立つかが非常に読みづらいモデルとなります。
これまでは現場担当者の勘と、代理店ヒアリングで数字を出していましたが、年々乖離が広がり状況が読めなくなってくるという問題が発生しました。

その結果、経営層からは、以下のようなビジネス上の「要望」が発生します。
これに回答したい、というのが発足のきっかけでした。

ビジネス上の「要望」

YYYY 年 MM 月の売上は一体いくらになるのかを、月初のタイミングで知りたい

なぜ私が配属されたのか

おそらくこれは以下の 2 点かと思います。

• 社歴が長く、その大半をメインプロダクト「ハピタス」で過ごしているため、ドメイン知識が多いこと
• 整理した内容を他人に伝えるのが得意な傾向があるため

データサイエンスの勉強をしていたわけでも、機械学習のスキルがあったわけでもありません。(今もまだあまりないです)
データベーススペシャリストは持っていますが、どちらかといえば重視されたのは「ドメイン知識」と「整理・説明能力」だったように思います。

もちろん暗黙の条件として、最低限の SQL の知識というものはあげられますが、これは社内のエンジニアであれば大体クリアしている水準のものしか利用していません。

配属されてから何をやってきたのか

理解と整理

• ビジネス上の「要望」に対して回答するために必要なものは何か
• 必要なもののうち、既にあるものは何か、不足しているものは何か

ビジネス上の「要望」に対して回答するために必要なものは何か

再掲しますが、今回のビジネス上の「要望」は「YYYY 年 MM 月の売上は一体いくらになるのかを、月初のタイミングで知りたい」というものです。
これを以下のように整理・分解しました。

• 売上とは「売掛金」であり、実際に振り込まれるタイミングではない
• 売上は締め日までに設定されたものを正とする
• 売上の構成要素
  • アフィリエイト報酬
  • 露出枠売りの固定報酬
  • その他 SSP 広告による売上など

必要なもののうち、既にあるものは何か、不足しているものは何か

構成要素それぞれについて確認した結果が以下の通りです。

種別	既にあるもの	不足しているもの
締め日の概念	スプレッドシートへの記載	SQL などで参照できる形で存在しない
アフィリエイト報酬	通常フローで取り込まれたものの売上	問い合わせ対応などのイレギュラーフローによる売上
露出枠売りの固定報酬	スプレッドシートへの記載	SQL などで参照できる形で存在しない
その他 SSP 広告による売上など	同上	同上

その他、検討時に出てきた要検討事項は以下の通りでした。

• アフィリエイト報酬
  • データにいくつかのステータスがあり、ステータス遷移の際に数値が変わることがある
  • 過去の傾向も予測に利用するため、過去の実績が必要
  • アフィリエイト成果がなくとも、問い合わせの対応などで裏で発生するデータも存在している
    • その結果、代理店からの最終報酬と、システム内のデータの数値は一致しない
• 露出枠売りの固定報酬
  • 前月の末に翌月分は大体提案が終わっている
  • しかし金額が足りない場合は駆け込み提案することもあり、最終結果を予測しづらい

不足事項、要検討事項の解消

これは簡単で (工数は別の話です) 不足事項と要検討事項をつぶしていくだけです。
ここは自力だけではなく、周囲のエンジニアにかなり助けられました。

• アフィリエイト報酬
  • ステータス遷移の際の数値の変動率を過去データから算出して適用
  • 実績データを取り込めるようにする仕組みの開発
    • 実績データを取り込んだタイミングで締め日を打つ
  • 問い合わせ対応のデータを売上にも取り込める仕組みへ改修
  • 上記でもカバーできない数値のずれは、代理店単位でのずれ率を過去データから算出して適用
• 露出枠売りの固定報酬
  • データ管理できるように機能開発
  • 月初時点の値がほぼ最終に近いため、予測はせず実績値を用いる

実実装

上記が解消でき、必要なデータが揃った後の集計 (データマート作成) は BigQuery を使いました。

データサイエンスチームの発足前にも、オズビジョンでは何回か分析に取り組もうとした過去がありました。
サービスローンチ後の比較的早い時期にデータの集計を行えるようにし、ユーザの LTV や ROI と言ったものを追えるようにしてきましたし、Tableau や Yellowfin、Redash などで参照できるように、プロダクトのデータがある AWS から分析用の BigQuery への日次転送なども行われていました。
今回はその資産を流用させてもらった形となっています。そのため、BigQuery がデータレイクとデータマートの役割を担っています。ただし、オリジナルのデータからデータレイクへ格納する際には、現状はほぼ何もしていません。

内容はシンプルに INSERT INTO data_mart.table SELECT a, b, c ...snip... FROM data_lake.table WHERE hoge = fuga ... snip ...; といったクエリを繰り返すものになっています。

ref) 【BigQuery初心者の雑記 vol.1】BigQuery Scripting で集計バッチ要らず

これから何をやっていきたいのか

売上予測について

精度の課題や、その都度出てきた要望への対応などを取り入れ、複数回のバージョンアップを経て、現在システム内で売上予測が日々動いています。BI ツールを利用した確認もできるようになってきました。

しかし、今回は機械学習などを入れているわけでもなく、過去の傾向からの予測を出すものになっているため、どうしても精度の課題は残っています。
深掘りをしていって見えてきたこととしては、細かいことは割愛しますが、「クライアント」「代理店」「ハピタス」全ての場所にどうしても人の手による作業が介在するため、それだけでも簡単に月単位で売り上げがずれたりすることがわかりました。
この辺りの精度改善は終わりが見えないため、売上予測については課題が残りますが、一度クローズとしています。

集計、データ自体について

今回、過去の資産の BigQuery を使わせてもらっていますが、ドメイン知識が十分とは言えない状態で転送を優先した当時の背景があるため、データ自体の信頼性が万全でないという問題がありました。

また、そもそもアプリケーション側に以下のような問題があります。

• 必要な正規化が足りず、同じデータを冗長に登録している
• 必要なデータが取れていない部分がある
• 既に使われなくなったデータが複数存在している
• ドメイン設計がしっかりされていないため、類似のデータが複数ある場合の正解がわからない

このあたりは愚直に対応しているのであればアプリケーションを直していくことになるのですが、レガシーコードが積み上がっていることもあり、調査と対応には膨大な工数がかかります。

今も、必要に応じてデータのクレンジングや選定を行っているので、データカタログを活用したデータレイクの整理をまずは進めていきたいと思っています。
システムは AWS にあるのに、分析は BigQuery なので、この辺りももっと最適化できるんじゃないかと思っています。
(とはいえ BigQuery の速さはすごい！)

【重要】そもそものビジネス課題について

今回、ビジネス上の「要望」は「YYYY 年 MM 月の売上は一体いくらになるのかを、月初のタイミングで知りたい」というものでしたが、結論から言うと いきなり予測に手を出すべきではなかった と言えます。

予測はできたけれどもそれによってどう動けば良いかわからない

これが今発生している大きな問題で、前述したようにアフィリエイトは「ユーザの行動から一定の期間をおいて運営側に収益が入る」仕組みです。そのため逆に言えば、「一定の期間をおいた」あとの着地見込みが出て、そのタイミングで焦っても、もうできることはほとんどないということが (今更ですが) 見えてきました。

また、予測値が大幅に達成見立ての場合、さらに積もうという動きが鈍化する傾向もありました。
現状ではこの予測自体は、傾向を知ることはできるものの、ビジネスを加速させるものにはなっていません。

やるべきだったこと

図はお借りしたものです。¹

データ分析とその活用による事業の加速は、「蓄積」「管理」「可視化/分析」「分析/予測」と進むべきでした。同じような図はたくさんありますが、全てをすっ飛ばしていきなり予測をしている例はありません。
今回「蓄積」は一部できていましたが、「管理」「可視化/分析」をすっ飛ばして「分析/予測」に進んでしまったため、仮説がない状態で予測だけ提供してしまい、結果的にはビジネスが動けない状態となってしまいました。

また、一部できている「蓄積」についても、ローンチから 10 年近くが経過し、サービスも複雑化し、当時の要件だけでは集計で見たい数値が追えないケースが増えてきています。

• 初期の検討不足
• 新規追加機能の考慮
• 分析軸の追加要望

その結果、各人が色々な方法で集計を行いはじめ、定義も出どころも不明な数字が氾濫し、経営から現場までが振り回され始めてきたため、一度基本に立ち戻るのが大切だと感じました。

後戻りにはなってしまいますが 「蓄積」「管理」「可視化/分析」をまずしっかり進めていかなければならないと考えています。

まとめ

ポイントサイト「ハピタス」を運営する株式会社オズビジョンにおける、データ分析のこれまでとこれから。

• 月次の売上を予測したいという要望に対応するため、データサイエンスチームが発足
• 要望の理解と整理を行い、不足事項や要検討事項を解消し、当初の要望である月次売上予測は完成
• しかし、現状分析をしないまま「予測」だけを提供しても、ビジネスを加速できなかった
• 基本に立ち戻り「蓄積」「管理」「可視化/分析(現状分析)」を進めていきたい

長々とお付き合いありがとうございました。

1. 第3世代BIにおけるデータ分析基盤の整備・構築と活用 ↩