「商品コードや顧客区分が部門ごとにバラバラ」——マスタデータの分類設計でトラブルを防ぐ考え方

「営業はT-001、製造は001-T、物流はPRT001——同じ部品なのに社内で3種類のコードが存在する」。こうした状況は決して珍しくありません。コード体系の不統一は、データ連携の複雑化・集計の誤り・システム間の不整合を生み出し続けます。本記事では、マスタデータのコードがバラバラになる根本原因と、長期的に維持できる設計で実務上重視したい3点を整理します。

なぜコード体系はバラバラになるのか

コード体系の不統一は、組織が成長する過程で自然に発生します。原因は大きく3つに整理できます。

第一の原因は「部門ごとの独自設計」です。CRMは営業部門が導入し、ERPは製造部門が主導した——このように部門単位でシステムを導入すると、それぞれで独自のコード体系が生まれます。後から連携しようとしても、体系が違うため変換テーブルが必要になり、そのテーブルのメンテナンスが新たな問題を生みます。

第二は「システム移行時の変換ルールなし」です。旧システムから新システムへのデータ移行時に、コード体系の変換ルールを定義せずに移行した結果、両方の体系が並存したままになるケースです。「移行は完了した」のにデータが実質2系統存在し、どちらが正しいか誰も把握していない状態が長年続きます。

第三は「追加・例外の積み重ね」です。当初の設計が3種類の顧客区分コードだったものが、例外対応・新事業追加・担当者交代を繰り返すうちに27種類に増殖し、最終的に「このコードの意味を知っている人がいない」状態になります。設計意図の文書化がないまま追加が続くと、誰も全体像を把握できなくなります。

コード体系設計で実務上重視したい3つの考え方

長期的に維持できるコード体系を設計するには、次の3点が実務上の基本となります。

一意性は「同一の実体には1つのコードのみ」という原則です。顧客A社が「CU-001」と「CU-001-01」の両方で登録されている状態は、集計・分析・AIの学習データとしてすべてに問題を生みます。一意性を維持するためには、新規登録時の重複検知チェックや一意制約・登録ルールなどを組み合わせることが重要です。

標準化は「全社・全システムで同じ体系を使う」原則です。各部門のシステムが共通の顧客コードを参照できる状態を作ることで、システム間連携の負荷や変換処理を大幅に削減しやすくなります。現実的な移行手順としては、まず「マスタとなるコード体系」を1つ決め、他のシステムでは変換テーブルで対応しながら段階的に統一していく方法が多くの現場で機能します。

拡張性は「将来の追加・変更に耐える設計」です。数年後に新しい商品カテゴリが生まれたとき、コードが追加できる余裕があるかを設計段階で考慮します。たとえば数値のみで品番コードを2桁設計すると最大約100種類が上限ですが、4桁にすれば最大約1万種類まで対応できます。設計時に「10年後のスケール」を想定することが、後からの大規模改修を防ぎます。

既存のバラバラなコードを整理するアプローチ

理想の設計原則はわかっても、すでにバラバラな状態になっているコードを一気に統一するのは現実的ではありません。実務的なアプローチは「段階的統合」です。まずコード体系を一覧化し、どの体系をマスタにするかを決定します。次に、変換テーブルを作成して各システムが共通コードを参照できる橋渡しを作ります。最後に、新規データは統一体系のみに登録するルールを徹底し、旧体系のコードを徐々に廃止します。

以下は典型的な対応例です。自動車部品の製造・販売会社で、営業・製造・物流の3部門が独立してコードを持っているケースを想定します。全社統一コードへの一括移行は業務影響が大きすぎるため、「顧客コード」から先に統一し、商品コード・取引先コードは翌年度に順次移行するロードマップを策定します。こうした段階的な移行により、業務を止めることなく2〜3年でコード体系の統一を実現することが可能です。

このテーマの関連記事

このカテゴリの関連記事もあわせてご覧ください。

マスタデータとは何か？ではマスタデータが品質問題の震源地になる理由を、マスタデータの名寄せ・重複除去では同一実体の統合手法を解説しています。コードが整備された後の維持方法についてはマスタデータを整備後に守る仕組みをご参照ください。