顧客・商品・取引先、どのマスタから整えるか——いま起きている症状から逆引きする

同じ取引先に、同じ見積書を二度送ってしまった。受注の伝票をシステムに登録しようとしたら、該当する商品コードが見つからずエラーになった。同じ会社なのに部署ごとに別の取引先コードで登録されていて、その会社との取引量を合計で把握できていなかった。どれも担当者の不注意に見えますが、引き金になっているマスタはそれぞれ違います。1つ目は顧客マスタ、2つ目は商品マスタ、3つ目は取引先マスタです。顧客・商品・取引先の3つとも手を入れたいが、人も時間も限られるので同時には進められない——という状況で、どれを先に選ぶかを決める材料が本記事です。いま出ている症状からの逆引き、業種ごとの傾向、そして参照関係を踏まえた順番の3つで整理します。マスタデータとは何か、なぜ品質問題が集まるのかという前提はマスタデータとは何か？顧客・商品・取引先マスタが「品質問題の震源地」になる理由で扱っているため、本記事は「どれから手をつけるか」から始めます。

3大マスタの特徴比較

まず3つのマスタの基本的な特徴と、それぞれが影響する業務領域、よくある品質問題を整理します。

顧客マスタでは重複登録や連絡先の陳腐化、商品マスタでは属性の欠損やコード体系の不統一、取引先マスタでは社名・取引条件・支払先情報の不整合が、品質上の課題として挙がりやすい傾向があります。ただしどの問題がどれだけ起きるかは、業務プロセスとシステム構成、運用ルールによって変わります。自社で実際に何が起きているかを先に確かめてください。

業種別の整備優先順位

どのマスタが候補になりやすいかには業種ごとの傾向があります。ただしこれは決まった順位ではありません。製造業でも仕入先の誤登録で調達と支払に支障が出ているなら取引先マスタが先ですし、金融でも顧客マスタ以外が最優先になることはあります。あくまで検討の出発点として見てください。

症状から整備すべきマスタを特定する

「どのマスタから整備すればよいかわからない」という場合は、現在発生している業務上の症状から逆引きする方法が有効です。

参照関係があるときは、参照される側から直す

症状と業種で候補を絞ったあと、もう一つ見ておきたいのがマスタ同士の参照関係です。顧客マスタや商品マスタが取引先マスタのコードを持っている構成では、取引先コードを変えると参照している側にも影響が及びます。

ただし「必ず参照される側から直す」とは限りません。コードはそのままで属性だけを直せる場合もありますし、参照元と参照先をまとめて移行・変換したほうが早い場合もあります。決めるべきは順番そのものではなく、コードを変える必要があるのか、変えるなら影響がどこまで及ぶのか、どの移行方式を採るのかです。図の参照の向きもシステム構成によって変わるため、自社の構成を先に確認してください。参照関係がなく独立しているなら、この観点は不要で、症状と業種だけで決めて構いません。

3大マスタの整備を阻む組織的課題

マスタデータの整備が進まない理由の多くは技術的な難しさではなく、組織的な課題にあります。よくある障壁とその対処を整理します。

• オーナーシップの不明確さ：顧客マスタを「誰が管理するのか」が曖昧なまま放置されているケースが多いです。営業・経理・IT部門がそれぞれ「他の部門が管理すべき」と考え、誰も主体的に整備しない状態になります。データオーナーを明示的に設置し、責任範囲を明文化することが第一歩です
• 「今が正しい値かわからない」という判断困難さ：顧客マスタの住所・担当者名が最新かどうかを確認できる情報源がないと、整備作業が進みません。各マスタの「確認方法（どのシステム・誰に確認すれば最新値が分かるか）」を明確にすることが必要です
• 整備作業のコストと緊急性の認識ギャップ：「マスタが汚くても今の業務は回っている」という認識があると、整備への投資が後回しになります。マスタの問題が実際に引き起こしているコスト（重複送付・手作業確認・BI不整合の修正工数）を定量化して可視化することで、整備の優先度が上がります
• 過去のシステム移行での「とりあえず移行」の蓄積：旧システムから新システムへの移行時に、問題のあるデータをクレンジングせずに移行するケースが多い。「移行さえすれば後で直せばよい」という先送りが繰り返されることで、問題が蓄積・複雑化します

