基幹システム刷新プロジェクトが、商品マスタで止まる理由——移行時に噴出する5つの問題

なぜシステム刷新は「データ」で止まるのか

システム刷新の計画において、機能要件は精緻に検討されます。どの業務をどう実現するか、画面はどうするか、既存システムとどう連携するか。ここには時間もコストも十分に配分されます。

一方でデータ移行は、計画書の上では「既存の商品マスタを新システムへ移行する」という一行で済んでしまうことがあります。移行するデータの中身は、その時点では誰も全量を見ていないからです。

しかし新旧のシステムでは、商品コードの体系が違います。項目の定義も、必須項目の範囲も、桁数や文字種の制約も違います。この差分は、実際に全件を新システムの形式に流し込もうとした瞬間に、初めて全量が可視化されます。

「移行してみたら、3割がエラーで弾かれた」という事態は、担当者の見落としではなく、この構造から生まれます。データは、触ってみるまで状態がわからないのです。

移行時に噴出する商品マスタの5つの問題

移行作業で表面化する問題は、企業や業種が違っても共通しています。代表的なものが次の5つです。

1. 重複データ——同一商品が複数のコードで登録されている

同じ商品が、担当者や登録時期の違いによって別々のコードで登録されている状態です。旧システムでは「なんとなく両方生きている」まま運用できてしまいますが、新システムで商品コードを一意に扱おうとすると、どちらを正とするかの判断が全件分必要になります。

さらに厄介なのは、重複した商品それぞれに在庫や受注の履歴が紐づいているケースです。データの統合と、履歴の引き継ぎ方をセットで決めなければなりません。

2. 表記ゆれ——単位・色・素材の書き方が担当者ごとに違う

「1000ml」「1L」「1リットル」。「黒」「ブラック」「BK」。同じ内容を指しているのに、登録した担当者や時期によって書き方が異なる状態です。

人が読む分には支障がなくても、新システムで属性による検索や絞り込みを実現しようとすると、これらは別の値として扱われます。ECの商品検索やレコメンドの精度が上がらない原因が、ここに潜んでいることも少なくありません。

3. 欠損項目——新システムの必須項目が旧データに存在しない

新システムでは必須とされている項目が、旧システムには存在しない、あるいは存在しても空欄のまま運用されてきた、というケースです。

寸法や重量、素材、規格などは、旧システムでは任意項目だったために埋められてこなかったことがあります。移行にあたっては、この欠損を誰がどう埋めるのかを決めなければなりません。数千件なら手作業も検討できますが、数万件を超えると人手での補完は現実的ではなくなります。

4. 廃番・休眠データ——生きているデータと死んでいるデータの区別がつかない

長年運用してきた商品マスタには、すでに取り扱いを終えた商品のデータが大量に残っています。問題は、それが「廃番」として明示的に区別されていない場合です。

移行対象を絞り込もうとしても、どれが現役でどれが休眠中なのか、マスタを見ただけでは判断できません。結果として「念のため全件移行する」という判断になり、新システムに不要なデータを持ち込んでしまいます。

5. 項目定義の不明——「この列が何を意味するか」を知る人が退職している

移行作業でもっとも手が止まるのが、この問題です。

・旧システムの項目に、用途のわからない列が残っている。

・項目定義書はあるものの現物と一致していない。

・当時の経緯を知る担当者はすでに退職している。

こうなると、その項目を移行すべきか捨てるべきかの判断すらできません。データそのものよりも、データの意味が失われていることのほうが深刻なのです。

なお、自社のマスタがどの程度この状態にあるかは、実際に数えてみるまでわかりません。全件の精査が難しい場合でも、無作為に100件を抽出して重複・欠損・表記ゆれの有無を確認するだけで、全体の傾向はかなりの精度でつかめます。移行計画を立てる前の1日で実施できる調査です。

本当の原因は「移行」ではなく、日常の管理にある

ここまで挙げた5つの問題は、いずれも移行作業によって生まれたものではありません。日々の運用の中で少しずつ蓄積してきたものが、移行というタイミングで一度に表面化しているだけです。

新商品を急いで登録した日の判断。仕入先から届いたデータをそのまま取り込んだ経緯。担当者が交代したときに引き継がれなかったルール。そのひとつひとつは、そのときの状況では合理的な選択でした。むしろ、限られた人数と時間の中で登録を止めなかったからこそ、事業は回ってきたとも言えます。

