データ整備を構成する4つの仕事の選定理由
この4つの仕事で「データ整備」という枠組みにした理由
あえて「データ整備」という新しい枠組みを設けた理由は以下のとおりである。
-
実務上の流れに即した分類が必要だったため
-
「データエンジニアリング」という言葉では領域が広すぎるため
-
「データマネジメント」は現場業務の実態にそぐわなかったため
実務上の流れと関連性に即した分類が必要だったため
抽出と整理は別の仕事の枠組みに入れてもいいかもしれない。
しかし、実務では、分析する人が自分で抽出する場合でも整理をまったくしないことはまれだ。また、抽出する人が整理も担うことが多い。こうした実務上のつながりを無視できないと考えている。
また、この枠組みの中に入れないと「インテリジェンス」の仕事が実質的に存在していないので「抽出」という仕事だけが浮いてしまう。特に整理との関連を強調するためにも抽出と整理を同じ枠組みの中に入れるのが良いと考えた。
「データエンジニアリング」という言葉では領域が広すぎるため
抽出・整理より前の獲得・生成・集約などまで全部含めて「データエンジニアリング」と呼ぶ場合もあるが、これだと1つの仕事を示す言葉としては範囲が広すぎる。
なので、何かを作るエンジニアリングと使いやすくするための調整といったコミュニケーションで分けるというのが良いと考えた。もちろん完全に切り離せはしないが、ひとまとめにするよりかはいいだろう。
「データマネジメント」は現場業務の実態にそぐわなかったため
「データマネジメント」も広すぎる上に「管理」が中心で利用することが中心ではない。そのため大企業であればともかく、大半の企業においてこの枠組みをそのまま適用するのは難しい。
なのでデータの利用にあたり、実務上でよく使う部分に焦点を当てた枠組みが別に必要だと思った。
「データ整備」は「大体集約と分析の間の仕事」
「データ整備」という枠組みがまったくないと、データエンジニアリングやデータマネジメントといったあまりにも広い領域を指す言葉を使うしかない。
一方で、範囲が広すぎるからと狭めようとすると今度はダッシュボード、データ抽出、データマートなどといった個別の内容で話すことになる。これだと関連性がわからず、それぞれのことだけを考えてしまいがちになる。
そこで、中間の領域である「集約と分析の間の仕事」という代わりに「データ整備」という枠組みを提案したい。