連載企画 第6回
ぶれないマスターデータ管理は「項目定義」と
「採番ルール」から

マスター管理の出発点は、「何をどう定義するか」にある

マスター管理を考えるうえで、最も基本であり、かつ重要なのがマスター項目の定義です。
そもそも「マスター」とは、企業活動の中で扱うモノや事象を定義し、業務の中で共通利用できる形に整えた情報を指します。
一見すると、項目を用意して値を登録すれば済むように思えるかもしれません。しかし実際には、「何をひとつのデータとして扱うのか」「どの粒度で管理するのか」「その項目は何を意味するのか」といった前提を曖昧にしたままでは、後から必ず運用上の課題が生まれます。
マスター管理の質は、こうした“定義の精度”によって大きく左右されるのです。

データ管理でまず押さえたい「粒度」の考え方

システム化を進める際に、最初の論点になりやすいのがデータの粒度です。
たとえば、ボールペンを商品マスターに登録する場合でも、管理の仕方はいくつも考えられます。
1本単位で管理するのか、複数本をセットとして扱うのか、あるいは販促用パッケージを含めた単位で定義するのか。商品ひとつを取っても、業務上どの単位で把握したいかによって、あるべき定義は変わります。
重要なのは、粒度が細かければ細かいほどよい、というわけではないことです。
たとえば「今年どれだけ売れたのか」を見たいのか、「ケース単位でどの程度出荷されたのか」を把握したいのかによって、適切な管理単位は異なります。販売個数を把握したいなら最小単位で、ケース出荷を重視するならケース単位で管理する必要があります。
つまり、データの粒度は、お客様が何を把握したいのか、どのように集計・分析したいのかに合わせて設計することが重要です。
そのうえで、集計結果が「漏れなく、ダブりなく」扱えるように整えることが、マスター設計の基本になります。

名称項目には“名前以外”を入れないという原則

マスター項目を定義する際に、見落とされやすいのが名称項目の扱い方です。
たとえば取引先名称の欄に、「〇〇商店」や「株式会社〇〇」といった正式名称だけでなく、「（取引終了）」「（廃止済み）」といった状態情報まで一緒に記載されているケースがあります。現場では便宜上わかりやすい方法かもしれませんが、データ管理の観点では望ましい状態ではありません。
本来、名称項目はあくまで“名称そのもの”を管理するためのものです。
取引状態や利用状況といった情報は、別項目として切り分けて管理すべきです。
これは人名や住所にも同じことがいえます。
姓名を分けて扱うべきか、住所を都道府県・市区町村・番地に分解すべきかといった判断も、後続業務や検索性、他システム連携を考慮して決める必要があります。
見た目にはひとつの文字列に見える情報でも、そこに複数の意味が混在していると、後から活用しにくくなります。
そのため、管理すべき要素を正しく抽出し、意味ごとに分けて定義することが、データ品質の向上につながります。

同じ項目名でも、意味が曖昧だと運用は崩れる

項目定義でもうひとつ重要なのが、意味定義の明確化です。
たとえば、店舗マスターに「席数」という項目があるとします。一見わかりやすい項目ですが、実際には「何をもって席数とするのか」が曖昧なままだと、運用上の混乱を招きます。
店舗の広さから算出した標準的な席数なのか。
店長の判断でレイアウトを変更した結果として、現在実際に運用している席数なのか。
あるいはフードコートのように複数店舗で共有している座席を、どの範囲まで含めるのか。
同じ「席数」という言葉でも、人によって解釈が異なれば、同じ項目を使っていても中身は揃いません。
その結果、分析結果や業務判断にズレが生まれてしまいます。
だからこそ、項目名だけではなく、その項目が何を意味するのかを、関係者全員が同じ認識で理解できる状態にすることが必要です。マスター管理における定義とは、単に項目を作ることではなく、意味をそろえることでもあります。

移行時に問われるのは、データマッピングの正確さ

現行システムから新システムへ移行する際には、データモデルのマッピングを正確に行うことが欠かせません。
これまで使ってきたデータが、新システムのどの項目に対応するのか。
その対応関係を明確にしないまま移行を進めると、必要なデータが抜け落ちたり、逆に意味の異なる項目同士を無理に対応づけてしまったりする恐れがあります。
ここでは、単にシステム上の項目名を見比べるだけでなく、ユーザーから見た使い方や、他システムとの連携のされ方まで考慮する必要があります。
つまり、マッピングとは単なる移し替え作業ではなく、業務の意味を保ったまま、新しい仕組みに正しく載せ替える作業だといえます。