問題は、それらの判断が積み重なったときに品質を保ち直す仕組みが、どこにもなかったことです。入力の時点で表記を統一する仕組みも、重複を検知する仕組みも、項目の意味を記録として残す仕組みもない。だから劣化が可視化されないまま蓄積し、移行という機会に一括で請求されます。

つまりこれは、担当者の管理不足ではなく、仕組みの不在によって起きる構造的な現象です。

刷新を「マスタを正す最大の好機」に変える

裏を返せば、システム刷新は商品マスタの全件に手を入れる、めったにない機会でもあります。

ここで重要なのは、クレンジングを「移行のための一度きりの作業」で終わらせないことです。移行のために全件を整えても、新システムでの日常の運用が旧システムと同じままであれば、マスタは再び同じ速度で劣化していきます。数年後の次の刷新で、同じ会議が繰り返されることになります。

移行を機に整えるべきなのは、次の3つです。

商品マスタの一元管理

どのシステム・どの部門から見ても、参照すべき商品情報が1か所に定まっている状態をつくります。「正しいデータはどこにあるのか」に全員が同じ答えを出せることが、品質を保つ前提になります。

入力時のバリデーション

表記のゆれや必須項目の欠損は、入力された後に探すより、入力される前に止めるほうが圧倒的に低コストです。単位や色の表記ルール、必須項目の充足チェックをシステム側に持たせることで、劣化の速度そのものを下げられます。

変換ルールのシステム化

仕入先ごとに異なる形式のデータを取り込む際の変換ルールを、担当者の判断ではなくシステムに定義しておきます。これにより、取り込みの時点で品質が担保され、担当者が交代してもルールが失われません。

私たちが提供しているLazuli PDPも、こうした「入口の品質」を担保するための仕組みのひとつです。サプライヤーから届く多様な形式のデータを構造化し、自動で変換・検証したうえで商品マスタに取り込むことで、移行後も品質が維持される状態をつくります。

いずれの手段を選ぶにせよ、判断のポイントは同じです。移行後の運用設計に、品質を保つ仕組みが含まれているかどうか。ここが含まれていない刷新は、きれいなデータを新しい入れ物に移し替えるだけで終わってしまいます。

まとめ——刷新プロジェクトの前に確認したい3つのこと

システム刷新を検討している段階であれば、次の3点を確認しておくことをおすすめします。

1. 商品マスタの件数と、重複・欠損の割合を把握しているか

移行の工数見積もりの精度が大きく変わります。

2. 項目定義書は、現物のデータと一致しているか

定義書の存在ではなく、現物との一致が重要です。ずれている項目は、移行時に必ず判断待ちの原因になります。

3. 移行後の品質維持ルールが、設計に含まれているか

クレンジングの計画はあっても、その後の運用ルールが設計に入っていないプロジェクトは少なくありません。

システム刷新でもっとも時間を要するのは、多くの場合、新しい機能をつくることではなく、これまでのデータを整えることです。その前提でスケジュールを引けるかどうかが、プロジェクトの成否を分けます。

==============================================================

■ よくある質問

==============================================================

Q1. 基幹システムの刷新プロジェクトで商品マスタの移行が難航するのはなぜですか？

A1. 新旧システムでコード体系・項目定義・必須項目の範囲が異なり、その差分は全件を新形式に流し込む段階で初めて可視化されるためです。重複データ、表記ゆれ、必須項目の欠損、廃番データの混在、項目定義の不明といった問題が移行時に一度に表面化し、計画段階の見積もりを超える工数が発生します。

Q2. システム移行の前に商品マスタをクレンジングする必要はありますか？

A2. 必要です。ただし全件の精査が難しい場合は、無作為に100件程度を抽出して重複・欠損・表記ゆれの有無を確認するだけでも、全体の傾向と必要な工数の目安がつかめます。移行計画を立てる前にこの調査を行うことで、見積もりの精度が大きく変わります。

Q3. データ移行を機に商品マスタ管理を改善するにはどうすればいいですか？

A3. クレンジングを移行のための一度きりの作業で終わらせず、移行後も品質が維持される仕組みまで設計に含めることです。具体的には、参照先が1か所に定まる商品マスタの一元管理、表記ゆれや欠損を入力時に止めるバリデーション、仕入先データの変換ルールのシステム化の3つが基本になります。