Slide 1

Slide 1 text

データ整備業でぶつかった5つの課題 データ整備人に求められる3つのスキル 2019/11/27 (Wed) データアーキテクト(データ整備人)を”前向きに”考える会

Slide 2

Slide 2 text

1. 自己紹介と業務紹介 2. データ整備業でぶつかった5つの課題と解決方法 3. データ整備人に求められる3つのスキル アジェンダ


Slide 3

Slide 3 text

自己紹介と業務紹介
 


Slide 4

Slide 4 text

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


Slide 5

Slide 5 text

自己紹介② 圧倒的操作系


Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

データ整備業の5つの課題と解決方法


Slide 8

Slide 8 text

話すこと・話さないこと
 ・データ整備業においての泥臭い運用の話 ・SQL周りのお話 話すこと ・データエンジニアリングの話 ・機械学習周りの話 話さないこと

Slide 9

Slide 9 text

どんなデータを扱っているか
 ・ADPLAN ・GA360 ・TreasureData ・POSデータ ・マスターデータ ・Adjust ・Appsflyer ・Firebase ・施策のデータ(SMC等) ・3rd Party DMP web App クライアント基幹データ その他

Slide 10

Slide 10 text

どんな依頼がくるか
 KPI設計して ちょっと自分で分析し たいから綺麗なデータ 頂戴 営業したいんだけど データ使って何かでき ない? この広告施策の 成果が悪い。 なんで? 広告活用にデー タ活かしたい! シードをくれ! ダッシュボードって 作れますか? 今エクセルで やってる作業を 簡単にできるよう にしてよ webとapp横断 で分析がしたい CRMに活かした い。顧客ランクを つけてくれ 媒体の管理画面で 見れない指標が見 れると聞いて BQ叩かせろ!

Slide 11

Slide 11 text

1. 意思決定の材料が欲しい 2. 広告活用したい 3. 自由分析したい 依頼の内容を大別すると3つ


Slide 12

Slide 12 text

どこ(誰)からデータ抽出依頼がくるか
 クライアント 社内からの依頼 クライアントからの依頼 同じ部の営業 広告運用 コンサルタント 広告営業 同じ部の営業 上司 基本的に同じ部の営業が一次受けをしてくれる(ことが多い)

Slide 13

Slide 13 text

求められていること・求められていないこと
 ・意思決定のための示唆 ・意思決定をするために必要なことのすり合わせ 求められていること ・意思決定をすること ・統計的知見による助言 求められていないこと

Slide 14

Slide 14 text

どうやって依頼を解決するか


Slide 15

Slide 15 text

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


Slide 16

Slide 16 text

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


Slide 17

Slide 17 text

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


Slide 18

Slide 18 text

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


Slide 19

Slide 19 text

自然と目的が添えられた上で依頼がくるようになった。 同時に自分自身のドメイン知見も向上した。 そもそもデータを出さずに課題解決することもたまにあった。 依頼者に対して何をしたくてデータが欲しいかをしつこく聞いた。 納得感がない場合は断ることも。 課題1: 雑に依頼がきて辛い
 やったこと① データがあると何が嬉しいんですかと聞くようにした 結果: 成功

Slide 20

Slide 20 text

・目的、期限、希望のアウトプットなど必要な情報の漏れがないように  依頼時のフォーマットを作った。 ・アウトプットのイメージで合意が取れるまで作業に着手しないようにした。 手戻りが圧倒的に少なくなった。 アウトプットのイメージを握っておくことで齟齬が生じなくなった。 課題1: 雑に依頼がきて辛い
 やったこと② 依頼のフォーマットを作った 結果: 成功

Slide 21

Slide 21 text

課題 2
 SQLのレビューが辛い 


Slide 22

Slide 22 text

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


Slide 23

Slide 23 text

課題2: SQLのレビューが辛い 
 SQLの書き方を統一してレビュワーが読みやすくするのが狙い。 インデントやView、カラムの命名規則など細かく作成した。 やったこと① SQLスタイルガイドを書いた ・浸透させるのが難しいのと、スタイルガイドからのちょっとのずれを指摘するのは本質 的ではない。フォーマッターがないと浸透は難しそう。 ・とはいえ、いくつかのルールは徹底されている(後述) 結果: 失敗

Slide 24

Slide 24 text

・全てをcolab化するのは逆にコストが増えるが、重要度が高いものや複雑なものは colabを使うとレビューがしやすく、知見も共有しやすい。 ・SQLをかけないビジネスメンバーへの説明も容易になる ・結果をDataflameとしてpythonで扱えるので統計情報を見たり、可視化したりして異常 値に気づけるきっかけになる 課題2: SQLのレビューが辛い 
 Google Colaboratoryで途中の処理を可視化しながら処理の流れを把握できるようにす ることが目的。 SQLがスパゲッティでも順次処理を追っていけば理解しやすい。 やったこと② Google ColaboratoryでのSQLレビュー 結果: 成功

Slide 25

Slide 25 text

課題 3
 類似した依頼が何度もきて辛い


Slide 26

Slide 26 text

課題3: 類似した依頼が何度もきて辛い
 例えば、期間を変えるだけ、など過去に出したものの焼き直しみたいな 依頼は頻繁にある。 そういったものは可能な限り手間をかけずに出したい、 なんなら一次受けした営業さんに捌いてもらいたい...

Slide 27

Slide 27 text

