データ整備業でぶつかった5つの課題_データ整備人に求められる3つのスキル_SD用.pdf

Transcript

1. データ整備業でぶつかった5つの課題 データ整備人に求められる3つのスキル 2019/11/27 (Wed) データアーキテクト（データ整備人）を”前向きに”考える会
2. 1. 自己紹介と業務紹介 2. データ整備業でぶつかった5つの課題と解決方法 3. データ整備人に求められる3つのスキル アジェンダ

3. 自己紹介と業務紹介
 

4. 自己紹介①
 名前と所属
 ・岩井晋太郎( @hogeta_)
 ・株式会社オプト データテクノロジー部 
 
 仕事のこと
 ・営業 → アフィリエイター → エンジニア → データ整備人(現職)
 ・アプリDMPサービスのサーバーサイドエンジニアとして弊社でのキャリアをスタート 
 ・今はデータ整備人の傍ら、コード書いたり、マーケっぽいことやったり、PMやったりしてる。 
 ・敬虔なるBigquery信者 
 
 個人的なこと
 ・出生は秋田県。都会に憧れて東京に出てきたけど永住の地は千葉になりそう 
 ・趣味は筋トレ(BIG3で300kgいけるようになったので中級者) 

5. 自己紹介② 圧倒的操作系

6. ・株式会社オプト ・Webの広告代理店 ・クライアントのデジタルシフト支援に力を入れるなど 広告以外のマーケティング領域にも注力 ・以下のツールを内省していた(どちらもBQを採用している) 会社紹介
 アプリのDMP AdjustやAppsflyerなどのアプリSDK のローデータを蓄積する Webの広告計測ツール (事業譲渡が決まった。。。 )
7. データ整備業の5つの課題と解決方法

8. 話すこと・話さないこと
 ・データ整備業においての泥臭い運用の話 ・SQL周りのお話 話すこと ・データエンジニアリングの話 ・機械学習周りの話 話さないこと
9. どんなデータを扱っているか
 ・ADPLAN ・GA360 ・TreasureData ・POSデータ ・マスターデータ ・Adjust ・Appsflyer ・Firebase ・施策のデータ(SMC等) ・3rd Party DMP web App クライアント基幹データ その他
10. どんな依頼がくるか
 KPI設計して ちょっと自分で分析し たいから綺麗なデータ 頂戴 営業したいんだけど データ使って何かでき ない？ この広告施策の 成果が悪い。 なんで？ 広告活用にデー タ活かしたい！ シードをくれ！ ダッシュボードって 作れますか？ 今エクセルで やってる作業を 簡単にできるよう にしてよ webとapp横断 で分析がしたい CRMに活かした い。顧客ランクを つけてくれ 媒体の管理画面で 見れない指標が見 れると聞いて BQ叩かせろ！
11. 1. 意思決定の材料が欲しい 2. 広告活用したい 3. 自由分析したい 依頼の内容を大別すると３つ

12. どこ(誰)からデータ抽出依頼がくるか
 クライアント 社内からの依頼 クライアントからの依頼 同じ部の営業 広告運用 コンサルタント 広告営業 同じ部の営業 上司 基本的に同じ部の営業が一次受けをしてくれる(ことが多い)
13. 求められていること・求められていないこと
 ・意思決定のための示唆 ・意思決定をするために必要なことのすり合わせ 求められていること ・意思決定をすること ・統計的知見による助言 求められていないこと
14. どうやって依頼を解決するか

15. 結局やっていることはSQL職人

16. 1. 雑に依頼がきて辛い 2. SQLのレビューが辛い 3. 類似した依頼が何度もきて辛い 4. ノウハウが共有されなくて辛い 5. リソースが足りなくて辛い データ整備業をしていてぶつかった5つの課題

17. 課題 1
 雑に依頼がきて辛い

18. 課題1: 雑に依頼がきて辛い
 とりあえずデータ出してよ、と言われた
 
 その度に僕は唇を噛み締め、APIじゃないんだぞ、と強く思った。
 
 しかし、なすすべなく画面に向かうのだった。。。

