カテゴリ、タグ、品番、ステータス、拠点コード、担当者コードなどは、検索・集計・外部連携の土台になります。 画面上は小さな選択肢やIDに見えますが、ここが乱れると、後からかなり広い範囲に影響します。
たとえば、「修理」「修繕」「メンテナンス」が別々のカテゴリとして増えてしまうと、問い合わせ集計では件数が分散します。 品番のハイフン有無や全角半角が混在すれば、検索やCSV更新で一致しないデータが増えます。 ステータス名が部署ごとに違えば、進捗管理や通知条件も複雑になります。
このページでは、コード体系を長く使える形にするために、カテゴリとタグの役割、表示名とコードの分離、階層設計、変更運用、検索UXとの関係まで整理します。
コード体系は、単なる命名ルールではありません。 検索条件、集計レポート、CSV更新、API連携、通知条件、権限設定など、多くの処理がコードを参照します。 そのため、コード体系が不安定なまま機能を増やすと、後から修正範囲が広がります。
画面例 コード体系を管理するマスタ画面
内部コード：TIRE_CHANGE ／ 別名：タイヤ履き替え・交換作業 ／ 種別：作業カテゴリ
内部コード：WHEEL_INSTALL ／ 別名：アルミ取付・AW取付 ／ 種別：作業カテゴリ
内部コード：GENERAL_REPAIR_OLD ／ 統合先：MAINTENANCE ／ 過去データ参照用
画面表示は日本語、内部処理は固定コードで扱う。名称変更しても過去データの意味が変わらないようにする。
略称、旧名称、現場で使う呼び方を別名として登録し、検索で拾えるようにする。
過去データで使われたコードは削除せず、入力候補から外して参照だけ残す。
コード管理では、表示名だけでなく、内部コード・別名・状態・統合先まで持たせると、検索や集計で扱いやすくなります。
問い合わせ集計レポート や 絞り込み検索UI は、見た目の設計だけでは成立しません。 集計の軸や検索条件として使うコードが安定していることが前提になります。 CSV更新を使う場合も、一括更新 の対象となるコードが決まっていないと、取り込みエラーや手作業の確認が増えます。
カテゴリとタグは似て見えますが、役割は異なります。 ここを混ぜると、検索条件や管理画面の意味が分かりにくくなります。
比較 カテゴリとタグの使い分け
カテゴリは、対象データをどこに置くかを決めるための分類です。
タグは、カテゴリをまたいで絞り込むための補助的な切り口です。
カテゴリの作り方は カテゴリ構造テンプレート、タグの活用は 改善施策に活かす の考え方が参考になります。
現場で見る名称と、システム内部で使うコードは分けておくべきです。 表示名は後から変えることがありますが、内部コードまで変えてしまうと、集計、連携、過去データへの影響が出ます。
| 項目 | 役割 | 例 | 設計上の注意点 |
|---|---|---|---|
| 表示名 | 画面上で人が読む名称 | タイヤ交換、ホイール取付、見積依頼 | ユーザーや現場担当者に分かりやすい日本語にする。変更される可能性がある。 |
| 内部コード | システム処理・連携・集計に使う固定値 | TIRE_CHANGE、WHEEL_INSTALL、QUOTE_REQUEST | 一度使い始めたら原則変更しない。英数字やアンダースコアなど規則を決める。 |
| 別名・同義語 | 検索やサジェストで拾うための補助語 | タイヤ履き替え、AW取付、見積相談 | 現場で使う呼び方、旧名称、略称を登録する。 |
| 状態 | 有効・廃止・統合済みなどの管理状態 | 有効、廃止、統合済み | 削除ではなく状態で管理し、過去データの参照に備える。 |
TIRE_CHANGE、QUOTE_REQUEST001 だけでは用途が分からない検索や外部連携まで考えると、内部コードの安定性が重要になります。 サジェストは サジェスト設計、外部連携の考え方は 冪等性 と合わせて確認できます。
カテゴリ階層は、細かく作るほど正確に見えます。 ただし、現場で入力する人や管理する人にとっては、階層が深いほど選択が難しくなります。 まずは2〜3階層で足りるかを確認するのが現実的です。
細かさが必要な場合でも、すべてを階層に入れる必要はありません。 「屋外向け」「高温対応」「急ぎ」「VIP」「法人向け」のような切り口は、カテゴリではなくタグで扱う方が自然です。
コード体系は、運用中に必ず変化します。 新しいカテゴリが必要になったり、似たタグを統合したり、古い品番を使わなくなったりします。 そのため、追加・統合・廃止の手順を最初に決めておく必要があります。
運用 コード変更の基本フロー
追加・統合・廃止したい理由と対象コードを登録する。
同じ意味のコードや別名で吸収できるものがないか確認する。
検索、集計、CSV、API、既存データへの影響を確認する。
管理者または責任部署が承認し、反映日を決める。
変更内容、理由、統合先、反映日を履歴として残す。
承認が必要なコード変更は、承認フロー の考え方と相性があります。
一括更新が必要な場合は、CSV一括更新 と合わせて計画します。 重複マージに近い考え方は、統合設計 でも扱います。
コードを完全に削除すると、過去の問い合わせ、見積、予約、集計が読みにくくなることがあります。 そのため、廃止コードも参照用として残すのが安全です。
品番・型番は、ユーザーや現場担当者によって入力の仕方が変わりやすい項目です。 全角・半角、ハイフンの有無、空白、旧型番、略称などが混在すると、検索結果に出ない、CSVで一致しないといった問題が起きます。
検索UX 品番サジェストと別名登録の例
品番検索では、表示名だけでなく、別名・旧品番・ハイフン違い・空白違いを検索キーとして持たせると実務で使いやすくなります。
検索画面では、正規化した値と別名辞書を使って候補を出すと、入力ミスや表記ゆれを吸収しやすくなります。 サジェストの設計は、サジェスト設計 と合わせて検討できます。
画面上の表示名は後から変えられますが、CSV更新やAPI連携で使うコードは簡単に変えられません。 外部システムや取引先が参照している場合、コード変更は相手側の修正にもつながります。
| 用途 | 避けたい状態 | 設計のポイント |
|---|---|---|
| CSV一括更新 | 表示名で一致させているため、名称変更で取り込めなくなる。 | 内部コードで一致させ、表示名は補助情報として扱う。 |
| API連携 | 相手側とコードの意味が一致していない。 | コード対応表を持ち、変更時は双方の反映タイミングを決める。 |
| 集計レポート | 同じ意味のカテゴリが複数あり、件数が分散する。 | 統合コードや親カテゴリを持たせ、集計軸を固定する。 |
| 検索フィルタ | 画面の選択肢と内部カテゴリが一致していない。 | 検索UIに出す名称と内部コードの対応を管理する。 |
外部連携がある場合は、コードを変更しない前提で設計します。 どうしても変更が必要な場合は、新コードを追加して旧コードを廃止扱いにし、移行期間を設ける方が安全です。
卸売・商社では、品番、ロット、納期、分納、掛率、取引先別条件などが増えやすくなります。 同じ商品でも取引条件によって見積や在庫確認の扱いが変わるため、商品カテゴリと条件タグを分けて管理することが重要です。
業務像は 卸売・商社向けWebシステム活用アイデア を前提にすると考えやすくなります。 見積フォームの項目設計は 項目設計 と合わせて、カテゴリ体系・品番体系・取引条件が一致するように確認します。
自動車販売・整備・タイヤショップでは、タイヤサイズ、ホイールサイズ、車種適合、作業メニュー、持込可否などが複雑になります。 「サイズ」「作業メニュー」「適合条件」を同じカテゴリに押し込むと、検索や予約条件が扱いにくくなります。
業務像は 自動車販売・整備・タイヤショップ向けWebシステム活用アイデア を前提にすると整理しやすくなります。 予約は 持込取付、入庫は 入庫予約 と合わせて、同じ言葉が別の意味で使われないようにコード体系を先に決めます。
問い合わせ管理では、カテゴリ名、ステータス名、担当振り分けルールがつながります。 カテゴリが曖昧だと、集計も担当振り分けも不安定になります。 問い合わせ分類は 問い合わせ分類（カテゴリ）を最適化する方法 と合わせて設計すると、レポートや通知条件にも使いやすくなります。
コード体系は、普段は目立ちませんが、検索・集計・連携の品質を左右する重要な設計です。 カテゴリは置き場所、タグは横断的な切り口として分ける。 表示名と内部コードを分離し、別名や旧名称も持たせる。 追加・統合・廃止の手順を決め、過去データを読める状態で残す。 この基本を押さえるだけでも、長期運用の負担は大きく変わります。
まずは、現在使っているカテゴリ・タグ・品番・ステータスを一覧にし、重複、表記ゆれ、意味の近いもの、廃止候補を確認してみてください。 そこから、画面に出す名称と、システム内部で使うコードを分けていくと、検索・集計・CSV更新・外部連携の設計が進めやすくなります。