「古いデータ」をどこまで引き継ぐか？移行要件で決めるべき「断捨離」の基準

システムを刷新する際、IT担当者や現場リーダーが最も頭を悩ませるのが「古いシステムにある膨大なデータをどうするか」という問題です。現場からは「これまでのデータはすべて見られるようにしてほしい」という要望が必ず出ますが、その言葉を鵜呑みにして要件に盛り込むと、プロジェクトの予算とスケジュールは瞬く間に食いつぶされます。

データ移行は、単なるコピペではありません。新旧システムの構造の違いを埋めるための、極めて高度でコストのかかる作業なのです。

1. データ移行のコストは「質 × 量」で決まる

ベンダーに見積もりを依頼すると、「データ移行支援」という項目で数百万円が計上されることがあります。これは主に「データの変換プログラム作成」や「流し込み作業」の費用です。しかし、その前段階にある 「データの整理（クレンジング）」 は、原則として発注側の仕事になります。

重複データの統合: 「株式会社〇〇」と「（株）〇〇」を名寄せする。
欠損値の補完: 必須項目になったのに、旧システムでは空欄だったデータを埋める。
コード変換: 旧システムの「商品コード」を新システムの体系に書き換える。

移行するデータの「量」が多ければ多いほど、この「質」を整えるための社内工数は膨れ上がります。

2. 移行要件における「断捨離」の 3つの基準

移行コストを抑え、プロジェクトを成功させるためには、要件定義の段階で以下の基準に基づいた「断捨離」を、現場リーダーと合意しておく必要があります。

① 期間で切る（例：直近 2年分だけ）

過去 10年分のデータをすべて移行する必要は本当にありますか？「めったに見ない過去のデータは、旧システムを閲覧専用として残すか、エクセルに書き出して保存しておく」という判断をするだけで、移行対象を 8割削れるケースも少なくありません。

② 状態で切る（例：完了した案件は移さない）

既に取引が終了した顧客や、 5年以上動いていない休眠顧客のデータは、新システムに持ち込まない方が賢明です。新システムを「最新の動いている業務」に集中させることで、検索スピードや使い勝手も向上します。

③ 項目で切る（例：備考欄のメモは捨て、基本属性だけ移す）

旧システムのフリー入力欄（備考欄）には、非構造化されたノイズの多いデータが溜まっています。これを新システムの適切な項目に振り分ける作業は地獄です。「重要な項目（名前、住所、残高など）に絞って移行する」という割り切りが必要です。

3. 「移行しないリスク」をどう説明するか

現場の反発を抑えるためには、「移行しない」ことのメリットを強調してください。「古いゴミデータを持ち込まないことで、新システムがサクサク動くようになります」「移行費用を削る分、欲しかったあの機能に予算を回せます」といった、現場にとっての直接的な利益を提示することが、合意形成の鍵となります。

データ移行の要件定義は、 IT化における 「最大の断捨離」 です。 IT担当者として、ベンダーと現場の板挟みになるのは辛いところですが、ここで勇気を持って「捨てる要件」を固めることが、リリース初日の現場の笑顔に繋がります。