19. 自然と目的が添えられた上で依頼がくるようになった。 同時に自分自身のドメイン知見も向上した。 そもそもデータを出さずに課題解決することもたまにあった。 依頼者に対して何をしたくてデータが欲しいかをしつこく聞いた。 納得感がない場合は断ることも。 課題1: 雑に依頼がきて辛い
 やったこと① データがあると何が嬉しいんですかと聞くようにした 結果: 成功
20. ・目的、期限、希望のアウトプットなど必要な情報の漏れがないように 　依頼時のフォーマットを作った。 ・アウトプットのイメージで合意が取れるまで作業に着手しないようにした。 手戻りが圧倒的に少なくなった。 アウトプットのイメージを握っておくことで齟齬が生じなくなった。 課題1: 雑に依頼がきて辛い
 やったこと② 依頼のフォーマットを作った 結果: 成功
21. 課題 2
 SQLのレビューが辛い 

22. SQLのレビューが辛い３つの理由 1. SQLが読みづらい (書き手よってインデントが違ったりとか) 2. SQLがスパゲッティ 3. データの仕様が分からない 課題2: SQLのレビューが辛い 

23. 課題2: SQLのレビューが辛い 
 SQLの書き方を統一してレビュワーが読みやすくするのが狙い。 インデントやView、カラムの命名規則など細かく作成した。 やったこと① SQLスタイルガイドを書いた ・浸透させるのが難しいのと、スタイルガイドからのちょっとのずれを指摘するのは本質 的ではない。フォーマッターがないと浸透は難しそう。 ・とはいえ、いくつかのルールは徹底されている(後述) 結果: 失敗
24. ・全てをcolab化するのは逆にコストが増えるが、重要度が高いものや複雑なものは colabを使うとレビューがしやすく、知見も共有しやすい。 ・SQLをかけないビジネスメンバーへの説明も容易になる ・結果をDataflameとしてpythonで扱えるので統計情報を見たり、可視化したりして異常 値に気づけるきっかけになる 課題2: SQLのレビューが辛い 
 Google Colaboratoryで途中の処理を可視化しながら処理の流れを把握できるようにす ることが目的。 SQLがスパゲッティでも順次処理を追っていけば理解しやすい。 やったこと② Google ColaboratoryでのSQLレビュー 結果: 成功
25. 課題 3
 類似した依頼が何度もきて辛い

26. 課題3: 類似した依頼が何度もきて辛い
 例えば、期間を変えるだけ、など過去に出したものの焼き直しみたいな 依頼は頻繁にある。 そういったものは可能な限り手間をかけずに出したい、 なんなら一次受けした営業さんに捌いてもらいたい...
27. スタイルガイドで唯一徹底されている「変数定義を一番上にする」のおかげで githubに再利用がしやすい形で過去の事例が溜まっている。 類似分析をする際に1からクエリを書かなくていいように汎用的に作成し、githubに保 存。汎用的な形とは変数をSQL文の一番上に書くこと ※保存先はBQでも良かったが検索しづらいのと githubでのレビューの都合上不採用 課題3: 類似した依頼が何度もきて辛い
 やったこと: 再利用がしやすい形でSQLを作成し、githubに保存 結果: 成功
28. 再利用しにくいSQL
 SELECT count(distinct id) FROM table WHERE date = “2019-11-11” # 任意の日付を入力してください AND event = “install” # 任意のイベントを入力してください 例:任意の日のインストール UUを出すSQL コメントで変更箇 所を示す 変更部分にコメントを書く。コメント部分を探すのが大変
29. 再利用しやすいSQL
 create temp function targetDate() as ("2019-11-11"); create temp function targetEvent() as ("install"); SELECT count(distinct id) FROM table WHERE date = targetDate() AND event = targetEvent() 変数(固定値を返す関数)を 一番上に定義する 例:任意の日のインストール UUを出すSQL 変数がSQLの一番上に集約されているので変更箇所が明白
30. 再利用しやすいSQL
 with const as ( select "2019-11-11" as targetDate, "install" as targetEvent ) SELECT count(distinct id) FROM table,const WHERE date = targetDate AND event = targetEvent 1行しかないCTE式を定義 例:任意の日のインストール UUを出すSQL もしfunctionが使えなければ1行しかないテーブルをcross joinする方法も
31. 課題 4
 ノウハウが共有されなくて辛い

