実に奥が深い、データクレンジング：データ移行の入口で行うべきこと
ERP導入において、データクレンジングは軽く見られがちなテーマです。
現行システムからデータを抽出し、形式を整え、移行先のERPに投入する。このように捉えると、データクレンジングは移行作業の一部として、技術的な前処理に見えるかもしれません。
しかし、現行データには長年の業務運用が蓄積されています。部門ごとの分類、過去の例外対応、旧システムの制約、帳票や集計のために作られた区分、Excelで補ってきた分類や集計、担当者だけが知っている意味付け。これらは、現行業務を支えるために積み重ねられてきたものです。
ERP導入では、そのデータを新しい業務に合わせて見直します。
何をまとめるのか
何をそろえるのか
何を直すのか
何を持ち込まないのか
以前の記事では、ビジネスデータ・リエンジニアリングとして、To-Be業務に合わせたデータのあり方を考えました。今回は、その考え方をデータ移行の入口でどう実務に落とし込むのか、つまりETLCにおけるExtractの中で行うデータクレンジングに焦点を当てます。
新しい家に持っていくものを選ぶ
データクレンジングは、引っ越しの準備に似ています。
住み慣れた家には、長年使ってきた家具があります。途中で増やした収納棚もあります。今は使っていない家電もあります。どこに何があるかは、家族の暮らしを下支えしてきた人だけが分かっています。他人から見ると不要に見えるものでも、本人にとっては簡単に手放せないものがあります。
引っ越しで難しいのは、荷物の数を減らすことだけではありません。
新しい家の間取り、収納、動線に合わせて、持っていくものを選び直すことです。今の家で役に立っていたものが、新しい家でも同じように役立つとは限りません。反対に、今は使っていないように見えるものでも、新しい暮らしで必要になることもあります。
ERP導入で扱うデータも同じです。
現行業務を支えてきたデータを、新しい業務の前提に合わせて見直します。同じ意味を持つ取引先コードや品目コードは統合するのか、管理上分けて残すのか。分類や単位はそろえるのか。誤った情報はどこで整えるのか。過去データはERPに持ち込むのか、参照用に残すのか。こうした判断を通じて、ERPで使うデータを選び、Extract対象として整えていきます。
この考え方が、データクレンジングの出発点になります。
構想策定で決めるのは、クレンジングの対処方針である
構想策定段階では、ERP選定後に行うデータクレンジングを見据えて、論点を整理しておく必要があります。
この段階では、まだERPパッケージが決まっていないので、項目名、桁数、移行ツール、詳細なチェックロジックは具体化できません。構想策定で行うのは、To-Beビジネスデータモデルと現行データの差分を明らかにし、どう対処するかを決めることです。
例えば、To-Beでは品目を全社共通で管理したい。一方、現行では販売管理と生産管理で別々の品目コードを使っている。この場合、構想策定では、ERP導入時に品目コードの統合が必要になることを明らかにし、どのような方針で統合するかを整理します。
また、To-Beでは品目分類を全社でそろえたい。一方、現行では販売管理、生産管理、購買管理で異なる分類を使っている。この場合は、ERPでどの分類体系に統一するのかが論点になります。
さらに、現行データに重複、不整合、更新漏れがある場合は、どれを修正対象とするかを見極めます。既存システム側で先に整えるべきものもあれば、ERP選定後の移行準備で補正するものもあります。
過去データの扱いも、この段階で方針を持っておきたい論点です。休眠顧客、廃番品、完結済みの過去取引履歴などは、ERPで日々管理するのか、旧システムやアーカイブで参照できればよいのかを考えます。
このように、構想策定段階のクレンジングでは、差分を四つの観点で整理します。
統合：同じ意味のデータをまとめる必要があるもの
統一：分類やコード体系をそろえる必要があるもの
修正：重複や不整合を直す必要があるもの
除外：ERPに持ち込まない判断が必要なもの
構想策定でクレンジングの対処方針を決めておくことで、導入フェーズでのデータ移行は進めやすくなります。統合・統一・修正の方針は複雑性を抑え、除外の方針はデータボリュームを減らします。結果として、データ移行の難易度を下げることにつながります。
どこまでがクレンジングで、どこからがTransformなのか
ERP導入でデータ移行の準備を進めると、あるデータをクレンジングで対処するのか、Transformで変換するのかで迷う場面があります。
判断の起点は、その作業が業務上の扱いを決めるものか、それともERPに取り込むための形式変換かです。
同じ顧客が複数コードで登録されている場合、どのコードを統合対象にし、どのコードを残し、どのコードをExtract対象外にするのかを整理します。これは、顧客を業務上どの単位で管理するかの判断です。
品目マスタでも、システムごとに分かれた品目コードを統合するのか、業務上の意味が異なるものとして残すのかを確認します。これも、品目をどの単位で扱うかの判断です。
これらはクレンジングで扱います。
一方、Extract対象として確定したデータについて、旧システムの取引先コードをERPの桁数に合わせる、日付形式を変える、旧システムの区分値をERPのコード値に読み替える、移行ファイルのレイアウトに合わせる、といった処理はTransformで扱います。
つまり、業務上の意味、必要性、正しさに関わるものはクレンジング。ERPに取り込むための形式、桁数、コード値、ファイル形式に関わるものはTransformと考えると整理しやすくなります。
この線引きが曖昧になると、顧客統合や品目統合のような業務判断を移行ツールの変換処理に押し込んでしまいます。逆に、日付形式や桁数のような技術的な変換を、業務部門の判断事項として扱ってしまうことになります。
ERP導入では、クレンジング対象とTransform対象を分けて一覧化しておくと、業務部門、IT部門、ベンダーの役割が明確になります。業務部門はデータの意味と必要性を判断し、ITやベンダーは変換ルール、移行ファイル、ロード方法、チェック方法を設計します。
「必要です」をどう扱うか
データクレンジングで除外を判断するとき、必ず出てくる言葉があります。
「このデータは必要です。」
営業は売上実績を確認したい。購買は仕入価格の推移を見たい。品質保証は過去ロットを追いたい。経理は過去明細を参照したい。製造は過去の生産実績を確認したい。どれも業務上は理解できる要望ですが、「必要です」という言葉をそのままExtract対象にしてしまうと、多くのデータがERPに持ち込まれます。
ここで確認したいのは、そのデータをどのように使うのかです。本稼働後も更新するデータであれば、ERPで管理する必要があります。受注残、発注残、在庫、売掛金、買掛金のように、業務継続に直結するデータはExtract対象になります。
一方で、過去を確認するためのデータは扱い方を分けて考えます。完結済みの取引履歴、過去単価、過去のマスタ設定などをERPへ直接取り込もうとすると、取引当時の取引先、品目、価格条件、保管場所などのマスタ状態まで考慮する必要があり、作業の難易度が一気に高くなります。参照目的であれば、ERPではなく旧システムの参照環境やBIで確認できる形が現実的です。
「必要です」の背景には、不安が含まれることもあります。
新しいERPになったとき、今まで見られていた情報が見られなくなるのではないか。過去の問い合わせに答えられなくなるのではないか。現場で困ったときに確認する手段がなくなるのではないか。
この不安に対して、単に移行対象かどうかを議論しても前に進みません。大切なのは、確認手段を具体的に示すことです。誰が、どの画面で、どの期間のデータを、どの目的で確認できるのか。ここが明らかになると、「ERPに持ち込むデータ」と「別の場所で参照できればよいデータ」を分けやすくなります。
除外とは、データを消すという意味だけではありません。ERPで管理するデータと、別の方法で残すデータを見極める判断でもあります。
全データを持ち込んで安心を作るのではなく、必要なデータを必要な場所で確認できる状態にする。これが、「必要です」という要望に向き合うときの大切な考え方です。
まとめ
新しい業務を想定し、その業務に必要なデータを選び、整え、正しい状態でExtract対象にする。これが、データクレンジングの本質です。
データクレンジングは、ETLCにおけるExtractの中で行う重要な活動です。
その過程では、「このデータは何を正とするのか」という問いも繰り返されます。この論点は、ERP稼働後にどのデータをどこで正本として管理するのかというSoT（Single Source of Truth）のテーマにつながります。SoTについては、別の記事で改めて整理します。
すべてを持ち込めば安心に感じます。
ただ、使わないデータまでERPに持ち込むと、過去のコード体系や例外運用まで引き継ぐことになります。新しい業務を始めるはずのERPの中に、古い業務の複雑さが残ってしまいます。
必要なデータを、必要な場所に、必要な形で残す。この判断があるからこそ、データクレンジングは実に奥が深いのです。
