日本企業におけるデータ衛生管理上の課題と対応の重要性

データハイジーン（Data Hygiene＝データの衛生管理）は、マスターデータ管理(MDM)やデータ管理に関わるすべての人が「必要かつ重要なもの」と認識しています。しかしその一方で、時間や労力、関心を割きたくない領域でもあります。 
データのクレンジングなどの作業はたいてい「舞台裏」で行われ、問題が起きたとき、あるいはより正確には「明らかな失敗」として表面化したときにしか注目されません。 

実は見過ごされがち ― データ衛生の大切さ 

データに問題があると、それがよりによって一番困る場面で明らかになることがよくあります。たとえば、顧客へのプレゼン中にエラーが発覚したり、取引先に渡したファイルでミスを指摘されたりするのです。 

米調査会社ガートナー社によれば、データ品質の悪さは全米国企業平均で年間約19億円の損失を企業にもたらし、さらに大企業の60%がデータ品質を一切測定していないとされています。 
これを改善するための高レベルの戦略やデータ管理方針について述べた記事は数多くあり、当社もこの分野で多くの専門知識を有しています。 
しかし今回はより現実的な視点で、日本特有の「データの落とし穴」について、具体例とともに解説し、実践的な解決策も紹介していきます。 

今回は、日本のビジネスデータに特有の２つの課題に焦点を当てます。

目次

- カタカナ表記の名前 

- 過剰なクレンジング  

カタカナ表記の名前 

日本のビジネスシーンでは、カタカナが広く使われています。特に、外来語（外国語由来の言葉）を表記する際によく用いられますが、それだけに限りません。企業名や商品名なども、スタイリッシュな印象を与えたり、英語にしかない概念を用いたり、或いはグローバルに打って出たいなどの理由から、 あえてカタカナで表記されることがあります。 
たとえば、「ニトリ」のように、カタカナで表記することでブランドイメージを演出している例もあります。 

たとえば、「Michaela Smythe」という名前を日本語で表記する場合、英語の発音では「ミケイラ・スマイス（maɪˈkɛlə ˈsmaɪð）」となりますが、日本語には有声の「th」音がないため、「ミケイラ・スマイズ」と書かれることもあります。 
また、中黒（「・」）の使用有無も統一していません（これについては後述します）。 
「Michaela」という名前は「Michael」の女性形であり、「Michelle」にも近く、しばしば「マイクル」や「マイクルア」と間違われます。「Smythe」は「Smith」と同じ発音をされることもあります（スミス）。 さらに、「Michaela」の愛称としては「Misha」や「Kay」が使われることがあり、それだけでも表記のバリエーションは以下のように多岐にわたります： 

著者の名前「Warwick Matthews」になると、さらにややこしくなります。 

• 「Warwick」という名前は、イギリスでは「ウォリック」、アメリカでは「ワーリック」あるいは「ウォルウィック」と発音が異なります。 

• また、「Warwick」は姓として使われることが多く、「Matthew」は名前として一般的なため、日本に限らず海外でも「Matthew Warwick（マシュー・ウォリック）」と間違われることがよくあります。 

最近では、「Warwick Matthews」のように“名＋姓”の順で表記するのが一般的になりつつありますが、これが正式なルールとして定着しているわけではありません。もっとも、最近のシステムではローマ字表記の英語名がそのまま使えるケースも多くなってきており、こうした表記の揺れや混乱は、実際にはそれほど問題にならないという見方もあるかもしれません。 
しかし、たとえローマ字で名前の表記の揺れを防げたとしても、氏名の順序の問題は依然として残ります。日本では「姓＋名」、英語圏では「名＋姓」で表記されるため、混乱を招くのです。 たとえば、以下のような表記はどちらが正しいのでしょうか？ 

最近の日本では、外国人名については「名＋姓」の順で表記するのが一般的になりつつありますが、これもまだ完全に統一されているわけではありません。 こうした表記の揺れは、データマッチングを非常に困難にする要因となります。 さらに深刻なのは、実際の企業名などに使われている外来語のカタカナ表記です。 たとえば「コンピューター」「ライフ」「コンプライアンス」などの単語は、比較的一貫したカタカナ表記が定着しており、表記のバリエーションが少ないため問題は起きにくいといえます。 
しかし、当社が日々扱っている実際のデータベースには、カタカナ表記に揺れのある 名称が多く存在します。こうしたケースでは、音を聞いて正確にカタカナで書き起こすことさえ難しいのが現状です。 

以下に、実際のデータベースから抜粋した、カタカナ表記が揺れが見られた実例をいくつか紹介します。 

