CRM項目を安全に廃止する手順｜参照先調査・データ移行・削除判断

使われなくなったCRM項目は、利用件数が少ないという理由だけで削除してはいけません。画面に表示されていなくても、数式、入力規則、ワークフロー、レポート、API連携、データ基盤が項目を参照している場合があるためです。安全に廃止するには、利用状況と依存関係を調べ、既存データを退避し、移行先へ切り替え、一定期間の凍結と監視を経てから削除可否を判断します。

この記事では、選択リスト内の値ではなく、テキスト、日付、参照、数式、集計などCRMの項目定義そのものを廃止する手順を扱います。選択肢の追加・統合・廃止を整理したい場合は、先にCRM選択リストの管理方法を確認してください。

CRM項目を安全に廃止する基本は、「棚卸し、依存関係調査、退避、移行、書き込み凍結、監視、削除判断」を一つの変更として管理することです。廃止の完了条件は、項目が画面から消えたことではなく、旧項目への書き込みが止まり、主要集計を新項目で再現できることです。

---

本記事のポイント

1. 項目の利用件数だけでなく、画面、数式、入力規則、自動化、レポート、API、データ基盤からの参照を調べて廃止可否を決めます。
2. データとメタデータを退避し、移行先への二重書き・照合・旧項目の書き込み停止を経て、問題があれば戻せる状態を保ちます。
3. 非表示、凍結、アーカイブ、削除は別の状態として扱い、製品ごとの復元期限と削除時のデータ消失条件を確認します。

---

削除ではなく「廃止状態」を先に決める

CRM項目の整理で最初に決めるのは、削除ボタンを押す日ではなく、利用者とシステムから見た状態です。「使っていない」という言葉には、画面では不要、入力は止めたい、過去データは残したい、レポートだけ参照中、法令や契約上の保存が必要、といった異なる条件が含まれます。

項目を減らす目的も明確にします。入力負荷を下げたいだけなら、レイアウトから外すだけで足りる場合があります。定義の重複を解消したいなら、後継項目への移行が必要です。データ保持の終了が目的なら、削除前に保存期間と証跡を確認します。列を追加するときの設計原則は顧客データ設計の基本にまとめています。

状態	何を止めるか	既存データ	選ぶ場面
表示停止	通常画面での閲覧・入力	保持する	利用者の入力負荷を先に下げたい
書き込み凍結	画面、フォーム、CSV、API、自動化からの更新	保持して監視する	参照先の切替が完了したか確かめたい
アーカイブ	通常利用と新規設定での参照	製品仕様に従って保持	復元余地を残して運用対象から外したい
削除	項目定義そのもの	消失または復元期限付き	依存先と保持要件がなく、復旧手段を確保できた

非表示は廃止ではありません。レイアウトから項目を外しても、APIや自動化が書き込みを続ければデータは更新されます。反対に、画面へ残して参照専用にしながら、権限、入力規則、連携設定で新規書き込みを止める方法もあります。状態ごとに「誰が読めるか」「何が書けるか」「どの処理が参照するか」を分けて記録します。

候補項目は利用件数と業務上の意味で判定する

廃止候補を探すときは、空欄率だけを見ないようにします。入力率が低くても、重大インシデントや解約理由など、発生頻度は低いが判断に必要な項目があります。一方、入力率が高くても、初期値のまま更新されず、誰も意思決定に使っていない項目は整理対象になり得ます。

候補一覧には、オブジェクト、表示名、内部名、データ型、作成日、管理責任者、入力元、直近の更新日時、値あり件数、重複する後継項目、利用目的を載せます。CRM管理者の日常棚卸しへ組み込む場合はCRM管理者の業務一覧を基準にすると、権限や入力品質の確認と同じ周期で進めやすくなります。

確認軸	調べる内容	廃止を急がない条件
更新実態	直近30日・90日の更新件数、最終更新元	定期連携や特定時期だけ更新される
業務利用	誰がどの判断、引き継ぎ、監査に使うか	低頻度でも重要な判断根拠になる
データ品質	空欄率、固定値率、重複項目との差分	後継項目で同じ意味を表せない
保持要件	契約、監査、法令、社内規程の保存期間	原本または変更履歴の保持が必要
復旧可能性	データ・設定の退避、復元期限、責任者	削除後の復元手段を確認できない

利用者への確認は「この項目を使っていますか」だけでは不十分です。「この項目がなくなると、どの会議、承認、顧客対応、集計で困るか」と聞くと、暗黙の用途を見つけやすくなります。項目責任者が不明な場合は、作成者ではなく、現在そのデータで判断している部門を暫定責任者にして確認を進めます。

