マスターデータ管理は誰が担う？ 訂正と利用の責任を決める

顧客名や商品名が部門ごとに違う。「一つのデータベースに集めれば解決する」と考えたくなる。しかし入力の責任者が決まっていなければ、同じ箱へ違う意味の情報が集まるだけかもしれない。反対に、部門へすべて任せれば、全社で顧客を数えるたびに照合が必要になる。

ここで選ぶべきは、すべてを中央へ移すか、すべてを分散するかという構図だけではない。どの情報の正しさを誰が引き受け、どの共通定義をそろえ、利用者へどの状態を届けるかである。本稿は顧客・商品などのマスターデータを例に、保存場所と管理責任を分けて考える。

一カ所へ置けば、同じ意味になるわけではない

英国政府の2026年のデータ所有モデルは、データの価値・品質・利用・共有を引き受ける所有者と、情報資産の保護や管理に関わる役割を区別する。共有データの条件や権威ある情報源を定める責任も扱う。英国行政の指針であり、日本の企業のために最適な組織図を実験で決めた文書ではない。英国政府「Data ownership model」

この区別から読み取れるのは、データベースを運用する人と、顧客の定義を決める人が常に同一とは限らないことだ。情報システム部門は保存やアクセスを整えられる。だが、休眠顧客を数える条件や、親会社と子会社を一件と扱うかは、業務の決定である。

中央化の対象を決める前に、「この値を誰が作り、誰が直し、違う部門から異議が出たら誰が決めるか」を書き出したい。全社共通の意味が必要な項目と、部門固有の意味を保つ項目が混ざっていないかを見る。

たとえば請求先の名称は契約・会計で同じものを参照したいかもしれない。一方、営業部門の見込み度と、保守部門の対応優先度を一つの「顧客ランク」に押し込む理由はない。言葉が同じでも目的が違えば、共通化する範囲を絞る。

業務側が所有する方式にも、共通の約束が要る

AWSが説明するデータメッシュは、各業務領域へデータの所有と提供の責任を持たせ、共通の基盤や標準を組み合わせる考え方である。中央の担当だけで多様な情報を解釈・整備する際の負担に触れる一方、分散した管理には新たな複雑さもある。製品の設計説明であり、分散すれば全社のデータ品質が必ず上がるという比較実験ではない。AWS「What is a Data Mesh?」

データを現場の近くで管理する利点は、意味を知る人が更新できることだ。ただし、各部門が「顧客番号」を別の対象に付ければ、利用者は横断比較ができない。共通で必要な識別子、変更の通知、公開する項目の意味は決める必要がある。

逆に中央チームを置くなら、そのチームに業務判断まで集中させない。異なる部門から出る変更依頼へ誰が答えるか、中央のルールを現場の例外へどう適用するかを決める。単一の保管場所と単一の判断者は同義ではない。

「最新」が必要な仕事と、後で合わせればよい仕事

顧客の住所が変わったとき、請求書を出す直前のシステムと、週次の経営集計では求める更新の速さが違う。どこで正を決めるかに加え、利用者へ変更がいつ伝わるかを明示する必要がある。

ある部署の画面で訂正できても、その訂正が請求に反映されるまで数日かかるなら、請求先の選択には別の確認が要る。一方、前年の顧客動向を分析する仕事では、毎秒の同期より、集計時点と定義の一致が重要かもしれない。全ての利用を同じ同期方式で設計しない。

編集上の提案は、重要な項目ごとに、更新できる担当、正を確認する場所、変更が届くタイミング、食い違いを直す経路を定めることだ。これらを決めずに「一元化完了」と宣言しても、利用時の照合作業は残る。

システムを複数持つなら、相互の複写や加工でどの意味が変わったか追えるようにする。中央へ集める場合も、元のデータが間違っていた時に誰へ戻すかを失わない。後から訂正できる仕組みがなければ、どちらの設計でも同じ誤りを拡散する。

顧客台帳の仮想例で、責任の置き方を変える

