データ整備の基礎

2022/04/07 初版公開

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

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

Transcript

1. データ整備の基礎
2. はじめに 本資料を読むにあたり前提となる説明や注意点 自己紹介 2
3. 本資料の目指すところ データ整備の全体像を描くことを目標とする データ整備の仕事を行うために必要な方法やスキルを具体 的に書く 長い間通用するように考え方を中心にして流行りのツール や環境に極力依存しないようにする データ整備に携わる人のキャリアを考えるのに役立つ資料 にする 3
4. 注意点 内容は全て筆者の個人的な経験に基づきます。知る範囲で最 も良いと考えている方法や、そうであったらいいと思ってい ることをまとめています データ整備への理解が広まることへの利害関係者です。自覚 の無いバイアスをもし見つけたらご指摘ください 内容は予告なく追加・変更されます 4
5. 自己紹介 しんゆう Twitter：@data_analyst_ ブログ：データ分析とインテリジェンス https://analytics-and-intelligence.net 最近の活動：データを使いやすくする人 （データアーキテクトまたはデータ整備人） 5
6. 更新履歴 2022/04/07 初版公開 6
7. 「データ分析」を概観する 「データ整備」を考えるにあたり先には「データ分析」の全 体像を掴んでおく データを整備する目的は「インテリジェンス」を作るためで あることを忘れてはならない 7
8. 「データ分析」で得られるのは「情報」 「データ分析」を行うことで得られるのは「行動の結果」で はなく「行動のための情報」 データ分析だけしても何も変わらないのは得られるのが「情 報」であって「行動」ではないから 「情報」は何かを決めて行動するより先に必要 8
9. なぜ「データ分析」をするのか 未来のことはわからないから「データ分析」をして「情報」 を入手する必要がある 意思決定や行動に使うためには、「情報」はそれより先に入 手しなければならない 「情報」を入手することにより意思決定の不確実性を下げ る、とも表現できる 9
10. 「情報」には２つある 「情報」には「データ」と「インテリジェンス」がある 加工されていない生の状態は「データ」 ある課題に対して次にどうするかを決めるのに使えるよう 分析されたのが「インテリジェンス」 10
11. 状況次第で「情報」の意味がかわる その「情報」が「データ」なのか「インテリジェンス」なの かは状況による 「現時点で晴れている」という「情報」は「出かけるのに傘 を持って行くか」という課題に対して 歩いて5分のコンビニに行くなら「雨は降らないだろうと」 推論、判断できるので「インテリジェンス」 夕方まで出歩く予定ならばまだ判断がつけられないので 「データ」 11
12. データ分析でインテリジェンスを作る 「データ分析」とは「データ」から「インテリジェンス」を 作ること 「データ」と「インテリジェンス」の区別を明確にする 「データ」のままで「インテリジェンス」になっていなけれ ばどんなにたくさん集めても意思決定に繋がらない 12
13. 意思決定と分析のプロセス 「データ分析」はプロセスとして捉えると見通しが良くなる データ整備はプロセスの中での「収集」フェーズと大きく関 係しているので、プロセスを知っておくことで整備の役割を より明確に捉えることが出来るようになる 13
14. 意思決定と分析のプロセスの全体像 「データ分析」は目的の決定から始まり、収集・処理・洞察 を経て意思決定と実行に至る一連のプロセスである データ分析には様々なモデルがあるが、大きな流れは同じな のでここで紹介するモデルにこだわる必要は無い 14
15. 本資料における「分析」の使い方 本資料では「データ分析」はプロセス全体、「分析」は処理 フェーズと洞察フェーズを合わせた言葉として使う 一般的には処理フェーズと洞察フェーズのみを指して「デー タ分析」や「分析」と表現されることもあるので注意 15
16. 意思決定と分析のプロセスの注意点 必ず目的（＝何が知りたいのか）から始める 与えられたデータをプログラミングで何とかする 面白い話をするためだけの「分析」をする 見栄えのいいダッシュボードを作る どこかのフェーズで失敗すると全体が破綻する 一方通行ではない。いったり来たりするのが通常 「分析」だけしか考えないとデータをいじくるだけで終わる 16
17. 「収集」フェーズを知る 意思決定と分析のプロセスのうち必要なデータを入手するの が「収集」フェーズ 手元にあるデータが何かに使えないかを考えるのではなく、 知りたいことに合ったデータを求め、もし手元になければ獲 得を試みる 17
18. 収集フェーズで行うこと 知りたいことに合ったデータを探し、使えるようにする DBに入っているデータをSQLを中心に利用して抽出する 画像、音声、テキストデータなどを加工する 書籍や資料から探して取り込む 外部からレポートを購入する 必要なデータが手元にないなら入手するための手続きを行う 18
19. データがなければ獲得を試みる データが手元に存在していなければ獲得できないかを試みる システムでログデータを取れるようにする サイトにタグを仕込む センサーやカメラを設置する 専門家へのヒアリング、ユーザーへのインタビューを行う 事情を知っている人とのコネクションを繋げる 19
20. データはデジタルに限らない 「データ」というとデジタル、数値、データベースを思い浮 かべる人が多いがそれだけに限らない。全てが「データ」 紙、物体のような非デジタル 数値だけでなく文字列やテキスト 定量だけでなく定性 画像、音声、噂話 20
21. 収集フェーズとデータ基盤 収集フェーズがうまくいかない要因は数多い 原因のいくつかは事前に準備をしておくことで取り除くこと ができる 「データを集約し、保管しておくため仕組み」が「データ基 盤」 21
22. 収集フェーズの主問題 欲しいデータが適切な時期に手に入らない 原理的に不可能な場合を除いて考えるといくつかの要因に分 けられる 事前に準備しておくことで解決を図るのは自然な発想 22
23. データが手に入らない要因 データが獲得できないか、獲得できても必要な時に間に合わ ない 課題 例 不可能 正確な未来予測・人の真の能力 技術的 技術力不足・設定不足やミス・処理能力不足 人的 スキル不足・コネクションがない リソース 予算・人員・データへの優先度 23
24. タイミングの問題 あるデータが欲しいと思ってから収集に動き始めても必要な データを揃えることができない。つまり獲得のタイミングが 悪い データの獲得がすでに不可能 データの獲得が間に合わない データは獲得できるが処理が間に合わない 24
25. データが獲得できない データの獲得がすでに不可能になっている 設定していなかったログは遡って取れない データ獲得できるがこれから準備を始めても必要な時期に間 に合わない 衛星を打ち上げても明日の天気予報には使えない 来週欲しいがシステム担当に依頼したら1か月かかる 25
26. 獲得できても処理が間に合わない データが獲得済み、あるいは獲得できることはわかっている が、使えるようにするまでに時間がかかりすぎる 複雑なコードを書く データの仕様の確認や指標の定義を決めるための調整 データ量が大きすぎて処理に時間がかかる 外部のデータに申し込みしてから待たされる 社内申請 26
27. なぜデータ基盤を作るのか タイミングが悪くてデータが欲しいと思ってから動き始める のでは間に合わないなら事前に準備しておこう、と考えるの は自然な発想 データ基盤と呼ばれる「技術的にデータを集約し、保管して おくため仕組み」を作る 27
28. データを基盤に集約するだけではダメ データ基盤を作ってそこにとにかくたくさんデータを入れて おけばそれでいい、とはならない データ基盤に集約した後に使いやすくしておくこと（整理） も必要 整理をしないのは家の中の荷物が棚も何もなしに全て床に散 らばっているようなもの。そのままでも使えないことはない が、生産性が著しく悪くなる 28
29. データを「整理」する データを使いやすい形に「整理」するとは例えば以下のこと 重複や欠損を取り除く 型やタイムゾーンなどの形式を揃える ネストされたデータを展開する よく利用する指標や複雑な処理が必要な指標を集計する 処理時間が利用に耐えられるようなサイズに切り分ける 29
30. データ基盤の考え方は昔から存在する データは入手できるが間に合わないことがあるから先に集め て整理する、という考え方は以前からある 図書館／資料室／本棚 データ基盤の構築は最近話題になることが多いが、デジタル 化やクラウドに環境が変化しただけ 大規模なシステムとは限らず、データを集約し、保管してい るならそれがデータ基盤 30
31. 収集フェーズの構成を捉える 「獲得」「集約」「整理」だけでは収集フェーズは成り立た ない 全てが必須の活動。規模に併せて投入リソース量を調整する 収集フェーズとデータ基盤はひとまとめで考えるには領域広 すぎる 別の仕事として分けるとしたらどうするべきか 31
32. 収集フェーズを構成する仕事 収集フェーズに含まれる残りの仕事 抽出：社内外から分析に適切なデータを探し出し、分析に 合わせて加工する 品質管理：不良データを出さない、つくらない、入れないよ うにデータとデータの流れを管理する 記録：メタデータを組織として残し、活用する仕組作り 保管：適切な方法でデータを残す 32
33. 収集フェーズだけで収まらない仕事 密接に関連するが収集には収まらない データマネジメント：特にデータガバナンス クラウド：GCP、AWS インフラ：ツールの導入や権限管理 パイプライン：機械学習による推薦システムなど セキュリティ：内部流出、産業スパイ、不正アクセス防止 他にも法務、倫理、文化 33
34. 収集フェーズの分け方を考える方針 収集フェーズと一緒にデータ基盤も考慮する 個々の仕事だけでもかなり膨大であり分担が必要 あまり細かく分けるよりは大まかにわける 明確に線引きができるわけではなく密接に連携が必要ではあ るがわかりやすさを優先する 34
35. 解決する方法の違いで分ける エンジニアリングで解決することが中心か、人がうまくやっ ていくことが中心かで分けると見通しがよくなりそう 100%どちらかではなくどちらの要素が強いかを基準に考える 35
36. エンジニアリングが中心 エンジニアリングで自動化、仕組み化する データ基盤の構築 データ基盤の安定的な運用 データ基盤への集約 ETL・ワークフローエンジンの設定 36
37. 人がうまくやっていくことが中心 実現するためには技術が必要だが方針決めや調整の要素が強 い 整理 品質管理 記録 抽出 37
38. 獲得はデータの種類による エンジニアリングを担う人が担当する傾向が強い システムログの設定 タグの埋め込み スクレイピング 定性データは収集から分析まで全部行うことも多い インタビュー、アンケート、行動観測 コミュニティからの業界情報 38
39. 保管も別に考える 「集約したデータをどこかにためて置き、必要な時に取り出 せるようにする」ならエンジニアリング ためたデータは流出しないように守らなければならず、情報 セキュリティ（サイバー攻撃、内部流出、産業スパイなど） と密接に関わるため別に考えた方がいい 39
40. 「データ整備」と名付ける 別の役割であると認識するためには別の名前が必要 収集フェーズとデータ基盤構築・運用の中で人がうまくやっ ていくことが中心になる４つの仕事を総称して 「データ整 備」 と名付ける 本資料で言う「整理」のみをさして「データ整備」と呼ぶ人 もいるので注意 40
41. データ整備とは何か 改めてデータ整備について概観する 41
42. データ整備を一言で表現すると 「データ整備」を簡潔に表現すれば「集約したデータを、分 析する人が使いやすくする」仕事 整備は集約と分析の間にあり、つまりはデータ分析プロセス を行うと意識していようがなかろうが必ず仕事が発生してい る もし意識していないのであれば生産性が極端に悪いか、誰か が知らないところで行っているかのどちらか 42
43. データ整備の４つの仕事 抽出：社内外から分析に適切なデータを探し出し、分析に合 わせて加工する 整理：迅速かつ正確な抽出ができるように事前にデータをき れいにして使いやすくしておく 品質管理：不良データを出さない、つくらない、入れないよ うにデータとデータの流れを管理する 記録：メタデータを組織として残し、活用する仕組作り 43
44. 別の仕事として認識するべき理由 なんとなく誰かがついでにやる仕事ではないと意識を向けら れる データ整備を別の仕事と認識していないとおきること 気づいた人がやるが評価されずやるだけ損になる 立場の弱い人が押し付けられる 外注に丸投げされる 44
45. データ整備とは中間加工 データ整備をしないと何が起きるかを料理で例えると 整備をしないデータ＝肉牛そのまま 肉にする、切り分ける、ベーコンを作る、カツにして冷凍 する、あたりが全部整備 料理に例えれば中間加工 プロにはブロック肉、忙しい人には味付け済みで焼くだけ にするまで加工 45
46. データ整備の仕事１：抽出 分析のために必要なデータが必要な形で用意されているとは 限らず、様々な場所から入手して加工することになる 技術的、時間的な制約で分析する人が抽出できない場合、抽 出を担う人が別に必要になり依頼とコミュニケーションが発 生する 本節は抽出を担う人が分析する人とは別にいる場合を想定し ている。分析する人が自分で抽出する場合はインプットの入 手以降を参照のこと 46
47. 抽出の役割 正しい分析を行うために必要なデータを適切な時期に適切な 形で提供する 依頼された内容をそのまま実現するだけでなく、本当に必要 なデータを利用者に提供する 依頼の内容が不適切であったり、過不足があれば打ち合わせ で埋めることも役割に含まれる 47
48. 抽出のタスク ルール策定、管理表の作成と運用、依頼ひな形の作成 内容・納期・アウトプットの決定、不当な依頼をはじく、着 手する優先順位を決める インプットの入手、コードを書く、アウトプット（ダッシュ ボード含む）の作成、追加変更要求への対応 自動化、業務フローや処理手順の見直し、整理へのフィード バック 48
49. 依頼を管理する 抽出依頼は多種多様な内容が社内外の様々な人から入るので 適切に管理しないとすぐに抜け漏れが発生する アウトプットや作成物は全て番号で紐づけると後で楽になる 49
50. 依頼のルールを決める 依頼時のルールで決めておくこと １つの依頼には1つの内容 受付窓口 受付担当 依頼時に最低限書いてもらうこと 納期の目安 50
51. 1つの依頼では1つの内容にする まったく違う内容が混ざっているとやりとりが混乱する 厳密に分けることは難しいので依頼者が分けた方がいいか判 別が難しければひとまず依頼を出してもらって受付時に相談 する 51
52. 受付窓口を１つにする 正式な依頼の窓口は１つに決める コミュニケーションのチャンネルがあちこちに散っている と抜け漏れが発生する 誰がどんな依頼を受けているかわからなくなる すでに行った内容と同じ依頼があっても気づくのがより難 しくなる 52
53. 受付担当も決める 依頼する部署や人によって誰が抽出を担当するか事前に決ま っている場合は担当者が受付すればいい そうでない場合は誰が受付するか決めていないと宙ぶらりん になる依頼が出る チームもしくは個人で受付担当者を決める 53
54. 最低限書いてもらうこと 依頼時に書いていなければ打ち合わせ前に聞く 区別がつく題名 概要 希望納期 アウトプットの形式の希望 書式だけ決めても守られないのでひな形も作る 54
55. 抽出依頼の目的や背景は必須ではない 正しい依頼を出すのは本来は依頼者の責任 内容の過不足の疑いがあり何がしたいのかの確認が必要にな ったら聞けばいい 依頼者の判断で書いてもらうことは差支えない 55
56. 依頼管理表を作る 依頼管理表に必ず書いておくべきこと 依頼番号 依頼者と合意した納期 依頼者と抽出担当者 依頼の題名 簡潔にまとめた進捗状況 56
57. 依頼番号は管理表以外でも使う 通常は通し番号。ユニークであれば何でも良い 依頼番号で全て紐づけると後で探す時に楽になる インプット 書いたコード アウトプット やり取りの記録 57
58. 急ぎの依頼は確約しない 事前に提示する納期はあくまでも目安であり「内容が確定し てから必要な期間」であることを強調する 急ぎの場合は依頼時に明記することもルールとしておく 58
59. 依頼管理表は使いやすさを心がける 使いづらいと使われなくなり依頼の管理がおざなりになるか 各人が独自に管理してしまう 使いやすい依頼管理表に必要なこと 一覧が見やすい 動作が軽い 並び替えが自由にできる 59
60. 依頼受付の注意点１：相談は歓迎する 別件のやりとりのついででも立ち話で口頭でも構わない 「こんなデータは取れる？」「もしこれ出してもらうならど れぐらいかかりそう？」と気軽に聞いてもらえる関係がある と良い 稼働が必要になったら正式に依頼してもらう 60
61. 依頼受付の注意点２：断るべきこと 聞いても具体性な行動が出てこない興味本位なデータの抽出 依頼の中に混ざっている依頼者が行うべきこと レポート作成（一部だけが混ざっている場合は特に注意） 関与していない場所で作られた無茶苦茶なデータの整形 その他の依頼への影響が大きい依頼 他の依頼に一切手が付けられなくなるような分量なら分割 して重要な部分だけ対応する 61
62. 依頼受付の注意点３：必ず依頼をもらう 少しでも稼働することになるなら必ず依頼を出してもらう ちょっとやるだけだからと記録を残さないと後でやりとりを 検索するのが難しくなる 依頼者・抽出担当者が退職などで不在だとさらに大変になる 62
63. ヒアリングではなく打ち合わせを行う 依頼として現れてきたことから、依頼者が目的を達成するた めに本当に必要なデータとのギャップ埋めるためのコミュニ ケーション 決めなければならないことは３つ 内容 アウトプットの形式 納期 63
64. 分析のための抽出を心がける 抽出はより良い分析と意思決定を行うために仕事を分担して いるのであり抽出担当者の希望や都合で誘導してはならない 抽出が楽な方法だけを提示する 抽出担当者があるべきだと思うデータを出す 分析や意思決定に踏み込むなら役割と責任を変える 64
65. 追加変更はある前提で考える 問題が複雑であるほど最初から完璧にはならない 分析を初めてから追加や変更したくなることは当然ある 事前に追加要請がありそうな項目を打ち合わせで確認できれ ば追加しておく 追加分が本当に必要なデータなのかは別の話なので改めて検 討する 65
66. 打ち合わせに望む心構え まず話をちゃんと聞く 意味が無いとか無茶ぶりとか決めつけない ただし鵜呑みにはしない 66
67. 依頼そのままを実現してはいけない 依頼の内容が本来必要なデータと乖離していると抽出しても 無駄になる 本当は他のデータがあるのに依頼者が自分の知識の範囲内 だけで依頼してきている 具体的な行動が想定されおらず興味本位だけで大量の依頼 を出している 抽出するために必要なコストの計算が現実とは大きく乖離し ている 67
68. 依頼に至った背景や知りたいことを聞く 依頼内容に違和感や過不足を感じたら詳しく聞く 本当に必要なデータと違うなら詳しく話を聞いて「本当に知 りたいことのためになるデータ」を提案する 68
69. 理想は何かを聞く 依頼者が出来ない、データが存在と思い込んでいると本来な らば実現可能なことが依頼に出てこない まずは理想的なデータは何かを聞く。その後納期、コストな どの制約下でいつまでならば何ができるかを考える 何も出てこなければ見てみたい、やってみたいだけで抽出は 不要かもしれない 69
70. 何かしら抽出が実現できないか検討する 抽出するとしてもごく基本的な数値だけで十分なことも多い 全部を突っぱねるよりは実現できそうなことを探してみる ただし他にやるべきことはいくらでもあるのでそちらを押し のけてまでやる必要はない 70
71. やり取りが長い場合は依頼を疑う 問題が複雑ではないのに1つの依頼でやり取りが何十回も続く 場合は依頼内容を疑う 目的が不明確でとりあえず思いついたから依頼した やろうとしていることは何となくあるが具体的な動きが考 えられていない 細部にこだわりすぎている 何が知りたいかを聞き、そのうち最も重要な2・3の項目に絞 ることで十分足りることも多い 71
72. 値が変わることは説明する 状態の変化によって以前の抽出と数字に違いが出るなら先に 説明しておく 退会による会員数やキャンセルによる売上の減少 分析に支障がないぐらい影響が軽微と依頼者が判断すればそ のまま抽出する 分析に耐えられないレベルで値が大きく変わる場合は集計方 法を見直す 72
73. 全て実現しようとしない 重要度が低い内容の一部を削ったり簡単にすることを提案す る 具体的にどこにどれぐらいの影響が出るかを提示すると受け 入れられやすい 本当に必要なことならやるしかないが抽出担当者が全て引き 受ける必要はない 73
74. 納期は余裕を持って決める 納期遅れを引き起こす事態が起きる事を常に想定しておく 急ぎの依頼が入る インプットの入手が予定より遅くなる 思っていたより複雑でもっと時間が必要になる 早めに終わっても誰も損しないので余裕を持った設定を提案 する 74
75. 見通しが立たなければ決めない 内容や納期が決められない場合は保留にする 必要なインプットが入手できるかわからない インプットを外部から入手するので問い合わせが必要 データの仕様を先に確認してからでないと実現が判断でき ない 「調べて折り返す納期」は決める 75
76. アウトプットは使い方を想定する 提供したデータを使う人にとって良い形式に出来るだけあわ せる 抽出側にとって都合が良い方法だけを考えてはいけない ただし依頼者がやるべきことを全て抽出で行う必要はない 76
77. 優先順位の決め方（１） 取りかかる順 納期が近い依頼 内容を早めに決めた方がよさそうな依頼の打ち合わせ データの入手や仕様の確認の手配 納期がまだ先であっても時間がかかりそうな依頼 重要度が高い依頼 77
78. 優先順位の決め方（２） 取りかかる順の続き 納期までの余裕がある依頼の打ち合わせ 納期が決まっている依頼 納期が決まっていない依頼 実際には後半まで回ってこないで納期が迫って優先順位が上 がってから着手になることが多い 78
79. コードを書く前にやること アウトプットに至るまでの大まかな流れを逆算して考える アウトプットを作るためにはどういったインプットが必要か を考える 手元にあるデータから何ができるかではなく「アウトプット を作るために必要なデータは何か」を考える 79
80. インプットを集める 必要なデータが全て手元に揃っていなければ入手する手配を する 社内の他の部署が持っている アクセス権限のないシステムの中にある 外部から入手する 獲得から始める 80
81. 追加変更がしやすいコードにする 会員情報の例 IDをユニークにしたリストを作る そこに様々な属性やフラグを追加する 最後に絞り込みと集計を行う 追加があったら集計の直前に挿入する 81
82. 検算する ある処理の前後で値が変わらないことがわかっているのであ れば検算できる トランザクションとマスタのINNER JOIN IDごとに特定のフラグや状態を加えるLEFT JOIN 購買件数や売上の集計 全部書いてからではなく段階を経るごとに行う 82
83. パラメータを活用する 1つのコードの中で同じ値を複数個所で指定する場合はパラメ ータを使う 日付 絞り込み 店舗やIDでの絞り込み パラメータを指定する場所は先頭に置くとわかりやすい 83
84. アウトプットは基本的な設定まで ダッシュボードなどでのグラフの作成や変更は分析する人が やるべきこと 依頼に含まれていたらやり方を教えるようにする 整備からは逸脱しているが、他にできる人があまりいないの で手伝うことになることも少なくない 84
85. 行や列の名前がわかるようにする 特に英語表記は他人にはわかりづらく問い合わせが増える。 作った当人でも時間が少し経つとわからなくなる 日本語表記にする 説明をすぐわかる所に書く 命名規則があるならば従う 85
86. 個別のツール内にコードは書かない 整理したデータを読み込ませるだけにした方がいい理由 表示までの時間が長くなる 加工のための関数が貧弱 修正がまとめて行えない ツールを変えるコストが膨大になる どこに何のロジックがあるかわからなくなる 86
87. ツールでは整理したデータを使う ツールの機能で新しい値やフラグの作成などは行わない方が 無難 データ基盤で整理してツールではツールでしか出来ないこと を行う 集計軸と値の切り替え 絞り込み条件の変更 可視化 87
88. コードは別に管理する ツール内にコードを書く場合もコードは別に管理する ツールの中だけにしか残していないと一括での修正が面倒に なる 88
89. データを残すかの判断材料 個別の依頼のために作られるデータは際限なく増えていくの で必要なければ残さない 定期的な自動更新が必要か コードを渡して解決するか ダッシュボードが必要か 再現できるか 処理は間に合うか 89
90. 復元できないアウトプットは残す 後で実行すると値が変わる場合は提供時点のデータをできる だけ残す 退会やキャンセルなど後でステータスが変わる レコードが増える 後々トラブル対応やデータが間違えていた際の調査で必要に なる 90
91. コードを渡す際の注意点 定期的に実行したいがツールを使うほどでもないならコード を渡すと楽 パラメータを利用して変更する場所は必要最低限にする 変更箇所は一ヵ所にまとめておく。コードの先頭推奨 しばらくすると動かなくなったと連絡が来るのでオリジナ ルのコードは確保しておく 91
92. 納期に遅れそうになったら早めに連絡 依頼者にも次の予定がある 遅れそうな可能性が出てきた段階で一報を入れる 必要な時期にインプットの入手が出来ないことがわかったら 納期の調整や内容の変更を打診する 92
93. 業務フローを改善する インプットの入手を効率化にするために入手先の作業を確認 し、改善に参加する 業務フロー 利用ツール 加工方法や手順 93
94. 汎用的なデータに入れるか検討する 指標を作るのにたくさんの加工が必要だとコードが長くな り、ミスが増えるし後で見るのも大変 今後も使っていくなら後述する汎用的なデータを作ってそこ から呼び出す方がいい 94
95. データ整備の仕事２：整理 抽出を迅速かつ正確に行うために、データ基盤に集約したデ ータを中心にきれいにして使いやすくしておく 本資料ではデータ基盤に入っているデータを中心に考える 非デジタルデータはデジタル化してデータ基盤に取り込む か、ファイリング 95
96. 整理のタスク 品質レベルに基づいて汎用的なデータを作る 作ったデータを保守する。不要なら削除する システムやツールの変更に対応する 96
97. データ基盤 本資料ではデータベースに入っているデータを中心に考える が、それ以外のデータも考え方は同じ 音声 画像 紙（書籍・資料） 実物 97
98. 未加工データを入手する もし集約した時点で加工済みなら未加工のデータに入れ替え るようにする 別の方法での集計や、改修が必要になった場合に元のデータ が存在しないと非常に難しくなる 98
99. 汎用的なデータを作る 汎用的なデータとは様々な依頼に対応できるように整理して 使いやすくしたもの トランザクションやマスタに様々な値や状態のフラグを付与 する 店舗や会員の状態などのデータは1つのテーブルに集めたほう が使いやすい 99
100. 不正なデータを修正する システム的にはエラーにならないが正しくないデータを品質 レベルに基づいて修正する 重複 欠損 列がずれた文字列 先頭の0が消えたid 想定外の値 100
101. 表記ゆれを無くす 同じ対象でもシステムの違いや手入力が原因で表記ゆれがあ ると正しい集計ができなくなるので直す マスタを作る 一括で変換する 手作業（最終手段） 101
102. 定義がぶれると困る指標を集計する 定義が決まっていてもその都度コードを書いているとどこか でずれる ぶれると困る指標は集計しておく 重要度が高い 多くの人が使っており影響が大きい 102
103. 形式を揃える 同じ形式で統一する ファイル名、テーブル名、カラム名 DATETIMEかTIMESTAMPか タイムゾーン フラグの形式（1/0、True/False） 区分値は数値か文字列か NULLと0や空欄の混在をなくす 103
104. 区分を作る 数値や値のパターンに応じて様々な区分値を作る 年代 階級値 申し込み状況 会員の状態 104
105. フラグを立てる 退会、許諾、申し込みなどの各種状態フラグ 1/0、True/Falseなど形式はそろえておく 筆者のおすすめは「数値型で0/1」 105
106. データの一部を取り出す 実際の利用で使うことが多い部分を取り出しておく 日時から日や月 住所から都道府県 URLからパラメータの値 106
107. 共通IDの付与と作成 サービスやシステムをまたがる場合にIDを繋げるマスタがあ るならJOINしておく 共通IDが無ければ作る 107
108. 個別の分析で作ったよく使う指標 最初は個別に作っていても、たびたび使われるなら汎用的な データに作る 「売上」の例 総計 過去1年の月別 いろいろなパターンで作れるが多すぎても紛らわしいのでニ ーズがあってからで良い 108
109. 使いやすいように処理しておく 使おうと思ってから作ることもできるが、先に作っておく方 がいいその他の例 JSON型を展開 文字列になっている数値や日付の型を正しくする unixtimeをDATETIMEやTIMESTAMPに変換 理由のない空白をNULLにする 109
110. センシティブなデータを隔離する 個人情報や機密情報は誰もが使えるようにはしない 暗号化、マスキング、フラグ化により特定できないようにし て使う 閲覧権限の管理も必要 110
111. 個別の事情を排除する クライアントやサービスごとにその都度条件を変えることな く集計できるようにする 売上 件数 会員数・顧客数 個別の事情が排除出来ない部分は別に作る 111
112. マスタは結合しておく方が楽 マスタと1対1で対応して誰が行っても同じ結果になるならば マスタや属性は汎用的なデータに入れておく 店舗 会員の状態フラグ 112
113. 解釈で結果に違いが出るなら結合しない 同じ店舗IDに対して店舗名によって有効期間が違う複数のレ コードがある店舗マスタは集計方法で結果がかわる IDごとに集計して名称を最新のIDに寄せる 店舗名で集計して店舗名変更前後で値のありなしがかわる どちらを使うかは利用者次第 113
114. 定義の変更によるデータの持たせ方 定義を変更するか、別にカラムを作るか Aは以前のままで新しくBを作る Aに新しいデータを入れてBに以前のデータを残す 全体で統制が取れるか、影響範囲が小さい場合を除けば前者 が現実的か 114
115. 変更は事前に周知する 関係者への周知は必須。平行稼働期間も設けた方がいい 指標の定義の変更 参照するテーブルやカラムの場所や名称の変更 システムやツールの移管 外部に公開していたりパートナーと共有している指標は特に 慎重に進める 115
116. システムやツールの移管 移管するなら前後で同じアウトプットが出来るようにする データ基盤の変更 ツールの変更 プログラミング言語の変更 全てを新しいシステムやツールにするのではなく利用してい ないデータを洗い出して除外する 同じにできない場合のずれの許容度は品質レベルに併せる 116
117. ツールの権限を個人にしない 権限を個人にしておくといなくなった時に問題が起きる 変更するように決めておいてもどこかで抜け漏れが発生する 可能性が高い 権限やアカウントは個人に付与せず、共有アカウントにして おく 117
118. 使われていないデータは削除する 放っておいても事故にならないが、必要なものが見つけられ なくなるので定期的に不要なデータは消した方がいい ただし勝手に消すと問題が発生して問い合わせ対応に追われ る 利用者が把握できるならヒアリングする。広い範囲で利用が されているデータならば期限を決めて告知し、問題起きない かを確かめる 118
119. 抽出と整理のバランスを取る 作ることだけに興味がある人だけで整理を行うと誰にも使わ れない大量のデータだけができる たくさんデータを作っても使われないなら無駄になる 何をどれぐらい作るかは抽出や分析の担当者も参画した方が いい 119
120. 誰も使わないなら整理はほどほどにする やろうと思えばいくらでも巨大なデータを作ることはできる が使われず無駄になるだけ 抽出、分析、エンジニアリング、周辺の領域も視野に入れる 120
121. 整理をし続けることが前提 会社の成長に伴いデータも増えるしやるべき事も変わってい くので一度作って終り、とはならない 使いやすさを維持するためには頻繁な変更が必要だが、シス テムやツールが追いついていない 簡略化や自動化はこれからできるようになってくるとしても 当面は人力で何とかする 121
122. データ整備の仕事３：品質管理 不良データを入れない、作らない、出さないための仕組み作 り 獲得、集約されたデータや整理や抽出で作られるデータが品 質レベルに見合っているかを監視する 122
123. 品質管理のタスク 品質レベルを決める 不良データを検知し、発生原因を突き止め改善する 集約したデータが品質を満たしているか評価する 品質レベルに合ったデータの定義と整理の方針を決める 提供するデータの品質を担保する 品質が守られているかを監視する 123
124. 品質レベルを決める 求める品質レベルを決めるのが先 整理の対象や方法は決めた品質レベルに従う。品質レベルは 分析への需要で決まる 品質レベルを決めないと目標が作れない。とにかくひたすら やるか、空いている時間にちょっとだけやるかになる 124
125. 品質レベルは随時見直す 最初は分析する人達と大雑把に決めてあとは使いながら需要 によって変えていく 技術的に出来ることや作業量の大小によって変えていいのは 「どれだけ実現できるか」だけ 125
126. 不良データを認識する 不良データとは「システムではエラーにならないが品質を満 たしていないデータ」のこと 同じデータであっても求められる品質レベルによって不良デ ータかそうでないか変わる システムでは検知できないため入ってきたら主体的に検知し なければならない 不良データなのか、異常値が不良データに見えているのかは 自動で判別ができないことが多い 126
127. 不良データかもしれないデータ あるべき状態と違うデータは不良データの可能性がある 通常とは明らかに違う 想定と大きくずれている 想定していない値がある トランザクションにあるのにマスタにない マスタにあるがトランザクションにない トレンドがある時点を境に大きく変わった 127
128. 不良データを検知する システムではエラーなのか自動判別できないので主体的に探 さないと見つからない 数値に違和感を感じた 事前に決めた閾値を超えた 一覧にない値が出てきた 提供したデータを見ている人から連絡をもらう前に整備側で 気づくのがあるべき姿 128
129. 不良データを検知する仕組みを作る 不良データの可能性がありそうなデータが出てきたらアラー トを鳴らす 簡単に作るなら「その日にレコードがあるか」や「直近〇日 の平均値や前年同月との比較」 アラートが多すぎると重要なデータへの警告を見逃すので区 別を付けるか数を調整する 129
130. 不良データかどうかを判別する レコード数が直近に比べて増加したとする メディアに取り上げられたために訪問が増えたならば「異 常値であるが不良データではない」 バッチが途中でとまって再実行されたせいで前日分だけKPI であるPVが2倍になったならば「不良データ」 先日のリリースの影響で1%程度多く数値がでるようになっ てしまった場合はもとめられる品質レベル次第で決まる 130
131. データを評価する ニュースやSNSなどのデータは正確性や信憑性を評価する グラフや結論におかしなところはないか 認知バイアスに捕らわれていないか 発信源は信用できるか デマやディスインフォメーションではないか 131
132. 獲得や集約の段階できれいにする 不良データは獲得や集約の段階で発生しないように改善して いくことが原則 発生したら原因を調査し、改善方法について獲得や集約の担 当者と協議する 改善が不可能な場合は整理するしかない 改善は可能で品質レベルを満たせるようにはできるがコスト に見合わないなら整理で吸収することも考える 132
133. 不良データの処理を決める 求められる品質レべルと重要度を考えて優先順位を決める 不良データだからといって全てきれいにする必要はない。分 析に影響がない範囲ならそのまま放置することもある 全社で見ている数値など本当に必要なデータは完璧に整理 しなければならない たまにしか使わない重要度の低い指標なら不良データの発 生を止めずに整理で吸収してきれいにする 133
134. 過剰品質に注意する 不良データを「作らない」だけでなく求められていない品質 レベルを過剰に「作らない」 さしあたりざっくりわかれば十分な指標なのにあとちょっ とで完全に綺麗になるからと膨大な時間を費やす 目的も背景も知らずに大量のテーブルやカラムを作る リモコンに誰も使わないボタンを大量につけているのと同 じ。作り手が自己満足するだけ 134
135. データの定義を決める 間違い探しと答え合わせのコミュニケーションは相当なコス ト 運用されてから時間が経つほど変更、統一することが困難に なる 回避するためには使う前に定義を決めて周知し、守らせる 135
136. 定義の違いによるぶれの例（１） 「売上」の集計方法 タイミング。購入時、入金時など 消費税のありなし キャンセルは除外するか ポイント利用、クーポン利用、割引分は減額するか 集計対象にする区分 136
137. 定義の違いによるぶれの例（２） 期間の指定方法。例は「4/16を基準に過去3か月以内」 3か月前の同日以降（1/16日以降） 90日以内（1/16日以降） 91日以内（1/15日以降） 月単位で見て3か月以内（1/1以降） 137
138. 定義の違いによるぶれの例（３） 「年代」の作り方 階級値のはば。10年きざみか5年きざみかあるいは混在 高年齢層の扱い。60歳以上、70際以上などでくくる基準 低年齢層の扱い。19歳までをまとめて「10代以下」など 有効な年齢の上限と下限。上限なら80歳までか、110歳ま で有功にするか 有効範囲外な階級値の表記。「その他」「不明」など 138
139. マスタデータを正しく保つ 入力制限をするなどして不良なデータを発生させないように する 直接扱うのが各部門ならば正しい入力がされているかを監視 する 外部から受け取るデータはひとまず整理で対応しつつ、改善 の方法を模索する 139
140. 数字の感覚を持つ 知っている人が見たら明らかに間違えているとすぐわかる数 値を出さない 桁数が全然違う あきらかにすぐ見つかる値がない 正しそうかの感覚がわからなければ提供する前に依頼者や知 っている人に確認する 新しい施策などで基準が不明な場合も依頼者と合意を取る 140
141. アウトプットやコードをレビューする 第三者の視点があると質が上がりミスも減る 能力や認識の違いを埋めることもできる 141
142. 合意した内容に勝手に付け加えない 「これもあったら便利だろう」と独自の判断で付け加えても 無駄になる 付け加えた方がいいと思うデータがあったら事前に提案す る。ただしあって困ることはないので依頼者から提案を拒否 されることはまずない。それで合意したと思って追加をして も結局使われない その時に本当に必要なデータなのか、リソースを他の仕事に あてるべきかを自分に問う 142
143. データ整備の仕事４：記録 データを迅速かつ正確に使う際ためにデータのためのデー タ、と言われるメタデータを記録する 個人だけでなく組織の活動になるかが鍵になる 143
144. 記録のタスク メタデータを書く メタデータを書きやすい環境と仕組みを作る メタデータを書くことが組織の活動になるように後押しする 144
145. メタデータはたくさんある ある指標のメタデータの例 定義、背景、データ型、作るためのコード 作成日、最終更新日 重要度、利用頻度 利用者、利用上の注意点、利用状況 変更削除時の連絡先 145
146. ある指標のメタデータの例（続き） メタデータには他にもある。これでも一部でしかない トラブル発生時の連絡先 権限の管理者、権限の種類、対象者のリスト 作成するのに使われているテーブル、このカラムを使って 作られているカラム このカラムが使われているコードやダッシュボード 146
147. メタデータを書く理由 何も記録が無いと時間を無駄にする 同じような指標が複数あるが何が正しいかわからない 見たいデータがどこにあるかがわからない 作成者に聞いてみたが当人も忘れているので調査待ち 作成者に聞いてみたいが誰に聞けばいいかわからない わかる人がもういないのでコードを紐解いてもらうところ から始めなければならない 147
148. 自分でメタデータを書く 誰も書いていないのであれば自分で積極的に書く 少しづつでも良いので継続的に書く 後でまとめて書こうとしても忘れるのでその時書く 定義を決めた 新しくテーブルができた 既存の指標の定義や背景を調べた 148
149. メタデータを絞り込む もし全てのメタデータを書けたとしても頻繁に参照されるの はそのうちほんの一部 滅多に使われないメタデータと扱いを分けないと探すのも手 間になる よく使う、たまに使う、めったに使わないぐらいでわける 通常はよく使うメタデータだけ表示してあとは必要に応じて 見られるようにするといい 149
150. メタデータの絞り込みのイメージ 新しく買ったパソコンのマニュアルの例 まず必要なのは「オンオフのボタンがどれか」 もしマニュアルが数千ページあり、最初にパソコンの形の 変遷が延々と書かれていても困る よく使われる機能やトラブル時の連絡先などは最初のわか りやすいところにまとまっていてほしい メタデータも同じで書いてあれば知りたい人には有用であっ ても多くの人にはそうではない 150
151. メタデータを書きやすい仕組みを作る 手作業で書いているとすぐに手が回らなくなるしやる気もな くなる テンプレートを作ってメタデータを書くための準備を減らす 新しいデータが増えたら書く欄やページだけでなくデータ型 など自動で取得できるメタデータを自動的に生成する 151
152. 組織の活動にする 特定の個人が最初だけ書くがすぐに誰も書かなくなる しばらくすると後から入ってきた別の人が1から調べてまた作 る、が繰り返される 組織の活動として関係する全員が書く文化にしたほうがいい 担当者レベルでは強制力がないのでマネージャーレベルから の投げかけを要請する 152
153. データ整備をしながら全体のバラン スを考える データ整備の中でも偏りがあるとうまく機能しない データ整備だけでは成立しないので周辺の仕事にも気をくば る ただし足りない部分を自分で補わなければならない、という わけではない 153
154. 全ては程度の問題 やろうと思えばいくらでも整備だけでリソースを使えるが見 返りは少ない 重要なことから優先順位を付けながら対応していく 整備の中で 収集フェーズの中で データ分析プロセスの中で 154
155. 整備の中でバランスを取る 抽出と整理のどちらかに偏り過ぎないようにする 抽出に偏ると目先の依頼をさばくだけになる 整理に偏ると誰も使わないデータだけが作られ続ける 抽出と整理は行っても品質管理と記録がおざなりになりやす いので特に気を付ける 155
156. 収集フェーズの中でバランスをとる 獲得や集約のリソースが不足しているならツールを利用する か、整備の担当者が獲得や集約も部分的に担えるかを考える 放置していると改善されるべき状態が放置される 入手出来るはずのデータが手に入れられない 自動化できる作業が手作業になる 少ないデータを無理やり整理して使う 156
157. データ分析の中でバランスをとる 整備だけしても利用者がいないと意味がない。分析や意思決 定への関与もしなければならないかもしれない。しかし別の 責任を持たなければならないことは注意 分析する人がいない 分析をしても意思決定に使われない 意思決定しても行動に繋がらない 157
158. データ整備の仕事をする際の考え方 データ整備の進め方の次に考え方も紹介する データ整備が独立してゼロから始まることはなく、周辺の仕 事を行う人との関わりの中で行うことに気を付ける 158
159. 整備以外の領域も意識する インフラ、情報セキュリティ、分析、意思決定、技術、理 論、法務、倫理、採用、育成・・・ 全てが出来る必要もなければ不可能ではあるが、まったくわ からないというわけにもいかない 無理のない範囲で理解を広げるようにする 159
160. 理想を押し付けない 整備の仕事が認識されるのは企業や事業がある程度進んでか らになることが多い 理想的な形は常に追い求めなければならないが、一方で現状 の仕組みになっているのは様々な理由や背景があるはず 事情を理解した上でより良い方法の提案をするよう心掛ける 160
161. 他の仕事をする人を尊重する 整備の担当者が他の人よりデータの扱いに長けているのは当 然であり、自分が詳しいことを相手が知らないからと見下す のは最低な態度 大半の人にとってはデータを扱ったり見たりするのは仕事の ほんの一部であり、分担しているのだからお互いに尊重し合 うことが大切 同時に言うなりになるわけでもなく、理不尽な扱いには抵抗 すること 161
162. まとめ 仕事ができるようになるためにもっと重要なこと 今後書く予定なこと お問い合わせ先 162
163. スライドを読むだけでは仕事はできない 本資料はデータ整備の仕事を行う上での基礎であるがこれだ けでは仕事はできるようにならない 実践と経験を経なければ何も身につかない スライドでは詳しい説明はできていない 働く企業、業界、業種、分析対象、手法にはそれぞれに独 自の事情と独自のデータがある 人が相手なので知識と技術だけでは足りない 163
164. 今後書く予定（１） データ整備に必要なスキル データ整備とキャリア データ整備の現状 データ整備のアンチパターン これからデータ整備を始めるなら 164
165. 今後書く予定（２） データ整備人材の採用、育成、評価 規模に合わせたデータ整備 データ整備とデータの民主化 データ整備が雑用にならないためにするべきこと データ整備のためのSQL 165
166. お問い合わせ 本資料に関するお問い合わせ・データ整備に関するご相談は 以下からお願いします Twitter（DMでも受付しています） 　アカウント：@data_analyst_ ブログのメールフォーム 　URL：https://analytics-and-intelligence.net 166