Upgrade to Pro — share decks privately, control downloads, hide ads and more …

データ整備の基礎

ShinU
April 07, 2022

 データ整備の基礎

2022/04/07 初版公開

お問い合わせ先
Twitter:@data_analyst_
メールフォーム:https://bit.ly/37orRqa

執筆者:しんゆう
ブログ:データ分析とインテリジェンス
https://analytics-and-intelligence.net

ShinU

April 07, 2022
Tweet

More Decks by ShinU

Other Decks in Business

Transcript

  1. データ整備の基礎

    View full-size slide

  2. はじめに
    本資料を読むにあたり前提となる説明や注意点
    自己紹介
    2

    View full-size slide

  3. 本資料の目指すところ
    データ整備の全体像を描くことを目標とする
    データ整備の仕事を行うために必要な方法やスキルを具体
    的に書く
    長い間通用するように考え方を中心にして流行りのツール
    や環境に極力依存しないようにする
    データ整備に携わる人のキャリアを考えるのに役立つ資料
    にする
    3

    View full-size slide

  4. 注意点
    内容は全て筆者の個人的な経験に基づきます。知る範囲で最
    も良いと考えている方法や、そうであったらいいと思ってい
    ることをまとめています
    データ整備への理解が広まることへの利害関係者です。自覚
    の無いバイアスをもし見つけたらご指摘ください
    内容は予告なく追加・変更されます
    4

    View full-size slide

  5. 自己紹介
    しんゆう
    Twitter:@data_analyst_
    ブログ:データ分析とインテリジェンス

    https://analytics-and-intelligence.net
    最近の活動:データを使いやすくする人

    (データアーキテクトまたはデータ整備人)
    5

    View full-size slide

  6. 更新履歴
    2022/04/07 初版公開
    6

    View full-size slide

  7. 「データ分析」を概観する
    「データ整備」を考えるにあたり先には「データ分析」の全
    体像を掴んでおく
    データを整備する目的は「インテリジェンス」を作るためで
    あることを忘れてはならない
    7

    View full-size slide

  8. 「データ分析」で得られるのは「情報」
    「データ分析」を行うことで得られるのは「行動の結果」で
    はなく「行動のための情報」
    データ分析だけしても何も変わらないのは得られるのが「情
    報」であって「行動」ではないから
    「情報」は何かを決めて行動するより先に必要
    8

    View full-size slide

  9. なぜ「データ分析」をするのか
    未来のことはわからないから「データ分析」をして「情報」
    を入手する必要がある
    意思決定や行動に使うためには、「情報」はそれより先に入
    手しなければならない
    「情報」を入手することにより意思決定の不確実性を下げ
    る、とも表現できる
    9

    View full-size slide

  10. 「情報」には2つある
    「情報」には「データ」と「インテリジェンス」がある
    加工されていない生の状態は「データ」
    ある課題に対して次にどうするかを決めるのに使えるよう
    分析されたのが「インテリジェンス」
    10

    View full-size slide

  11. 状況次第で「情報」の意味がかわる
    その「情報」が「データ」なのか「インテリジェンス」なの
    かは状況による
    「現時点で晴れている」という「情報」は「出かけるのに傘
    を持って行くか」という課題に対して
    歩いて5分のコンビニに行くなら「雨は降らないだろうと」
    推論、判断できるので「インテリジェンス」
    夕方まで出歩く予定ならばまだ判断がつけられないので
    「データ」
    11

    View full-size slide

  12. データ分析でインテリジェンスを作る
    「データ分析」とは「データ」から「インテリジェンス」を
    作ること
    「データ」と「インテリジェンス」の区別を明確にする
    「データ」のままで「インテリジェンス」になっていなけれ
    ばどんなにたくさん集めても意思決定に繋がらない
    12

    View full-size slide

  13. 意思決定と分析のプロセス
    「データ分析」はプロセスとして捉えると見通しが良くなる
    データ整備はプロセスの中での「収集」フェーズと大きく関
    係しているので、プロセスを知っておくことで整備の役割を
    より明確に捉えることが出来るようになる
    13

    View full-size slide

  14. 意思決定と分析のプロセスの全体像
    「データ分析」は目的の決定から始まり、収集・処理・洞察
    を経て意思決定と実行に至る一連のプロセスである
    データ分析には様々なモデルがあるが、大きな流れは同じな
    のでここで紹介するモデルにこだわる必要は無い
    14

    View full-size slide

  15. 本資料における「分析」の使い方
    本資料では「データ分析」はプロセス全体、「分析」は処理
    フェーズと洞察フェーズを合わせた言葉として使う
    一般的には処理フェーズと洞察フェーズのみを指して「デー
    タ分析」や「分析」と表現されることもあるので注意
    15

    View full-size slide

  16. 意思決定と分析のプロセスの注意点
    必ず目的(=何が知りたいのか)から始める
    与えられたデータをプログラミングで何とかする
    面白い話をするためだけの「分析」をする
    見栄えのいいダッシュボードを作る
    どこかのフェーズで失敗すると全体が破綻する
    一方通行ではない。いったり来たりするのが通常
    「分析」だけしか考えないとデータをいじくるだけで終わる
    16

    View full-size slide

  17. 「収集」フェーズを知る
    意思決定と分析のプロセスのうち必要なデータを入手するの
    が「収集」フェーズ
    手元にあるデータが何かに使えないかを考えるのではなく、
    知りたいことに合ったデータを求め、もし手元になければ獲
    得を試みる
    17

    View full-size slide

  18. 収集フェーズで行うこと
    知りたいことに合ったデータを探し、使えるようにする
    DBに入っているデータをSQLを中心に利用して抽出する
    画像、音声、テキストデータなどを加工する
    書籍や資料から探して取り込む
    外部からレポートを購入する
    必要なデータが手元にないなら入手するための手続きを行う
    18

    View full-size slide

  19. データがなければ獲得を試みる
    データが手元に存在していなければ獲得できないかを試みる
    システムでログデータを取れるようにする
    サイトにタグを仕込む
    センサーやカメラを設置する
    専門家へのヒアリング、ユーザーへのインタビューを行う
    事情を知っている人とのコネクションを繋げる
    19

    View full-size slide

  20. データはデジタルに限らない
    「データ」というとデジタル、数値、データベースを思い浮
    かべる人が多いがそれだけに限らない。全てが「データ」
    紙、物体のような非デジタル
    数値だけでなく文字列やテキスト
    定量だけでなく定性
    画像、音声、噂話
    20

    View full-size slide

  21. 収集フェーズとデータ基盤
    収集フェーズがうまくいかない要因は数多い
    原因のいくつかは事前に準備をしておくことで取り除くこと
    ができる
    「データを集約し、保管しておくため仕組み」が「データ基
    盤」
    21

    View full-size slide

  22. 収集フェーズの主問題
    欲しいデータが適切な時期に手に入らない
    原理的に不可能な場合を除いて考えるといくつかの要因に分
    けられる
    事前に準備しておくことで解決を図るのは自然な発想
    22

    View full-size slide

  23. データが手に入らない要因
    データが獲得できないか、獲得できても必要な時に間に合わ
    ない
    課題 例
    不可能 正確な未来予測・人の真の能力
    技術的 技術力不足・設定不足やミス・処理能力不足
    人的 スキル不足・コネクションがない
    リソース 予算・人員・データへの優先度
    23

    View full-size slide

  24. タイミングの問題
    あるデータが欲しいと思ってから収集に動き始めても必要な
    データを揃えることができない。つまり獲得のタイミングが
    悪い
    データの獲得がすでに不可能
    データの獲得が間に合わない
    データは獲得できるが処理が間に合わない
    24

    View full-size slide

  25. データが獲得できない
    データの獲得がすでに不可能になっている
    設定していなかったログは遡って取れない
    データ獲得できるがこれから準備を始めても必要な時期に間
    に合わない
    衛星を打ち上げても明日の天気予報には使えない
    来週欲しいがシステム担当に依頼したら1か月かかる
    25

    View full-size slide

  26. 獲得できても処理が間に合わない
    データが獲得済み、あるいは獲得できることはわかっている
    が、使えるようにするまでに時間がかかりすぎる
    複雑なコードを書く
    データの仕様の確認や指標の定義を決めるための調整
    データ量が大きすぎて処理に時間がかかる
    外部のデータに申し込みしてから待たされる
    社内申請
    26

    View full-size slide

  27. なぜデータ基盤を作るのか
    タイミングが悪くてデータが欲しいと思ってから動き始める
    のでは間に合わないなら事前に準備しておこう、と考えるの
    は自然な発想
    データ基盤と呼ばれる「技術的にデータを集約し、保管して
    おくため仕組み」を作る
    27

    View full-size slide

  28. データを基盤に集約するだけではダメ
    データ基盤を作ってそこにとにかくたくさんデータを入れて
    おけばそれでいい、とはならない
    データ基盤に集約した後に使いやすくしておくこと(整理)
    も必要
    整理をしないのは家の中の荷物が棚も何もなしに全て床に散
    らばっているようなもの。そのままでも使えないことはない
    が、生産性が著しく悪くなる
    28

    View full-size slide

  29. データを「整理」する
    データを使いやすい形に「整理」するとは例えば以下のこと
    重複や欠損を取り除く
    型やタイムゾーンなどの形式を揃える
    ネストされたデータを展開する
    よく利用する指標や複雑な処理が必要な指標を集計する
    処理時間が利用に耐えられるようなサイズに切り分ける
    29

    View full-size slide

  30. データ基盤の考え方は昔から存在する
    データは入手できるが間に合わないことがあるから先に集め
    て整理する、という考え方は以前からある
    図書館/資料室/本棚
    データ基盤の構築は最近話題になることが多いが、デジタル
    化やクラウドに環境が変化しただけ
    大規模なシステムとは限らず、データを集約し、保管してい
    るならそれがデータ基盤
    30

    View full-size slide

  31. 収集フェーズの構成を捉える
    「獲得」「集約」「整理」だけでは収集フェーズは成り立た
    ない
    全てが必須の活動。規模に併せて投入リソース量を調整する
    収集フェーズとデータ基盤はひとまとめで考えるには領域広
    すぎる
    別の仕事として分けるとしたらどうするべきか
    31

    View full-size slide

  32. 収集フェーズを構成する仕事
    収集フェーズに含まれる残りの仕事
    抽出:社内外から分析に適切なデータを探し出し、分析に
    合わせて加工する
    品質管理:不良データを出さない、つくらない、入れないよ
    うにデータとデータの流れを管理する
    記録:メタデータを組織として残し、活用する仕組作り
    保管:適切な方法でデータを残す
    32

    View full-size slide

  33. 収集フェーズだけで収まらない仕事
    密接に関連するが収集には収まらない
    データマネジメント:特にデータガバナンス
    クラウド:GCP、AWS
    インフラ:ツールの導入や権限管理
    パイプライン:機械学習による推薦システムなど
    セキュリティ:内部流出、産業スパイ、不正アクセス防止
    他にも法務、倫理、文化
    33

    View full-size slide

  34. 収集フェーズの分け方を考える方針
    収集フェーズと一緒にデータ基盤も考慮する
    個々の仕事だけでもかなり膨大であり分担が必要
    あまり細かく分けるよりは大まかにわける
    明確に線引きができるわけではなく密接に連携が必要ではあ
    るがわかりやすさを優先する
    34

    View full-size slide

  35. 解決する方法の違いで分ける
    エンジニアリングで解決することが中心か、人がうまくやっ
    ていくことが中心かで分けると見通しがよくなりそう
    100%どちらかではなくどちらの要素が強いかを基準に考える
    35

    View full-size slide

  36. エンジニアリングが中心
    エンジニアリングで自動化、仕組み化する
    データ基盤の構築
    データ基盤の安定的な運用
    データ基盤への集約
    ETL・ワークフローエンジンの設定
    36

    View full-size slide

  37. 人がうまくやっていくことが中心
    実現するためには技術が必要だが方針決めや調整の要素が強

    整理
    品質管理
    記録
    抽出
    37

    View full-size slide

  38. 獲得はデータの種類による
    エンジニアリングを担う人が担当する傾向が強い
    システムログの設定
    タグの埋め込み
    スクレイピング
    定性データは収集から分析まで全部行うことも多い
    インタビュー、アンケート、行動観測
    コミュニティからの業界情報
    38

    View full-size slide

  39. 保管も別に考える
    「集約したデータをどこかにためて置き、必要な時に取り出
    せるようにする」ならエンジニアリング
    ためたデータは流出しないように守らなければならず、情報
    セキュリティ(サイバー攻撃、内部流出、産業スパイなど)
    と密接に関わるため別に考えた方がいい
    39

    View full-size slide

  40. 「データ整備」と名付ける
    別の役割であると認識するためには別の名前が必要
    収集フェーズとデータ基盤構築・運用の中で人がうまくやっ
    ていくことが中心になる4つの仕事を総称して 「データ整
    備」 と名付ける
    本資料で言う「整理」のみをさして「データ整備」と呼ぶ人
    もいるので注意
    40

    View full-size slide

  41. データ整備とは何か
    改めてデータ整備について概観する
    41

    View full-size slide

  42. データ整備を一言で表現すると
    「データ整備」を簡潔に表現すれば「集約したデータを、分
    析する人が使いやすくする」仕事
    整備は集約と分析の間にあり、つまりはデータ分析プロセス
    を行うと意識していようがなかろうが必ず仕事が発生してい

    もし意識していないのであれば生産性が極端に悪いか、誰か
    が知らないところで行っているかのどちらか
    42

    View full-size slide

  43. データ整備の4つの仕事
    抽出:社内外から分析に適切なデータを探し出し、分析に合
    わせて加工する
    整理:迅速かつ正確な抽出ができるように事前にデータをき
    れいにして使いやすくしておく
    品質管理:不良データを出さない、つくらない、入れないよ
    うにデータとデータの流れを管理する
    記録:メタデータを組織として残し、活用する仕組作り
    43

    View full-size slide

  44. 別の仕事として認識するべき理由
    なんとなく誰かがついでにやる仕事ではないと意識を向けら
    れる
    データ整備を別の仕事と認識していないとおきること
    気づいた人がやるが評価されずやるだけ損になる
    立場の弱い人が押し付けられる
    外注に丸投げされる
    44

    View full-size slide

  45. データ整備とは中間加工
    データ整備をしないと何が起きるかを料理で例えると
    整備をしないデータ=肉牛そのまま
    肉にする、切り分ける、ベーコンを作る、カツにして冷凍
    する、あたりが全部整備
    料理に例えれば中間加工
    プロにはブロック肉、忙しい人には味付け済みで焼くだけ
    にするまで加工
    45

    View full-size slide

  46. データ整備の仕事1:抽出
    分析のために必要なデータが必要な形で用意されているとは
    限らず、様々な場所から入手して加工することになる
    技術的、時間的な制約で分析する人が抽出できない場合、抽
    出を担う人が別に必要になり依頼とコミュニケーションが発
    生する
    本節は抽出を担う人が分析する人とは別にいる場合を想定し
    ている。分析する人が自分で抽出する場合はインプットの入
    手以降を参照のこと
    46

    View full-size slide

  47. 抽出の役割
    正しい分析を行うために必要なデータを適切な時期に適切な
    形で提供する
    依頼された内容をそのまま実現するだけでなく、本当に必要
    なデータを利用者に提供する
    依頼の内容が不適切であったり、過不足があれば打ち合わせ
    で埋めることも役割に含まれる
    47

    View full-size slide

  48. 抽出のタスク
    ルール策定、管理表の作成と運用、依頼ひな形の作成
    内容・納期・アウトプットの決定、不当な依頼をはじく、着
    手する優先順位を決める
    インプットの入手、コードを書く、アウトプット(ダッシュ
    ボード含む)の作成、追加変更要求への対応
    自動化、業務フローや処理手順の見直し、整理へのフィード
    バック
    48

    View full-size slide

  49. 依頼を管理する
    抽出依頼は多種多様な内容が社内外の様々な人から入るので
    適切に管理しないとすぐに抜け漏れが発生する
    アウトプットや作成物は全て番号で紐づけると後で楽になる
    49

    View full-size slide

  50. 依頼のルールを決める
    依頼時のルールで決めておくこと
    1つの依頼には1つの内容
    受付窓口
    受付担当
    依頼時に最低限書いてもらうこと
    納期の目安
    50

    View full-size slide

  51. 1つの依頼では1つの内容にする
    まったく違う内容が混ざっているとやりとりが混乱する
    厳密に分けることは難しいので依頼者が分けた方がいいか判
    別が難しければひとまず依頼を出してもらって受付時に相談
    する
    51

    View full-size slide

  52. 受付窓口を1つにする
    正式な依頼の窓口は1つに決める
    コミュニケーションのチャンネルがあちこちに散っている
    と抜け漏れが発生する
    誰がどんな依頼を受けているかわからなくなる
    すでに行った内容と同じ依頼があっても気づくのがより難
    しくなる
    52

    View full-size slide

  53. 受付担当も決める
    依頼する部署や人によって誰が抽出を担当するか事前に決ま
    っている場合は担当者が受付すればいい
    そうでない場合は誰が受付するか決めていないと宙ぶらりん
    になる依頼が出る
    チームもしくは個人で受付担当者を決める
    53

    View full-size slide

  54. 最低限書いてもらうこと
    依頼時に書いていなければ打ち合わせ前に聞く
    区別がつく題名
    概要
    希望納期
    アウトプットの形式の希望
    書式だけ決めても守られないのでひな形も作る
    54

    View full-size slide

  55. 抽出依頼の目的や背景は必須ではない
    正しい依頼を出すのは本来は依頼者の責任
    内容の過不足の疑いがあり何がしたいのかの確認が必要にな
    ったら聞けばいい
    依頼者の判断で書いてもらうことは差支えない
    55

    View full-size slide

  56. 依頼管理表を作る
    依頼管理表に必ず書いておくべきこと
    依頼番号
    依頼者と合意した納期
    依頼者と抽出担当者
    依頼の題名
    簡潔にまとめた進捗状況
    56

    View full-size slide

  57. 依頼番号は管理表以外でも使う
    通常は通し番号。ユニークであれば何でも良い
    依頼番号で全て紐づけると後で探す時に楽になる
    インプット
    書いたコード
    アウトプット
    やり取りの記録
    57

    View full-size slide

  58. 急ぎの依頼は確約しない
    事前に提示する納期はあくまでも目安であり「内容が確定し
    てから必要な期間」であることを強調する
    急ぎの場合は依頼時に明記することもルールとしておく
    58

    View full-size slide

  59. 依頼管理表は使いやすさを心がける
    使いづらいと使われなくなり依頼の管理がおざなりになるか
    各人が独自に管理してしまう
    使いやすい依頼管理表に必要なこと
    一覧が見やすい
    動作が軽い
    並び替えが自由にできる
    59

    View full-size slide

  60. 依頼受付の注意点1:相談は歓迎する
    別件のやりとりのついででも立ち話で口頭でも構わない
    「こんなデータは取れる?」「もしこれ出してもらうならど
    れぐらいかかりそう?」と気軽に聞いてもらえる関係がある
    と良い
    稼働が必要になったら正式に依頼してもらう
    60

    View full-size slide

  61. 依頼受付の注意点2:断るべきこと
    聞いても具体性な行動が出てこない興味本位なデータの抽出
    依頼の中に混ざっている依頼者が行うべきこと
    レポート作成(一部だけが混ざっている場合は特に注意)
    関与していない場所で作られた無茶苦茶なデータの整形
    その他の依頼への影響が大きい依頼
    他の依頼に一切手が付けられなくなるような分量なら分割
    して重要な部分だけ対応する
    61

    View full-size slide

  62. 依頼受付の注意点3:必ず依頼をもらう
    少しでも稼働することになるなら必ず依頼を出してもらう
    ちょっとやるだけだからと記録を残さないと後でやりとりを
    検索するのが難しくなる
    依頼者・抽出担当者が退職などで不在だとさらに大変になる
    62

    View full-size slide

  63. ヒアリングではなく打ち合わせを行う
    依頼として現れてきたことから、依頼者が目的を達成するた
    めに本当に必要なデータとのギャップ埋めるためのコミュニ
    ケーション
    決めなければならないことは3つ
    内容
    アウトプットの形式
    納期
    63

    View full-size slide

  64. 分析のための抽出を心がける
    抽出はより良い分析と意思決定を行うために仕事を分担して
    いるのであり抽出担当者の希望や都合で誘導してはならない
    抽出が楽な方法だけを提示する
    抽出担当者があるべきだと思うデータを出す
    分析や意思決定に踏み込むなら役割と責任を変える
    64

    View full-size slide

  65. 追加変更はある前提で考える
    問題が複雑であるほど最初から完璧にはならない
    分析を初めてから追加や変更したくなることは当然ある
    事前に追加要請がありそうな項目を打ち合わせで確認できれ
    ば追加しておく
    追加分が本当に必要なデータなのかは別の話なので改めて検
    討する
    65

    View full-size slide

  66. 打ち合わせに望む心構え
    まず話をちゃんと聞く
    意味が無いとか無茶ぶりとか決めつけない
    ただし鵜呑みにはしない
    66

    View full-size slide

  67. 依頼そのままを実現してはいけない
    依頼の内容が本来必要なデータと乖離していると抽出しても
    無駄になる
    本当は他のデータがあるのに依頼者が自分の知識の範囲内
    だけで依頼してきている
    具体的な行動が想定されおらず興味本位だけで大量の依頼
    を出している
    抽出するために必要なコストの計算が現実とは大きく乖離し
    ている
    67

    View full-size slide

  68. 依頼に至った背景や知りたいことを聞く
    依頼内容に違和感や過不足を感じたら詳しく聞く
    本当に必要なデータと違うなら詳しく話を聞いて「本当に知
    りたいことのためになるデータ」を提案する
    68

    View full-size slide

  69. 理想は何かを聞く
    依頼者が出来ない、データが存在と思い込んでいると本来な
    らば実現可能なことが依頼に出てこない
    まずは理想的なデータは何かを聞く。その後納期、コストな
    どの制約下でいつまでならば何ができるかを考える
    何も出てこなければ見てみたい、やってみたいだけで抽出は
    不要かもしれない
    69

    View full-size slide

  70. 何かしら抽出が実現できないか検討する
    抽出するとしてもごく基本的な数値だけで十分なことも多い
    全部を突っぱねるよりは実現できそうなことを探してみる
    ただし他にやるべきことはいくらでもあるのでそちらを押し
    のけてまでやる必要はない
    70

    View full-size slide

  71. やり取りが長い場合は依頼を疑う
    問題が複雑ではないのに1つの依頼でやり取りが何十回も続く
    場合は依頼内容を疑う
    目的が不明確でとりあえず思いついたから依頼した
    やろうとしていることは何となくあるが具体的な動きが考
    えられていない
    細部にこだわりすぎている
    何が知りたいかを聞き、そのうち最も重要な2・3の項目に絞
    ることで十分足りることも多い
    71

    View full-size slide

  72. 値が変わることは説明する
    状態の変化によって以前の抽出と数字に違いが出るなら先に
    説明しておく
    退会による会員数やキャンセルによる売上の減少
    分析に支障がないぐらい影響が軽微と依頼者が判断すればそ
    のまま抽出する
    分析に耐えられないレベルで値が大きく変わる場合は集計方
    法を見直す
    72

    View full-size slide

  73. 全て実現しようとしない
    重要度が低い内容の一部を削ったり簡単にすることを提案す

    具体的にどこにどれぐらいの影響が出るかを提示すると受け
    入れられやすい
    本当に必要なことならやるしかないが抽出担当者が全て引き
    受ける必要はない
    73

    View full-size slide

  74. 納期は余裕を持って決める
    納期遅れを引き起こす事態が起きる事を常に想定しておく
    急ぎの依頼が入る
    インプットの入手が予定より遅くなる
    思っていたより複雑でもっと時間が必要になる
    早めに終わっても誰も損しないので余裕を持った設定を提案
    する
    74

    View full-size slide

  75. 見通しが立たなければ決めない
    内容や納期が決められない場合は保留にする
    必要なインプットが入手できるかわからない
    インプットを外部から入手するので問い合わせが必要
    データの仕様を先に確認してからでないと実現が判断でき
    ない
    「調べて折り返す納期」は決める
    75

    View full-size slide

  76. アウトプットは使い方を想定する
    提供したデータを使う人にとって良い形式に出来るだけあわ
    せる
    抽出側にとって都合が良い方法だけを考えてはいけない
    ただし依頼者がやるべきことを全て抽出で行う必要はない
    76

    View full-size slide

  77. 優先順位の決め方(1)
    取りかかる順
    納期が近い依頼
    内容を早めに決めた方がよさそうな依頼の打ち合わせ
    データの入手や仕様の確認の手配
    納期がまだ先であっても時間がかかりそうな依頼
    重要度が高い依頼
    77

    View full-size slide

  78. 優先順位の決め方(2)
    取りかかる順の続き
    納期までの余裕がある依頼の打ち合わせ
    納期が決まっている依頼
    納期が決まっていない依頼
    実際には後半まで回ってこないで納期が迫って優先順位が上
    がってから着手になることが多い
    78

    View full-size slide

  79. コードを書く前にやること
    アウトプットに至るまでの大まかな流れを逆算して考える
    アウトプットを作るためにはどういったインプットが必要か
    を考える
    手元にあるデータから何ができるかではなく「アウトプット
    を作るために必要なデータは何か」を考える
    79

    View full-size slide

  80. インプットを集める
    必要なデータが全て手元に揃っていなければ入手する手配を
    する
    社内の他の部署が持っている
    アクセス権限のないシステムの中にある
    外部から入手する
    獲得から始める
    80

    View full-size slide

  81. 追加変更がしやすいコードにする
    会員情報の例
    IDをユニークにしたリストを作る
    そこに様々な属性やフラグを追加する
    最後に絞り込みと集計を行う
    追加があったら集計の直前に挿入する
    81

    View full-size slide

  82. 検算する
    ある処理の前後で値が変わらないことがわかっているのであ
    れば検算できる
    トランザクションとマスタのINNER JOIN
    IDごとに特定のフラグや状態を加えるLEFT JOIN
    購買件数や売上の集計
    全部書いてからではなく段階を経るごとに行う
    82

    View full-size slide

  83. パラメータを活用する
    1つのコードの中で同じ値を複数個所で指定する場合はパラメ
    ータを使う
    日付
    絞り込み
    店舗やIDでの絞り込み
    パラメータを指定する場所は先頭に置くとわかりやすい
    83

    View full-size slide

  84. アウトプットは基本的な設定まで
    ダッシュボードなどでのグラフの作成や変更は分析する人が
    やるべきこと
    依頼に含まれていたらやり方を教えるようにする
    整備からは逸脱しているが、他にできる人があまりいないの
    で手伝うことになることも少なくない
    84

    View full-size slide

  85. 行や列の名前がわかるようにする
    特に英語表記は他人にはわかりづらく問い合わせが増える。
    作った当人でも時間が少し経つとわからなくなる
    日本語表記にする
    説明をすぐわかる所に書く
    命名規則があるならば従う
    85

    View full-size slide

  86. 個別のツール内にコードは書かない
    整理したデータを読み込ませるだけにした方がいい理由
    表示までの時間が長くなる
    加工のための関数が貧弱
    修正がまとめて行えない
    ツールを変えるコストが膨大になる
    どこに何のロジックがあるかわからなくなる
    86

    View full-size slide

  87. ツールでは整理したデータを使う
    ツールの機能で新しい値やフラグの作成などは行わない方が
    無難
    データ基盤で整理してツールではツールでしか出来ないこと
    を行う
    集計軸と値の切り替え
    絞り込み条件の変更
    可視化
    87

    View full-size slide

  88. コードは別に管理する
    ツール内にコードを書く場合もコードは別に管理する
    ツールの中だけにしか残していないと一括での修正が面倒に
    なる
    88

    View full-size slide

  89. データを残すかの判断材料
    個別の依頼のために作られるデータは際限なく増えていくの
    で必要なければ残さない
    定期的な自動更新が必要か
    コードを渡して解決するか
    ダッシュボードが必要か
    再現できるか
    処理は間に合うか
    89

    View full-size slide

  90. 復元できないアウトプットは残す
    後で実行すると値が変わる場合は提供時点のデータをできる
    だけ残す
    退会やキャンセルなど後でステータスが変わる
    レコードが増える
    後々トラブル対応やデータが間違えていた際の調査で必要に
    なる
    90

    View full-size slide

  91. コードを渡す際の注意点
    定期的に実行したいがツールを使うほどでもないならコード
    を渡すと楽
    パラメータを利用して変更する場所は必要最低限にする
    変更箇所は一ヵ所にまとめておく。コードの先頭推奨
    しばらくすると動かなくなったと連絡が来るのでオリジナ
    ルのコードは確保しておく
    91

    View full-size slide

  92. 納期に遅れそうになったら早めに連絡
    依頼者にも次の予定がある
    遅れそうな可能性が出てきた段階で一報を入れる
    必要な時期にインプットの入手が出来ないことがわかったら
    納期の調整や内容の変更を打診する
    92

    View full-size slide

  93. 業務フローを改善する
    インプットの入手を効率化にするために入手先の作業を確認
    し、改善に参加する
    業務フロー
    利用ツール
    加工方法や手順
    93

    View full-size slide

  94. 汎用的なデータに入れるか検討する
    指標を作るのにたくさんの加工が必要だとコードが長くな
    り、ミスが増えるし後で見るのも大変
    今後も使っていくなら後述する汎用的なデータを作ってそこ
    から呼び出す方がいい
    94

    View full-size slide

  95. データ整備の仕事2:整理
    抽出を迅速かつ正確に行うために、データ基盤に集約したデ
    ータを中心にきれいにして使いやすくしておく
    本資料ではデータ基盤に入っているデータを中心に考える
    非デジタルデータはデジタル化してデータ基盤に取り込む
    か、ファイリング
    95

    View full-size slide

  96. 整理のタスク
    品質レベルに基づいて汎用的なデータを作る
    作ったデータを保守する。不要なら削除する
    システムやツールの変更に対応する
    96

    View full-size slide

  97. データ基盤
    本資料ではデータベースに入っているデータを中心に考える
    が、それ以外のデータも考え方は同じ
    音声
    画像
    紙(書籍・資料)
    実物
    97

    View full-size slide

  98. 未加工データを入手する
    もし集約した時点で加工済みなら未加工のデータに入れ替え
    るようにする
    別の方法での集計や、改修が必要になった場合に元のデータ
    が存在しないと非常に難しくなる
    98

    View full-size slide

  99. 汎用的なデータを作る
    汎用的なデータとは様々な依頼に対応できるように整理して
    使いやすくしたもの
    トランザクションやマスタに様々な値や状態のフラグを付与
    する
    店舗や会員の状態などのデータは1つのテーブルに集めたほう
    が使いやすい
    99

    View full-size slide

  100. 不正なデータを修正する
    システム的にはエラーにならないが正しくないデータを品質
    レベルに基づいて修正する
    重複
    欠損
    列がずれた文字列
    先頭の0が消えたid
    想定外の値
    100

    View full-size slide

  101. 表記ゆれを無くす
    同じ対象でもシステムの違いや手入力が原因で表記ゆれがあ
    ると正しい集計ができなくなるので直す
    マスタを作る
    一括で変換する
    手作業(最終手段)
    101

    View full-size slide

  102. 定義がぶれると困る指標を集計する
    定義が決まっていてもその都度コードを書いているとどこか
    でずれる
    ぶれると困る指標は集計しておく
    重要度が高い
    多くの人が使っており影響が大きい
    102

    View full-size slide

  103. 形式を揃える
    同じ形式で統一する
    ファイル名、テーブル名、カラム名
    DATETIMEかTIMESTAMPか
    タイムゾーン
    フラグの形式(1/0、True/False)
    区分値は数値か文字列か
    NULLと0や空欄の混在をなくす
    103

    View full-size slide

  104. 区分を作る
    数値や値のパターンに応じて様々な区分値を作る
    年代
    階級値
    申し込み状況
    会員の状態
    104

    View full-size slide

  105. フラグを立てる
    退会、許諾、申し込みなどの各種状態フラグ
    1/0、True/Falseなど形式はそろえておく
    筆者のおすすめは「数値型で0/1」
    105

    View full-size slide

  106. データの一部を取り出す
    実際の利用で使うことが多い部分を取り出しておく
    日時から日や月
    住所から都道府県
    URLからパラメータの値
    106

    View full-size slide

  107. 共通IDの付与と作成
    サービスやシステムをまたがる場合にIDを繋げるマスタがあ
    るならJOINしておく
    共通IDが無ければ作る
    107

    View full-size slide

  108. 個別の分析で作ったよく使う指標
    最初は個別に作っていても、たびたび使われるなら汎用的な
    データに作る
    「売上」の例
    総計
    過去1年の月別
    いろいろなパターンで作れるが多すぎても紛らわしいのでニ
    ーズがあってからで良い
    108

    View full-size slide

  109. 使いやすいように処理しておく
    使おうと思ってから作ることもできるが、先に作っておく方
    がいいその他の例
    JSON型を展開
    文字列になっている数値や日付の型を正しくする
    unixtimeをDATETIMEやTIMESTAMPに変換
    理由のない空白をNULLにする
    109

    View full-size slide

  110. センシティブなデータを隔離する
    個人情報や機密情報は誰もが使えるようにはしない
    暗号化、マスキング、フラグ化により特定できないようにし
    て使う
    閲覧権限の管理も必要
    110

    View full-size slide

  111. 個別の事情を排除する
    クライアントやサービスごとにその都度条件を変えることな
    く集計できるようにする
    売上
    件数
    会員数・顧客数
    個別の事情が排除出来ない部分は別に作る
    111

    View full-size slide

  112. マスタは結合しておく方が楽
    マスタと1対1で対応して誰が行っても同じ結果になるならば
    マスタや属性は汎用的なデータに入れておく
    店舗
    会員の状態フラグ
    112

    View full-size slide

  113. 解釈で結果に違いが出るなら結合しない
    同じ店舗IDに対して店舗名によって有効期間が違う複数のレ
    コードがある店舗マスタは集計方法で結果がかわる
    IDごとに集計して名称を最新のIDに寄せる
    店舗名で集計して店舗名変更前後で値のありなしがかわる
    どちらを使うかは利用者次第
    113

    View full-size slide

  114. 定義の変更によるデータの持たせ方
    定義を変更するか、別にカラムを作るか
    Aは以前のままで新しくBを作る
    Aに新しいデータを入れてBに以前のデータを残す
    全体で統制が取れるか、影響範囲が小さい場合を除けば前者
    が現実的か
    114

    View full-size slide

  115. 変更は事前に周知する
    関係者への周知は必須。平行稼働期間も設けた方がいい
    指標の定義の変更
    参照するテーブルやカラムの場所や名称の変更
    システムやツールの移管
    外部に公開していたりパートナーと共有している指標は特に
    慎重に進める
    115

    View full-size slide

  116. システムやツールの移管
    移管するなら前後で同じアウトプットが出来るようにする
    データ基盤の変更
    ツールの変更
    プログラミング言語の変更
    全てを新しいシステムやツールにするのではなく利用してい
    ないデータを洗い出して除外する
    同じにできない場合のずれの許容度は品質レベルに併せる
    116

    View full-size slide

  117. ツールの権限を個人にしない
    権限を個人にしておくといなくなった時に問題が起きる
    変更するように決めておいてもどこかで抜け漏れが発生する
    可能性が高い
    権限やアカウントは個人に付与せず、共有アカウントにして
    おく
    117

    View full-size slide

  118. 使われていないデータは削除する
    放っておいても事故にならないが、必要なものが見つけられ
    なくなるので定期的に不要なデータは消した方がいい
    ただし勝手に消すと問題が発生して問い合わせ対応に追われ

    利用者が把握できるならヒアリングする。広い範囲で利用が
    されているデータならば期限を決めて告知し、問題起きない
    かを確かめる
    118

    View full-size slide

  119. 抽出と整理のバランスを取る
    作ることだけに興味がある人だけで整理を行うと誰にも使わ
    れない大量のデータだけができる
    たくさんデータを作っても使われないなら無駄になる
    何をどれぐらい作るかは抽出や分析の担当者も参画した方が
    いい
    119

    View full-size slide

  120. 誰も使わないなら整理はほどほどにする
    やろうと思えばいくらでも巨大なデータを作ることはできる
    が使われず無駄になるだけ
    抽出、分析、エンジニアリング、周辺の領域も視野に入れる
    120

    View full-size slide

  121. 整理をし続けることが前提
    会社の成長に伴いデータも増えるしやるべき事も変わってい
    くので一度作って終り、とはならない
    使いやすさを維持するためには頻繁な変更が必要だが、シス
    テムやツールが追いついていない
    簡略化や自動化はこれからできるようになってくるとしても
    当面は人力で何とかする
    121

    View full-size slide

  122. データ整備の仕事3:品質管理
    不良データを入れない、作らない、出さないための仕組み作

    獲得、集約されたデータや整理や抽出で作られるデータが品
    質レベルに見合っているかを監視する
    122

    View full-size slide

  123. 品質管理のタスク
    品質レベルを決める
    不良データを検知し、発生原因を突き止め改善する
    集約したデータが品質を満たしているか評価する
    品質レベルに合ったデータの定義と整理の方針を決める
    提供するデータの品質を担保する
    品質が守られているかを監視する
    123

    View full-size slide

  124. 品質レベルを決める
    求める品質レベルを決めるのが先
    整理の対象や方法は決めた品質レベルに従う。品質レベルは
    分析への需要で決まる
    品質レベルを決めないと目標が作れない。とにかくひたすら
    やるか、空いている時間にちょっとだけやるかになる
    124

    View full-size slide

  125. 品質レベルは随時見直す
    最初は分析する人達と大雑把に決めてあとは使いながら需要
    によって変えていく
    技術的に出来ることや作業量の大小によって変えていいのは
    「どれだけ実現できるか」だけ
    125

    View full-size slide

  126. 不良データを認識する
    不良データとは「システムではエラーにならないが品質を満
    たしていないデータ」のこと
    同じデータであっても求められる品質レベルによって不良デ
    ータかそうでないか変わる
    システムでは検知できないため入ってきたら主体的に検知し
    なければならない
    不良データなのか、異常値が不良データに見えているのかは
    自動で判別ができないことが多い
    126

    View full-size slide

  127. 不良データかもしれないデータ
    あるべき状態と違うデータは不良データの可能性がある
    通常とは明らかに違う
    想定と大きくずれている
    想定していない値がある
    トランザクションにあるのにマスタにない
    マスタにあるがトランザクションにない
    トレンドがある時点を境に大きく変わった
    127

    View full-size slide

  128. 不良データを検知する
    システムではエラーなのか自動判別できないので主体的に探
    さないと見つからない
    数値に違和感を感じた
    事前に決めた閾値を超えた
    一覧にない値が出てきた
    提供したデータを見ている人から連絡をもらう前に整備側で
    気づくのがあるべき姿
    128

    View full-size slide

  129. 不良データを検知する仕組みを作る
    不良データの可能性がありそうなデータが出てきたらアラー
    トを鳴らす
    簡単に作るなら「その日にレコードがあるか」や「直近〇日
    の平均値や前年同月との比較」
    アラートが多すぎると重要なデータへの警告を見逃すので区
    別を付けるか数を調整する
    129

    View full-size slide

  130. 不良データかどうかを判別する
    レコード数が直近に比べて増加したとする
    メディアに取り上げられたために訪問が増えたならば「異
    常値であるが不良データではない」
    バッチが途中でとまって再実行されたせいで前日分だけKPI
    であるPVが2倍になったならば「不良データ」
    先日のリリースの影響で1%程度多く数値がでるようになっ
    てしまった場合はもとめられる品質レベル次第で決まる
    130

    View full-size slide

  131. データを評価する
    ニュースやSNSなどのデータは正確性や信憑性を評価する
    グラフや結論におかしなところはないか
    認知バイアスに捕らわれていないか
    発信源は信用できるか
    デマやディスインフォメーションではないか
    131

    View full-size slide

  132. 獲得や集約の段階できれいにする
    不良データは獲得や集約の段階で発生しないように改善して
    いくことが原則
    発生したら原因を調査し、改善方法について獲得や集約の担
    当者と協議する
    改善が不可能な場合は整理するしかない
    改善は可能で品質レベルを満たせるようにはできるがコスト
    に見合わないなら整理で吸収することも考える
    132

    View full-size slide

  133. 不良データの処理を決める
    求められる品質レべルと重要度を考えて優先順位を決める
    不良データだからといって全てきれいにする必要はない。分
    析に影響がない範囲ならそのまま放置することもある
    全社で見ている数値など本当に必要なデータは完璧に整理
    しなければならない
    たまにしか使わない重要度の低い指標なら不良データの発
    生を止めずに整理で吸収してきれいにする
    133

    View full-size slide

  134. 過剰品質に注意する
    不良データを「作らない」だけでなく求められていない品質
    レベルを過剰に「作らない」
    さしあたりざっくりわかれば十分な指標なのにあとちょっ
    とで完全に綺麗になるからと膨大な時間を費やす
    目的も背景も知らずに大量のテーブルやカラムを作る
    リモコンに誰も使わないボタンを大量につけているのと同
    じ。作り手が自己満足するだけ
    134

    View full-size slide

  135. データの定義を決める
    間違い探しと答え合わせのコミュニケーションは相当なコス

    運用されてから時間が経つほど変更、統一することが困難に
    なる
    回避するためには使う前に定義を決めて周知し、守らせる
    135

    View full-size slide

  136. 定義の違いによるぶれの例(1)
    「売上」の集計方法
    タイミング。購入時、入金時など
    消費税のありなし
    キャンセルは除外するか
    ポイント利用、クーポン利用、割引分は減額するか
    集計対象にする区分
    136

    View full-size slide

  137. 定義の違いによるぶれの例(2)
    期間の指定方法。例は「4/16を基準に過去3か月以内」
    3か月前の同日以降(1/16日以降)
    90日以内(1/16日以降)
    91日以内(1/15日以降)
    月単位で見て3か月以内(1/1以降)
    137

    View full-size slide

  138. 定義の違いによるぶれの例(3)
    「年代」の作り方
    階級値のはば。10年きざみか5年きざみかあるいは混在
    高年齢層の扱い。60歳以上、70際以上などでくくる基準
    低年齢層の扱い。19歳までをまとめて「10代以下」など
    有効な年齢の上限と下限。上限なら80歳までか、110歳ま
    で有功にするか
    有効範囲外な階級値の表記。「その他」「不明」など
    138

    View full-size slide

  139. マスタデータを正しく保つ
    入力制限をするなどして不良なデータを発生させないように
    する
    直接扱うのが各部門ならば正しい入力がされているかを監視
    する
    外部から受け取るデータはひとまず整理で対応しつつ、改善
    の方法を模索する
    139

    View full-size slide

  140. 数字の感覚を持つ
    知っている人が見たら明らかに間違えているとすぐわかる数
    値を出さない
    桁数が全然違う
    あきらかにすぐ見つかる値がない
    正しそうかの感覚がわからなければ提供する前に依頼者や知
    っている人に確認する
    新しい施策などで基準が不明な場合も依頼者と合意を取る
    140

    View full-size slide

  141. アウトプットやコードをレビューする
    第三者の視点があると質が上がりミスも減る
    能力や認識の違いを埋めることもできる
    141

    View full-size slide

  142. 合意した内容に勝手に付け加えない
    「これもあったら便利だろう」と独自の判断で付け加えても
    無駄になる
    付け加えた方がいいと思うデータがあったら事前に提案す
    る。ただしあって困ることはないので依頼者から提案を拒否
    されることはまずない。それで合意したと思って追加をして
    も結局使われない
    その時に本当に必要なデータなのか、リソースを他の仕事に
    あてるべきかを自分に問う
    142

    View full-size slide

  143. データ整備の仕事4:記録
    データを迅速かつ正確に使う際ためにデータのためのデー
    タ、と言われるメタデータを記録する
    個人だけでなく組織の活動になるかが鍵になる
    143

    View full-size slide

  144. 記録のタスク
    メタデータを書く
    メタデータを書きやすい環境と仕組みを作る
    メタデータを書くことが組織の活動になるように後押しする
    144

    View full-size slide

  145. メタデータはたくさんある
    ある指標のメタデータの例
    定義、背景、データ型、作るためのコード
    作成日、最終更新日
    重要度、利用頻度
    利用者、利用上の注意点、利用状況
    変更削除時の連絡先
    145

    View full-size slide

  146. ある指標のメタデータの例(続き)
    メタデータには他にもある。これでも一部でしかない
    トラブル発生時の連絡先
    権限の管理者、権限の種類、対象者のリスト
    作成するのに使われているテーブル、このカラムを使って
    作られているカラム
    このカラムが使われているコードやダッシュボード
    146

    View full-size slide

  147. メタデータを書く理由
    何も記録が無いと時間を無駄にする
    同じような指標が複数あるが何が正しいかわからない
    見たいデータがどこにあるかがわからない
    作成者に聞いてみたが当人も忘れているので調査待ち
    作成者に聞いてみたいが誰に聞けばいいかわからない
    わかる人がもういないのでコードを紐解いてもらうところ
    から始めなければならない
    147

    View full-size slide

  148. 自分でメタデータを書く
    誰も書いていないのであれば自分で積極的に書く
    少しづつでも良いので継続的に書く
    後でまとめて書こうとしても忘れるのでその時書く
    定義を決めた
    新しくテーブルができた
    既存の指標の定義や背景を調べた
    148

    View full-size slide

  149. メタデータを絞り込む
    もし全てのメタデータを書けたとしても頻繁に参照されるの
    はそのうちほんの一部
    滅多に使われないメタデータと扱いを分けないと探すのも手
    間になる
    よく使う、たまに使う、めったに使わないぐらいでわける
    通常はよく使うメタデータだけ表示してあとは必要に応じて
    見られるようにするといい
    149

    View full-size slide

  150. メタデータの絞り込みのイメージ
    新しく買ったパソコンのマニュアルの例
    まず必要なのは「オンオフのボタンがどれか」
    もしマニュアルが数千ページあり、最初にパソコンの形の
    変遷が延々と書かれていても困る
    よく使われる機能やトラブル時の連絡先などは最初のわか
    りやすいところにまとまっていてほしい
    メタデータも同じで書いてあれば知りたい人には有用であっ
    ても多くの人にはそうではない
    150

    View full-size slide

  151. メタデータを書きやすい仕組みを作る
    手作業で書いているとすぐに手が回らなくなるしやる気もな
    くなる
    テンプレートを作ってメタデータを書くための準備を減らす
    新しいデータが増えたら書く欄やページだけでなくデータ型
    など自動で取得できるメタデータを自動的に生成する
    151

    View full-size slide

  152. 組織の活動にする
    特定の個人が最初だけ書くがすぐに誰も書かなくなる
    しばらくすると後から入ってきた別の人が1から調べてまた作
    る、が繰り返される
    組織の活動として関係する全員が書く文化にしたほうがいい
    担当者レベルでは強制力がないのでマネージャーレベルから
    の投げかけを要請する
    152

    View full-size slide

  153. データ整備をしながら全体のバラン
    スを考える
    データ整備の中でも偏りがあるとうまく機能しない
    データ整備だけでは成立しないので周辺の仕事にも気をくば

    ただし足りない部分を自分で補わなければならない、という
    わけではない
    153

    View full-size slide

  154. 全ては程度の問題
    やろうと思えばいくらでも整備だけでリソースを使えるが見
    返りは少ない
    重要なことから優先順位を付けながら対応していく
    整備の中で
    収集フェーズの中で
    データ分析プロセスの中で
    154

    View full-size slide

  155. 整備の中でバランスを取る
    抽出と整理のどちらかに偏り過ぎないようにする
    抽出に偏ると目先の依頼をさばくだけになる
    整理に偏ると誰も使わないデータだけが作られ続ける
    抽出と整理は行っても品質管理と記録がおざなりになりやす
    いので特に気を付ける
    155

    View full-size slide

  156. 収集フェーズの中でバランスをとる
    獲得や集約のリソースが不足しているならツールを利用する
    か、整備の担当者が獲得や集約も部分的に担えるかを考える
    放置していると改善されるべき状態が放置される
    入手出来るはずのデータが手に入れられない
    自動化できる作業が手作業になる
    少ないデータを無理やり整理して使う
    156

    View full-size slide

  157. データ分析の中でバランスをとる
    整備だけしても利用者がいないと意味がない。分析や意思決
    定への関与もしなければならないかもしれない。しかし別の
    責任を持たなければならないことは注意
    分析する人がいない
    分析をしても意思決定に使われない
    意思決定しても行動に繋がらない
    157

    View full-size slide

  158. データ整備の仕事をする際の考え方
    データ整備の進め方の次に考え方も紹介する
    データ整備が独立してゼロから始まることはなく、周辺の仕
    事を行う人との関わりの中で行うことに気を付ける
    158

    View full-size slide

  159. 整備以外の領域も意識する
    インフラ、情報セキュリティ、分析、意思決定、技術、理
    論、法務、倫理、採用、育成・・・
    全てが出来る必要もなければ不可能ではあるが、まったくわ
    からないというわけにもいかない
    無理のない範囲で理解を広げるようにする
    159

    View full-size slide

  160. 理想を押し付けない
    整備の仕事が認識されるのは企業や事業がある程度進んでか
    らになることが多い
    理想的な形は常に追い求めなければならないが、一方で現状
    の仕組みになっているのは様々な理由や背景があるはず
    事情を理解した上でより良い方法の提案をするよう心掛ける
    160

    View full-size slide

  161. 他の仕事をする人を尊重する
    整備の担当者が他の人よりデータの扱いに長けているのは当
    然であり、自分が詳しいことを相手が知らないからと見下す
    のは最低な態度
    大半の人にとってはデータを扱ったり見たりするのは仕事の
    ほんの一部であり、分担しているのだからお互いに尊重し合
    うことが大切
    同時に言うなりになるわけでもなく、理不尽な扱いには抵抗
    すること
    161

    View full-size slide

  162. まとめ
    仕事ができるようになるためにもっと重要なこと
    今後書く予定なこと
    お問い合わせ先
    162

    View full-size slide

  163. スライドを読むだけでは仕事はできない
    本資料はデータ整備の仕事を行う上での基礎であるがこれだ
    けでは仕事はできるようにならない
    実践と経験を経なければ何も身につかない
    スライドでは詳しい説明はできていない
    働く企業、業界、業種、分析対象、手法にはそれぞれに独
    自の事情と独自のデータがある
    人が相手なので知識と技術だけでは足りない
    163

    View full-size slide

  164. 今後書く予定(1)
    データ整備に必要なスキル
    データ整備とキャリア
    データ整備の現状
    データ整備のアンチパターン
    これからデータ整備を始めるなら
    164

    View full-size slide

  165. 今後書く予定(2)
    データ整備人材の採用、育成、評価
    規模に合わせたデータ整備
    データ整備とデータの民主化
    データ整備が雑用にならないためにするべきこと
    データ整備のためのSQL
    165

    View full-size slide

  166. お問い合わせ
    本資料に関するお問い合わせ・データ整備に関するご相談は
    以下からお願いします
    Twitter(DMでも受付しています)

     アカウント:@data_analyst_
    ブログのメールフォーム

     URL:https://analytics-and-intelligence.net
    166

    View full-size slide