マスタ運用と名寄せ設計｜コード体系・更新ルール・重複マージでデータを崩さない

業務システムは、機能より先に「データが崩れる」と止まります。とくにマスタ（顧客、商品、拠点、タグ、カテゴリ）周りは、運用を決めずに走り出すと、表記ゆれ・二重登録・更新漏れが増えます。 本記事では、マスタ運用の設計と、重複データを事故らせない考え方を整理します。

マスタ運用が崩れる典型パターン

• 入力者ごとに表記が違う（株式会社/（株）、全角半角、スペース）
• 同じ顧客・同じ品目が複数できる（検索で見つからない）
• 更新権限が強すぎて、勝手に書き換わる
• 逆に権限が弱すぎて、誰も直せない

マスタ更新の運用設計（まず決めること）

1. 更新窓口を決める

• 更新できる人を絞る（担当＋管理者）
• 更新依頼の導線を用意する（フォーム／コメント／差し戻し）

2. 更新の理由を残す

• 「なぜ変更したか」がないと、数ヶ月後に戻せなくなります
• 変更履歴（簡易でOK）を残すだけで、揉め事が減ります

3. 更新頻度を決める

• 毎回リアルタイム更新が必要か、週次の棚卸しで足りるか
• 頻度が決まると、承認や監査ログの要件も整理しやすくなります

コード体系（ID/カテゴリ/タグ）の作り方

コードは「人間が読める」ことより、「揺れない」ことが重要です。運用で増える前提でルールを作ります。

• カテゴリは階層を深くしすぎない（迷った瞬間に入力が止まる）
• タグは自由に増やすのではなく、候補制（乱立を防ぐ）
• コードは意味を持たせすぎない（後で変更が難しくなる）

重複データの対策：作らない／見つける／統合する

作らない（入口対策）

• 入力補助（住所・社名のサジェスト、郵便番号）
• 登録前の重複警告（似た名称・電話番号一致など）

見つける（検知）

• 同一電話番号、同一メール、住所一致の候補一覧
• 「0件検索」や検索ログから、探しにくい表記を拾う

統合する（マージ）

統合は怖いので、手順を固定します。現実的には次の3ステップが安全です。

• 統合元・統合先（正）を決める
• 紐づくデータ（問い合わせ、予約、請求など）を先に一覧化する
• 統合を実行し、監査ログに残す（戻せるようにする）

最小構成で始めるなら

• マスタ更新は「担当＋管理者」だけ
• カテゴリは少なく、タグは候補制
• 重複警告だけ先に入れる（完全自動マージは後回し）

まとめ

マスタ運用は、凝った機能より「決め事」で安定します。更新窓口、コード体系、重複の扱いを先に固めると、システム全体の手戻りが減ります。