業務システムでは、拠点・担当者・カテゴリ・料金・権限などのマスタが後から何度も変更されます。
拠点名の変更、担当者の異動、カテゴリの統廃合、料金改定。ひとつずつは小さな修正に見えても、検索・集計・通知・権限・外部連携まで関係していると、想定外の不具合につながります。
本記事では、マスタを「一度登録したら終わり」ではなく「運用中に変わり続けるもの」として扱い、影響範囲と履歴をどう設計しておくかを解説します。
マスタ設計で最初に押さえたいのは、内部で使うIDと、画面に表示する名称を分けることです。
たとえば「東京営業所」という拠点名を、そのまま検索条件・通知条件・外部連携のキーにしていると、名称が「東京支店」に変わっただけで関連処理に影響が出ます。画面上の表示名は変わっても、内部IDは変えない。これがマスタ運用の基本です。
拠点検索のような領域では、表示名変更が検索結果やURLにどう影響するかも確認しておく必要があります。拠点の検索軸や運用ルールは、拠点検索設計 の考え方とも関係します。
拠点マスタ変更のイメージ
画面の名称は変えても、内部IDを固定しておけば、過去データや連携先との関係を保ちやすくなります。
office_id: 003
表示名：東京営業所
通知先：tokyo-sales@example.jp
集計区分：関東エリア
office_id: 003
表示名：東京支店
通知先：tokyo-branch@example.jp
集計区分：関東エリア
このように、IDを固定しておけば「東京営業所時代のデータ」と「東京支店になった後のデータ」を同じ拠点として扱えます。逆に、名称をキーにしてしまうと、単なる名称変更なのか、別拠点への移行なのかが後から判断しづらくなります。
使わなくなったマスタをすぐ削除すると、過去の注文、問い合わせ、作業記録、請求、通知履歴などが参照できなくなることがあります。業務システムでは、物理削除よりも「無効化」を基本にした方が安全です。
たとえば、古いカテゴリを無効化した場合でも、過去の案件画面では当時のカテゴリ名を表示できる必要があります。一方、新規登録画面ではそのカテゴリを選べないようにします。この切り分けがないと、過去データの確認と現在の入力ルールが混ざります。
削除や復旧の考え方は、復旧設計 とも近い領域です。マスタ変更後に問題が分かったとき、どこまで戻せるかを事前に決めておくと、現場側の確認も短く済みます。
マスタ更新で問題になりやすいのは、変更作業そのものではありません。変更した後に、どこへ影響するかが見えていないことです。
特に、次の5つは事前に確認しておきたい領域です。
検索まわりでは、マスタ変更後にユーザーが旧名称で検索するケースもあります。検索ログを見ながら同義語や候補表示を調整する考え方は、検索ログ の設計ともつながります。
通知では、担当者の異動や退職が関係します。担当者名の差し込みや宛先条件は、通知テンプレ 側だけでなく、担当者割当 のルールとも合わせて確認する必要があります。
権限については、拠点名や部署名の変更が閲覧範囲に影響する場合があります。拠点単位で画面やデータを分けている場合は、権限設計 の前提と矛盾しないかを見ておきます。
マスタ変更前チェック画面のイメージ
実装では、変更前に影響先を一覧表示して、担当者が確認できる画面を用意すると運用しやすくなります。
| 確認項目 | 影響例 | 状態 |
|---|---|---|
| 検索 | 旧名称で検索された場合に候補表示するか | 要確認 |
| 集計 | 過去分も新カテゴリに含めるか、旧カテゴリのまま残すか | 要確認 |
| 通知 | 担当者変更後の通知先、未割当時の扱い | 未設定 |
| 権限 | 拠点変更後の閲覧範囲、管理者権限 | 確認済み |
| 外部連携 | CSV出力コード、API連携先のマスタID | 確認済み |
こうした確認画面があると、マスタ担当者だけで判断せず、関連部署や運用担当に確認を回しやすくなります。変更前の確認事項を画面に出すだけでも、見落としはかなり減らせます。
カテゴリは、運用が進むほど増えやすいマスタです。最初は細かく分けたものの、実際には使われないカテゴリが出てきたり、逆に新しい業務区分が必要になったりします。
ここで重要なのは、カテゴリ名を変えるだけで済ませないことです。カテゴリを統合する場合、過去の集計をどう扱うかを決めておかないと、月次レポートや前年比較の数字が途中から変わります。
どちらが正解という話ではなく、業務上どちらを優先するかの判断です。現在の管理を分かりやすくしたいのか、過去レポートとの比較を重視するのかで、選ぶべき設計が変わります。
検索UIが関係する場合は、カテゴリ構造だけでなく、選択肢の見せ方も同時に確認します。カテゴリの考え方は カテゴリテンプレ、絞り込み画面の作り方は 絞り込みUI とあわせて見ると判断しやすくなります。
マスタ運用を最初から大きく作り込む必要はありません。まずは、変更履歴と監査ログを残すところから始めるだけでも、後から原因を確認しやすくなります。
最低限、次の情報は残しておきたいところです。
変更履歴の表示イメージ
マスタの変更内容を後から確認できるようにしておくと、問い合わせや不具合調査の初動が速くなります。
監査ログの基本的な考え方は、監査ログ と同じです。マスタ変更は、画面上では地味に見えますが、影響先が広い場合があります。だからこそ、変更内容を説明できる状態にしておくことが重要です。
小さく始めるなら、次の順番が現実的です。
最初から完璧な管理画面を作るよりも、変更時に困りやすい部分から順番に固めていく方が、現場に定着しやすくなります。
製造業では、品目、型番、仕様、工程、取引先、検査区分など、多くのマスタが関係します。仕様項目が増えたり、カテゴリが再編されたりすると、検索、CSV出力、帳票、集計に影響します。
業務全体の考え方は 製造業向け を前提に、仕様項目の増減は 仕様項目設計、一括更新は CSVインポート とセットで考えると、運用後の変更にも対応しやすくなります。
自動車販売・整備・タイヤショップでは、店舗、作業メニュー、車種区分、予約枠、設備、担当者などのマスタ変更が発生しやすい領域です。
たとえば、作業メニュー名を変えたときに、予約画面、管理画面、通知メール、売上集計まで同じ意味で扱えるか。店舗名を変えたときに、過去予約や顧客通知に影響しないか。こうした確認が必要になります。
業務像は 自動車販売・整備・タイヤショップ向け を前提に、ID、無効化、履歴、通知先、集計区分をまとめて設計しておくと、繁忙期の変更対応もしやすくなります。
マスタは、登録して終わりではありません。拠点名、担当者、カテゴリ、料金、権限などは、運用の中で必ず変わります。
そのため、内部IDと表示名を分けること、削除ではなく無効化を基本にすること、検索・集計・通知・権限・外部連携への影響を確認することが重要です。カテゴリ統廃合では、過去集計をどう扱うかも先に決めておく必要があります。
まずは、変更履歴と監査ログを残すところからで十分です。誰が、いつ、何を、どう変えたのかが分かるだけでも、原因確認や復旧の判断はかなりしやすくなります。マスタ運用を後回しにせず、変更される前提で設計しておくことが、業務システムを長く使うための土台になります。