2026/10/02
MDM / Master Data Managementは2000年代半ばから使われるようになった言葉で、それ以前にはほとんど見当たりません。そして現在でもマスターデータに問題があると答えるCIOは多い。MDMは新しい、そして現在でも課題とされているナウい言葉だと言えるでしょう。
しかし「マスターデータの管理」そのものの歴史は古く、メインフレームが登場し、業務のさまざまな情報処理を担うようになった時から「製品」や「顧客」といったマスターデータが存在しました。マスターがあるなら、誰かが登録し、直し、守っていたということです。それはそれで立派なマスターデータ管理です。
メインフレームは今も高価ですが、昔はいっそう高価で、そこに積まれるメモリもストレージも高価でした。だから大企業から順に、優先部門や業務から順に、それぞれ大プロジェクトをたてて「システム化」してきたわけです。今の目線からすれば「部分最適」であり「サイロ」だと非難されるところでしょうが、優先順で一つずつシステム化していったのだから自然な成り行きと言えるでしょう。言ってみれば当時は、サイロを建てること自体が贅沢だったのです。
やがてシステム化は一巡します。定型的な事務仕事がだいたいシステム化されたのは1990年代。Windowsが出てきてパソコンが一人一台になった頃でした。それまで紙の伝票に手書きしていたのが、画面の伝票にキーボードで打ち込むようになった。やっている業務そのものは変わらないながら、いちいち紙のファイルを取ってくる必要もないし、社名や品名を別の伝票に書き写す必要もなくなりました。
「データ連携」とさかんに言われるようになったのがこの頃です。注文を受けたが、工場はまだ知らない。出荷はしたが、経理はまだ知らない。それぞれ別のシステムだからです。そうした問題を解決するのがデータ連携でした。こちらも、必要なシステムインターフェースを一本ずつ順番に作っていきました。当時は「インターフェース一本あたり一人月」の費用がかかるのが相場であり、やはり高価だったのです。
その当時、基幹システムのニューウェーブが日本を席巻しました。ERP / Enterprise Resource Planningです。これらはパッケージソフトウェアであり、必要な機能はプログラミングすることなく、インストールすれば手に入ります。いまAIエージェントによる「SaaSの死」が噂されているのと同じ構図で、パッケージソフトウェアによる「スクラッチの死」がさかんに唱えられました。IT業界では定期的に死の予告をしたくなるようです。そういえば「ビッグデータの死」が発表されて話題になったこともありました。
ERPが強かったのは「機能ぜんぶ入り」だけではありません。地味ではありますが、マスターが一本化されていることも強みでした。ERPといっても中身は業務それぞれに対応するモジュールでできており、セットで買うだけでなくバラでも買えます。追加でモジュールを買っても同じマスターが流用できる効用は計り知れません。
しかし日本企業はここで一つ大きく躓きました。従来のマスターをそのまま使おうとしたことです。ERPのマスターは一本化するだけあって、汎用的で正規化された構造を持っていました。ここでERPのマスターに合わせて業務やデータの定義を見直すことが期待されていましたが、日本の多くの企業はERPに屈しなかった。マスターをそのままに、無数のアドオンプログラムを作って対応しました。顧客には「NTTドコモビジネスX株式会社」だけでなく「NTTドコモビジネスX (別枠)」などを追加して計算方法を分けたり、注文の納期に「2050-12-31」とあったら「保留」扱いにするための特殊ロジックを組込んだりしました。
本来はそこでルールと定義を見直し、会社名には会社名しか認めない、日付には日付しか入れないようにすべきでした。データ項目を作って、別枠だったら別枠と、保留だったら保留と管理するのが本筋です。そのための議論の中で、「顧客」とは何か、「別枠」とは、「保留」とは何かを整理して再定義し、業務ルールを見直します。旧弊な慣習や不要な制約を取り払う手術も必要でしょう。DX / デジタル・トランスフォーメーションもMDM同様、古くて新しい概念だったということです。ところが日本企業の多くは、業務を変えるほうの圧力に耐えてしまい、逆にERPをトランスフォーメーションする道を選んだということです。
アドオンプログラムが増えると、ERPは簡単に乗換えられません。それどころかERPのバージョンアップすらままならない。ERPだけではなく、アドオンプログラムすべての動作保証のための検証や修正、あるいは作り直しが必要になるからです。日本企業はITについて腰が重いとよく言われます。バージョンアップが早いことが評価されず、むしろ敬遠されるのが日本のIT市場の特徴ですが、無数のアドオンプログラムも大きな原因だったといえるでしょう。
アドオンプログラムの大きな副作用は、同じERPを使っていながらマスターが一つではなくなることです。「NTTドコモビジネスX (別枠)」は営業の都合であって、経理から見れば謎の取引先が一社増えたように見えます。工場が保留の意味で納期を「2050-12-31」と入力すれば、EDIは律儀に、未来の部品発注をしてしまうかも知れません。「あれは保留という意味だ」と知っているのは人間と、一部のアドオンプログラムだけだからです。
日本がERPに「耐えて」いる間に、世界のITはビッグデータだ、データレイクだ、SaaSだ、機械学習だと進歩し続けました。しかし日本は業務を変えず、マスターを変えなかったため、ITは腰が重いままでした。
マスターを変えないのが問題ならば、対応策はマスターを変えることです。業務にあわせ、ビジネス環境に合ったマスターを持てるよう業務や定義を吟味し、議論し、変更していくことは論理的な帰結です。
しかしここで、日本企業におけるもう一つの問題が立ちはだかります。情報システム部門はシステムを管理し、システム以外は管理しません。そしてマスターはシステムのインプットでありアウトプット、つまりシステムの外にあります。いっぽう業務部門からすると、データは業務ではありません。自分の仕事ではないと考えます。どちらも自分の領分ではないと考える結果、両者が集まって議論する代わりに、どちらも話題にしない状況が生まれます。マスターデータに関して、業務とシステムの「お見合い」状態が長らく続いてきました。
マスターが「ゆるい」まま誰も手を付けないため、多大な労力をつかってERPを入れ替えても、期待した成果はなかなか出ません。マスターの定義やルールの緩さを、アドオンプログラムでカバーするには何倍もの手間やコストがかかります。新居に引っ越しても、元の家具を元の位置に置こうとしてリフォームするようなものです。
MDM / マスターデータ・マネジメントが登場するのは、そのような局面です。あるべきマスターを作ろう、システム都合や部分最適で盛り込んだ特殊仕様を整理し、整然としたマスター体系にしよう。本来の意図を確認し、部門ごとの定義を突き合わせ、重複するものは一つにし、別物であれば別項目を立てよう。それがMDMです。そうしてできた正しいマスターを、ゴールデンマスターと呼びます。名前は華やかですが、実体は人の会話と泥臭い調査の堆積から生まれた結晶です。
「ゴールデンマスターとやらを作ったって意味がない」という反論はごもっともです。現行システムの全マスターをゴールデンマスターで置き換えることを「マスター統合」といいますが、それは既存の全システムの全面改修を意味するからです。マスターを一本化しないのであれば、今あるバラバラなマスターにゴールデンマスターという新しいマスターが一つ加わるだけになってしまいます。
ゴールデンマスターを作るが、マスター統合による一本化はしない。しかしゴールデンマスターは作りっぱなしではない。それがMDMです。既存システムのマスターはそのまま残したうえで、それらの対応関係を一箇所で引き受けてしまう。全面改修をせずに「一つの正しいマスター」を成立させるのが、MDMの発想です。
ゴールデンマスターは、顧客なら顧客、製品なら製品といったマスターごとに、全システムのマスターを最小粒度でカバーします。MDMには、マスターごとのすべての情報が入っており、それを正しい形、正しい内容で維持します。データベース用語でいう「正規化」です。
それだけではない。MDMは、同時に「クロスリファレンス (Xref)」を持ちます。意訳すると「マスター読替え表」、もっと言えば社内に散らばった方言の翻訳辞書です。MDMはすべての情報を最小粒度で持っているのだから、既存のどのマスターのどの項目も、ゴールデンマスターの部分集合でしかない。既存のどの項目にも読替えてマッピングできるはずです。それが読替え表です。ある顧客はゴールデンマスターでは1番で、販売システムではC255番、経理ではBB11番だったら、横に並べて一行にすれば機械的に読替えが可能になります。
たとえば、ある営業部門で新規顧客を検知したら、まずMDMを探します。MDMになければ社内のどこにもない完全な新規顧客ということです。そこでゴールデンマスターを追加し、同時に関連する全部門のクロスリファレンスを追加し、それぞれの顧客コード、それぞれの住所や電話番号の形式に変換して配信します。そうすれば、同じ顧客の同じ情報が、それぞれのシステムに、それぞれの形式で一斉に登録されます。
MDMはデータウェアハウスに対しても同様のはたらきをします。データウェアハウスにはゴールデンマスターを配信し、ETLにはクロスリファレンスを配信することで、ゴールデンマスターでできたデータウェアハウスを構築できることになります。
データウェアハウス以外の新システムを追加するときもMDMは同様のはたらきをします。新しいマスターや項目が増える都度、その分のゴールデンマスターを増強し、クロスリファレンスを追加します。複雑で精妙なデータベース操作ではありますが、そこをノンプログラミングで実現するのがMDMツールです。週単位の時間をかけてSEが作っていたシステムインターフェースが、マスター管理者である「データスチュワード」による分単位の設定作業に置き換わり、圧倒的なスピードを獲得します。ここで重要なのはデータベース操作ではなく、マスターを変更するという業務判断と意思決定です。
MDMはまた、基幹システムの変更やERPの乗換えにも有効です。新旧システムどちらも、対象が同じ業務であるならば、必要なマスターはゴールデンマスターにすべて入っているはずです。あとはマッピングと読替えがあるばかりです。
またMDMがあれば、新システム開発のための現行調査や分析の手間を大きく省くことになるでしょう。すべてのマスターが業務に即した形でMDMに入っているからです。そしてデータ移行も最小限の労力となるはずです。クロスリファレンスには旧システムとのマッピングは既に入っているので、そこに新システムとのマッピングを追加するだけだからです。
このように役に立つMDMですが、MDMをうまく動かす大事なポイントが一つあります。
それは現場のベテランです。彼らが引っ張ってくれるようであれば、MDMの成功はほぼ間違いありません。業務に即したマスターを作れるのは、業務の実態を体で知っている人だからです。それが、システム部門が主導で、現場ヒアリングを◯回予定、誰がアサインされるかは不明という状態だと成功確度が落ちます。ベテランと距離が離れる分だけ、業務の実態が分からなくなるからです。さらに、もしシステム部門が現場ではなくベンダーと会話するだけだと、なお一層確度が落ちるでしょう。ベンダーが知っているのはMDMツールです。「2050-12-31」は2050年の12月31日だと解釈するはずです。
MDM成功のカギは人と会話をすること、情報を把握することです。基幹システム更改にはマスターが大事、マスターの変革にはMDMが大事、そしてMDMの成功には会話が大事だというのが、MDMの視点からみた「基幹システム論」です。データを整えるには、そのデータを使っている人の話を聞くしかない。この原則は、生成AIに社内の知識を持たせようとする取り組みでも、おそらく変わらないはずです。