削除前に調べる参照先を7領域で揃える

依存関係の調査では、CRM製品が提供する「使用箇所」や「依存関係」の表示を起点にしつつ、それだけで完了としません。Salesforceの「Where is this used?」は、入力規則、レイアウト、数式、Apex、フロー、Lightningページ、レポートなど幅広い参照を表示しますが、管理パッケージ内の参照、閲覧権限がないレポート、上限を超えた参照などは表示できない場合があります。Microsoft Dataverseも削除を妨げる依存関係を表示できますが、外部システム側のマッピングは別に確認が必要です。

1. 画面と入力：ページレイアウト、フォーム、モバイル画面、必須設定、クイック作成、インポートテンプレートを確認します。
2. データモデル：参照関係、数式、集計、入力規則、重複ルール、レコードタイプ、変換時の項目マッピングを確認します。
3. 自動化：フロー、ワークフロー、通知、承認、割り当て、スコアリング、バッチ処理の条件と更新先を確認します。
4. 分析：レポート、ダッシュボード、リスト、セグメント、予測、エクスポート、定例会議の集計表を確認します。
5. 連携：APIクライアント、Webhook、ETL、iPaaS、CSV、データウェアハウス、BI、名寄せ処理の内部名と列順を確認します。
6. 権限と監査：項目レベル権限、権限セット、監査ログ、履歴追跡、マスキング、保持ポリシーを確認します。
7. 人の運用：手順書、スプレッドシート、営業会議、顧客提出資料、監査証跡での利用を確認します。

検索には表示名だけでなく、内部名、API名、旧表示名、エクスポート列名を使います。CRM内の参照検索がゼロでも、コードリポジトリ、連携設定、BI、データ辞書、共有ドライブ内のCSVテンプレートに残っている可能性があります。参照先ごとに「所有者、切替方法、検証方法、完了日」を記録し、未確認のまま削除判断へ進まないようにします。

データとメタデータを別々に退避する

復旧には、項目の値だけでなく、項目定義と参照設定も必要です。Salesforceのバックアップ案内では、レコードはデータ、カスタム項目、ページレイアウト、レポート、ダッシュボード、コードなどはメタデータとして区別されています。CSVで値を出しただけでは、データ型、数式、権限、画面配置、自動化の条件を再現できません。

データ退避では、レコードID、旧項目の値、更新日時、更新者、後継項目の値、移行結果を保存します。数式項目や集計項目は通常のデータエクスポートに含まれない場合があるため、計算式と参照元をメタデータ側へ残し、必要なら結果値も別途取得します。機密性の高い項目は、退避先のアクセス権と保存期限を本番CRMと同等以上にします。

メタデータ退避には、項目の内部名、表示名、データ型、長さ、既定値、数式、入力規則、参照関係、権限、レイアウト、履歴追跡、依存一覧を含めます。退避ファイルには取得時刻、対象環境、取得者、件数、ハッシュまたは版番号を残し、どの変更前状態へ戻せるのかを説明できるようにします。

CRM項目を廃止する6ステップ

実施順は「消してから直す」ではなく、「後継を用意してから旧項目を止める」です。新旧項目を一時的に併存させると作業は増えますが、利用者や連携先を一度に切り替えずに済み、差分を測れます。

1. 項目の意味と責任者を確定する。何を記録し、誰が入力し、どの判断に使う項目かを一文で定義します。廃止理由、後継項目、保持期限、承認者、変更番号を記録します。
2. 利用状況と依存関係を棚卸しする。値あり件数、更新頻度、入力元を取得し、7領域の参照先を検索します。自動検出の範囲と限界も記録し、外部連携は所有者へ確認します。
3. データと設定を退避する。旧値をレコードID付きで保存し、項目定義、権限、数式、画面、自動化、レポートの設定を版管理します。復元の責任者と所要時間を確認します。
4. 後継項目へ移行する。旧値から新値への対応表を作り、変換不能な値は例外キューへ分けます。フォーム、API、自動化を後継項目へ切り替え、一時的な二重書きで新旧値を照合します。
5. 旧項目の書き込みを止めて監視する。画面から外すだけでなく、権限、フォーム、インポート、API、自動化からの更新を止めます。旧項目への新規書き込み、主要レポート差分、連携エラー、例外件数を一定期間監視します。
6. アーカイブまたは削除を承認する。保持要件、復元期限、製品仕様、監視結果を確認し、参照専用で残す、アーカイブする、削除するのいずれかを決めます。削除後も復元期限まで退避データと変更記録を保持します。

移行では値の存在だけでなく意味の一致を検証する

