マスタ運用の設計｜拠点・担当・カテゴリ変更で現場が壊れない「影響範囲」と履歴

業務システムは、マスタが更新され続ける前提で設計しないと、運用で壊れます。
拠点名が変わる、担当者が異動する、カテゴリが統廃合される、料金が改定される――このとき、検索・集計・通知・権限が連鎖的に崩れるケースが多いです。
本記事では「変更される前提」でマスタを運用するために、影響範囲と履歴の持ち方を整理します。

1. 原則：IDは変えない。名称は変わる（だから分離する）

「表示名」をキーにすると、名称変更で全部壊れます。
拠点・担当・カテゴリは、内部はIDで持ち、表示は名称で持つのが基本です。
拠点検索のような領域は 拠点検索設計 の考え方（検索軸と運用）に揃え、表示名変更が検索結果やURLに与える影響を整理しておくと安全です。

2. 無効化（廃止）を基本にする：削除は最後の手段

マスタを物理削除すると、過去データの参照が壊れます。基本は無効化です。

• 無効化：新規では選べないが、過去データでは参照できる
• 置換（移行）：旧カテゴリ→新カテゴリへ寄せる（履歴を残す）

削除や復元の考え方は 復旧設計 と同型です。「戻せる」ことが運用安定に直結します。

3. 影響範囲チェック：マスタ変更は“5つの連鎖”が起きる

マスタ変更は、次の領域に連鎖します。ここを洗い出しておくと事故が減ります。

• 検索：フィルタ、同義語、ゼロヒット（検索ログ）
• 集計：カテゴリ別集計、拠点別集計（過去比較がズレる）
• 通知：担当者名差し込み、宛先ルール（通知テンプレ）
• 権限：拠点権限、閲覧範囲（権限設計）
• 外部連携：API/CSV/Webhook（IDが変わると破綻）

たとえば担当者が異動しただけなのに、通知が空欄になる・割当が変になる事故はよくあります。割当ロジックは 担当者割当 の前提に揃え、未割当時の扱いも合わせて定義すると壊れにくいです。

4. カテゴリ統廃合：集計の“連続性”を守るために履歴を持つ

カテゴリは、作って終わりではなく統廃合されます。統廃合時に重要なのは「過去との比較」をどう保つかです。
次の2案のどちらかを選びます。

• 案A：過去も含めて新カテゴリに寄せる（過去集計が変わることを許容）
• 案B：過去は旧カテゴリのまま残し、集計レイヤーで束ねる（連続性を守る）

検索UIが絡む場合は、カテゴリ構造（カテゴリテンプレ）とフィルタUI（絞り込みUI）をセットで見直さないと、ユーザーが迷子になります。

5. 監査ログ：マスタは“静かな爆弾”なので変更履歴が必須

マスタは、変更が地味な割に影響が大きいです。最低限、次の履歴を残します。

• 誰が（操作者）
• いつ（時刻）
• 何を（対象ID）
• どう変えたか（差分）
• 理由（任意でもよいが、あると強い）

監査性の型は 監査ログ と同じです。マスタ変更が原因の不具合は「気づきにくい」ので、説明できる形を優先してください。

業種別にマスタ運用が刺さる場面（例）

製造業（品目・仕様・カテゴリ）

品目や仕様の属性が増えやすく、カテゴリ再編が起きやすいです。業務像は 製造業向け を前提に、仕様項目（仕様項目設計）の追加とCSV更新（CSVインポート）をセットで設計すると運用が楽になります。

自動車販売・整備・タイヤショップ（拠点・メニュー・作業枠）

拠点、作業メニュー、設備の追加・変更が頻繁に起きます。業務像は 自動車販売・整備・タイヤショップ向け を前提に、表示名変更で予約や通知が壊れないよう、ID運用と履歴を徹底すると事故が減ります。

まとめ

マスタは変わる前提で設計すると、運用で壊れにくくなります。
IDと名称を分離し、削除ではなく無効化を基本にし、影響範囲（検索/集計/通知/権限/連携）を事前に潰す。
履歴と監査ログを残して「戻せる」運用に寄せる。これが、マスタ運用を武器にする最短ルートです。