部門ごとの利用実態を踏まえた分類が、使いやすさを左右する

データの分類を考える際には、どの部門がどのように使うのかという視点も欠かせません。
たとえば、営業部門が日常的に参照するカテゴリーと、経理部門が主に利用するカテゴリーでは、必要とする情報の切り口や優先順位が異なります。
こうした違いを無視して一律の設計にしてしまうと、どの部門にとっても使いにくいマスターになりかねません。
マスター管理は、全社共通で使えることが重要ですが、同時に、それぞれの業務で使いやすいことも求められます。
そのためには、部門ごとの利用実態を踏まえながら、情報の見せ方や分類の仕方を丁寧に設計することが重要です。

データ品質を支えるのは「データオーナー」の明確化

マスター管理を運用の中で機能させるうえで、もうひとつ重要なのがデータオーナーの明確化です。
たとえば電話番号のように、複数の部門で利用される情報があったとしても、「最初に誰が登録するのか」「どの部門がその正確性に責任を持つのか」が決まっていなければ、データ品質は安定しません。
実際の現場では、「このデータはあの部門が入れるはず」「この項目は別の部署で管理しているはず」といった認識のずれが起こりやすく、それが放置されると、入力漏れや責任の所在不明につながります。
特に、企業の登記情報のように正確性が強く求められるデータについては、なおさら責任部門を明確にしておく必要があります。
データ品質は、仕組みだけでは維持できません。
誰が持ち主なのかを定め、責任と運用をセットで設計することが、品質向上の前提になります。

センシティブ情報は、品質と運用のバランスで考える

データ管理では、アクセス権限の考え方も重要です。
特にセンシティブな情報については、誰が管理し、誰が閲覧できるのかを事前に検討しなければなりません。
ただし、厳格に制限しすぎると運用が煩雑になり、現場で使いづらい仕組みになってしまいます。
一方で、あいまいなまま運用すると、データの信頼性や安全性が損なわれる可能性があります。
そのため大切なのは、データ品質と業務運用のバランスを取ることです。
どのデータを誰が持ち、どこまで見られるのかを明確にすることで、安全性と実用性の両立がしやすくなります。

採番ルールは、データ統一の土台になる

マスター管理において、項目定義と並んで重要なのが採番ルールです。
採番ルールとは、商品や製品などのデータに対して識別番号を割り当てるためのルールを指します。
この採番ルールは、先に述べたデータの粒度とも深く関係しています。
たとえば商品番号を付けるとき、最も細かい単位から一貫性を持って採番しなければ、同じ商品を別のものとして扱ってしまったり、逆に異なるものを同じものとして扱ってしまったりする可能性があります。
また、営業部門と他部門で異なる商品コードを使っている状態では、同一商品かどうかの判別が難しくなります。
だからこそ、採番ルールを定める際には、全社共通で使える番号体系を設計し、一貫して運用することが重要です。

将来の事業拡大を見据えるなら、「桁数不足」に注意する

採番ルールを検討する際には、将来的な拡張性も考えておかなければなりません。
特に典型的な課題となるのが、コードの桁数不足です。
事業や商品数が増えたとき、既存のコード体系では収まりきらなくなり、桁数を増やさざるを得なくなるケースがあります。
こうした問題は、導入時には見えにくいものの、長期運用では大きな負担になりがちです。
その背景としてよくあるのが、コードそのものに意味を持たせる「意味あり桁」の採用です。

「意味あり桁」は便利だが、将来の制約にもなり得る

たとえば、食品会社の商品コードで、1桁目に事業区分を埋め込むケースを考えてみます。
“1”はアイスクリーム、“2”は砂糖、“3”はチョコレート、といった形で分類しておけば、一見すると直感的でわかりやすく見えます。
しかし、新しい事業が追加された瞬間に、そのルールは制約に変わります。
1桁目を事業部、2桁目をサブジャンル、3桁目以降を連番にしていた場合、事業が増えたり分類体系が変わったりすると、既存コードの再設計が必要になる可能性があります。
つまり、意味あり桁は“今は便利”でも、将来の変化に弱い設計になりやすいのです。

J-MDMで推奨する考え方は「無意味採番」

