はじめに
DELISH KITCHENでデータサイエンティストをやっている山西です。
今回は「データサイエンティストとしてプロダクト開発プロジェクトに積極関与した経験談」をお送りします。
背景
DELISH KITCHENをはじめとするプロダクトの開発/改善は、仮説検証サイクルによって日々推進されております。
仮説検証サイクルにより、各機能/改善のリリース後の効果の良し悪しが分析によって振り返られ、次の方策へと繋げられていきます。
本記事では、データサイエンティストの立場で、この仮説検証サイクルを支援するプロダクト改善フローを紹介します。
実践して学んだことや意識したこと等々もポエム調で織り交ぜていきます。
業務フロー
プロダクトの仮説検証サイクルにおけるデータ職責としての業務フローは、
- 分析の準備
- データの準備
- 分析および振り返り
に大別できます。
以下、それぞれの業務感について簡単に紹介します。
1. 分析の準備
KPIとログの設計
プロダクトへの新機能追加/または改善を行う際、リリース後にその結果の良し悪しをKPI、特定の指標で観察することになります。
よって、
何を観測したいか
→そのためにはどんな準備（分析設計/ユーザーの行動ログ）が必要か
をPdM（プロダクトマネージャー）と連携しながら整理していきます。
その具体作業や心持ちは以下の記事に詳しくまとめています。 tech.every.tv
当たり障りの無い主張ではありますが、「目的、仮説をしっかり言語化し共通認識を持ったうえで具体（ログ、分析手法）を詰める」ことの大切さを、実践してみて改めて学ぶことが多々ありました。
ここが疎かになると、
- KGIからズレたKPIを設定してしまう
→ 視点のすり合わせが出来ていない。アウトカムが意識出来ていない。 - 仕込んだログが宙に浮いたり一人歩きしたりする
→ ログが使われない、意図されない使われ方をしてしまう。 - 本来の目的とずれた分析をしてしまう
→ 統計、機械学習的にはリッチでも、ビジネスサイドから見たらSo What?な示唆になりがち - 過剰な準備をしてしまう
→ ダッシュボード作ったけど見られない、使われない問題
など、苦い着地をしがちです。
企画時点から一蓮托生的にPdMと視点をあわせることが、より良い仮説検証サイクルを目指すため近道になると感じております。
A/Bテストによる効果検証の準備
プロダクトの開発/改善を振り返るための効果検証のアプローチとしては、A/Bテストを採用することが多いです。
過去にその推進の具体感や全体像についてそれぞれ紹介した記事があるので、よろしければご覧ください。 tech.every.tv tech.every.tv
2. データの準備
分析としての準備が出来たら、次はデータの準備に取り掛かります。
1.で策定した分析計画の具現に向け、ユーザーの行動ログ等のビッグデータを目的に応じた形で利用可能な状態を作り出します。
そのために、
- Spark, SQLを駆使しつつETLを実装
- 必要に応じて中間テーブルを実装
- BIツール（ダッシュボード）による可視化、定期実行体制の構築
- A/Bテストの設定
等々、いわゆるアナリティクスエンジニアリングの部分もデータ職責として一通り行います。
弊社は、データサイエンティストでも結構ETL等、データ処理をはじめとしたエンジニアリングのコードを書いている組織だと勝手に思っています。
（データエンジニアと完全分業できるほど人員が多く無い」という裏事情も正直あったりはします。）
これは個人のスペシャリスト志向、ジェネラリスト志向等々のキャリア感にも左右され賛否両論はあると思います。
が、個人的には「"データの成り立ち"や"ビッグデータとしての集計の勘所"を経験で裏打ちできる」ことで生まれるプラスの側面も大きいと考えております。
例えば以下のエピソードが挙げられます。
エンジニアリング目線も加味しつつログ設計を最適化出来る
前段の話に戻りますが、「1. 分析の準備」でログを設計する際には、
- 事業視点（観察したいKPIに対してどういうログが欲しいか）
を考慮していました。
ここにさらに
- エンジニアリング視点（どういうログだと、効率的にETL, 集計管理できるか）
を加味できるようになれば、双方の視点を踏まえたログ設計が可能になります。
データのニーズの変化に臨機応変に対応できる
ビジネスサイドの要求は往往にして変化しがちです。
仮説に沿った分析、ログ設計計画を立てたとしても、「違う角度からデータを見たい」という要望は多々発生します。
こういう際、データエンジニアに頼らずとも「自前でデータの奥底にまである程度触ることができ、ETL手法や中間テーブルの持ち方等を再検討して新たなデータのニーズに対応できる」ことは、手の動かしやすさ、俊敏性に直結すると感じております。
3. データの分析
機能がリリースされ、データが観察可能な状態になったら、その経過をKPIの観察、BIツールの観察等で見守ります。
そして、最終意思決定者であるPdMと共に結果や考察をまとめていきます。
仮説検証としては「1. 分析の準備」の内容の履行が主になりますが、必要に応じて追加の事後分析や探索的分析も行います。
例えば、「KPIの単純集計」や「シンプルな可視化」よりもさらに奥行きのある示唆（ユーザーニーズや、根底に潜むユーザークラスタなど）を得たい場合は、データと分析の特性に合った多変量解析やら機械学習手法を選定し実施します。
また、A/Bテストでは、解釈に癖のある「有意差」をどう評価するかなどなど、統計的な知見の解釈のサポートを行ったりもします。
そして、このようにして統計、機械学習の文脈で得られたデータ解釈を、PdM向けに還元することになります。
- データの本質に着眼し、良い分析手法を選定し示唆を出すためのデータサイエンスのハードスキル面
- その解釈結果をビジネスの言葉に翻訳し、PdMに還元するための言語化等々のソフトスキル面
など、意思決定を支援する計らいはさまざまな難しさはあるものの、新たな知見が生まれたり、成果に寄与したときは達成感があります。
終わりに
簡単ですが、プロダクト開発におけるデータサイエンティスト（アナリティクスエンジニアに近いかもしれません）の立ち回り例を紹介しました。
データ人材としてプロダクトの価値の増大に貢献できるよう、引き続き精進していきたいところであります。
似たような背景、課題感を抱えたどなたかに対して、この記事で何かしら響くものがあれば幸いです。