カタカナ表記のバリエーションの多くは、文字数の違いや表記の微妙な差にすぎません。そのため、多くの検索・マッチングシステムでは、文字数をベースにした照合アルゴリズムを用いており、こうした違いが即座に致命的なエラーになることはあまりありません。 
とはいえ、これらの表記の揺れを適切に管理していない場合、特定の企業や個人を見落としてしまったり、同一のエンティティに対して重複レコードが作成されてしまうリスクは避けられません。 
特に、日本語の企業名を扱うようなシステムでは、「完全一致（strict matching）」が使われることも少なくなく、重複の発生リスクが高まります。 
（※なお、重複レコードは、データマネジメントにおける最大の敵のひとつです。） 

次に、カタカナに関連する要素として中黒（「・」）について触れておきます。 
中黒は日本語では単語同士を区切るために使われますが、その使い方には一貫性がありません。たとえば、「コンプライアンス・データラボ」は実際には3語で構成されていますが、中黒は1つしか使われていません。 
さらに問題なのは、多くのデータパース（解析）システムが欧米市場向けに開発されているため、中黒を「文字」として扱ってしまい、本来の「区切り記号」として正しく認識できないことがある点です。 その結果、中黒があるかないかによってマッチングの結果が変わってしまうため、データ照合において中黒の有無は非常に重要な要素になります。 
この問題を解決するには、クレンジングルールをアップデートし、「中黒あり・なし」両方のパターンを柔軟に処理できるスマートな仕組みが求められます。 

過剰なクレンジング

実は、データが「過剰にクレンジング」されてしまう原因はさまざまですが、ここでは主に次の2つのケースを取り上げます： 

1. アルファベットベースの汎用的なクレンジングが、日本語データに最適化されていないケース 
2. 「ノイズ文字」として削除された結果、情報が失われるケース

なお、②は実質的に①の一部なので、ここではまとめて解説します。 
 

多くの企業向けMDM（マスターデータ管理）／CRM（顧客関係管理）／ERP（基幹業務）システムには、句読点や記号を正規化・削除するための汎用的なクレンジングルーチンが組み込まれています。これらのシステムは一般的に、日本語の記号【】（）〜 『』「」を認識し、不要と判断すれば削除します。 
問題なのは、より微妙な記号類です。たとえば、〒、〶（郵便番号のマーク）、・（中黒）、々（踊り字） です。先ほど述べたように、中黒「・」は単語や意味の区切りを表す重要な記号です。見た目は地味でも、意味的には非常に大きな役割を果たしています。そのため、単純に削除してしまうと、言葉の構造が壊れてしまう恐れがあります。 
また、「々」は漢字の繰り返しを表す記号で、たとえば「人々」は「人人」と同じ意味を表します。しかし、日本語以外の解析システムでは、これを単なる1文字の漢字として扱ってしまうことがよくあります。 一方で、より賢いシステムでは、「々」をその直前の文字に置き換えて標準化し、表記ゆれ（例：「人々」と「人人」）の発生を防ぐことができます。
「〒」や「〶」は、その後に続くデータが日本の住所であり、郵便番号で始まっていることを示すマーカーです。 
したがって、これらを削除してしまうと、システムが「これは住所データだ」と認識できなくなり、データ分類や抽出の精度に影響を与える可能性があります。 

このように、「見た目は小さな違い」でも、日本語特有の記号や表現を正しく処理できないクレンジングルールは、データ品質の低下を引き起こすリスクをはらんでいます。 
日本語に最適化されたクレンジングルールの整備は、今後ますます重要になってくるでしょう。 

「〒」という文字は、便利でもあり同時に“ノイズ”でもある 

たとえば「〒」のような記号は、日本の住所の始まりを示す目印としては便利ですが、それ自体に意味を持たないため、多くのMDMシステムでは削除されるか、無視されてしまいます。 
中には記号をそのまま残すシステムもありますが、それはさらに厄介です。 
理想的な対応としては、「〒」を削除する一方で、そこから日本の郵便番号が始まり、その後に日本式の住所が続くという前提で処理できるよう、システムにフラグを立てることです。 

このような日本語住所の自動パース（構造解析）とベストプラクティスについては、今後詳しく取り上げる予定です。 

丸括弧（ ）や鉤括弧「」も、単なる“ノイズ”ではなく実際に意味を持つことがあります。ただし、その価値を正しく活かせるかどうかは、システムの“賢さ”次第です。 
たとえば、次のような企業名があったとします：

（株）東日本医療技術 

丸括弧を単純に削除してしまうと「株東日本医療技術」になってしまい、「株」が企業名の一部のように見えてしまいます。 
優れた解析システムであれば、「（株）」を社名から適切に取り除くだけでなく、その企業が「株式会社」であることを示す属性情報として別途保持することができます。 
さらに例を挙げると：

株式会社東日本医療技術（大阪本店） 

