一貫したデータの命名、できていますか？　～ネーミングルール策定と継続的な調整のポイント～

1. ネーミングルールの重要性

ネーミングルールが無いと、個々の設計者が自由に名称をつけてしまいます。その結果、表記揺れや同音異義語・異音同義語が多発し、業務側がデータの中身を誤解してしまう、業務とITの間でコミュニケーションの齟齬が生じるといった事態に繋がります。さらに生成AIに読み込ませる際にも、命名がばらついてしまっていると、誤った解釈や学習効率の低下を招く恐れがあります。
このような事態を防ぐためには、データ設計段階でネーミングルールを策定し、一貫した命名を行うことが重要です。

今回は、論理データ項目名に焦点を当て、基本となるネーミングルールとルールをブラッシュアップする際のポイントをご説明します。

2. 基本となる3つのルール

（1）データ項目名の構成要素

弊社ではデータ項目名を設計する際は、「主要語」「区分語」「修飾語」の3要素を組み合わせて命名することを推奨しています。

こちらは、ウイリアム・R.デュレル氏が1987年に発表した、業界標準とも言える命名ルールです（参考：ウイリアム・R.デュレル 著, 「データ資源管理 : 企業内データの有効活用を目ざして」, 1987 ）。

要素	定義	例
主要語	・業務上の資源（リソース）や出来事（イベント）などの実体を指す用語 ・省略は不可	品目 組織　など
区分語	・とりうる値の範囲や集合（定義域）を指す用語 ・省略は不可	ID コード 名称 金額 数量　など
修飾語	・主要語や区分語の意味をさらに詳細化する場合に使用する用語 ・一つ以上組み合わせることも、省略も可能	親 ○○ 発注元 ×× 合計 △△　など

基本的には「修飾語＋主要語＋区分語」の順で配置し命名します。このルールを用いることで誰がデータ項目名を命名しても一貫性と分かりやすさを保つことができます。
例：発注元組織ID、親品目コード、合計仕入金額、予定納品数量　など　

（2）区分語一覧の適用

データ項目名を構成する「区分語」に利用する用語をあらかじめ一覧化し、命名時には必ずこの一覧から選択するようにします。例えば、次のように整理しておきます。

区分名	形式	定義
ID	数値	・数値のみの識別子項目 ・無意味連番
コード	英数	・英数を含む識別子項目 ・無意味/有意味連番両方を含む
数量	数値	・数量一般 ・小数点以下の有/無数値両方を含む

区分語一覧から選択して命名することで、IDやコードなど、人によってどちらを選択するのか迷いがちな用語の使い方を揃えることができます。また、データ項目名からどのような値を管理する項目なのかも一目でわかるようになります。

（3）用語一覧の適用

「区分語」と同様に、「主要語」「修飾語」も一覧化しておき、命名時に適切な用語が一覧上にあれば選択するようにします。
区分語一覧は、データ項目の値範囲に対して使用する用語の統一を図るものであり、用語一覧は、業務上の実体や概念を表す用語の統一を図るという目的の違いがあるため、分けて作成します。
用語一覧は一般的な用語ではなく、自社や業界で頻出する言葉を整理します。もし、社内に業務用語集がある場合は、それを活用するとよいです。
例えば次のように整理します。

用語名	定義
品目	本社およびグループ会社が売買を行う際に扱うモノ。 製品番号レベルのものは含まない。
取引先	得意先や仕入先を含めた本社およびグループ会社が取引を行う相手。 法人だけでなく、支店などの組織レベルも含む。

この一覧から主要語や修飾語を選択することで、異音同義語や同音異義語の発生を防ぐことができます。

3. ネーミングルールのブラッシュアップ

ネーミングルールは簡単に作れるように見えます。しかし実際に運用していくと、うまくルールに当てはまらない悩ましい問題が多く出てきます。ここで、筆者がコンサルティング現場で経験したよくある問題を二つご紹介します。皆様も自分たちならどうするか？と考えてみてください。
なお、今回は英語で命名する際の問題点に焦点を当てておりますが、日本語でも同じような対応は必要と考えています。

問題①：修飾語の配置

時刻を表す“品目配送日時”という日本語のデータ項目を、英語で“Item Delivery Date Time”と命名したとします。しかし、時刻には、現地時間や標準時間を表すものがあるため、それらを識別する必要が出てきます。そこで、日本の標準時を表す修飾語“JST”を付け加えることにします。ここで問題となるのが、修飾語の配置です。
英語で命名しているので、本来のルールであれば、“JST Item Delivery Date Time”のように、標準時を表す修飾語も主要語の前に配置することになります。しかし、これでは、“JST”が何を修飾しているのかが分かりにくく、また英語の語順としても違和感があります。
そのため、標準時を表す修飾語のみ例外的に区分語の前に置くことを許容することにします。
“Item Delivery JST Date Time”
なお、標準時を表す修飾語を区分語より後ろに配置する案も考えられます。しかしこの案を適用すると、修飾の方向に統一性が無くなり、今後配置順における他の例外が出てきた際、一貫した対応を取れなくなる可能性があります。よって、標準時を表す修飾語は区分語の前に配置するルールとしています。

このように、ルールを適用してみて、当てはまらない状況が出てくることはよくあります。しかし、例外を増やし過ぎると一貫性を損ねる恐れがあるため、極力増やさないようにしつつ、例外とした場合は適用範囲を明確にしておくとよいです。

問題②：略語の許容範囲

主要語や修飾語に対する略語の使用をどこまで許容するかはよく議論になります。基本的には、システム上で設定できる名称の文字数に制限が無い限り、略語は使用しない方が望ましいです。これは、設計者によって同じ略語が異なる意味で使用される可能性があるためです。例えば、“Org”という略語を、“Organization”の意味で使用する設計者もいれば、“Original”の意味で使用する設計者もいるといったケースがあります。
一方で、社内や業界内等で略語の使用が一般的となっている用語をどのように扱うかは問題となります。例えば、損益を表す“Profit and Loss”は、 “PL”を使うのが一般的ですが、こうした略語を許容すべきかどうかはよく意見が分かれる点です。
このような問題を解決するため、既存の用語一覧を基に、略語の使用が一般的な用語を選定します。選定した用語は、用語一覧上でも略語のまま定義し、それ以外の略語は使用を認めないこととします。ただし、新たに略語を使用したい場合は、その都度検討を行い、必要に応じて一覧を更新していきます。

このように、名称の一貫性を担保しつつ、現場の実情に沿ったルールとするための工夫が重要です。

4. 最後に：ネーミングルールの実践に向けて

ネーミングルールは、ルールを決めた後からが本当の始まりです。実際に運用する中で、これまでご説明したような悩ましい判断や細かい調整を繰り返し行う必要があります。
しかし、こうした問題をひとつひとつ解決しながら運用を続けていくことで、開発チームにもルールの意義が浸透し、誰が設計しても一定品質で命名されるようになります。人間だけでなく生成AI等の機械にとっても、データを正しく解釈するためには、一貫したルールに基づいた名称を付与することが大切です。

データ統合基盤など自社でシステムを開発する際には、ネーミングルールの策定と適用を検討するようにしてみてください。