データ整備とどう付き合うか

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

1. データ整備とどう付き合うか 2021/12/17 しんゆう 　@data_analyst_
2. • データを集めたのにどうもうまく使えないという話は よく聞こえてくる • その原因の１つに使いやすくするための「データ整 備」が欠けていることが考えられる • データ整備はデータを扱うなら必須であるがまだ浸透 しているとはいえない • そこでデータ整備の役割や取り組み方を広めることを 意識してまとめた 本資料について 前置き
3. • 内容は資料公開時点における私見です – 後日意見が変わっているかもしれませんがご了承ください • データ整備への理解が広まることへの利害関係者です – 気を付けてはいますが自覚の無いバイアスがあるかもしれ ません • 全体像を描くことを意識しています – なので自分のことは棚に上げています 本資料について 本資料についての注意点
4. 目次 1. 「データ整備」を概観する 1.1. 意思決定と分析のプロセスの全体像とデータ整備 1.2. データ整備の役割とタスク 1.3. データ整備の現状を眺めてみる 2. データ整備との付き合い方を考える 2.1. データ整備の捉え方 2.2. データ整備の進め方 2.3. データ整備を担う際に気を付けてほしいこと 2.4. データ整備をしないとどうなるのかを説明する
5. • 名前：しんゆう　 • ブログ：データ分析とインテリジェンス https://analytics-and-intelligence.net • Twitter：@data_analyst_ • 最近の活動：データを使いやすくする人 （データアーキテクトまたはデータ整備人） 本資料について 自己紹介
6. 目次 1. 「データ整備」を概観する 1.1. 意思決定と分析のプロセスの全体像とデータ整備 1.2. データ整備の役割とタスク 1.3. データ整備の現状を眺めてみる 2. データ整備との付き合い方を考える 2.1. データ整備の捉え方 2.2. データ整備の進め方 2.3. データ整備を担う際に気を付けてほしいこと 2.4. データ整備をしないとどうなるのかを説明する
7. 目次 1. 「データ整備」を概観する 1.1. 意思決定と分析のプロセスの全体像とデータ整備 1.2. データ整備の役割とタスク 1.3. データ整備の現状を眺めてみる 2. データ整備との付き合い方を考える 2.1. データ整備の捉え方 2.2. データ整備の進め方 2.3. データ整備を担う際に気を付けてほしいこと 2.4. データ整備をしないとどうなるのかを説明する
8. • 本資料における「データ分析」とは、意思決定のため に行う予測や推論のこと • 大前提として、データ基盤を構築する目的は「データ 分析」を行い意思決定の質を向上させるため 大前提：「データ分析」は意思決定のため 意思決定と分析のプロセスの全体像とデータ整備
9. • 「データ分析」は目的の決定から始まり、収集・処理 ・洞察を経て意思決定と実行に至る一連のプロセス • データ分析プロセスにはCRISP-DMなどいろいろなモ デルがあるが、概ね言っていることに違いはないので 自分の理解している言葉遣いで考えてもらえればよい 意思決定と分析のプロセスの全体像 意思決定と分析のプロセスの全体像とデータ整備 目的の 決定 要求 収集 処理 洞察 伝達 決定と 実行 フィード バック
10. • 「データ分析」は目的の決定から始まり、収集・処理 ・洞察を経て意思決定と実行に至る一連のプロセス • 本資料における「分析」は特に断りが無い限りプロセ スにおける「処理」「洞察」フェーズを指す。つまり 「手に入れたデータを何とかする」こと 「分析」とは「処理」と「洞察」 意思決定と分析のプロセスの全体像とデータ整備 目的の 決定 要求 収集 処理 洞察 伝達 決定と 実行 フィード バック
11. • 「データ分析」は目的の決定から始まり、収集・処理 ・洞察を経て意思決定と実行に至る一連のプロセス • 「収集」フェーズでは分析のためにデータを集める • データなら何でもよいのではなく、いま知りたいこと のためのデータでなければならない 「収集」では目的にあわせたデータを集める 意思決定と分析のプロセスの全体像とデータ整備 目的の 決定 要求 収集 処理 洞察 伝達 決定と 実行 フィード バック
12. • 「データ分析」は目的の決定から始まり、収集・処理 ・洞察を経て意思決定と実行に至る一連のプロセス • 「収集」フェーズでは分析のためにデータを集める • 主問題：必要な時に必要なデータが手に入らない 「収集」フェーズの主問題 意思決定と分析のプロセスの全体像とデータ整備 目的の 決定 要求 収集 処理 洞察 伝達 決定と 実行 フィード バック
13. • 必要な時に必要なデータが手に入らない原因（一部） データが手に入らないとどうにもならない 意思決定と分析のプロセスの全体像とデータ整備 要因 具体例 原理的に入手することが無理 正確な災害予知・人の真の能力 欲しいと思ってから入手しようとし てもできない 去年開催していたキャンペーンのクリッ クログを今からとる 入手はできるが欲しい時に間に合わ ない 観測所を立てる（明日の天気予報には使 えない） 入手しているが処理が追いつかない 100個のExcelファイルにフォーマット がばらばらで格納されている 入手しているが組織やマネジメント が要因で使えない エンジニアのリソース不足で手が回らず 他に扱える人がいない
14. • 原理的に無理ならばあきらめて代替手段を捜すかあき らめる • 組織やマネジメントが要因ならばまた別の問題 • それ以外の問題はどう解決したらいいのか？ 問題を切り分ける 意思決定と分析のプロセスの全体像とデータ整備
15. • データの入手が間に合わない データは取れるがタイミングが悪い 意思決定と分析のプロセスの全体像とデータ整備 要因 具体例 原理的に入手することが無理 正確な災害予知・人の真の能力 欲しいと思ってから入手しようとし てもできない 去年開催していたキャンペーンのクリッ クログを今からとる 入手はできるが欲しい時に間に合わ ない 観測所を建てる（明日の天気予報には使 えない） 入手しているが処理が追いつかない 100個のExcelファイルにフォーマット がばらばらで格納されている 入手しているが組織やマネジメント が要因で使えない エンジニアのリソース不足で手が回らず 他に扱える人がいない
16. • 欲しいと思ってから動くのではデータの入手が間に合 わないならば事前にやろう、となるのが自然な発想 • データ基盤を構築してデータを集約し、保管する • 無ければデータを生成することも試みる – クリックイベント – アンケート – 観測所を立てる 間に合わないなら事前に集めておこう 意思決定と分析のプロセスの全体像とデータ整備
17. • データ基盤の構築は最近話題になることが多いが、考 え方は以前からある – 図書館 – 資料のファイリング • デジタル化やクラウドへの変化はあるが考え方は同じ 考え方は昔からあり、手段がかわっているだけ 意思決定と分析のプロセスの全体像とデータ整備
18. • とにかくため込んでおけばそれで十分ではない • ため込んでおくだけだと、いざ使おうとした時にいろ いろな問題が起きる 集めて終わりではない 意思決定と分析のプロセスの全体像とデータ整備
19. • データはあるのに処理が追いつかない データは取ったが使えない 意思決定と分析のプロセスの全体像とデータ整備 要因 具体例 原理的に入手することが無理 正確な災害予知・人の真の能力 欲しいと思ってから入手しようとし てもできない 去年開催していたキャンペーンのクリッ クログを今からとる 入手はできるが欲しい時に間に合わ ない 観測所を立てる（明日の天気予報には使 えない） 入手しているが処理が追いつかない 100個のExcelファイルにフォーマット がばらばらで格納されている 入手しているが組織やマネジメント が要因で使えない エンジニアのリソース不足で手が回らず 他に扱える人がいない
20. • 100個のExcelファイルを使い始める前に1つにまとめ る必要がある。形式が違うのであれば個別にしらべて 揃えなければならない • データが正しいかを確かめ、欠損や重複は無いか、あ るならどう扱うのか決めなければならない • こんなことをあらゆるデータで行っていたらいつまで 経っても仕事が終わらない 使う前にきれいにする必要がある 意思決定と分析のプロセスの全体像とデータ整備
21. • データが集約できていても使い物にならない – Excelの例はほんの一例 – 重複や欠損はあたりまえ • ちょっとした抽出でもクエリが長くなり、時間がかか る上にミスも増える • データを使いたい時にすぐ使えるようにするには、基 盤に集約してさらに整理もしておく必要がある データは集めるだけではつかえない理由 意思決定と分析のプロセスの全体像とデータ整備
22. • 本や資料を入手した順に積み上げているだけではどこ にあるかわからなくなるのでジャンル・執筆者名など で並び替えておくと取り出しやすくなる 整理も基盤の構築と同様にあたりまえの考え方 意思決定と分析のプロセスの全体像とデータ整備
23. • 整理してデータをきれいにしても使いやすくなるには まだ足りない • 技術的なスキルが不足しているので代わりに抽出する • おかしなデータが増え続けるのを放置すると対応でき なくなるので品質管理する • どこにどのようなデータが存在するのかを誰に聞けば いいのかがわからないのでメタデータを記録する 整理してもまだ足りない 意思決定と分析のプロセスの全体像とデータ整備
24. • 収集フェーズは「生成」「集約」「保管」「抽出」 「整理」「品質管理」「記録」で構成される • 「ガバナンス」「インフラ」「法務」「倫理」も収集 には必要であるが、プロセス全般に関わること • 領域が広すぎるし内容も全く違うので１まとめにして 扱うのは無理がある • どこで切り分けるのがよいだろうか 収集フェーズの構成を考える 意思決定と分析のプロセスの全体像とデータ整備
25. • 「生成」は集めるデータによって違いが大きい – ログならエンジニア – アンケートなら分析者（リサーチャー） • 「集約」はインフラも絡んで技術の要素が強い • 「保管」は同時に守るための情報セキュリティがセッ トでこれもまた非常に大きな領域 個別に考えた方がよさそうなこと 意思決定と分析のプロセスの全体像とデータ整備
26. • 「抽出」「整理」「品質管理」「記録」は内容は違う が大まかに見ると共通している点がある – 集約してから分析に使うまでの間でやること – 技術的な要素よりも対人間の要素が強い • それぞれが大きな課題であり今後は分かれるかもしれ ないが、今のところはここをまとめたほうが見通しは よさそう あと４つをひとまとめにするのはどうか 意思決定と分析のプロセスの全体像とデータ整備
27. • この４つの役割の総称を「データ整備」と呼ぶ • データ整備とは「データを使いたい誰もが使いたい時 に迅速に、かつ正確なデータが入手できるようにする こと」と言える • 軽く言うと「データを使いやすくすること」 データ整備とは 意思決定と分析のプロセスの全体像とデータ整備
28. • この３区分で使われることが現状では多い • データ整備は「データレイクに集約されてから分析の 手前まで」が担当領域、ともいえる • 表にまとめてみると以下のようになるが、厳密ではな いのであまりこだわらないほうがいい データレイク・データウェアハウス・データマート 意思決定と分析のプロセスの全体像とデータ整備 区分 用途 整理 担当 たとえ データレイク 生のデータ なし 集約 倉庫 データウェアハウス 汎用的なデータ あり 集約／整備 卸売り データマート 個別の案件 あり 整備 小売店
29. • 収集フェーズの役割を利用と保管、技術的と人的にわ けてみる。中心とは「要素が強い」ぐらいのイメージ 収集フェーズのマッピング（β版） 意思決定と分析のプロセスの全体像とデータ整備 サイバーセキュリ ティ 集約 ？ 整備 利用 保管 技術が中心 人が中心 生成
30. 目次 1. 「データ整備」を概観する 1.1. 意思決定と分析のプロセスの全体像とデータ整備 1.2. データ整備の役割とタスク 1.3. データ整備の現状を眺めてみる 2. データ整備との付き合い方を考える 2.1. データ整備の捉え方 2.2. データ整備の進め方 2.3. データ整備を担う際に気を付けてほしいこと 2.4. データ整備をしないとどうなるのかを説明する
31. • データを使いやすくするのに必要な４つの役割 – 抽出　　　・・・　分析のためのデータを提供する – 整理　　　・・・　データをきれいにする – 品質管理　・・・　データとデータの流れを管理する – 記録　　　・・・　メタデータを管理する • 個々の役割についてもう少し詳しく触れてみる データ整備の役割 データ整備の役割とタスク
32. • 依頼者（主にビジネスサイド）が正しい分析を行うた めに必要なデータを適切な時期に適切な形で提供する • 「依頼されたデータを出す」ではなく「分析に本当に 必要なデータを利用者に届ける」ことまで含まれるべ き • 依頼の内容が不適切であったり、過不足があれば打ち 合わせで埋める データ整備の役割（１）抽出 データ整備の役割とタスク
33. • 抽出のタスク – 依頼の管理、ルール作り – 打ち合わせ – インプットの入手 – 主にSQLを利用してデータを作成 – アウトプットの提供（CSV・ダッシュボード） – インプットの入手を効率化するための業務フローや仕組み の改善 データ整備の役割（１）抽出：タスク データ整備の役割とタスク
34. • 迅速かつ正確な抽出ができるように事前にデータをき れいにしておく • 分析に十分に有用かどうかが基準。完璧にきれいかや 技術的に優れているかは重要だが優先度は低い データ整備の役割（２）整理 データ整備の役割とタスク
35. • 整理のタスク – 重複や欠損を無くす – よく使う指標の作成 – 共通IDの作成 – データ型やタイムゾーンの統一 – テーブルを適切に切り分ける – マスタのクレンジング – 個人情報の隔離 データ整備の役割（２）整理：タスク データ整備の役割とタスク
36. • 不良データを出さない、つくらない、入れないように する仕組みを作る • すでにあるデータだけでなく、これから作られるデー タにも注意を払う • 政府CIOポータル「データ品質管理ガイドブック」 https://cio.go.jp/sites/default/files/uploads/doc uments/data_hinshitu_guide_beta.pdf データ整備の役割（３）品質管理 データ整備の役割とタスク
37. • 品質管理のタスク – 提供するデータ品質の担保 – データの扱い方の方針の決定 – データの定義の決定 – データの評価（間違い、極端な過不足、デマ） – モニタリング – 生成・集約への修正依頼 データ整備の役割（３）品質管理：タスク データ整備の役割とタスク
38. • メタデータを組織として残すための仕組みを作る • 特定の個人の活動ではなく組織全体の活動に広げられ るかが鍵 データ整備の役割（４）記録 データ整備の役割とタスク
39. • 記録のタスク – メタデータを書く – メタデータとして残す項目やレベルの決 – メタデータを書いてもらうためのルールや仕組み作り データ整備の役割（４）記録：タスク データ整備の役割とタスク
40. 目次 1. 「データ整備」を概観する 1.1. 意思決定と分析のプロセスの全体像とデータ整備 1.2. データ整備の役割とタスク 1.3. データ整備の現状を眺めてみる 2. データ整備との付き合い方を考える 2.1. データ整備の捉え方 2.2. データ整備の進め方 2.3. データ整備を担う際に気を付けてほしいこと 2.4. データ整備をしないとどうなるのかを説明する
41. • データ分析が広まったのがこの10年ぐらい • まずデータを「使いたい」が最初にあり、「使うため には集めなければならない」になってきた • データ基盤の構築が最近のトレンド • 先行しているところは「集めたけれどもそのままだと 使えない」が浸透し始めている模様 整備の必要性はまだ広まっていない データ整備の現状を眺めてみる
42. • データを使うなら整備は必須だが、整備を別の役割と して打ち出している企業は少ない • 別の職名で実質的に整備が求められるということはま まある • 整備を分けて考えていない理由 – 分ける発想がうまれていなかった – 規模が小さいのでまだわからない – 実は分ける必要無いかもしれない データ整備が１つの役割として認識されていない データ整備の現状を眺めてみる
43. • 整備は集約と分析の間にあるため「あればなお良い」 ではなく「誰かがやらなければならない」のに誰が何 をするのかが不明瞭 • エンジニア、分析者双方にとっては領域外なところも ありやりたがる人は少ない データ整備が宙ぶらりんになっている データ整備の現状を眺めてみる
44. • 本来の役割とは内容も求められるスキルも違うのにな んとなく回ってくる • 以下のそれぞれの場合でそれぞれの問題がおきる – エンジニアが整備もしている – 分析者が整備もしている – マネージャーやマーケターなどが整備している • データはあるが利用に耐えうる整備はしていない場合 もある それでも誰かがデータ整備をしている（はず） データ整備の現状を眺めてみる
45. • データを扱うスキルを持つ人が他に誰もいないとデー タ分析に関わっていなくても回ってくる • 分析する人の話を聞かずに先に作って「せっかく作っ たのに使われない」が起きる • 整備は技術よりも段取りとコミュニケーションの比重 が高く、ビジネスサイドと直接やり取りをする必要が あるが関係がまずくなることも エンジニアが整備をすると起きる問題 データ整備の現状を眺めてみる
46. • 分析しようにも整備しないと使い物にならないので自 分で整備もせざるを得ない • ある程度体制が出来た後から入ってくることが多く、 既存システムに振り回される上に発言力が低くエンジ ニアとビジネスサイドの板挟みになりがち • 何でも屋になって気づいたら整備ばかりで分析をまっ たくしなくなったりする 分析者が整備をすると起きる問題 データ整備の現状を眺めてみる
47. • マネージャーやマーケターがデータを使いたいと思っ ても他に誰も整備をやる人がいないと手を出すことに • 畑違いの分野なのでスキル不足で効率がひどく悪い • ちょっとしたことにも半日かかったりするがもっと簡 単にできる方法があることに気づくことができない • 本来の仕事に使える時間が削られる それ以外の人が整備をすると起きる問題 データ整備の現状を眺めてみる
48. • データは気にしなくてもいろいろと集まる（ログ・レ ポートなど）ので、集められて扱える状態にはなって いるが利用に耐えうる整備は行われていない • ただそこにあるデータなので何かの目的に合致してい るわけでもない（偶然使えることはある） • 使うために整備を始めるまでに多大なコミュニケー ションコストが発生して挫折してしまう 誰も整備をしていない データ整備の現状を眺めてみる
49. • 目立たない、なので評価にも繋がりにくいため押し付 け合いになり政治力で誰が何をするか決まる • とりあえず若手や初心者に担当させてパフォーマンス があがらない。人の入れ替わりも多く発展しない • 外注に丸投げしてノウハウが溜まらない 役割が不明瞭なためにおきるさらなる問題 データ整備の現状を眺めてみる
50. • 日本人は「情報」と「兵站」が苦手らしい、はおそら く多くの人と合意できる • データの「収集」とは情報（インテリジェンス）のた めの兵站（ロジスティクス） • 集約やインフラはそのうち「物流」で比較的わかりや すいため注目される（例：宅急便）が整備は荷物の中 身についての話 データ整備がいまいち流行らない原因 データ整備の現状を眺めてみる
51. 目次 1. 「データ整備」を概観する 1.1. 意思決定と分析のプロセスの全体像とデータ整備 1.2. データ整備の役割とタスク 1.3. データ整備の現状を眺めてみる 2. データ整備との付き合い方を考える 2.1. データ整備の捉え方 2.2. データ整備の進め方 2.3. データ整備を担う際に気を付けてほしいこと 2.4. データ整備をしないとどうなるのかを説明する
52. 目次 1. 「データ整備」を概観する 1.1. 意思決定と分析のプロセスの全体像とデータ整備 1.2. データ整備の役割とタスク 1.3. データ整備の現状を眺めてみる 2. データ整備との付き合い方を考える 2.1. データ整備の捉え方 2.2. データ整備の進め方 2.3. データ整備を担う際に気を付けてほしいこと 2.4. データ整備をしないとどうなるのかを説明する
53. • 役割も求められるスキルも違い、片手間でできる分量 でもないので既存の役割とは別と認識したほうがいい • エンジニア・データアナリストやデータサイエンティ スト・マーケターなどと同列に扱う • 「明確に区別はできないが別の役割であり、状況に よっては兼任することはありえる」ぐらいがよさそう データ整備を別の役割として認識する データ整備の捉え方
54. • 担当者やデータ関連職種以外の人に認識してもらうた めにも組織としての職名があったほうが望ましい • 「本職のついでにやる」からいつまでたっても抜け出 せないのでは • エンジニアや分析者としての評価をされても別の仕事 をしているので職名が無いと評価されづらいリスク 整備の職名があったほうが望ましい データ整備の捉え方
55. • 同じ名称でも違う内容、違う名称でも同じ内容を指し ていることがあるため言葉の定義に注意 – データアーキテクト（データ整備人） – データスチュワード／BIエンジニア – アナリティクスエンジニア – データエンジニア／データサイエンティスト／データアナ リストとあるが一部ないしは大半が整備 データ整備に携わる人の職名 データ整備の捉え方
56. • データ整備はDMBOKで言うと以下のあたり – ドキュメントとコンテンツ管理 – 参照データとマスターデータ – データウェアハウジングとビジネスインテリジェンス – メタデータ – データ品質 • 上記に加えてアドホックな「抽出」 データ整備はデータマネジメントの一部 データ整備の捉え方
57. 目次 1. 「データ整備」を概観する 1.1. 意思決定と分析のプロセスの全体像とデータ整備 1.2. データ整備の役割とタスク 1.3. データ整備の現状を眺めてみる 2. データ整備との付き合い方を考える 2.1. データ整備の捉え方 2.2. データ整備の進め方 2.3. データ整備を担う際に気を付けてほしいこと 2.4. データ整備をしないとどうなるのかを説明する
58. • 重要度で区別は付けられないが優先度が高いのは抽出 と整理 • 組織が小さいうちは品質管理と記録は必要最低限に留 めてリソースを抽出と整理に回すほうがいい – 重要な指標に関すること – 全体への影響が大きい箇所 – メタデータはメモ程度 データ整備のうちどれが重要か データ整備の進め方
59. • SQL（＋Excel・プログラミング） • コミュニケーション能力 – 依頼されたことをそのまま実現するのではない – あるべきデータの提示、改善の要求、理不尽なら押し返す • 改善しようとする気持ちと実行力 – 整備そのものが「より使いやすく」する仕事 – 気持ちだけでなくいざとなったら自分でやる力 データ整備の３大スキル（2021年版） データ整備の進め方
60. • 後工程になる分析で何をするか理解しやすいので分析 経験者がパフォーマンスを出しやすいと思われる • 技術面はエンジニアが圧倒的に強みを持つ。あとは分 析スキルがあるとなお良いのでは • 集約と分析の間であり、調整や橋渡しも行うので最初 から整備はおすすめしない データ整備はだれがやるのがいいのか データ整備の進め方
61. • 必ず「何が知りたいのか」から始める • 最初は重要指標に絞る • そのためにどのようなデータが必要なのかを考えれば 次の行動は決まる • できれば個人情報の隔離もしておく • どのツールを入れるかは最後。手元にあるか簡単に無 料で入手できるツールをまずは使う 何から整備したらいいのか データ整備の進め方
62. • 前後も含めて考えると優先度は分析→集約→整備 • ただし集約・整備・分析のどこかが大きく崩れると全 部だめになる – 分析に使われなければ集約も整備も無駄 – 集約されていないと使いたい時に使えない – 整備されていないと使いものにならない • 整備以外にも気を配る 集約や分析とのバランスも考える データ整備の進め方
63. • データ整備が貢献できなくなる要因の代表例 – 目的不在で整備だけする – 整備担当者の発言力が低くその他雑用扱いになる – 受け身すぎる（依頼通りに抽出する／業務フローを改善し ない） – 高価なツールをいきなり入れる – リーダーシップ不在 – 最初からＤＭＢＯＫ データ整備のアンチパターン データ整備の進め方
64. • 意識はしておかないといけないことの例 – ガバナンス・・ルールを守らせる – 法務・・・・・個人情報 – 倫理・・・・・エコーチェンバー • 集約や分析と含めて周辺領域と明確な区別はできない ので状況に応じて埋めることも必要。でも１人で全部 はできないのでみんなでうまく分担する データ整備以外にも意識しておきたいこと データ整備の進め方
65. 目次 1. 「データ整備」を概観する 1.1. 意思決定と分析のプロセスの全体像とデータ整備 1.2. データ整備の役割とタスク 1.3. データ整備の現状を眺めてみる 2. データ整備との付き合い方を考える 2.1. データ整備の捉え方 2.2. データ整備の進め方 2.3. データ整備を担う際に気を付けてほしいこと 2.4. データ整備をしないとどうなるのかを説明する
66. • 組織でプロセスの全領域をカバーすることになるが、 収集だけでもかなり広い領域 • 細かく分担を考えるほどの組織になっている場合はま だまだ少ない。人がそれなりにいても整備を切り分け ている企業は皆無 • つまり、データに関わるならば整備の役割の一部を担 うことになる可能性が高い 整備をまったくしないで済む場合はあまりない データ整備を担う際に気を付けてほしいこと
67. • 分析のためのデータであることを意識してほしい – 何かを作る前に分析する人の意見を先に聞く – 希望をそのまま実現しようとしない。怪しいと思ったら何 を知りたいのか聞いてみる – 完璧に整理できるかや技術的に正しいかよりも分析に有用 かを優先する エンジニアが整備もするなら データ整備を担う際に気を付けてほしいこと
68. • 整備に時間を取られて分析が出来なくならないように してほしい – 何でも屋にならないように気を付ける – 整備の範疇を超えた不適切な依頼（インプットの整形、レ ポート作成、内容不明瞭な依頼）は押し返す – 生成や集約の問題を全部整備で吸収しない 分析担当者が整備もするなら データ整備を担う際に気を付けてほしいこと
69. • 本当に必要最低限なことだけに絞ってほしい – 重要な指標を抽出するのに必要な整理だけにする – 無理はせずに早く人を探す（特に経営層やマネージャー） – あれこれ出来る人が望ましいがSQLが書けるアルバイトが いるだけでも違う マネージャーやマーケターが整備もするなら データ整備を担う際に気を付けてほしいこと
70. 目次 1. 「データ整備」を概観する 1.1. 意思決定と分析のプロセスの全体像とデータ整備 1.2. データ整備の役割とタスク 1.3. データ整備の現状を眺めてみる 2. データ整備との付き合い方を考える 2.1. データ整備の捉え方 2.2. データ整備の進め方 2.3. データ整備を担う際に気を付けてほしいこと 2.4. データ整備をしないとどうなるのかを説明する
71. • データを使ったことがある人は感覚的に理解している と思われるが特にそれ以外の人（特に経営・マネジメ ント層）にはどう伝えるのがいいか • データで伝わりづらかったら料理に例えてみる データ整備をしないとデータはまともに使えない データ整備をしないとどうなるのかを説明する
72. • 料理をしようと思ったらそれぞれの生産者のところへ 買いに行き、購入した食材を自分でさばいて使う。加 工品も全部自分で作る 料理をするのに全部自分で食材を用意するとしたら 種類 場所 やること 加工食品 肉 牧場 解体・きりわけ ベーコン 魚 港 さばく 干物 米や野菜 農家 脱穀 もち・豆腐 データ整備をしないとどうなるのかを説明する
73. • もしも「物流」や「中間加工」がなく料理を作るのに 全部自分でやらなければならないとしたら大変なこと になる • データ整備をしないデータ分析は「物流」や「中間加 工」の無い料理と同じようなもの • 整備をしないデータはまともに使うことはできない • データは食材と違って物理的な障害が無いので伝わり づらいかも データ整備をしないデータ分析とは データ整備をしないとどうなるのかを説明する
74. まとめ
75. • 整備をしないとデータがまともに使えない • 整備は別の役割として認識して分担を考えよう • プロセス全体の中での整備なのでバランスを考えよう 整備の実務について（＋その他いろいろ）ブログに書いています データ分析とインテリジェンス：https://analytics-and-intelligence.net 質問・疑問などお気軽にご連絡ください Twitter：@data_analyst_ データ整備はまだ始まったばかり まとめ