データ整備とは何か

「データ整備」の定義

「データ整備」とは、データが集約されてから、分析に用いられるまでのプロセスにおいて行われる、以下の4つの仕事の総称を指す。

  • 抽出
  • 整理
  • 品質管理
  • 記録

なぜこの4つでまとめて1つの枠組みにしたかについては個々の仕事の説明の後に述べる。

データ整備の4つの仕事の概要

データ整備の仕事1:抽出

分析に必要なデータを取り出す仕事である。必要なデータが不足している場合には、以下のような関連作業も含まれる。

  • データを整理する(内容は後述)
  • アクセス権限申請
  • 外部データ入手の手続きや設定
  • データの獲得・生成・集約
  • 上記作業を担当者に依頼

抽出担当者が分析者とは別の場合、抽出の仕事は要求に基づいており、迅速かつ正確なデータを提供することが求められる。

要求が必ずしも正確・適切とは限らないので、より適切な内容を抽出担当者から提案したり、分析にそぐわない内容を削ることを提案したりすることもある。さらに、優先順位やデータの状況に応じて「いつまでに何をやるか」をすり合わせるコミュニケーションも必要になる。

抽出の際に集計という"分析"の最初の段階が入ることがあって混同されがちだが、分析の手前の話である。ダッシュボードの作成は、基本的には「抽出」のアウトプットの1つの形だと考えていい。

データ整備の仕事2:整理

その名の通り生のデータを整形する仕事のことである。代表的な内容は以下の通り。

  • 重複の削除
  • 欠損値の補完
  • 分類項目の新設(例:年代、地域)
  • 異なるデータソースの統合
  • データ型の統一
  • UnixTimeの変換
  • 不適切な値の修正

ここでいう「不適切な値の修正」とは、エラーにはならないので動くがそのままだと不都合が起きるので整理しておくと良いこと全般を指している。詳しくは整理の仕事についてまとめる。

年齢を例にあげると、マイナスが含まれている際にNULL化や-1への変換などを行う。

整理をやり過ぎると手間とコストに対して見返りは少ないので塩梅が難しい。DWHやデータマートは整理した結果の1つの形式なので、名前にこだわる必要はない。

データ整備の仕事3:品質管理

求めるデータの品質のレベルを決め、そのレベルが保たれているかを監視する仕事である。チェックに引っかかったら直すのは「整理」の役割となる。

使いやすさには絶対的な指標は存在せず、利用者の要件に応じた基準設定が求められる。

個別に監視するのは無理なのでツールでまとめて行いたいところだが、まだ一部のことしかできてないようだ。あらゆる項目を望むレベルで自動的にチェックできる仕組みができるようになるまでは人力で目検チェックはなくならないだろう。

データ整備の仕事4:記録

メタデータを残すこと。メタデータとは「データについてのデータ」。あるカラムがあったとして

  • 定義
  • どのような値が入るのが正しい状態か
  • いつできたか
  • いつ更新されるか
  • 出所
  • 誰が作り、問題が起きたら誰に聞くか
  • 他のテーブルとの関連性
  • 使っていけない期間
  • 何のために作ったか

などなど、項目を書き出すときりがない。そのため記録の仕事もやろうと思えばいくらでも時間を使えてしまうが、どこまで記録したら十分なのかを客観的に評価する術がないのが悩ましい。

また、有志による一時的な活動に留まってしまうことを避けるため、個人ではなく組織として記録しメタデータを残すための仕組みを考えるところまでを含めた仕事としてとらえておきたい。

この4つの仕事で「データ整備」という枠組みにした理由

あえて「データ整備」という新しい枠組みを設けた理由は以下のとおりである。

  • 実務上の流れに即した分類が必要だったため
  • 「データエンジニアリング」という言葉では領域が広すぎるため
  • 「データマネジメント」は現場業務の実態にそぐわなかったため

実務上の流れと関連性に即した分類が必要だったため

抽出と整理は別の仕事の枠組みに入れてもいいかもしれない。

しかし、実務では、分析する人が自分で抽出する場合でも整理をまったくしないことはまれだ。また、抽出する人が整理も担うことが多い。こうした実務上のつながりを無視できないと考えている。

また、この枠組みの中に入れないと「インテリジェンス」の仕事が実質的に存在していないので「抽出」という仕事だけが浮いてしまう。特に整理との関連を強調するためにも抽出と整理を同じ枠組みの中に入れるのが良いと考えた。

「データエンジニアリング」という言葉では領域が広すぎるため

抽出・整理より前の獲得・生成・集約などまで全部含めて「データエンジニアリング」と呼ぶ場合もあるが、これだと1つの仕事を示す言葉としては範囲が広すぎる。

なので、何かを作るエンジニアリングと使いやすくするための調整といったコミュニケーションで分けるというのが良いと考えた。もちろん完全に切り離せはしないが、ひとまとめにするよりかはいいだろう。

「データマネジメント」は現場業務の実態にそぐわなかったため

「データマネジメント」も広すぎる上に「管理」が中心で利用することが中心ではない。そのため大企業であればともかく、大半の企業においてこの枠組みをそのまま適用するのは難しい。

なのでデータの利用にあたり、実務上でよく使う部分に焦点を当てた枠組みが別に必要だと思った。

「データ整備」は「大体集約と分析の間の仕事」

「データ整備」という枠組みがまったくないと、データエンジニアリングやデータマネジメントといったあまりにも広い領域を指す言葉を使うしかない。

一方で、範囲が広すぎるからと狭めようとすると今度はダッシュボード、データ抽出、データマートなどといった個別の内容で話すことになる。これだと関連性がわからず、それぞれのことだけを考えてしまいがちになる。

そこで、中間の領域である「集約と分析の間の仕事」という代わりに「データ整備」という枠組みを提案したい。