MDM(マスターデータ管理）とは？目的・メリット・進め方｜経験談

MDM開始時に、CIOに言われた一言が印象的でした、、、

CIOは過去のMDMプロジェクトを見てきた経験から、プロジェクトの壮絶さ過酷さからの一言だったかなと思います。幸い私はプロジェクトを無事完遂でき、今も幸せに仕事を楽しむことができています。

とはいえ、CIOの一言が象徴するように、
MDM（マスターデータ管理）は、
・目的・効果が見えずらい、というか理解してもらえない
・関連するプロジェクト・システムが多岐にわたる
・結果、難易度が高い
といった傾向があります。

本記事で、過去の経験に基づき、

を解説していきます。

MDM導入ステップの前に「MDMとは？」基本情報

MDMの定義とは？

MDMは、
・Mobile Device Management
・Master Data Management
があります。

Mobile Device Managementは、よく会社から提供される端末に導入され端末をセキュリティーの観点から管理するものです。今回はこちらは語りません。

Master Data Managementは、本記事の本題のマスターデータ管理の仕組みを指します。

MDM導入前に企業が直面している課題

実体験に基づいた課題感です。以下の内容はMDMを導入検討しているどの企業にも該当する内容ではないでしょうか。（根拠：前職ではMDM推進、現職ではMDMのアドバイザリーをしています。会社が違えど同じ課題・景色を目にしています）

MDM導入前どの企業も直面している課題は、
・各部署がバラバラにマスターを管理
・マスターを統括する部署不在
・マスターを管理するシステムもバラバラ存在、高コスト
といった状況です。

MDMの必要性

ビジネスには様々なシステムが必要です。それらのシステムが情報をコミニケーションする上で統一のマスタ（特に商品マスタ）の定義は非常に重要です。

なぜ重要か? わかりやすい例でいうと、人がグローバルでコミニケーションをとる場合、共通言語もしくは、いちいち翻訳が必要です。みんなで英語を使った方がコミニケーションコストはガクッと下がります。

システムも同様です。

社内の各システムがなんらかの共通言語でコミニケーションが必要です。このコミニケーションするためのマスタを定義するのがMDMプロジェクトの一部です。

ビジネス視点でMDMがもたらす効果

分かり易い順で解説します。

・マスタ管理工数が削減できる
・将来のシステム導入コストが削減できる
・正になるマスターを一元管理できる
・正確なレポーティングが作成可能になる

さらに、解説すると実際には
・野良マスタ管理システムを駆逐できる
・ブラックボックス化（マスタ職人の退職リスク）をリスク回避できる
・ITプラットフォームの足固めできる
・お客様へ提供する情報品質の改善につあがりブランド力・信頼度向上につながる

上げればきりがないのですが、ROIに結び付けにくいのも事実です。おすすめは、マスタ管理の工数削減や野良システムの駆逐でROIを算出しつつ、リスク回避＋未来への投資への足かせでストーリーを固める必要があります。

MDMを導入したけど結局マスタ管理が様々な場所で行われていたり、マスタ管理プロセスまで標準化を狙わないと、目的の見えずらいプロジェクトなのでとん挫するリスクが高いです。

↑わたしは、この点に関してプロジェクト開始前に相当リサーチして気づき打ち手をうったのが功を奏した気がします。

導入を推進したMDMプロジェクト概要

私の推進したMDMプロジェクト概要です。

機密情報もあるので、以下の情報からプロジェクト規模や難易度を推測ください。
・グローバル企業
・商品点数：とんでもなく多い
・IT組織：100名以上
・従業員数：1万人以上
・導入前は、データガバナンスの組織不在

MDM導入の10ステップと勘所

早速、私のMDM導入経験からまとめた１０の重要なステップと勘所を共有していきます。

ステップ1　MDMのスポンサーの明確化

CIOがMDMは上手くいかないといった背景には、MDMのスポンサーが不明確になりやすい点が大きな要素と感じます。

受発注・倉庫業務とは違い、マスタの品質精度の向上が業務的メリットに直結しずらく、誰もボールを持ちたがらない背景があります。

私のプロジェクトの場合、組織のほぼトップがマスタ管理の重要性・正しいマスタを持つ必要性を説き関係者を巻き込めたことが大きな勝因です。幸いでした。

このようなケースはレアかなと思います。一般的には、かなりの権限のあるスポンサーが見つからない場合MDM導入の旅は相当苦しくなります。

いずれにせよ、スポンサーを含めその他関係者の理解を深めるために、MDMの社内教養を深める機会を増やすのはプロジェクト立ち上げに向けおすすめです。私も相当丁寧に実施しました。この活動の中で、ステップ3の要素を盛り込み半洗脳していきました。

ステップ2　MDMの活動で解決する課題の明確化

スポンサーが権限があるのは重要な要素です。しかし、何りよも大事なのは中身てす。中身の無い企画は遅かれ早かれ関係者の気持ちは離れていきます。

MDMで何の課題を解決するのか？明確な戦略・効果の狙いの明文化が必要です。

私の担当したプロジェクトでは、
・社内のマスタ管理業務工数
・WEBに公開するマスタ品質の欠落によるブランド力の棄損
等でした。

マスタはどの業務にも直接的には関連しないですが、どの業務にも間接的に関連するため自社の課題の分析とストリーで関係者をつむぎ巻き込む必要があります。

ストーリーが出来たらオーナーから落としてもらうのがおすすめです。

ステップ3　MDMの定義の明確化 自社にとってのMDM（マスターデータ管理）とは？

スポンサー・意義＆目的がクリアになってもまだまだプロジェクト開始前にやるべきことがあります。この活動はプロジェクトのスコーピングと密接に関係する重要な活動になります。

その活動は「マスターデータ」とは？の定義が必要だからです。

以下は、実際にプロジェクト初期のマスターデータの各人の捉え方のサンプルです。

MDM開始初期は大体こんな状態で認識齟齬があります。

この社内コンセンサスがない状態では、会議をするたびに、そもそも論を持ち出され一向に進みません。

私の担当したプロジェクトでは、初めに自社にとってMDMとは？なぜMDMの活動が必要か？を宣教する活動から開始しました。

参考ですが、私の会社のMDMは、全社共通の正のマスターデータの格納場所でした。これにより、データレイクとの役割の違い、点在するローカルシステムのマスターのスコープアウトが出来ました。

ステップ4　システム・事業体制の明確化

ここまでの前提を決めることができれば、プロジェクト立ち上げは一般的なシステム開発プロジェクトと同様です。この「MDMも一般的なシステム開発プロジェクト同様」の部分が重要です。

MDMのプロジェクトを「データを統合するITインフラのプロジェクト」と捉え推進してしまうと、事業・業務を上手く巻き込めず失敗に終わります。

実際、私がMDMを推進する前にも同じようなMDMプロジェクトは存在しほぼ空中分解した状態でした。MDMのプロジェクトも、ビジネス・業務を巻き込み、ビジネス・業務・ITの視点で推進が必要です。

ここまでくれば個人的に8割成功に近づいている気がします。

ステップ5　プロジェクト立ち上げ

ステップ４まで完了すれば、プロジェクトの立ち上げフェーズです。MDMの特徴として関係者が多くなる傾向があります。理由は、これまでサイロ化していたシステム+マスタなのでどの事業・業務にも関連するからです。体制図・役割の定義が非常に大事です。

おそらく、MDM導入前はマスタ管理部門もないと思うので、このあたりからプロジェクト→組織立ち上げも意識しつつ人選が必要です。

ステップ6　マスタ標準化の推進

自社としてのマスタの定義が共通化・標準化できればITとしてはその決められた条件でシステム構築しデータを格納し、必要情報を連携するだけです。

この標準化はなかなか決まりませんでした。商品マスタをグローバルでシステム横ぐしで管理するキーの採番ルールがなかなか決まらなかったです。たたき台を作りビジネスPMにプレゼンだけしてもらい推進しました（事業がボールをもつべきなので）。

結果、最大の難所を時間をかけずに進めることができました。MDMのプロジェクトやDXのプロジェクトではITが相当乗り出してプロジェクトを推進するケースがかなりあります。

ステップ7　マスタ管理業務導入の推進

マスタの標準化と並行して、マスタ管理業務プロセスの構築が必要です。それまで自社でサイロ化した業務に対して横ぐしのプラットフォームができるわけなので、最大限に効率化しマスタ品質を担保できる業務設計も必要です。

ここでのアドバイスとしては、どこまでコンプラの要素を取り入れるかです。大体、ここらへんでコンプラ要件がやってきてプロジェクトが混とんとします、笑。

ですが、プロジェクトの目的が明確化されていれば、その目的に沿って今それをやるべきか？それとも、次のフェーズで対応すべきか検討し判断できます。コンプラの問題対応も行うべきですが、どこまでやるのか正直線引きは非常に難しいです。コンプラの要素を盛り込むと対応項目が増え構築難易度は上がります。(1番は関係者が増えることが最大の難点ですが、、、)。コンプラ系の話題の場合、自社でリスクをどこまで取るか判断しだいかなと思います。

ITの視点のポイントは、このコンプラ関連のリスクが顕在化したら必ずオーナーに報告すべきです。時としてコンプラ問題は全社に相当なインパクトを与える可能性があります。一個人の判断で進めてしまうのは危険です。エスカレ・相談の結果プロジェクトを遅らせる判断が下されたならそれは、企業が具備すべきコンプラ要件を問題が発生する前に対応できてよかった！くらいの感じでとらえましょう。遅延はあまり気にすべきではありません。（ベストは最初から巻き込み、要件FIXさせることですが、、、）

ステップ8　システム障害との奮闘

モノづくりフェーズでの課題は他システム同様バグとの戦いです。今は少ないかもしれませんが、わたしがMDMを導入したころはそもそもMDMのパッケージ自体が世に出回ったばかりの段階でどの製品も成熟していない感じで製品バグも沢山あり苦労しました。

ITの人はパッケージ製品群の商品ライフサイクルとバグの関係を理解しておくとITレベルが上がる気がします。やはり、どんな製品でも市場に出回った初期は欠陥が多く、アーリーアダプターは苦労します。。。苦労する反面、他社に先駆けシステム等を導入できれば競合優位性の構築が可能です。天秤にかけビジネスジャッジが必要です。

MDMの障害の特徴としてマスタのコンテンツの問題が多々発生します。以前のサイロ化したマスタ管理では、ある項目がなくてもOKだったけど、新しい仕組み・ルールではある項目がないとNGだったり、このマスター設定は発生しない状態とかあります（ほんとに良くあります）。ITとしては、なるべく事前にマスタ品質をあるべき姿に持っていけるように、データ分析＋入念なデータ移行＋マスタ修正依頼を丁寧に計画すべきです。

ステップ9　マスタ管理プロジェクトから組織へ

上段で解説しましたが、MDMのプロジェクトはいずれ組織化をしました。組織化と言ってもマスタ自体のオーナーはビジネスになるので、ピンとこないかもしれません。補足すると、データをガバナンスする組織を立ち上げ自社として備えるべき情報・あるべき情報品質を統制・管理する組織です。このプロジェクトから組織化まで持っていけないと、いつまでも本業のある業務・ビジネスユーザーが片手間でマスタ統制をしたり、ITも運用に渡すことができず疲弊していきます。

ステップ10　効果検証

最後に大事な事が効果検証です。MDMはインフラ構築ではなく、ビジネス・業務施策としてやるべきですと定義しました。その効果が刈り取れているのか？違いがあれば改善すべき点はなんなのか？確認が必要です。

MDM(マスターデータ管理）とは？目的・メリット・進め方｜経験談まとめ

MDM導入の勘所を10のステップにまとめご紹介しました。序盤のステップが成功するMDMプロジェクトの肝です。どの部署にも関連のあるマスターで、ビジネスメリットも明確化しにくいやっかいな代物ではありますが、裏返すとどの部署にも関連がありビジネス全体にじわじわと効果が派生するのがマスターデータマネージメントです。

ぜひ、本記事の内容を参考に幸せになれるMDMプロジェクトを推進ください。