見出し画像

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

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

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

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

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

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


■感想

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

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


この記事が参加している募集

いつも応援していただいている皆さん支えられています。