2020-05-14 第3回 データアーキテクト（データ整備人）を”前向きに”考える会 #前向きデータ整備人

2020/05/14 に開催された 第3回 データアーキテクト（データ整備人）を”前向きに”考える会 のイベントレポートです。

第3回 データアーキテクト（データ整備人）を”前向きに”考える会 (2020/05/14 19:00〜)

●イベント概要
第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や仕様に対して情報システムを構築する
・データエンジニア
　　情報システムはデータを素早く、的確、完全に回す
　　仕様があったらデータではない

●今なぜデータエンジニア？
・ビッグデータ前
　　情報を持っていることが優位
　　少ないサンプルや実験で意思決定→統計学
　　集めることが困難
・ビッグデータ後
　　データ量、多様性が爆発的に増加
　　高度な情報ツールを使いこなせると有利
　　組織的にサポートする体制が必要になった

●データエンジニアとは？
・分析者、意思決定者
　　目的があって、それに向かって様々なことを考え、試し、決断
　　仕様はない
　　不確実性にトライ&エラーでアプローチ
・データエンジニア
　　データのハンドリングから意思決定を支援
　　データエンジニアリングの本質も不確実性

●理想のデータエンジニア
・分析者、意思決定者がやっていること
　　インプット
　　→サイクル
　　　　観察
　　　　→モデルを想像
　　　　→仮説を立て
　　　　→仮説を検証
　　　　→さらに探索
　　→意思決定
・スピードが武器
　　気づきを裏付けるデータを素早く取り出せることが優位性
・膨大で多様なデータから気づきを裏付けるデータを素早く取り出す
　　データエンジニアの出番

●スピードアップのための要素
・データを知る
　　日頃からデータに親しみ、すぐに何でも答えられる
　　どこにあって、どう取得して来ている、
　　どんなデータが、どのような状態で、存在するか
　　どうすれば手に入るか、操作できるか
・データを出す
　　可視化や加工の方法
　　最新のツールを熟知し、最も早い方法で出す
　　出したデータの雰囲気がわかる、ミスに気づける
・コミュニケーションとイテレーション
　　相手の目的意識を理解し、相手の言葉で話す
　　やわらかいリクエストを問いで固める

●データエンジニアの活躍シーン
・意思決定者の右腕
　　聞けばすぐに答えが返ってくる
　　即座にデータを切って見せてくれる
・分析者のパートナー
　　統計やモデルに専念させる
　　意思決定者からの要望を翻訳
・システムエンジニアとの接続
　　意思決定者や分析者の柔らかい要望を翻訳
　　定常的になったデータ抽出・加工はシステム化

■感想

サービス開発の初期から対象を絞ってデータ整備
データアーキテクチャに関わる全員で取り組む
データの生成者と活用者の間で通訳になる

など、気づきと共感をたくさんいただけました！
登壇者の皆さん、運営の皆さん、ありがとうございました！