こうした課題を避けるために、有効な考え方が無意味採番です。
無意味採番とは、コード自体には意味を持たせず、単なる連番として扱う方法です。
事業区分や商品分類などの意味情報は、別の項目や別マスターとして管理し、識別コードと切り離して設計します。
この方法であれば、事業の拡大や新しいジャンルの追加があっても、コード体系そのものに大きな影響を与えにくくなります。
その結果、拡張性を保ちながら、安定した運用を続けやすくなります。
もちろん、無意味採番が常に正解というわけではありません。
実際の業務では、商慣習や現場の運用上、ある程度意味を持ったコードの方が扱いやすい場面もあります。
大切なのは、わかりやすさと拡張性のバランスをどう取るかを見極めることです。

JANコードだけでは足りないこともある

商品を識別するコードとしては、JANコードやITFコードが広く使われています。
ただし、社内での商品管理においては、JANコードが必ずしも最小単位の識別コードになるとは限りません。
たとえば、JANコードは同じでも、ラベルの追加や包装形態の違いなどによって、社内運用上は別のものとして管理したいケースがあります。
期間限定キャンペーン用のパッケージが付いた商品などは、その典型です。
たとえば「グレープゼリー 10個入り 500g スタンドパック」という商品に、キャンペーン用パッケージを付ける場合、JANコードは変わらなくても、現場としては通常商品と区別して把握したいことがあります。
このような場合、外部向けの標準コードとは別に、社内管理のためのより詳細な識別ルールを持つ必要があります。

商品のバリエーション管理には、グルーピングの発想も欠かせない

商品管理では、個別商品の識別だけでなく、グルーピングの考え方も重要です。
たとえば「10個入り」「20個入り」といった入り数の違いや、「グレープ」「レモン」といったフレーバー違いなど、商品には複数のバリエーションがあります。
これらをすべて個別商品として持つだけでは、価格設定や集計の観点で扱いにくくなることがあります。
そのため、個別商品を束ねる代表品目を設け、必要に応じてその単位でマスターを利用できるようにすることが有効です。
代表品目を使えば、商品群をまとめて分析したり、業務に適した粒度で管理したりしやすくなります。
個別管理と集約管理の両方ができる状態を整えておくことが、データ活用のしやすさにつながります。

企画段階の商品には、別のコード体系が必要なこともある

特にR&D部門を持つ企業では、商品化が確定していない企画段階のデータをどう扱うかも重要な論点になります。
企画中の商品に対しても、管理上は何らかの識別コードが必要になりますが、その時点ではまだJANコードを付ける段階ではないこともあります。
また、10件の企画のうち、最終的に商品化されるのが1件だけということも珍しくありません。
このような場合、商品化されなかった案にまで正式な商品コードを割り当ててしまうと、使われないコードが大量に残り、管理が煩雑になります。
そのため、企画段階では正式採番とは別の仮コード体系を用意し、商品化後に正式なコードへ移行する、といった運用が有効です。
これは、現場の業務フローとシステム運用を無理なく両立させるための重要な考え方です。

重要なのは、自社の業務に合った管理方法を選ぶこと

ここまで見てきたように、項目定義も採番ルールも、単に“きれいな設計”を目指せばよいわけではありません。
企業ごとに業務フローは異なり、扱うデータの種類や求められる粒度、運用上の優先事項も変わります。
だからこそ重要なのは、自社の業務に合ったコード管理方法を選び、分類方法を適切に設計し、現場でスムーズに運用できる形に落とし込むことです。
ルールを作ること自体が目的ではなく、業務の中で継続的に使え、データ活用につながる仕組みにすることが本質です。

まとめ｜マスター管理の質は、「定義」と「採番」で決まる

マスターデータ管理を成功させるためには、まず「何をどう管理するのか」を明確にしなければなりません。
データの粒度をどうするのか、名称項目と状態情報をどう分けるのか、項目の意味をどこまで明文化するのか。さらに、誰がそのデータに責任を持ち、どのようなルールで識別コードを付与するのかまで含めて設計する必要があります。
特に、項目定義と採番ルールは、マスター管理の土台そのものです。
ここが曖昧なままでは、システム移行や他システム連携、全社での共通利用、将来的な拡張のどこかで必ずひずみが生まれます。

J-MDMで目指すのは、単にデータを集めることではなく、企業の変化に耐えながら、長く使い続けられるマスター基盤をつくることです。
理想のデータ管理を実現するためには、目の前の運用だけでなく、その先の活用や拡張まで見据えて、「項目の定義」と「採番ルール」を設計することが欠かせません。