32. 課題4: ノウハウが共有されなくて辛い
 マニアックなSQLの小技とかデータの仕様で気づいたこととかが 共有されておらず、知識がかなり属人化していた。 知識が属人化すると、結果的に作業が属人化するので疲弊する。 (体験談) リファレンスがないので初めてデータを触る人の教育コストも高くなる。
33. GithubにSQLを書いていて気づいたノウハウやデータ構造についてのTipsを貯めて いった。 (これは完全に某M社さんのパクリ) ちょっとずつ溜まっていっているが、 まだリファレンスとしては不十分 課題4: ノウハウが共有されなくて辛い
 やったこと① GithubにクエリのTipsを保存 結果: 成功?
34. 定義した関数を保存するというBigqueryの機能がある。 ここによく使う関数を保存する 課題4: ノウハウが共有されなくて辛い
 やったこと② 永続UDFの採用 結果: 成功? ここ最近できた機能なのでまだそれほど関数は作成されていない。 サービスごとにプロジェクトが違うのどこのプロジェクトにまとめるかは 決めかねている。
35. 課題 5 
 リソースが足りなくて辛い

36. 結局これが一番大きな問題で、まだ解決できていない。 いくら作業を効率化したとしても、作業自体はなくならないので 結果的には非常にスケールしにくい状態。 組織として専任がいるわけではないので、キューが詰まりやすい。 課題5: リソースが足りなくて辛い

37. 興味ある人を対象にSQLの社内勉強会を開催。 課題5: リソースが足りなくて辛い
 やったこと SQL布教活動 ・結局SQLを定常的に書かないとできるようにならない ・SQLが書けるのと、扱うデータを理解するは別の問題 結果: 失敗
38. 課題5: リソースが足りなくて辛い
 結局やりたいことはデータの民主化なんだけど
 障壁を極限まで取り除いた状態での
 民主化が必要なんじゃないかと思った。

39. やりたい分析のほとんどは
 行動分析とユーザー分析
 課題5: リソースが足りなくて辛い

40. 課題5: リソースが足りなくて辛い
 扱うデータソースによってカラム名や仕様、値が異なる。 データの仕様の理解という部分は SQL習得と同等以上にコストがかかる。 webだろうがappだろうが、posデータだろうが全ての行動ログを同じ形式に変換することで そこのコストを大幅に下げ、データを触る敷居もグッと下げたい スキーマはもちろん、値の表記揺れの統一なども全てこのインターフェースで吸収する構想。 When,Who,Where,Whatさえ分かれば行動分析はできるという思想。 やろうとしていること① 全ての行動ログを同じ形式に変換する抽象化インターフェースの作成
41. ①で作ろうとしているものは自由分析をしたい人向けのインターフェースだが、 これは完全にユーザー分析に特化したマート。 ID単位でLTVやRFM、接触メディアなど必要なユーザーステータスがデイリーで更新され、 過去との比較も容易にできる 課題5: リソースが足りなくて辛い
 やろうとしていること② ユーザー分析が容易にできるマートの作成 id 総課金額 CV回数 直近来訪日 xx 5000 20 2019/11/27 usermart_20191112 イメージ

42. データ整備人に求められる３つのスキル

43. 雑に投げられたデータ抽出の依頼から、 「これを出すことでどんなメリットがあるのか」 「結果を用いてこの人は何をしようとしているのか」 等を考える能力。 そして必要に応じて議論を交わして落とし所を見つける能力 これがないと、データを出すAPIと化してしまう。 やらなくていいことをしないため データを出すことが本質的な課題解決にならないことを認識させるため ① 課題抽出力
 なぜ必要か
44. 出したいものが出せるか、工数はどのくらいかかるかを判断するため。 ただ書けるだけじゃなく、自分が扱うDBの関数は全て理解していること が望ましい。 依頼の内容を聞いた段階で頭の中である程度SQLが組み上がるレベル ②高いSQL力
 なぜ必要か
45. 扱うデータの仕様、どのように取得され、どこで加工されているか等を 可能な限り把握すること。 扱うデータに責任を持つということ。 データの不整合があった場合のあたりのつけどころが広がる。 SQL以前に必要なデータがあるかという観点での実現可否を判断するため。 ③データ理解力
 なぜ必要か
46. ご静聴ありがとうございました