CRM・SFAが定着しない

CRM移行で「全部の項目を移したい」と言われたら

公開 2026年9月17日

要件定義の3回目で、先方の担当者が言いました。「とりあえず今の項目は全部移してください。要らないものは、あとで消せばいいので」。

この「あとで消せばいい」が実現した現場を、私はほとんど見ていません。意思が弱いからではありません。消す作業が、足す作業より重いからです。

「全部」と言うのは、捨てた結果を引き受けられる人がその場にいないから

全部移したいと言う人は、たいてい全部を使うつもりがありません。聞けば、半分以上は「たぶん使わない」と答えます。それでも全部と言うのは、判断の非対称があるからです。

移した項目が使われなくても、誰も困りません。移さなかった項目が半年後に必要になったら、「あのとき移さないと決めた人」がはっきりします。旧システムは移行後に契約を切るので、取り返しもつきません。

この構図の中に一人で立たされたら、「全部」と言うのが個人としては最も合理的です。だから「本当に使いますか」と聞いても会話は進みません。使うかどうかを聞かれているのではなく、責任を取れるかを聞かれていると受け取られるからです。

ここを読み違えて説得に入ると、相手は黙ります。黙ったまま期日が来て、結局全部移ります。

減らす交渉が止まるのは、証明の向きが逆になっているから

もう1つ、構造の問題があります。

「この項目は使う」は、用例を1つ出せば示せます。「この項目は使わない」は、これから起きないことの証明です。旧システムに参照ログが残っていれば実測できますが、国産の販売管理や自作のExcel台帳では、まず残っていません。

そこで「使っていない証拠を出してください」と言うと、出せない側が黙るだけで終わります。減らす交渉は、相手に不可能な立証を求めた瞬間に止まります。

つまり、減らす方向で合意を取ろうとする限り、この会話には出口がありません。出口は、二択の中身を変えることの側にあります。

移すかどうかではなく、CRMの項目にするか、読める場所に置くか

組み替えはこうです。「移すか、捨てるか」をやめて、「CRMの項目にするか、読める場所に置くか」にする。

読める場所とは、旧システムの参照専用アカウント、あるいは切替日に取った全件エクスポート（日付入りのCSVを、社内の共有ドライブに1式）です。どちらも運用コストはほぼゼロで、中身は1件も失われません。

この二択にすると、「捨てる」という選択肢が消えます。捨てないので、承認も要りません。相手が守ろうとしていたもの、つまり「なくなったら困る」は、そのまま守られます。

そのうえで、CRMの項目にするかどうかは1つの質問で決まります。切替日以降、その項目に誰が値を入れるか。

入れる人がいない項目は、CRMに置く理由がありません。過去の値しか持たない項目は、レポートの集計軸にも、予測にも、自動化の分岐にも使えないからです。入力されない列が1本増えるだけで、その列はレポート作成時に毎回「これは使えるのか」を確認させます。

線引きは参照の頻度でやります。月に1回以上開くなら移す。年に数回なら、読める場所に置く。ここは感覚ではなく、相手に「直近半年で何回見ましたか」と聞けば、たいてい答えが出ます。

項目を増やすのは一度の判断だが、減らすのは複数の作業になる

「あとで消せばいい」が効かない理由を、仕様で確認しておきます。HubSpotの公式ドキュメント「Organize, delete, and export properties」（最終更新 2026年6月11日）には、次の2点が明記されています。

1つ。セグメント、フォーム、ワークフローなどで使われている項目は、そのままではアーカイブできません。 先に使用箇所を外す必要があります。管理画面には、その項目のアーカイブを妨げているアセットが一覧で出ます。

2つ。アーカイブした項目は90日後に完全削除され、それ以降は復元できません。 90日以上前にアーカイブしたものは戻せない、と公式に書かれています。

並べると、「あとで消す」の実際の中身が見えます。使用箇所を全部外し、アーカイブし、90日以内に「本当に消していいか」をもう一度判断する。これを移行直後の3か月でやることになります。いちばん問い合わせが多く、いちばん手が空いていない時期です。

だから消されません。項目は、移行のときに増えた数のまま固定されます。

切替日を1つ決めると、移行範囲の会話はほぼ終わる

実務では、範囲の交渉より先に日付を決めます。

切替日を決めて、それ以降に発生する記録だけを新しいCRMに入れる。過去は旧システムに残して参照する。この形にすると、議論が「何を移すか」から「いつから新しく書き始めるか」に変わります。決めることが1つの日付だけになるので、合意も速い。

移行するのは、切替日をまたいで進行しているものに限ります。オープンの商談、有効な契約、対応中の問い合わせ。完了して動かないものは、参照側で足ります。

この考え方は、CRMだけの話ではありません。先日のカレンダー移行でも同じ判断をしました。旧サービスから新サービスへ過去の予定を一括で移す公式な方法がなく、非公式な手段は使いたくない。そこで切替日を決めて、以降の予定だけを新しい側に入れ、過去は旧サービスを残して見る形にしました。失われたものは1件もありません。

そのうえで、移行計画に1行だけ足しておきます。切替日から90日後に、全項目の入力率を出して見直す。 HubSpotは項目定義と入力率（値が入っているレコードの割合）を一括でエクスポートできるので、この見直しは30分で終わります。

この1行があると、「全部移したい」と言った人は、全部と言わなくて済むようになります。いま捨てる判断を求められていないと分かるからです。判断を捨てるのではなく、判断できる材料が揃う時点まで動かしただけ。決裁の観点でも、こちらのほうが通ります。

なお、項目を増やしたぶんの入力負荷は実在します。キーウォーカーが2025年10月8日から10日に実施した調査（PRIZMAによるインターネット調査、SFA・CRM・BIツール導入済み企業の営業部門の現場担当者と管理職1,034名）では、入力が遅れる理由の2位が「入力項目が多すぎる」38.5%でした。BIベンダーの自社調査なので比率は桁感として読む前提ですが、移行時の項目数がそのまま毎日の入力画面になる、という関係は変わりません。

顧客の社内工程まで含めて収益の設計を組み直す考え方は、レベニューアーキテクチャとはに置いています。

移行の判断は「残すか捨てるか」ではなく、「CRMの項目にするか、読める場所に置くか」です。この二択に組み替えると、全部残したまま、CRMだけを軽くできます。

今週、移行対象の項目一覧を開いてください。1項目ずつ「切替日以降、誰が値を入れるか」を書く。名前が出てこない項目が半分を超えていたら、それは移行の設計ではなく、旧システムのコピーを作ろうとしています。