エンジニアとデータサイエンティストがもっと仲良くなるためのデータサイエンティストの話

2018年12月19日に発表した第1回DSE勉強会の発表資料です。

Transcript

1. エンジニアと データサイエンティスト がもっと仲良くなるための データサイエンティストの話 DBD DSE 西山 徹
2. 2 サマリ • 自己紹介 • Introduction • この会の目的とか • おことわり • 本題 • 前菜:「でーたさいえんてぃすと」「えーあい」って? • データサイエンティストってどんな人? i. データサイエンティストのスキルセット • データサイエンティストってどう働いてるの? i. 一般的なデータ分析プロジェクトのよくある流れ ii. DSEのデータサイエンティストが今、何をしているか • エンジニアとデータサイエンティストがシナジーを発揮するために • Appendix • データサイエンティストになろう! i. 目的別データ分析関連書籍
3. 3 Introduction • この会の目的とか • エンジニアとデータサイエンティストが もっと仲良くなればお互いのスキル上がるし、 きっとFortunaも良いものになるよねー • ので、エンジニア <-> データサイエンティスト間で 積極的に技術交流していきましょう! • ということでまず今日は、「そもそも データサイエンティストって何?何してるの? 何属性が弱点?」みたいな話をしたいと思います
4. 4 Introduction • おことわり • 話の性質上主語が大きくなりがちですが、 お手柔らかにお願いします
5. 5 本題
6. 6 「でーたさいえんてぃすと」「えーあい」って? • …ぶっちゃけよくわかんないですよねーー(^q^) • そうだ!詳しそうな人に聞いてみよう!
7. 7 OK, Google. 「データサイエンティストって何?」
8. 8 「でーたさいえんてぃすと」って? • By 営業の人とか偉いおじさん • 「エンジニアと一緒。プログラム書いてるし。」 • 「統計に詳しいマーケターでしょ。」 • 「AI作れる人。機械学習とかどうでも良いからさっさと ディープラーニングしてよ。」 • By 知ってそうな感じの人 • 「データサイエンティストはデータエンジニアとは違って ビジネス理解も大事だよねー」 • 「論文を読んで提案手法をスクラッチで実装できないと 本当の意味でデータサイエンティストとは言えない(ｷﾘｯ」 • 「データ分析以外の仕事も降ってくる辛いお仕事です」 • By 金融系の人 • 「うちにはアクチュアリーならいるけど?」
9. 9 Hey, Siri. 「AIって何?」
10. 10 「えーあい」って? • By 営業の人とか偉いおじさん • 「Watsonを使って外注で開発した わが社のチャットボットこそAIです」※中身はルールベース • By 知ってそうな感じの人 • 「ロジスティック回帰をAIって言うのはないわー。」 • 「ディープラーニングならAIなの? 結局は機械学習(統計)モデルでしょ?」 • BySiri • 「私のことですが何か?」
11. 11 結論: どっちもバズワードなので 明確な定義はありません
12. 12 「でーたさいえんてぃすと」「えーあい」って? • …それだと身も蓋もないので最低限説明します • データサイエンティスト • データ分析業務に従事する人。 • 現状データ分析業務のプロセスが広く一般に 確立されていないので、人によっていろんな仕事を やらざるをえないやっているので誤解されがち。 • データを使って有用な知見を導出するために、 統計学だったり機械学習の知見を使う人々。 • AI • 略(理由は口頭で)
13. 13 データサイエンティストって どんな人?
14. 14 データサイエンティストってどんな人? • データサイエンティストのスキルセット • 一応偉い人が教科書的な定義を決めたらしい
15. 15 データサイエンティストとは? • データサイエンティストのスキルセット a. ビジネス 力（business problem solving） b. データサイエンス 力（data science） c. データエンジニアリング 力（data engineering） 出典: http://www.datascientist.or.jp/news/2014/pdf/1210.pdf
16. 16 データサイエンティストとは? • データサイエンティストのスキルセット • 複合スキルを活かしてデータ分析課題に取り組む人と言えそう • 周りの人を見ていてもどれかのスキルを軸に活躍している人が多い (気がする) • ビジネス 力（business problem solving） • コンサル・マーケター・営業出身の人とか • データサイエンス 力（data science） • 学生時代に統計・機械学習の研究した人とか、あるいは 研究スキルをデータサイエンス分野で活かしてる人とか • データエンジニアリング 力（data engineering） • (web系orソフトウェア)エンジニア・SI系出身の人とか • その人がどの系統っぽいかを見極めると話がしやすいかも • スキルセットのイメージを具体化するためにはこんなのも • ちなみにもうちょっと細かい分類もある 出典: http://www.datascientist.or.jp/news/2014/pdf/1210.pdf
17. 17 データサイエンティストとは? • データサイエンティストと似てる人たち? • データアナリスト(ビジネスアナリスト) • データエンジニア • 機械学習エンジニア • AIエンジニア • データサイエンティストと同様明確な定義はない • つまり、組織によって役割は違う • ただし、「◦◦エンジニア」は分析基盤の構築やモデルの運用 などエンジニアリング色が強い業務、 「◦◦アナリスト」は組織の意思決定やKPIモニタリングや施策導出などビ ジネス色が強い業務をやってる印象 • 両者を一緒くたに「データサイエンティスト」と呼んでいる ケースも多い(冒頭の例)
18. 18 データサイエンティストって どう働いてるの?
19. 19 一般的なデータ分析プロジェクトのよくある流れ • 具体的なモデルケースを見ていきましょう • ケース • あなたはソシャゲ企業のデータサイエンティストとして、 スマホゲーム上の行動ログを用いてユーザの離反予兆を 検知するモデルを作成することになりました
20. 20 一般的なデータ分析プロジェクトのよくある流れ • 大まかなプロセス • 要件定義 • データ確認 • 予測モデル構築 • (予測モデルのAPI・バッチ化) • (精度のモニタリング) 各プロセスで行うことを詳しく見ていきます
21. 21 一般的なデータ分析プロジェクトのよくある流れ • 要件定義 • 予測モデルを構築するためにどのようなデータが使えるか 確認する • 例えば、単なるアクセスの有無だけでなく、どういった行動 (イベント参加・ガチャの結果)をとったかわかる状態に なっているか • 詳細は実際にいじってみないとわからないので、ざっくりで良い (ただし「いじってみないとわからない」ことを関係者と 合意する必要がある ) • 「離反」をどう定義するか • 例えば「最終ログインから、何日空いたら離反」と定義するのか • これが「目的変数」と呼ばれるものになる • 予測モデルをどうビジネスに活用できるか • やりたいことが「予測モデルにより離反するユーザを事前に検知、離反予 兆ユーザのための施策により離反が防止できる」 ことだとすると、施策を打つために離反の何日ほど前から予兆が わかっていないといけないか
22. 22 一般的なデータ分析プロジェクトのよくある流れ • データ確認 • 実際のデータを確認して、データにどのような 特徴があるか確認する • DAU, MAUは?1ユーザあたりの行動ログ数は? 離反ユーザの数は?離反が多い・少ない時期はある? 離反ユーザはどのくらい前からアクセス傾向に変化が ありそう? • ここで行った確認結果を通して、 「使えそう(ビジネスに活用できそう)な予測モデルができる か」を関係者と詰めていく
23. 23 一般的なデータ分析プロジェクトのよくある流れ • 予測モデルの構築 • ここまでに得られた情報を元に、 機械学習モデルを構築する • どういう特徴量を使うべきか・あるいは使わないべきかを判断する • 構築したモデルによる予測結果を担当者に 展開し、ビジネス活用が可能かどうか改めて 協議する • 実際に離反ユーザを予測できるか・予測したユーザに 施策を打つことで離反が防止できそうかなどを テストすることを含む
24. 24 一般的なデータ分析プロジェクトのよくある流れ • 例えばこんなことを考える • 3日間ログインなし -> 離反と定義し、 それを1日前に予測できるモデルを作った例 12/12 12/9 12/8 12/1 この期間の行動で 離反する/しないを予測する 離反予兆ユーザに離反防止 施策を打つための期間 離反期間(ログインしない) ≒コミュニケーション できないので手遅れ
25. 25 一般的なデータ分析プロジェクトのよくある流れ • 例えばこんなことを考える • 3日間ログインなし -> 離反と定義し、 それを1日前に予測できるモデルを作った例 12/12 12/9 12/8 12/1 この期間の行動で 離反する/しないを予測する 離反予兆ユーザに離反防止 施策を打つための期間 離反期間(ログインしない) ≒コミュニケーション できないので手遅れ マーケ担当からのコメント : 施策を打つのに1日じゃ短いよ。 もっと前に離反予兆ユーザが知りたい
26. 26 一般的なデータ分析プロジェクトのよくある流れ • 例えばこんなことを考える • 3日間ログインなし -> 離反と定義し、 それを1日前に予測できるモデルを作った例 12/12 12/9 12/6 11/29 この期間の行動で 離反する/しないを予測する 離反予兆ユーザに離反防止 施策を打つための期間 離反期間(ログインしない) ≒コミュニケーション できないので手遅れ データサイエンティスト : 離反の3日前に予測できるよう にモデルを改良しました。 そのかわり、精度は5%ほど 落ちてしまいます。
27. 27 一般的なデータ分析プロジェクトのよくある流れ • 例えばこんなことを考える • 3日間ログインなし -> 離反と定義し、 それを1日前に予測できるモデルを作った例 12/12 12/9 12/6 11/29 この期間の行動で 離反する/しないを予測する 離反期間(ログインしない) ≒コミュニケーション できないので手遅れ データサイエンティスト : 離反の3日前に予測できるよう にモデルを改良しました。 そのかわり、精度は5%ほど 落ちてしまいます。 マーケ担当からのコメント : 精度が下がったのは仕方ないけど、 3 日あれば複数の施策も打てるしこっち の方が良いかな。 色々施策打ってテストします ! 離反予兆ユーザに離反防止 施策を打つための期間
28. 28 一般的なデータ分析プロジェクトのよくある流れ • 予測モデルのAPI・バッチ化 • 前段の議論で予測モデルが活用できそうとなった 場合、予測モデルをスケジュール実行できるように する必要がある • 必要なデータ加工・予測モデルによる予測結果の付与な どを自動化できるようAPI・バッチ化する • ここで既存のインフラ担当者などとやりとりが発生する
29. 29 一般的なデータ分析プロジェクトのよくある流れ • 精度のモニタリング • 予測モデルは、通常一定期間を経ると精度が 落ちてしまう • なので、常に予測精度が落ちていないか監視し、 定期的に予測モデルを作り直す必要がある • 上記をある程度自動化するために、ダッシュボードで 精度を手軽に監視できる仕組みをつくる必要がある • ここらへんは失敗談を過去に発表してるので よければぜひ
30. 30 DSEのデータサイエンティストが今何をしているか • 一般的な「データ分析プロジェクト」にとどまらず 色々やっている • アルゴリズム&モデリング • 機械学習モデル構築ツール(dsciAI)の開発 • データクオリティ • SS保有データの品質の標準化・向上 • マーケティングサイエンス • マーケター向き合いのデータ提供および新機能開発 • R&D • 自然言語処理技術を用いたユーザの特徴量抽出方法の検討 • 新規データ分析基盤の検討 • 商圏分析 • …色々ありつつトライアルカンパニー様と粛々と進めてます
31. 31 エンジニアと データサイエンティストが シナジーを発揮するためには?
32. 32 エンジニアとデータサイエンティストが仲良くするためには • 前提 • エンジニアとデータサイエンティストは、 スキルセットだけでなくマインドセットも違う • ここを意識するのが協業していく際の一番の ポイントになると思っています • 極論、エンジニア <-> データサイエンティストに限った話 ではないですが… • ので、データサイエンティストがエンジニアと 協業する際につまづきそうなポイントを まとめてみます
33. 33 エンジニアとデータサイエンティストが仲良くするためには • ケース • ある飲み会での愚痴 • データサイエンティストside 「あの人(エンジニア)は、コード書く力は間違いないけど ビジネス理解がいつも浅いからなあ…コードが汚いって すぐ怒るし。良い分析結果出てるんだから別にうるさく 言わなくても良いのになあ。」 • エンジニアside 「あの人(データサイエンティスト)の書くコード、 オレオレ記法が多すぎて読み解け無いんだよなあ… ろくにテストもしてないコード渡してくるしgitも ちゃんと使えないし。」
34. 34 エンジニアとデータサイエンティストが仲良くするためには • さっきのケースで伝えたいこと • データサイエンティストとエンジニアは 仕事の進め方や大事にしている価値観が異なる • 両方の価値観を正確に理解するのは難しいけど、 どういった違いがあるのかは理解できると良さそう データサイエンティスト養成読本 ビジネス活用編 p.87 より引用
35. 35 エンジニアとデータサイエンティストが仲良くするためには • データサイエンティストがエンジニアと協業する上で 障害になりそうなところ • チーム開発の経験が少なかったり、 コードの品質管理に疎い傾向にある • 分析プロジェクトでは、書捨てのコードも多く発生し、 必ずしもコードをGitで共有・品質管理しない • モデルをアプリケーションの中で運用する視点が弱い • アプリケーション開発・運用の視点が抜けてしまうと、 精度ばかりに着目してしまい、メンテナンス・運用コスト が高い予測モデルができたりする • 気づいたことがあったら随時議論しましょう!
36. 36 まとめ • データサイエンティストに対する理解を 深めてもらうための基礎知識や、エンジニアと どういう時に協力が必要になるのか、 どういうポイントで躓きそうかをまとめました • もちろんこのケースにあてはまらない例も 多々あるかとは思いますが、少しでも 参考になると嬉しいです