スタイルガイドで唯一徹底されている「変数定義を一番上にする」のおかげで githubに再利用がしやすい形で過去の事例が溜まっている。 類似分析をする際に1からクエリを書かなくていいように汎用的に作成し、githubに保 存。汎用的な形とは変数をSQL文の一番上に書くこと ※保存先はBQでも良かったが検索しづらいのと githubでのレビューの都合上不採用 課題3: 類似した依頼が何度もきて辛い
 やったこと: 再利用がしやすい形でSQLを作成し、githubに保存 結果: 成功

Slide 28

Slide 28 text

再利用しにくいSQL
 SELECT count(distinct id) FROM table WHERE date = “2019-11-11” # 任意の日付を入力してください AND event = “install” # 任意のイベントを入力してください 例:任意の日のインストール UUを出すSQL コメントで変更箇 所を示す 変更部分にコメントを書く。コメント部分を探すのが大変

Slide 29

Slide 29 text

再利用しやすい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の一番上に集約されているので変更箇所が明白

Slide 30

Slide 30 text

再利用しやすい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する方法も

Slide 31

Slide 31 text

課題 4
 ノウハウが共有されなくて辛い


Slide 32

Slide 32 text

課題4: ノウハウが共有されなくて辛い
 マニアックなSQLの小技とかデータの仕様で気づいたこととかが 共有されておらず、知識がかなり属人化していた。 知識が属人化すると、結果的に作業が属人化するので疲弊する。 (体験談) リファレンスがないので初めてデータを触る人の教育コストも高くなる。

Slide 33

Slide 33 text

GithubにSQLを書いていて気づいたノウハウやデータ構造についてのTipsを貯めて いった。 (これは完全に某M社さんのパクリ) ちょっとずつ溜まっていっているが、 まだリファレンスとしては不十分 課題4: ノウハウが共有されなくて辛い
 やったこと① GithubにクエリのTipsを保存 結果: 成功?

Slide 34

Slide 34 text

定義した関数を保存するというBigqueryの機能がある。 ここによく使う関数を保存する 課題4: ノウハウが共有されなくて辛い
 やったこと② 永続UDFの採用 結果: 成功? ここ最近できた機能なのでまだそれほど関数は作成されていない。 サービスごとにプロジェクトが違うのどこのプロジェクトにまとめるかは 決めかねている。

Slide 35

Slide 35 text

課題 5 
 リソースが足りなくて辛い


Slide 36

Slide 36 text

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


Slide 37

Slide 37 text

興味ある人を対象にSQLの社内勉強会を開催。 課題5: リソースが足りなくて辛い
 やったこと SQL布教活動 ・結局SQLを定常的に書かないとできるようにならない ・SQLが書けるのと、扱うデータを理解するは別の問題 結果: 失敗

Slide 38

Slide 38 text

課題5: リソースが足りなくて辛い
 結局やりたいことはデータの民主化なんだけど
 障壁を極限まで取り除いた状態での
 民主化が必要なんじゃないかと思った。


Slide 39

Slide 39 text

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


Slide 40

Slide 40 text

課題5: リソースが足りなくて辛い
 扱うデータソースによってカラム名や仕様、値が異なる。 データの仕様の理解という部分は SQL習得と同等以上にコストがかかる。 webだろうがappだろうが、posデータだろうが全ての行動ログを同じ形式に変換することで そこのコストを大幅に下げ、データを触る敷居もグッと下げたい スキーマはもちろん、値の表記揺れの統一なども全てこのインターフェースで吸収する構想。 When,Who,Where,Whatさえ分かれば行動分析はできるという思想。 やろうとしていること① 全ての行動ログを同じ形式に変換する抽象化インターフェースの作成

Slide 41

Slide 41 text

①で作ろうとしているものは自由分析をしたい人向けのインターフェースだが、 これは完全にユーザー分析に特化したマート。 ID単位でLTVやRFM、接触メディアなど必要なユーザーステータスがデイリーで更新され、 過去との比較も容易にできる 課題5: リソースが足りなくて辛い
 やろうとしていること② ユーザー分析が容易にできるマートの作成 id 総課金額 CV回数 直近来訪日 xx 5000 20 2019/11/27 usermart_20191112 イメージ


Slide 42

Slide 42 text

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


Slide 43

Slide 43 text

雑に投げられたデータ抽出の依頼から、 「これを出すことでどんなメリットがあるのか」 「結果を用いてこの人は何をしようとしているのか」 等を考える能力。 そして必要に応じて議論を交わして落とし所を見つける能力 これがないと、データを出すAPIと化してしまう。 やらなくていいことをしないため データを出すことが本質的な課題解決にならないことを認識させるため ① 課題抽出力
 なぜ必要か

Slide 44

Slide 44 text

出したいものが出せるか、工数はどのくらいかかるかを判断するため。 ただ書けるだけじゃなく、自分が扱うDBの関数は全て理解していること が望ましい。 依頼の内容を聞いた段階で頭の中である程度SQLが組み上がるレベル ②高いSQL力
 なぜ必要か

Slide 45

Slide 45 text

扱うデータの仕様、どのように取得され、どこで加工されているか等を 可能な限り把握すること。 扱うデータに責任を持つということ。 データの不整合があった場合のあたりのつけどころが広がる。 SQL以前に必要なデータがあるかという観点での実現可否を判断するため。 ③データ理解力
 なぜ必要か

Slide 46

Slide 46 text

ご静聴ありがとうございました