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