マスタ整備プロジェクトの進め方

マスタデータの整備を「プロジェクト」として進める際の標準的な進め方を紹介します。担当者の自助努力ではなく、組織的な取り組みとして推進することが整備の成否を分けます。

• フェーズ1（現状把握）：対象マスタのデータプロファイリング（件数・重複率・NULL率・コード体系の現状）を実施し、問題の全体像を数値で把握します。問題の規模感が見えることで、プロジェクト計画の精度が上がります
• フェーズ2（クレンジング基準の策定）：「重複をどう統合するか」「廃番の扱いはどうするか」「欠損値はどう補完するか」のルールを業務部門と合意します。このルール策定が最も時間がかかるフェーズですが、ルールなしに作業を進めると後で全部やり直しになります
• フェーズ3（クレンジングの実施）：策定したルールに基づいてデータをクレンジングします。大量データには自動化スクリプトを活用し、例外ケースは手作業で対処します。クレンジング前のデータは必ずバックアップします
• フェーズ4（ガバナンス体制の整備）：整備完了後のデータを維持するための変更管理フローを整備します。新規登録・変更・廃番のプロセスと承認フロー、定期的なデータ品質モニタリングの仕組みを作ります

あわせて、整備の前後で同じ測り方をする指標を決めておいてください。重複の候補として挙がった件数の割合、必須項目の欠損率、コード体系のルールに合わない件数、マスタが原因で発生した手作業の修正・照合にかけた時間、登録や変更のときにルール違反が起きた件数などです。

1点だけ注意があります。重複の「候補」として自動抽出された件数と、実際に重複だった件数は別のものです。名寄せツールが挙げた候補をそのまま重複件数として報告すると、整備後の改善幅を実態より大きく見せてしまいます。候補のうち何件が本当に重複だったかを人が確認した数で比べてください。

整備後の維持管理：変更管理フローの設計

一度整備したマスタデータも、適切な変更管理がなければ時間とともに再び劣化します。整備完了後の品質を維持するための変更管理フローの設計が重要です。

• 新規登録ルールの設計：新しい顧客・商品・取引先を登録する際の手順・承認フロー・必須入力項目を定めます。特に重複登録の防止（登録前の既存データ検索を義務付ける等）が重要です
• 変更・廃番フローの設計：マスタの属性を変更する際の承認フロー・変更履歴の記録方法を定めます。廃番・使用中止にする際のルール（使用中止日・後継コードの設定等）も明文化します
• 定期的な品質チェック：月次または四半期ごとに重複率・NULL率・コード体系違反件数をモニタリングし、閾値を超えた場合はオーナーに是正を依頼します。「問題が見える仕組み」があることで、品質維持へのモチベーションが維持されます

マスタ整備を後回しにするコスト

マスタデータの整備は「すぐに成果が見えない投資」に見えるため、後回しにされがちです。放置したときのコストは見えにくいだけで、重複を確認して直す手作業の時間、BIの数値が合わないときの調査と修正、ERP移行時にまとめてクレンジングする費用として後から出てきます。これらは実際に計測できます。該当する作業に月何時間かけているか、直近の移行でクレンジングにいくらかかったかを集めれば、整備した場合の費用と並べて比較できます。ただし放置すれば必ず費用が増えると言い切れるものではないので、自社で測った数字で示してください。

BFTのアプローチ

BFT Insightでは、顧客・商品・取引先の3マスタを対象とした品質診断を実施します。業務上の症状（重複送付・受注エラー・購買の二重発注等）と対象マスタの品質状態を照合し、整備の優先順位と具体的な改善計画を提案します。

まとめ

顧客・商品・取引先はそれぞれ特性が違い、影響する業務もよくある品質問題も異なります。どれから整えるかは、いま出ている症状から逆引きし、業種の傾向と参照関係で確かめるという順で決めてください。

選んだあとは、整備して終わりにしないことです。データオーナーを決め、新規登録・変更・廃番の承認フローと定期的な品質チェックを用意しておかないと、同じ状態に戻ります。3大マスタの診断・整備支援についてはBFT Insightにご相談ください。