最低限これだけは整備しておいた方がいいこと / maemuki-data-seibinin03

29e4aa4e265e478995df09ca52d62103?s=47 ShinU
May 14, 2020

最低限これだけは整備しておいた方がいいこと / maemuki-data-seibinin03

第3回 データアーキテクト(データ整備人)を”前向きに”考える会
https://analytics-and-intelligence.connpass.com/event/174369/

作成者 :しんゆう@データ分析とインテリジェンス
ブログ :https://analytics-and-intelligence.net/
Twitter:https://twitter.com/data_analyst_

29e4aa4e265e478995df09ca52d62103?s=128

ShinU

May 14, 2020
Tweet

Transcript

  1. 最低限これだけは整備しておいた方がいいこと しんゆう@データ分析とインテリジェンス 2020/05/14 第3回 データアーキテクト(データ整備人)を”前向きに”考える会 #前向きデータ整備人

  2. • 本日の資料は https://speakerdeck.com/shinu/maemuki-data-seibinin03 に公開済み。ブログ・Twitterからもリンクあり • 〇 SNSで話題にすること #前向きデータ整備人 • ×

    録画・録音 • アーカイブの配信はありません 資料・SNS・写真撮影などについて
  3. • 特にプロダクトの初期には整備のためだけに人を置くどこ ろか時間をかけるメリットはあまりない • だからといって余裕が出たらやればいいと整備を全て後回 しにすると、気づいたら時すでに遅しで重要な指標ですら まともに共有することが出来なくなってしまう • また後になればなるほど整備を始めようにも膨大なリソー スを取られてしまい、分析に時間をさけなくなる

    • そこでとにかくこれだけは整備しておけ、と考える3つの 項目についてまとめた 前置き
  4. • 自己紹介 • 最低限これだけは整備しておいた方がいいこと 1.重要な指標を簡単に取れるようにすること 2.個人情報の隔離 3.重要事項の記録 • まとめ 目次

  5. 自己紹介

  6. • しんゆう( Twitter : @data_analyst_ ) • ブログ「データ分析とインテリジェンス」を書いてる人 https://analytics-and-intelligence.net/ •

    フリーランスでデータに関する仕事をあれこれ • 仕事でやりたいこと:意思決定のための情報分析をする人 • 仕事でやってること:データをうまく使えるようにする人 自己紹介
  7. 最低限これだけは整備しておいた方がいいこと

  8. • 以下の3点についてはプロダクトの初期であろうとできる ように取り組んでおくことが望ましい 1. 重要な指標を簡単に取れるようにすること 2. 個人情報の隔離 3. 重要事項の記録 その理由について、各項目ごとに説明する

    最低限これだけは整備しておいた方がいいこと
  9. 最低限これだけは整備しておいた方がいいこと 1.重要な指標を簡単に取れるようにすること

  10. 早い段階でデータを整備しておかないと起きる事 • データを扱うのが1人あるいはごく少数である初期の場合 は問題にはならない。間違っていても気づかない データ レイク 集計できるAさん 売上110万円

  11. 早い段階でデータを整備しておかないと起きる事 データ レイク 別のエンジニアにお 願いしたCさん 100万円 集計できるAさん 定義を変更したので 105万円 Aさんに以前のクエ

    リをもらったBさん 110万円 • データを触る人数が増えるとすぐに概ね同じだが集計方法 の微妙な違いが出て合わなくなってくる
  12. 早い段階でデータを整備しておかないと起きる事 データ レイク POSの売上を集計し てるから税抜きだ 100万円 キャンセル分を引く ようにしたから 105万円 消費税も加味したか

    ったから 110万円 • 何かの拍子でずれに気づくと答えあわせ大会が始まる • ずれの原因がわかって一安心するがその時はそれで終わる
  13. 早い段階でデータを整備しておかないと起きる事 データ レイク 違うことをみんなわ かっていればいいじ ゃん クライアントと共有 しているから先方に 話を先に通さないと うちのチームはずっ

    と税込みで見てるか ら困る • 揃えようにもそれぞれがそれぞれの理由で使い慣れており 簡単ではない。全社レベルで方向合わせは大変
  14. 早い段階でデータを整備しておかないと起きる事 データ レイク ロジックに若干の変 更が必要になったの を聞いて「了解!」 → やらない ロジックに若干の変 更が必要になったけ

    れどできない → エンジニア稼働 数字がすごくずれて 大騒ぎ → 長いSQLの中で 1つだけ変更し忘れ • その他にもいろいろな問題が頻発
  15. 早い段階でデータを整備しておかないと起きる事 データ レイク ずっと前からいるF さん 「忘れた」 異動してきたEさん 「前の部署で は・・」 新しく入ってきたD

    さん 「この数値はどうい う意味ですか」 • といったことが、あらゆるレベルのあらゆるデータで起き、 定期的に繰り返される
  16. • なので整備はしておくべきなのは誰も反対しないはず • しかし、特に初期の段階では整備にリソースを振り分ける 余裕も意味もあまりない • 使う人が少ないのに整備に時間をかけてもしょうがない • いくら整備しても完璧にはできないので、トラブルは必ず 起きる

    • だからといって放置すると、事態は悪化するばかり どうしたらいいのか
  17. • そこで、重要な指標を簡単に取れるようにすることだけは やっておくことを強くお勧めする • ではその重要な指標とは何か どうしたらいいのか

  18. • そこで、重要な指標を簡単に取れるようにすることだけは やっておくことを強くお勧めする • ではその重要な指標とは何か • 「全社レベルで共有しておくべきKPI」 どうしたらいいのか

  19. • そこで、重要な指標を簡単に取れるようにすることだけは やっておくことを強くお勧めする • ではその重要な指標とは何か • 「全社レベルで共有しておくべきKPI」 • みんなの目線を合わせるためであり、売上かもしれないし、 会員数かもしれない

    • 部署単位とか言い出すときりがないのでまずは全社レベル を必須とし、本当に必要なら増やせばいい どうしたらいいのか
  20. どのように整備するか データ レイク • 整備したデータマートから重要指標がごく簡単に、定義が ぶれないように取れるようにしておく データ マート 複雑なクエリは 全部ここで吸収

  21. どのように整備するか データ レイク • 整備したデータマートから重要指標がごく簡単に、定義が ぶれないように取れるようにしておく データ マート 売上100万円 売上100万円

    売上100万円 日付などごく簡 単な指定のみ
  22. どのように整備するか データ レイク • 各部署でのカスタマイズは当然必要になるが、基礎の数字 を共有しておくことでぶれを抑えられる データ マート 売上100万円 うちはそれでOK

    売上100万円 +うちはキャンセル は無視したいので 105万円 売上100万円 +うちは税込みで見 たいから110万円
  23. 最低限これだけは整備しておいた方がいいこと 2.個人情報の隔離

  24. • 個人情報の隔離はなぜ必要かといえば ✓ 漏れるリスク ✓ 目の前にあったらつい悪さをしないとも限らない ✓ 何かあった時に余計な疑いをかけたりかけられたり • そのままにしておくことにメリットはない

    個人情報の隔離はなぜ必要か
  25. どうやって個人情報を隔離するか データ レイク • 分析用のデータマートを作る際に消すなりフラグなどに変 換してしまうのが手っ取り早い データ マート 数値が見られればOK 営業

    ここで個人情報 のデータを消す か変換する
  26. どうやって個人情報を隔離するか データ レイク • 同時に個人情報が含まれている場所へのアクセスも必要な 人以外には制限をかける。とりあえずこれで隔離できる データ マート 数値が見られればOK 営業

  27. どうやって個人情報を隔離するか データ レイク • しかし、問い合わせからの調査などで個人情報が必要にな った場合に整備されていないデータを使うのは大変 データ マート 問い合わせがあって 調査する役目の

    アナリスト まったく整備さ れていない状態 のデータを扱う
  28. どうやって個人情報を隔離するか データ レイク • 例:人を特定してその人の購買の詳細を見たい → 購買が整備しないとまともに使えない状態だと大変 データ マート 問い合わせがあって

    調査する役目の アナリスト まったく整備さ れていない状態 のデータを扱う
  29. どうやって個人情報を隔離するか データ レイク • 解決策:個人情報を含んだ形で整備をしておく データ マート 不正かどうかを調べ る役割の アナリスト

    データ マート 個人情報を消さ ずに整備
  30. どうやって個人情報を隔離するか データ レイク • 個人情報以外は同じデータマートをもう1つ作る データ マート 不正かどうかを調べ る役割の アナリスト

    データ マート ここで個人情報 を削除
  31. どうやって個人情報を隔離するか データ レイク • 個人情報が含まれている部分をアクセス制限して使わない 人には触らせない データ マート 不正かどうかを調べ る役割の

    アナリスト データ マート 通常は使わない
  32. どうやって個人情報を隔離するか データ レイク • 必要になってもデータの体系などが同じように扱えるので ゼロから整備のロジックを入れなくて済む データ マート 不正かどうかを調べ る役割の

    アナリスト データ マート もし必要な場合 でも通常データ と同じに扱える
  33. • 保管のためのコストとかバッチ処理の時間といった問題も あるので必要なことだけやるか、手っ取り早く削除だけす るなど総合的な判断になる • なお削除するとはカラムを落とすだけでなく ✓ 暗号化・マスク ✓ フラグやコード化(電話番号登録あり/なし)

    ✓ 一部情報のみ(住所→都道府県) • なども含む 併せて考える必要があること
  34. 最低限これだけは整備しておいた方がいいこと 3.重要事項の記録

  35. 記録が無いと・・・ • 初期のころは少人数の作った当人達がデータも扱うので知 っている、すぐ聞けるためやはり困らない 初期からいるエンジニア

  36. 記録が無いと・・・ このデータの仕様 は? • プロダクトや人が増えたり分析や整備など、エンジニアで はなくデータを使う人は問い合わせが必要 後から入った 整備・分析担当

  37. 記録が無いと・・・ 調べるのでしばらく 待って → 数日待ち • 全てを正確にぱっと答えることは難しいし、よく忘れてる ので調べなおしで返答に時間がかかる

  38. 記録が無いと・・・ • 詳しかった人がすでにいないので1から調べなおしになっ て大変。正確にわからないこともしばしば このデータの仕様 は? わかる人がいないの でゼロからしらべな いと・・・

  39. 記録が無いと・・・ • 記録を残そうとすると知っている人に聞く→聞いた人が書 くの流れで後から入った人が全部やるはめになる 記録を残そう! 〇〇だからそっちで 書いておいて

  40. 記録が無いと・・・ • はっきりいって面倒だし、無くても聞けばいいし、いまま で誰もやってないからいいやとなって、振出しに戻る 面倒だし他に使う人 いないし、もういい か・・・

  41. 記録が無いと・・・ • はっきりいって面倒だし、無くても聞けばいいし、いまま で誰もやってないからいいやとなって、振出しに戻る このデータの仕様 は? 次に入った人が言うこと

  42. • 人の記憶に頼るのはやめて、記録するべき • 特に記録しておきたい項目 1. データの仕様 2. データの変更記録 3. 特殊な抽出ロジック

    記録しよう
  43. • いつどこで誰が何をしたら/おきたらどういった値が入っ てくるかについての正確な仕様 • 作った時に全て記録し、かつエラーチェックの仕組みまで 作っておくのが理想ではあるが実現性は低い • 仕様が固まるまでの試行錯誤期間においては頻繁に変わっ たり無くなるのは当然なので程度の問題は残るが、数か月 前のデータがきちんと取れない、はやはりまずい

    1.データの仕様
  44. • 途中でデータの変更がされた場合、いつどの時点で何がど う変わったかも併せて記録する • よくあるのが区分値の追加、廃止、統合 • データが存在していない場合、区分が追加でも廃止でも 「本当にその区分のデータが存在しない状況なのか、本来 はあるべきなのにないのか」の区別がつかない 2.データの変更記録

  45. • 抽出するのに複雑なロジックはそれ単体で記録しておく • 顧客の状態を見るために複数のテーブルをつなげて複雑に 場合分けをするとか、クライアントごとに微妙に条件が異 なるといったケースは特に必要 • 通常はデータマートを作る際に全て吸収しておくにしても、 修正やロジックの確認が必要になった場合にクエリだけか ら読み取るのは大変。非常時であればなおさら早くミスな

    くが求められる 3.特殊な抽出ロジック
  46. • 必ず忘れるのでとにかく人の記憶に頼ることはやめる • メモレベルでもとにかくどこかに記録を残しておく • テキストに殴り書きでもあれば全然違う • 初期段階から記録することを始めて、文化として定着させ ておかないと途中からだと厳しい 記録することを文化とする

  47. 全てに共通すること

  48. • 共通して言えることは ✓ 遅かれ早かれやることになるので、整備担当がとかでは なく最初にやっておくべきことに含むのが良い ✓ 一方、整備に時間をかけすぎてサービスの開発が進まな いのは本末転倒 ✓ 全て完璧にしていたらきりがないので本当に主要なこと

    に絞る 共通すること
  49. まとめ

  50. • まったく整備されないままで時間が経ってから整備を始め ようとすると簡単なことでも膨大な時間をかけないとでき なくなることがある • データ整備の担当を後から入れるにもパフォーマンスを出 すには必要なことは先にやっておいてもらうのがよいので まずはこれだけはやっておいた方がいいことをまとめた • まだやっていないことがあったらすぐに取り掛かってみま

    せんか まとめ
  51. 宣伝

  52. • データ整備関連のニュースや記事がまとまっていないので、 あったらいいなと思ってたけど誰もやってくれないので自 分で始めた • 適当に見つけたのが溜まったら都度発行する形式 • ブログか「データ整備人ニュース(仮)」で検索してくだ さい。そのうちまとめページを作る予定 データ整備人ニュース(仮)

  53. • データ分析やその周辺にまつわる色々なイベントを開催中 • Compassで「データ分析とインテリジェンス」というグル ープがあるので興味があれば登録しておくと新しいイベン トの登録や募集開始時に連絡がいきます https://analytics-and-intelligence.connpass.com/ Compassグループ

  54. ご清聴ありがとうございました しんゆう@データ分析とインテリジェンス https://analytics-and-intelligence.net/ Twitter:@data_analyst_