旧項目と後継項目のデータ型が同じでも、意味が同じとは限りません。たとえば自由記述の「契約更新月」を日付へ移す場合、月だけの値、和暦、未定、複数契約といった例外があります。一括変換できる条件と人が確認する条件を先に分け、移行後に空欄率、変換失敗、範囲外の日付を数えます。

参照項目の廃止では、レコードIDの対応と削除権限を確認します。数式・集計項目では、計算結果の一致だけでなく、参照元の欠損、再計算のタイミング、丸め方を確認します。項目種別ごとにテスト条件を変え、単純なCSV置換だけで全項目を扱わないようにします。

凍結期間は業務周期に合わせる

監視期間は一律の日数ではなく、項目が使われる周期で決めます。日次連携なら複数回の正常実行、週次会議の集計なら少なくとも次回会議、月次請求や更新管理なら月次処理を一巡させます。季節業務や年次監査でしか使わない項目は、短い凍結期間だけで削除せず、参照専用で保持する判断も必要です。

検証点	合格条件の例	異常時の対応
新規書き込み	旧項目への更新がゼロ	更新元のフォーム、API、自動化を特定して切替
移行件数	対象件数＝成功＋承認済み例外	追加移行を止め、退避データと対応表を照合
主要レポート	新旧の差分を全件説明できる	フィルター、結合、集計軸を旧設定と比較
連携	所定回数の送受信成功、列ずれなし	旧内部名を参照するクライアントを切り戻す
業務確認	責任者が次の会議・承認を新項目で完了	不足する意味や権限を補い、凍結期間を延長

製品ごとの復元期限と削除条件を確認する

削除の扱いはCRM製品で異なります。Salesforceでは削除したカスタム項目とデータを、完全削除しない限り15日間復元できますが、項目履歴追跡データは削除されます。また、数式、項目更新、Apexなどから参照されるカスタム項目は削除できません。復元できる期間があることと、完全に元の状態へ戻ることは同じではありません。

HubSpotではプロパティをアーカイブし、アーカイブ済みプロパティは90日後に完全削除されます。ワークフローなどで使用中のプロパティには削除を妨げる依存先が表示され、使用箇所を外してからアーカイブします。プロパティ履歴のエクスポートには現在値と過去値、更新時刻を含められるため、誤変更の復旧資料として使えます。

Microsoft Dataverseでは、カスタム列を削除すると保存データが失われ、元へ戻すには削除前のバックアップから環境を復元する必要があると案内されています。参照列を削除すると関連付けも削除されます。管理画面が削除を許可したとしても、復旧の影響が項目単位に収まるとは限らないため、製品ごとの復元単位まで確認します。

よくある質問

CRM項目はいつ廃止すべきですか？

業務上の目的がなく、後継項目または別のデータで必要な判断を再現でき、保持要件と依存先がないと確認できたときです。空欄率が高い、最近更新されていない、画面にないという一条件だけでは決めません。まず入力と表示を止め、監視期間を経て削除可否を判断します。

削除前にどの参照先を確認しますか？

画面とフォーム、数式・入力規則・参照関係、自動化、レポートとダッシュボード、API・ETL・BI、権限と履歴、手順書と定例会議を確認します。製品の使用箇所検索だけでなく、内部名を使って外部連携とデータ基盤も検索します。

既存データはどこへ移しますか？

同じ意味を持つ後継項目がある場合は対応表に沿って移し、意味を一意に変換できない値は例外キューで人が確認します。履歴としてのみ必要な場合は、アクセス制御された退避データまたは参照専用の保管先へ移します。移行先、保持期間、閲覧権限、削除責任者をセットで決めます。

非表示・凍結・削除はどう使い分けますか？

非表示は利用者の画面から外す状態、凍結は画面・フォーム・API・自動化からの新規書き込みを止める状態、削除は項目定義とデータを製品仕様に従って除去する状態です。通常は非表示と凍結で影響を測り、監視に合格してからアーカイブまたは削除へ進みます。

削除後に問題が見つかったら元へ戻せますか？

製品と経過日数によって異なります。Salesforceのカスタム項目は一定期間復元できますが、履歴追跡など戻らない情報があります。Dataverseは環境バックアップからの復元が必要になる場合があります。削除前に復元方法、復元単位、所要時間、失われる情報を実際の契約と設定で確認してください。

CRM項目の廃止は、項目数を減らす作業ではなく、入力、処理、集計、履歴の責任を別の場所へ安全に移す変更です。依存関係と復元条件を先に可視化し、書き込みを止めてから実際の業務周期を一巡させれば、過去データの説明力を保ちながらCRMを整理できます。