業務システムでは、商品・料金・拠点・担当者などの「マスタ」が土台になります。 検索、見積、予約、請求、権限、通知など、多くの機能がマスタを参照して動くため、ここが曖昧だと画面だけをきれいに作っても運用で困る場面が出てきます。
よくあるのは、「商品名が部署ごとに違う」「料金改定がどの画面に反映されたか分からない」「拠点が増えたのに検索条件に出てこない」「退職した担当者が通知先に残っている」といった問題です。 これらは個別の画面不具合に見えて、実際にはマスタの責任分界、更新ルール、承認、履歴管理が決まっていないことが原因になっているケースが多くあります。
このページでは、商品・料金・拠点・担当者などのマスタを、長く運用しやすい形にするための設計ポイントを整理します。
マスタ運用で最も重要なのは、正しい情報の置き場所を決めることです。 商品マスタが基幹システム、ECサイト、営業用Excel、担当者の個人メモに分かれていると、どれを信じればよいか分からなくなります。
すべてをひとつのシステムに集約できれば理想的ですが、実際にはそうならないケースも多くあります。 その場合は、「この項目はどのシステムが正か」を項目単位で決める必要があります。
画面例 マスタ管理画面の基本構成
正情報：基幹システム ／ Web説明文：Web管理画面 ／ 最終承認：商品企画部
価格改定予定：2026/05/01 ／ 承認者：営業企画部 ／ 反映先：見積フォーム・カタログ検索
後継品：PX-2400 ／ 社外表示：在庫限り ／ 社内メモ：既存顧客のみ対応
型番・価格は基幹システム、Web説明文と公開状態はWeb管理画面で管理。
価格、公開状態、後継品、販売停止日は承認後に反映。
変更前・変更後・変更理由・承認者・反映日時を記録。
マスタ管理画面では、項目そのものだけでなく「誰が確認し、どこへ反映されるか」も見えるようにしておくと運用しやすくなります。
CSV/EDI/API連携が絡む場合は、CSV/EDI/API連携の設計 と同じく、どちらのシステムが更新元なのか、差分更新を誰が確認するのかを決めておく必要があります。
マスタ運用で曖昧になりやすいのが、「誰が直すのか」です。 商品名を直す人、価格を直す人、拠点情報を直す人、担当者情報を直す人が同じとは限りません。 責任者を決めないまま管理画面だけ用意すると、変更したいときに毎回確認が発生します。
責任分界 マスタごとの管理責任
商品企画・製品部門が管理。型番、商品名、カテゴリ、販売状態、後継品などを扱う。
営業企画・経理が管理。価格、割引、適用開始日、キャンペーン条件などを扱う。
管理部門・各部門責任者が管理。拠点名、所在地、担当者、通知先、権限を扱う。
責任者を決めるときは、編集者と承認者を分けるかどうかも確認します。 商品説明の修正は担当者が直接反映してよいが、価格変更は承認が必要、といった違いが出るためです。
マスタ更新では、単に編集できればよいわけではありません。 いつ誰が直し、誰が確認し、いつ反映され、過去の内容を確認できるか。 この4点を決めておかないと、後から原因確認が難しくなります。
料金や公開状態など影響が大きい項目は、編集者と承認者を分けた方が安全です。 権限の考え方は 権限設計の実務 と合わせて考えると整理しやすくなります。
特に料金マスタでは、適用開始日と終了日が重要です。 旧料金で契約済みの顧客と、新料金を適用する顧客を同時に扱う必要があるため、日付を持たない料金データは後で扱いにくくなります。
マスタは、履歴がないと信用されにくくなります。 変更前と変更後、変更者、承認者、変更理由、反映日時を残しておくと、後から問い合わせや請求の確認が必要になったときに説明できます。
流れ 料金マスタ変更の承認フロー例
新価格、適用開始日、対象商品を入力する。
見積フォーム、カタログ、CSV出力への反映先を確認する。
営業企画・経理など、責任者が内容を確認する。
指定日時から新しい料金を有効にする。
変更前後、理由、承認者、反映日時を記録する。
変更履歴の設計は、監査ログ設計 と近い考え方です。 マスタは多くの機能に影響するため、通常の操作ログよりも変更内容を詳しく残す価値があります。
BtoBでは、同じ商品マスタでも、社外に見せる情報と社内だけで確認する情報が混在します。 たとえば、社外には型番・仕様・資料ダウンロードを表示し、社内には原価、仕切り、代替品判断メモ、クレーム履歴を表示する、といった形です。
公開範囲 同じマスタを見せ分ける例
製品カタログ、資料請求、検索画面などに表示する情報です。
営業、サポート、品質保証など、社内担当者だけが確認する情報です。
ページやExcelを分けて管理すると、どちらかが古くなる可能性があります。 同じマスタの中で公開範囲を持たせ、ログイン権限や画面ごとに出し分ける設計にすると、更新作業を減らせます。
この考え方は、製造業や卸売で特に重要です。 業務像を先に確認したい場合は、製造業向けWebシステム活用アイデア や 卸売・商社（BtoB企業）向けWebシステム活用アイデア のような、情報の出し分けが前提になる業種別ページと合わせて見るとイメージしやすくなります。
マスタは裏側の設定に見えますが、ユーザーが触る画面にも大きく影響します。 検索条件、見積の選択肢、予約枠、担当者通知などは、すべてマスタの内容を参照します。
| 機能 | 参照する主なマスタ | マスタが不十分な場合に起きること | 関連トピック |
|---|---|---|---|
| 製品カタログ検索 | 商品、カテゴリ、仕様、用途、公開状態 | 検索条件に出ない、表記がばらつく、廃止品が表示される。 | 絞り込み条件設計 |
| 見積フォーム | 商品、料金、オプション、割引、適用期間 | 旧料金で計算される、オプションの組み合わせが合わない。 | 料金計算ロジック |
| 予約システム | 拠点、担当者、設備、時間枠、休業日 | 存在しない枠が表示される、担当者不在の日に予約が入る。 | 時間枠設計 |
| 問い合わせ振り分け | 部署、担当者、カテゴリ、拠点、通知先 | 退職者に通知される、担当部署が分からない問い合わせが増える。 | 担当振り分けルール |
製品検索を作る場合も、検索UIだけを調整しても限界があります。 カテゴリ、型番、用途、仕様値などのマスタが整理されていないと、ユーザーは条件を選びにくくなります。 検索画面の改善とマスタの正規化は、同時に考える必要があります。
マスタは一度作って終わりではありません。 商品は増え、拠点は変わり、担当者は入れ替わり、料金も改定されます。 増えることを前提に、廃止・統合・表記ゆれへの対応を最初から用意しておくと、後の運用がかなり楽になります。
過去の見積、問い合わせ、受注に使われたマスタを削除すると、履歴画面で何を扱っていたのか分からなくなります。 そのため、原則として削除ではなく、廃止フラグや非表示フラグを使います。
同じ商品や拠点が複数登録されている場合、単純に片方を消すのではなく、統合履歴を残します。 どのIDをどのIDへ統合したかが分かれば、過去データとの対応も取りやすくなります。
型番、略称、旧名称、英語名などは、表記ゆれが起きやすい項目です。 正式名称だけでなく、別名や検索用キーワードを持たせると、検索しやすくなります。 型番・品番の候補表示には、サジェスト設計 の考え方も使えます。
最後に、マスタ運用を設計するときに確認しておきたい項目を整理します。
マスタ運用は、画面の見た目よりも地味なテーマですが、業務システムの品質を大きく左右します。 商品・料金・拠点・担当者などのマスタが安定していれば、検索、見積、予約、通知、集計の精度も上がります。
重要なのは、正しい情報の置き場所、責任者、承認、反映タイミング、履歴、公開範囲を明確にすることです。 この土台があれば、CSV連携やAPI連携、検索画面、見積フォームなどを拡張するときにも、判断がしやすくなります。
まずは、自社の主要マスタを一覧にして、「どの項目を誰が管理しているのか」「いつどこへ反映されるのか」を確認してみてください。 そこを整理するだけでも、現場で起きている多くの確認作業を減らせる可能性があります。