この場合、「株式会社」は正式な法人種別であり、「（大阪本店）」は事業所情報です。 
多くのアルファベット圏向けのシステムでは、「句読点や括弧」を削除するルールがあるため、「大阪本店」の情報ごと消えてしまい、最終的に「東日本医療技術大阪本店」のような形で処理されてしまう可能性があります。 これはデータマッチングの観点では必ずしも致命的ではないかもしれませんが、最適とは言えず、重複登録のリスクが高まります。 
さらに、括弧を「区切り」として解釈するシステムでは、「東日本医療技術」と「大阪本店」が別々の“単語”として扱われることがあります。 
このとき、システムが2つの語に同じ重みづけ（重要度）を与えてしまうと、かえって正しいマッチングができなくなる可能性があります。 

実際に、漢字一文字ずつを“単語”として扱い、共通文字数でマッチングを行うMDMシステムも存在します。 
この手法は一見有効な場合もありますが、よく使われる漢字が含まれると、関係のない名前同士でも誤ってマッチしてしまう（＝誤検出）可能性が高まります。 
たとえば「東」「日」「本」「大」「阪」「本」「店」といった汎用的な文字は多くの社名に含まれており、それだけを手がかりにしてマッチングすると、膨大な類似候補が抽出されてしまうのです。 

多くのMDMシステムでは、「株式会社」や「有限会社」などの“ノイズワード”とされる語句を自動的に除去するよう学習されています。 
その中には、「日本」「東」「西」「北」「南」「東京」「大阪」「本店」「支店」なども含まれることがあります。 
その結果、「株式会社東日本医療技術（大阪本店）」という名前が、極端なケースでは「医療技術」だけにクレンジングされてしまうこともあります。 
しかし、これはあまりにも情報量が少なく、あまりに汎用的な語句のため、データベース上のマッチングが非常に難しくなってしまうのです。 

 信頼できる専門家との連携が、データ品質を大きく左右する 

データクレンジングのベストプラクティス：4つのヒント 

1. 削除されている内容を確認し、リストを批判的に見直す
   多くのシステムでは、英語データに対しては50以上のクレンジングルールがあるのに、日本語データに対してはたった5つしかない――というようなアンバランスがよく見られます。自社データの9割が日本語であれば、この差は見過ごせません。まずはルールの中身をしっかり把握することが重要です。
   
   
2. 「クレンジングしすぎない」方針を基本にする 
   入力が検索エンジンのように非常に不規則である場合を除けば、厳格でミニマムなルールでも十分なマッチング精度は確保できます。過剰なクレンジングは、かえって情報の損失やマッチング漏れにつながりかねません。ベストなのは「バランスの取れた、賢いクレンジング」です。
    
   
3. 異なるバリエーションは「残す」ことを前提に
   すべてを1つの表記にまとめるのではなく、複数のバリエーション（例：未加工、生データ、ローマ字、カナ、軽度クレンジング済み、重度クレンジング済みなど）を保存しておく方が、後の照合や検索の柔軟性が高まります。
   ストレージコストは年々下がっており、現代のデータベースは大規模なクエリ結果にも十分対応できます。候補として多数の「似たデータ（false positive）」が返ってきても、絞り込むロジックさえあれば問題ありません。 
   
   
4. ローカルの専門家と連携する
   たとえば CDLのような日本市場に精通した専門企業と連携することで、データ品質を短期間でベストプラクティスレベルまで引き上げることが可能です。
   適切なアドバイスやツール選定、クレンジング設計の支援を得ることで、社内のデータ整備プロジェクトの成功率が大きく変わります。  

 
 
今後も、データ衛生管理に関するベストプラクティスのガイドを順次公開予定です。あわせて、CDLが今後リリース予定の製品・サービスにもぜひご注目ください 

著者のご紹介

ウオリック・マセウス 

ウオリック・マセウス(Warwick Matthews)  
最高技術責任者 兼 最高データ責任者

複雑なグローバルデータ、多言語MDM、アイデンティティ解決、「データサプライチェーン」システムの設計、構築、管理において15年以上の専門知識を有し、最高クラスの新システムの構築やサードパーティプラットフォームの統合に従事。 また、最近では大手企業の同意・プライバシー体制の構築にも携わっている。  

米国、カナダ、オーストラリア、日本でデータチームを率いた経験があり、 最近では、ロブロー・カンパニーズ・リミテッド（カナダ最大の小売グループ）および米国ナショナル・フットボール・リーグ（NFL）のアイデンティティ・データチームのリーダーとして従事。  

アジア言語におけるビジネスIDデータ検証、言語間のヒューリスティック翻字解析、非構造化データのキュレーション、ビジネスから地理のIDデータ検証など、いくつかの分野における特許の共同保有者でもある。

Copyright Compliance Data Lab, Ltd. All rights reserved.        
掲載内容の無断転載を禁じます。