2020-05-14 第3回 データアーキテクト（データ整備人）を”前向きに”考える会 #前向きデータ整備人
2020/05/14 に開催された 第3回 データアーキテクト（データ整備人）を”前向きに”考える会 のイベントレポートです。
●イベント概要
第3回オンライン開催のお知らせ
昨今の状況を鑑み、開催を延期しておりましたが、第3回 データアーキテクト（データ整備人）を”前向きに”考える会はオンラインにて開催します。
この会について
データを整備・抽出・加工したりダッシュボード作ったりとエンジニアとアナリストの間にある「誰かがやらないと別の誰かが困るのに、なぜか誰もやりたがらない役割」であるデータアーキテクト（データ整備人）のスキル・ノウハウ・キャリアなどについて、恨みつらみではなく”前向き”に考えようという会です。
データアーキテクト（データ整備人）とは
データアーキテクト（データ整備人）については主催者によるこちらの資料をご覧ください。
■最低限これだけは整備しておいた方がいいこと
しんゆう さん
●前提
・プロダクトの初期
整備のためだけに人を置く、時間を割くメリットはない
・後になるほど
分析に時間を割けなくなる
●最低限これだけは整備しておいた方がいいこと
1. 重要な指標を簡単に取れるようにすること
2. 個人情報の隔離
3. 重要事項の記録
● 1. 重要な指標を簡単に取れるようにすること
・早い段階でデータを整備しておかないと起きること
データを触る人が増えてくると
微妙な違いが出て数字が合わなくなる
なにかの拍子にずれに気づき答え合わせ大会
全社レベルで揃えるのは大変
・あらゆるレベルのあらゆるデータで起き、定期的に起きる
SQLの一部で修正漏れ
ちょっとの変更でもエンジニア稼働
変更忘れ
→放っておくと大変
・全社レベルで共有しておくべきKPI
みんなの目線を合わせる数字
部署単位とか言い出すときりがない
まずは全社レベル
・どう整備するか
データマートを用意して、かんたんに抜いたら揃うように
カスタマイズは必要だけどぶれないように
● 2. 個人情報の隔離
・そのままにしておくことにメリットはない
データマートを作る際に消す、フラグ変換するなど
・見えない場所に隔離
困るのは、調査で見る必要があるとき
元データを整備していないと、長いクエリ
・一旦、個人情報を消さないで整備したマート
個人情報を消したマート
通常は消したマートを参照
・保管コスト、バッチの処理時間は延びる
削除、変換するだけにするなどと総合的な判断
暗号化・マスク
フラグ、コード化
電話番号あり/なし
一部の情報
住所→都道府県
● 3. 重要事項の記録
・記録がないと
忘れてしまう
回答に時間がかかる
つくった人がいなくなった
・記録を残そうと言った人が全部やることになる
大変なので放置
→ 人が入ってくると繰り返し
・記録しておきたい項目
データの使用
データの変更しよう
特殊な抽出ロジック
・データの仕様
いつどこで誰が何をしたら/おきたらどういった値が入ってくるか
つくったときにすべて記録、エラーチェックのしくみ
仕様が固まるまで試行錯誤で変わってしまったり
・データの変更記録
いつどの時点で何がどう変わったか
区分値の追加、廃止、統合
本当にデータが存在しないのか、あるべきなのにないのか
入っていないといけない の記録は残っていると良い
・特殊な抽出ロジック
複雑なロジック
複数テーブルをつなぐ、クライアントごとに微妙に条件が違う
など
データマートで吸収
それでも修正、ロジック把握は必要
非常時に必要になるから記録する
・記録することを文化にする
人は忘れる
メモでもとにかく記録に残す
テキストになぐり書きでも
初期の段階から記録
文化として定着させる
●共通すること
・遅かれ早かれやることになる
・整備でサービス開発が進まないのは本末転倒
・完璧を目指したらきりがないので絞る
■集計屋さんからの「前向きな」脱却 ・ アナリストとしての立場でやったこと
長岡 彰平 さん
●SMN株式会社
・ソニーグループのマーケティングテクノロジー会社
・広告配信DSP Logicad
●データマイニング課
・カイゼン・企画に関する分析
・意思決定サポート
・要望に応じた集計・加工
●集計屋の役割
・ビジネスフローの本流には登場しない
・間接的に需要がある
広告主の配信ログを取り出して など
・「大した手間でもないからやるか」
集計依頼が増える
分析工数が逼迫
アナリストが作業者になっていく
他部署から彼らは集計屋だと認識
・分析と集計は表裏一体
集計をすべて廃止するのは現実的ではない
●無数の小タスクへの対応
・分析の余地がない、こまごましたタスクが多数
1. 報告系
ある程度形式が決まっている
データさえ出力すれば対応が完了
2. そうゆう業務フローだから系
依頼トリガーで、集計以外の複数の作業が発生
●1. 報告系
・特徴
依頼者
ログがほしい
dm課
統計解析ソフト
hadoop
・やろうとしたこと
定型化 & 自動化
・課題
何をやっているかわからない処理が多数
・やったこと
集計を1クエリで済ませる
マスターデータをHadoop環境にもコピーしてもらった
SQLを真面目に勉強
・定型化はできたが、自動化できない
依頼者が統計解析ソフトをいじるのは現実的ではない
依頼者とHadoopのインターフェースが必要
・エンジニアに相談
R&Dのpython環境
便利ライブラリ
定期的なpython勉強会
・対応後
依頼者
Google Forms
Google Sheets
分析用サーバ
python
hadoop
→ 依頼の総量が増えた
●2. そうゆう業務フローだから系
・特徴
a社の設定をAに変えて
集計
設定
バッチを流す
終了チェック
完了連絡
・課題
終了チェックが大変
集計クエリが重い
パターンが多い
フォーマットが悪いから依頼が雑になる悪循環
改善したいけど、わからないことだらけ
・エンジニアに相談
この業務向けのアプリを開発
作業内容をドキュメント化
・対応後
使いやすいUI
入力に応じて条件分岐
アドホックなSQLが必要なときだけ作業
→ フローがわかりやすくなった
・すぐに手を出せる部分を局所的に効率化してしまった
後でアプリ化するときに仕様整理が難航
●教訓
・自分たちだけで解決しようとしてはいけない
・自身のスキルを伸ばすことも大事
・早めに手を打つ
■カスタマーサクセスのためのデータ整備人の活動記録
吉田 康久 さん
※前半は、ブラウザのリロードを忘れて伺えず
●カスタマーサクセスのためのデータ整備人の活動記録
・ステップ1. 主要KPI計算の豆のデータパイプライン整備
・ステップ2. データ基盤で出せる価値を感じてもらう
・ステップ3. 自走できる環境に近づける
●ステップ1. 主要KPI計算の豆のデータパイプライン整備
・以前の状況
RDBから多段のスプレッドシートが依存関係
→主要KPIのダッシュボード
各シートにも罠
修正したら、他で壊れる
使わなくなる
・データワークフローの可視化
スプレッドシートの依存関係をすべて整理
・ワークフローの簡素化と自動化
スプレッドシートをスクリプトに置き換え
このデータって今見ていますか？をヒアリング
●ステップ2. データ基盤で出せる価値を感じてもらう
・価値が出る & 分析可能なところはどこか
ペルソナ策定会
カスタマージャーニーマップ作成会
などに参加
・簡単な分析やダッシュボードを持ち込む
CJM作成中に、それって本当か統計見てみませんか？
・自分たちで分析できるように
SQLのペアプロ
頻出の題材はSQL100本ノック
・意思決定の場所に自分から行く
施策の効果検証テンプレートを埋めていく
こちらのデータソースを使うと効果的
このKPIを計測するデータは今はないので、作り込みが必要です
●ステップ3. 自走できる環境に近づける
・メタデータを整理
BigQueryのData Catalog
・どうやって継続的にメタデータを管理するか
生き物なサービスにどう合わせていくか？
既存のカラムにコメント付与
2020年以前はNULL、集計値が入るように。条件は、、、
利用回数が多いものから
・開発チームがメタデータを付与するインセンティブ
DBにメタデータがあると、オンボーディングを早める
普段アプリケーションコードを触らない人への説明
→チームでメタデータを育てていく
・RDBから BigQueryへのメタデータ組み込み
DDLにメタデータを付与
→embulk + tbls
→DataCatalog
コメント付与率を可視化してモチベーションを維持
●私が思うデータ整備人の役割
・データの活用者を助ける
・データを取り巻く環境がどうあるべきかを定義
・データの生成者と協力して、あるべき姿に近づけていく
■分析者、経営者からみた「理想のデータ整備人」とは？
中村仁也 さん
この資料でのデータエンジニアは
データアーキテクト（データ整備人）です。
●「データエンジニア」定義の理由
・システムエンジニア
RFPや仕様に対して情報システムを構築する
・データエンジニア
情報システムはデータを素早く、的確、完全に回す
仕様があったらデータではない
●今なぜデータエンジニア？
・ビッグデータ前
情報を持っていることが優位
少ないサンプルや実験で意思決定→統計学
集めることが困難
・ビッグデータ後
データ量、多様性が爆発的に増加
高度な情報ツールを使いこなせると有利
組織的にサポートする体制が必要になった
●データエンジニアとは？
・分析者、意思決定者
目的があって、それに向かって様々なことを考え、試し、決断
仕様はない
不確実性にトライ&エラーでアプローチ
・データエンジニア
データのハンドリングから意思決定を支援
データエンジニアリングの本質も不確実性
●理想のデータエンジニア
・分析者、意思決定者がやっていること
インプット
→サイクル
観察
→モデルを想像
→仮説を立て
→仮説を検証
→さらに探索
→意思決定
・スピードが武器
気づきを裏付けるデータを素早く取り出せることが優位性
・膨大で多様なデータから気づきを裏付けるデータを素早く取り出す
データエンジニアの出番
●スピードアップのための要素
・データを知る
日頃からデータに親しみ、すぐに何でも答えられる
どこにあって、どう取得して来ている、
どんなデータが、どのような状態で、存在するか
どうすれば手に入るか、操作できるか
・データを出す
可視化や加工の方法
最新のツールを熟知し、最も早い方法で出す
出したデータの雰囲気がわかる、ミスに気づける
・コミュニケーションとイテレーション
相手の目的意識を理解し、相手の言葉で話す
やわらかいリクエストを問いで固める
●データエンジニアの活躍シーン
・意思決定者の右腕
聞けばすぐに答えが返ってくる
即座にデータを切って見せてくれる
・分析者のパートナー
統計やモデルに専念させる
意思決定者からの要望を翻訳
・システムエンジニアとの接続
意思決定者や分析者の柔らかい要望を翻訳
定常的になったデータ抽出・加工はシステム化
■感想
サービス開発の初期から対象を絞ってデータ整備
データアーキテクチャに関わる全員で取り組む
データの生成者と活用者の間で通訳になる
など、気づきと共感をたくさんいただけました！
登壇者の皆さん、運営の皆さん、ありがとうございました！
いつも応援していただいている皆さん支えられています。