架空の企業で、会計と契約部門が同じ法人を異なる名称で登録し、請求の宛先を誤るとする。法人識別と請求先情報について共通の定義と責任者を置き、訂正を両方へ反映する案を選ぶ。一つの場所で確定する価値が高いからだ。

条件を変え、営業の「重要顧客」と保守の「緊急対応顧客」が一致しないことを問題視しているとする。二つは目的が違うため、中央の一つのランクへ統合する案は適切でない。名称と用途を分け、必要なときだけ対応関係を示す。違いを消すことより、違う意味を誤用しないことが重要だ。

さらに商品情報を現場の専門家しか直せず、中央の依頼窓口が混み合っているなら、領域の担当に更新権限を持たせ、全社で使う識別子や公開条件を共通化する案へ変える。担当を分けても標準を放棄するわけではない。

これらは仮想例で、英国政府やAWSがこの企業の構成を検証したわけではない。選択を変える条件は、データがどの業務で同じ意味を持つ必要があるか、誤りを直せる人がどこにいるかである。

住所を直す例では、使う業務によって反映期限も変わります。配送には当日の住所が必要でも、締め済みの請求記録には取引時点の住所を残す必要があります。現在値の配信と履歴の保存を分けてから責任を決めれば、すべてを最新値で上書きする問題を避けられます。

中央にも、分散にも新しい待ちが生まれる

中央に一つの窓口を置いた場合、部門の担当が誤りを見つけても、修正の承認待ちが長ければ間違った値を使う時間が続く。分散方式なら部門の修正は速くても、別部門へ届くまで古い値が残るかもしれない。問題は置き場の数だけでなく、訂正が到達する道とその所要時間にある。

AWSも分散した所有には構成上の複雑さが増えると説明する。これは分散を否定する証拠ではない。業務部門がデータの意味を引き受ける利点と、共有・アクセス・標準の仕事を新たに担う費用を比べる必要があるということだ。複数のチームが責任を持つなら、境界で落ちる更新を発見できる手段も用意したい。

たとえば契約先の住所を変えた後に会計へ伝わらないなら、データ所有者は正しい値を持っていても、請求の失敗を防げない。利用者側の必要な時点までに変更を届けられるかを確認する。中央保管でも分散保管でも、更新通知と照合の設計が弱ければ同じ失敗が起きる。

全社の「正」の値を一つに定めても、時点の違いが残る。月末締め時点の顧客名と今日の顧客名は、両方正しい場合がある。過去の取引を訂正すべきか、現在の連絡先だけ変えるべきかを同じ上書き操作にしない。必要な履歴を持てる設計かどうかも、共通の場所を選ぶ前に確認する。

また、共有を増やせば情報の取扱いも広がる。部門別管理では必要な人だけが見ていた項目を全社共通へ出す場合、利用目的と閲覧範囲を明確にしたい。分散案でも、横断利用のために複写するなら、複写先の管理者を決める。集約と分散はどちらも権限の設計を伴う。

この設計を決める会議には、同じ項目を使う側だけでなく、誤りを直す側も招く。入力者が訂正できない共通台帳は、責任の所在を一つにしたように見えて、修正待ちを全社に広げる。逆に各部門で修正できても、下流へ通知できなければ食い違いは残る。どちらの案でも、訂正の申請から利用先への反映まで一件を追跡できるかを確かめる。

保存場所の数ではなく、訂正の到達を見る

評価には、重複件数だけでなく、訂正が必要な場所へ届くまでの時間、食い違いを解消できた件数、利用者が誤った定義を選ばずに済んだかを見る。ただし数値を一つへまとめ、低いほど必ずよいと決めない。現場が訂正を報告しやすくなれば、最初は食い違いの発見数が増えることもある。

中央にする場合は共通定義を決める人と現場の修正窓口を置く。分散する場合は領域ごとの責任者と共通の識別・共有条件を置く。どちらも欠けていれば設計図の見た目だけが変わる。マスター管理の結論は、置き場の一本化ではなく、正しさを引き受ける人と訂正が届く道を決めることである。