CRM選択リストの管理方法｜項目追加・統合・廃止でデータを壊さないルール
CRMの選択リストは、商談ステージ、失注理由、業種、顧客ランクなどを同じ基準で集計するための土台です。しかし、依頼のたびに似た値を追加すると、「製造業」と「メーカー」、「検討中」と「情報収集中」のような重複が生まれます。名称だけを直したつもりでも、フォーム、連携、レポート、自動化が旧値を参照していれば、入力停止や集計漏れにつながります。
選択肢は画面上の文言ではなく、複数の業務が参照するデータ契約として扱う必要があります。顧客データ全体の設計から見直す場合は顧客データ設計の基本を先に確認し、この記事では選択肢の追加・統合・廃止に範囲を絞って、安全な変更手順を整理します。
CRM選択リストを安全に管理する要点は、変更前に「値の意味・入力元・依存先・既存件数・移行先」を一つの台帳へまとめ、追加、統合、廃止を同じ承認フローで扱うことです。選択肢の追加前に、依存関係と既存値の移行先を確認します。廃止は即時削除ではなく、新規入力の停止、既存値の移行、参照先の切替、監視、削除判断の順に進めると、履歴を残しながら事故を防げます。
本記事のポイント
- 選択リストは表示名の一覧ではなく、フォーム、連携、自動化、レポートが共有するデータ契約として管理します。
- 統合・廃止の前には利用件数と依存先を調べ、旧値から新値への対応表、退避データ、切り戻し条件を用意します。
- 変更後は旧値の再発、空欄率、分類不能、連携エラー、集計差分を監視し、入力元まで直して再発を止めます。
選択肢を増やす前に、意味と依存関係を棚卸しする
最初に確認するのは「新しい言葉が必要か」ではなく、「既存の選択肢では答えられない業務上の問いがあるか」です。たとえば「製造業」と「メーカー」が同じ集計区分なら追加ではなく表記統一の候補です。一方、製造工程別に担当や提案内容を変える必要があるなら、業種の値を増やすより、別項目や関連レコードへ分けた方が安定する場合があります。
選択リストの目的を決めるときは、選択した結果で誰が何を変えるのかを一文にします。「レポートで見たい」だけでは粒度が決まりません。「失注理由別に翌月の改善施策を決める」「顧客ランク別に訪問頻度を変える」のように、意思決定と接続します。CRMを記録の箱ではなく判断基盤として捉える考え方はAI CRMの導入判断にも共通します。
変更台帳には、少なくとも次の情報を残します。申請者と管理者だけで閉じず、フォーム担当、営業企画、データ連携担当、レポート利用者が同じ変更番号を参照できるようにします。
| 確認項目 | 記録する内容 | 見落とした場合の影響 |
|---|---|---|
| 値の意味 | 含むケース、含まないケース、似た既存値との違い | 担当者ごとに判断が分かれ、重複値が増える |
| 表示名と内部値 | 画面表示、APIやインポートで使う値、翻訳 | 表示は正しくても連携だけ失敗する |
| 入力元 | 手入力、フォーム、CSV、API、ワークフロー、外部連携 | 管理画面を直しても旧値が再流入する |
| 依存先 | 入力制御、権限、数式、自動化、レポート、セグメント、連携 | 条件分岐や集計から対象が抜ける |
| 既存データ | 値別件数、空欄件数、最終更新日、所有部門 | 移行量と業務影響を判断できない |
| 移行と復旧 | 旧値と新値の対応表、退避方法、切り戻し条件、責任者 | 誤変換後に元の値へ戻せない |
製品ごとに「表示名」と「保存される識別子」の扱いは異なります。HubSpotでは列挙型プロパティの内部値は保存後に変更できず、既存フォームへ選択肢の変更が自動反映されない場合があると案内されています。Microsoft Dataverseでも、Choiceは一つの列だけで使うローカル選択肢と複数列で共有するグローバル選択肢を使い分けられます。共有範囲を広げれば一括管理しやすい一方、変更の影響先も増えるため、「共通化できる」ことと「共通化すべき」ことを分けます。
選択リスト全体の責任者は、個々の値を登録できる人ではなく、定義、依存先、移行、監視まで完了を確認できる人にします。日常業務との分担はCRM管理者の業務一覧を基準にすると、申請者と承認者の役割を切り分けやすくなります。
追加・統合・廃止を6ステップで進める
変更の種類にかかわらず、同じ順番で進めると確認漏れを減らせます。小さな名称変更でも、内部値や参照条件まで変わるなら変更管理の対象です。反対に、説明文だけの修正で保存値と条件式が変わらないなら、影響範囲を限定できます。
- 申請を分類する。追加、表示名変更、統合、入力停止、完全削除のどれかを明記します。既存値で表現できない理由、利用開始日、想定件数、終了条件も添えます。期間限定のキャンペーン名なら、恒久的な選択肢ではなくキャンペーン履歴で持つ方が適切です。
- 利用状況と依存先を検索する。値別件数を抽出し、フォーム、レコードタイプ、入力規則、依存選択リスト、ワークフロー、レポート、セグメント、APIマッピング、CSVテンプレートを調べます。検索結果がゼロでも、外部システムが将来送る予定の値や、文字列として条件式に埋め込まれた値がないかを確認します。
- 対応表と合格条件を決める。旧値ごとに「新値へ変換」「履歴として保持」「空欄化」「人が確認」を割り当てます。合格条件は、更新対象件数、未変換件数、レポート差分、連携エラー件数まで数値で決めます。一対多に分かれる統合は自動変換せず、判定に必要な別データを用意します。
- 退避して限定テストする。対象レコードのID、旧値、更新日時をエクスポートし、元へ戻せる状態を作ります。検証環境または少数レコードで、画面入力、フォーム、CSV、API、自動化、レポートを一巡させます。権限やレコードタイプが異なる利用者も含めます。
- 入力元、既存値、参照先の順で切り替える。まず旧値の新規流入を止め、次に既存データを対応表で移行し、最後にレポートや自動化の条件を新値へ切り替えます。実行順と担当者、開始・終了時刻、処理件数を変更台帳へ追記します。
- 監視してから変更を閉じる。旧値が再発していないか、空欄や「その他」が急増していないか、連携失敗や集計差分がないかを確認します。異常があれば値だけを再修正せず、フォーム、インポート、APIなど再流入した入力元を直します。
追加は「既存値との差」と終了条件を先に決める
追加申請では、既存値と重ならない定義、入力する人、利用する処理、想定件数を確認します。追加後に一件も使われない値は、業務上不要だったか、フォームや権限に反映されていない可能性があります。Salesforceではレコードタイプや依存選択リストによって表示される値が変わるため、値を登録しただけで全利用者が選べるとは限りません。
期限のある施策名や支店名を恒久マスタへ足し続けると、選択肢が分類ではなく履歴の置き場になります。獲得経路のように大分類と個別施策を分ける設計を応用し、追加時点で「利用が終わる条件」と「見直し日」を決めると、使われない値を残し続けずに済みます。
統合は既存レコードだけでなく条件式も置き換える
統合では、同義の旧値を一つの新値へ寄せます。ただし、レコードの更新だけでは完了しません。HubSpotの公式ガイドでは、選択肢のマージによって対象オブジェクトの値は新しい選択肢へ更新される一方、旧値を使うセグメント、ワークフロー、フィルターは自動更新されず、手作業で新値へ直す必要があると説明されています。統合前に依存先一覧を作る理由はここにあります。
Salesforceの値置換は既存レコードの該当値をまとめて更新し、処理はバックグラウンドジョブとして実行されます。制御側の選択リスト値を置換すると、その値に結び付いた依存関係が失われるため、新しい値で依存関係を作り直す必要があります。また、置換でレコードの更新日時へ影響する仕様もあるため、「最近更新されたレコード」を営業キューや連携条件に使っている場合は、意図しない再処理が起きないか確認します。
廃止は新規入力停止と既存値削除を分ける
廃止には少なくとも二つの状態があります。一つは、新規には選ばせないが、既存レコードの履歴として値を残す状態。もう一つは、既存値も別値へ移し、元の選択肢を削除する状態です。Salesforceでは値を無効化すると既存レコードの値を保持したまま新規選択を止められ、削除時には別値または空欄への置換を選べます。削除と同時の値置換ではワークフロールールが起動しないという注意点もあるため、自動化が移行処理を補完すると期待せず、結果を件数で照合します。
HubSpotのアーカイブも、将来の利用を隠しつつ既存レコードの値は維持し、レポートやセグメントではアーカイブ済みの値が表示される仕組みです。一方、Microsoft Dataverseは使用済みの選択肢を削除すると該当レコードのデータが無効になる可能性があり、削除前に有効な値へ更新するよう案内しています。名称が似ていても「無効化」「アーカイブ」「削除」の効果は製品ごとに違うため、管理画面の操作名だけで判断しません。
実施後は旧値の再発と集計差分を監視する
変更直後に画面で新しい値が選べることだけを確認しても、運用の安全性は判断できません。監視では、入力、保存、連携、利用の四つを分けます。入力はフォームや手入力で期待する値が選べるか、保存は内部値が正しいか、連携は外部システムとの往復で値が変わらないか、利用はレポートと自動化が同じ対象を返すかを見ます。
| タイミング | 確認する指標 | 異常時の初動 |
|---|---|---|
| 変更直後 | 更新成功件数、未変換件数、API・インポートエラー、権限別の表示 | 追加更新を止め、退避データと処理ログを保全する |
| 翌営業日 | 旧値の新規発生、空欄率、その他率、自動化の実行件数 | 旧値を送ったフォーム・連携・テンプレートを特定する |
| 1週間後 | 主要レポートの変更前後差、担当部門別の偏り、手動修正件数 | 定義の誤解か設定漏れかを切り分け、説明文と入力制御を直す |
| 次回棚卸し | 未使用値、類似値、例外件数、承認なしの追加、廃止候補 | 値ごとに維持、統合、入力停止、削除候補を再判定する |
切り戻し条件も事前に決めます。たとえば、未変換が対象件数の一定割合を超えた、主要な商談レポートの件数が一致しない、外部連携が連続して失敗した場合は、処理を止めて旧値へ戻します。閾値は業務の許容範囲に合わせますが、「担当者が問題ないと感じたら完了」ではなく、同じ数字で判断できるようにします。
選択肢の意味、変更履歴、依存先、移行結果を一か所へ残すと、次回の変更で再調査する範囲を狭められます。完了条件は、管理画面の保存ではなく、旧値が再発せず、主要レポートが説明でき、例外の処理担当が決まっていることです。
よくある質問
CRMの選択リストは誰が管理すべきですか？
CRM管理者またはSales Opsが管理責任者となり、営業、マーケティング、連携担当からの変更申請を一つの窓口で受けます。責任者は値を登録するだけでなく、定義の重複、既存件数、依存先、移行結果、監視完了まで確認します。業務部門は利用目的と判断基準を示し、技術担当は保存値と連携への影響を確認する分担が実務的です。
新しい選択肢を追加する基準は何ですか？
既存値では表せない意思決定があり、複数の担当者が同じ基準で判定でき、一定件数の利用が見込めることが基準です。単発キャンペーン名、自由記述で十分な補足、既存値の言い換えは追加しません。申請時に対象、対象外、入力者、利用するレポートや自動化、終了条件を定義します。
既存値を統合・廃止するときに何を確認しますか？
値別の既存件数、空欄、入力元、依存選択リスト、フォーム、ワークフロー、レポート、セグメント、API・CSV連携を確認します。そのうえで旧値と新値の対応表を作り、元の値を退避します。廃止はまず新規入力を止め、既存値と参照先を移し、旧値の再発がないことを確認してから削除可否を判断します。
レポートや自動化への影響をどう調べますか？
対象フィールド名だけでなく、変更する表示名と内部値の両方を検索します。レポートのフィルター、ダッシュボードのグループ、ワークフローの分岐、セグメント、数式、入力規則、連携マッピング、インポートテンプレートを一覧化します。変更前後で同じ基準日の件数を比較し、差分が意図した移行件数と一致するかを確認します。
製品仕様を確認する
CRM選択リストは、小さな設定に見えて、入力、連携、自動化、集計を結ぶ共有ルールです。変更前に意味と依存関係を可視化し、既存値の移行と切り戻しを用意し、実施後の再発まで監視すれば、項目を整理しながら過去データの説明力を保てます。
