← 実践記事

OTSUMU KNOWLEDGE

Salesforceの費用が重いときの選択肢:移行・併用・自社開発

Salesforceの費用が重いときは、まず使っていないライセンスと機能の棚卸しから。残る・軽いCRMへ移行・一部を自社開発して併用・全面自社開発の4つの選択肢を、費用の全体像と業務の独自性から比較し、判断の手順と移行時の失敗の避け方を解説します。

Salesforceの費用が重いと感じたとき、選択肢は「使い方を見直して残る」「機能の軽い別ツールへ移る」「一部を自社開発して併用する」「全面的に自社開発へ切り替える」の4つに整理できます。最初に確かめるべきなのは、費用の重さがライセンスの単価ではなく「使っていない機能と使っていない人に払っている」ことから来ていないかどうかです。ここを確かめずに移行を決めると、移行先でも同じ問題が繰り返されます。

結論から言えば、多くの会社でまず効くのは、ユーザー数と契約エディションの棚卸し、使われていないカスタマイズの整理です。そのうえで、自社の営業プロセスが標準的で、使っている機能が顧客管理と商談管理の基本に限られるなら、軽いツールへの移行が現実的になります。逆に、独自の業務フローや他システムとの連携が多く、それが競争力の源泉になっているなら、コア部分だけを自社開発し、残りは既製ツールを使う併用型が候補になります。

この記事は、Salesforceを数年運用してきて、更新のたびに費用が気になっている経営者・営業企画・情報システム担当の方に向けて書いています。費用が重くなる構造、4つの選択肢の比較、判断の手順、移行時に起きやすい失敗とその避け方までを、具体的な場面とともに整理します。

Salesforceの費用が「高い」と感じる理由を分解する

Salesforceの費用が高いと感じるとき、その中身は大きく分けて次の4つのどれか、あるいは組み合わせです。どれが主因かによって、取るべき対策がまったく変わります。

  • ライセンス数の問題:実際にはログインしていない人、閲覧しかしない人にもフル機能のライセンスを割り当てている。
  • エディションの問題:上位エディションの機能を前提に契約しているが、その機能をほとんど使っていない。
  • 周辺費用の問題:追加のオプション製品、外部アプリ、導入パートナーへの保守費用、社内の管理者の人件費などがかさんでいる。
  • 価値の問題:費用そのものより、入力されない・活用されないことで「払っている分の効果が出ていない」と感じている。

4つ目は見落とされがちですが、実はもっとも多い原因です。営業がデータを入れず、経営判断にも使われていないなら、どのツールに移っても「高い」と感じ続けます。入力が定着しない問題は、ツールの問題ではなく設計と運用の問題であることが多く、営業がCRMに入力しない問題で詳しく扱っています。

費用の全体像を一枚にまとめる

判断の前に、Salesforce関連の費用を一枚の表にまとめます。ライセンス費用だけを見ていると、移行による削減額を過大に見積もってしまいます。

費用の区分中身の例移行で減るか
ライセンス費用ユーザー数 × エディション単価、追加の製品ライセンス移行先の費用に置き換わる
外部アプリ・連携ツールAppExchangeのアプリ、連携用のミドルウェア移行先で同等の機能が必要か次第
導入・保守パートナー費用設定変更、カスタマイズ開発、問い合わせ対応移行先でも何らかの支援は必要
社内の管理工数管理者の設定作業、ユーザー対応、レポート作成ツールが単純になれば減ることが多い
移行に伴う一時費用データ移行、再設定、教育、並行稼働移行する場合のみ新たに発生

この表を埋めると、ライセンス費用が全体のうちどれくらいを占めているのか、移行すると何が残り何が新たにかかるのかが見えてきます。

選択肢1:使い方を見直してSalesforceに残る

移行は大きな決断なので、まずは「残る」選択肢を本気で検討します。Salesforceに残る場合でも、費用を下げる手段はいくつかあります。

ライセンスの棚卸し

ユーザーごとに最終ログイン日、作成・更新したレコード数、閲覧しかしていないかを確認します。管理画面のレポートで確認できる情報を使えば、外部に頼まなくても棚卸しは可能です。次のような人がいないかを見ます。

  • 退職・異動したのにライセンスが割り当てられたままの人
  • 月に数回しかログインせず、ダッシュボードを見るだけの人
  • 実際の入力はアシスタントがまとめて代行している人

閲覧中心の人には、より軽いライセンス種別や、レポートを別の方法で共有する手段が使えないか検討します。ライセンス種別の構成や条件は変わることがあるため、最新の内容は契約窓口や公式情報で確認してください。

エディションと追加製品の見直し

契約時には必要だと考えた上位機能が、実際には使われていないことがあります。自動化のルール、承認プロセス、高度な予測機能などについて、直近で実際に動いているものを洗い出します。使われていない追加製品は、更新のタイミングで外せないか確認します。

カスタマイズの整理

長く使っているSalesforceには、誰が作ったか分からない項目、使われていないページレイアウト、動いているかどうか分からない自動処理が積み重なっています。これが管理工数とパートナー費用を押し上げます。項目ごとに入力率を確認し、ほとんど入力されていない項目は非表示にする、使われていない自動処理は停止するといった整理をします。

この「残る」選択肢は、移行の一時費用もリスクもかからないため、まず試す価値があります。整理した結果、それでも費用が重いと判断できれば、移行の検討に進む根拠にもなります。

選択肢2:機能の軽い別のCRMへ移行する

Salesforceの機能の大半を使っておらず、顧客情報・商談・活動履歴の管理が中心なら、機能の軽いCRMへの移行が候補になります。HubSpot、kintone、Zoho CRMなど、方向性の異なる製品があります。

移行を検討する際は、次の観点で候補を比べます。

  • 今使っている機能が揃うか:商談のステージ管理、見積もり、レポート、メール連携など、日常で使っている機能を一覧にして照合する。
  • カスタマイズの自由度:自社独自の項目や画面をどこまで作れるか。軽いツールほど自由度が低いことがある。
  • 連携先:会計、請求、マーケティングツール、問い合わせフォームなど、今つながっているシステムと同様につなげられるか。
  • 将来の増え方:ユーザー数や機能を増やしたときに費用がどう伸びるか。最初は安くても、必要な機能が上位プランにしかないこともある。

軽いツールに移ると、ライセンス費用は下がっても、これまでSalesforceで実現していた独自の処理が作れず、結局は手作業や別ツールで補うことになる場合があります。手作業が増えればその人件費が発生するため、表の「社内の管理工数」の欄も含めて比較することが大切です。

試用期間を「本番に近い形」で使う

多くのCRMには試用期間やデモ環境があります。ここで画面を眺めるだけで終わらせず、実際の営業担当2〜3人に、直近の商談を数件入力してもらうのが有効です。入力にかかる手間、スマホからの使いやすさ、上長が見たいレポートが作れるかを、日常の業務に近い形で確かめます。あわせて、既存データの一部(たとえば取引先100件程度)を試しに取り込み、項目の対応付けや文字化け、日付の形式などで問題が起きないかも確認しておくと、本番の移行で慌てずに済みます。管理者だけで評価すると「機能は足りている」という判断になりがちですが、現場が使い続けられるかは実際に触ってもらわないと分かりません。

選択肢3:一部を自社開発して併用する

営業の基本的な顧客管理は既製ツールで十分だが、自社独自の業務部分(たとえば特殊な見積もり計算、案件ごとの複雑な進行管理、顧客向けポータル)がSalesforce上の大きなカスタマイズになっている、という状況はよくあります。この場合、独自部分を切り出して自社開発し、顧客管理の基本は既製ツールに任せる併用型が選択肢になります。

併用型のポイントは、データの持ち主をはっきり決めることです。顧客の基本情報はCRM、見積もりや案件進行は自社システム、というように「どのデータをどちらが正とするか」を決め、API連携で必要な情報だけをやり取りします。持ち主が曖昧なまま両方で同じデータを編集できるようにすると、どちらが最新か分からなくなり、かえって手間が増えます。

併用型のメリットは、既製ツールの更新や改善の恩恵を受けつつ、自社の強みに関わる部分だけを自由に作り込める点です。デメリットは、連携部分の開発と保守が必要になることです。連携の障害時にどう復旧するかまで含めて設計しておく必要があります。

選択肢4:全面的に自社開発へ切り替える

営業プロセス全体が独自で、既製のCRMの考え方に業務を合わせるほうが負担になっている場合、あるいはCRMそのものが顧客向けサービスの一部になっている場合は、全面的な自社開発も選択肢に入ります。自社開発の判断軸についてはCRMを自社開発すべきかで詳しく整理しています。

全面的な自社開発は、ライセンス費用がかからない代わりに、開発費用、サーバー費用、保守・改善の費用が継続的にかかります。「ライセンスが高いから自社開発すれば安くなる」という単純な比較では判断できません。また、Salesforceが持っている権限管理、監査の仕組み、モバイル対応、レポート機能などを一から作ることになるため、必要な機能を絞り込めるかどうかが成否を分けます。

4つの選択肢を比較する

4つの選択肢を、判断に関わる観点で並べると次のようになります。

観点使い方を見直して残る軽いCRMへ移行一部を自社開発して併用全面的に自社開発
一時費用小さいデータ移行・再設定・教育開発費・連携開発開発費・データ移行
継続費用見直し後のライセンス移行先のライセンスライセンス+自社開発部分の保守保守・サーバー・改善
業務への適合現状維持業務を製品に合わせる必要あり独自部分は自由に作れるすべて自社に合わせられる
切り替えリスクほぼない中程度中程度大きい
向いている状況使われていない機能・ライセンスが多い標準的な営業プロセス独自業務が一部に集中業務全体が独自、CRMが事業の中核

どの選択肢が正しいかは会社によって異なります。大切なのは、比較のときに一時費用だけでなく、数年間の継続費用と社内工数を含めることです。

判断の手順:どの選択肢を選ぶかを決める流れ

選択肢を決めるには、次の順番で進めると判断がぶれにくくなります。

  1. 費用の全体像を把握する:ライセンス、外部アプリ、パートナー費用、社内工数を一枚にまとめる。
  2. 使っている機能を棚卸しする:日常的に使う機能、月に一度使う機能、使っていない機能に分ける。
  3. 使われ方を確認する:ユーザーごとのログイン頻度と入力量、項目ごとの入力率を確認する。
  4. 「残る」場合の削減策を試算する:ライセンス整理とカスタマイズ整理でどこまで下がるかを見積もる。
  5. 独自業務の範囲を特定する:自社独自の処理がどこに集中しているか、それが競争力に関わるかを判断する。
  6. 移行先の候補を比較する:軽いCRM、併用型、全面自社開発のそれぞれで、一時費用と数年分の継続費用を試算する。
  7. 移行の負担を見積もる:データ移行、連携の作り直し、教育、並行稼働の期間を見込む。
  8. 次の更新時期から逆算して決める:契約更新のタイミングに合わせて、判断の期限と移行のスケジュールを決める。

特に8番目は重要です。年間契約の更新直前に移行を決めても間に合わず、結局もう一年契約を延長することになりがちです。更新時期の半年以上前から検討を始めると、選択肢を落ち着いて比べられます。

具体的な場面で考える

ここでは、架空の例を2つ挙げて、判断の流れを示します。

例1:営業10名ほどの専門商社

営業担当とその上長、経営陣、事務担当がSalesforceを使っている会社を想定します。棚卸しをしたところ、経営陣は月に数回ダッシュボードを見るだけ、事務担当は見積書作成のために閲覧しているだけでした。使っている機能は顧客情報、商談ステージ、活動記録、簡単なレポートに限られていました。

この場合、まず閲覧中心の人のライセンスを見直し、それでも費用に見合わないと判断するなら、軽いCRMへの移行が候補になります。業務が標準的なので、製品の考え方に合わせる負担は小さく、移行のリスクも比較的抑えられます。

例2:独自の案件進行管理を持つサービス会社

案件ごとに多数の工程があり、工程ごとに担当者、承認、顧客への報告が発生するサービス会社を想定します。この会社では、Salesforce上に工程管理のための独自オブジェクトと大量の自動処理を作り込んでおり、変更のたびにパートナーへの依頼が必要でした。

この場合、軽いCRMに移ると工程管理を再現できません。顧客管理と商談管理は既製ツールに残し、案件の工程管理を自社開発のシステムとして切り出す併用型が候補になります。工程管理は自社の強みでもあるため、自社開発にすることで改善のスピードも上がります。

移行・併用で起きやすい失敗と避け方

移行や併用を決めたあと、よく起きる失敗とその避け方を整理します。

  • ライセンス費用だけで比較してしまう:移行先の費用が安く見えても、連携の作り直しや手作業の増加で総額が逆転することがある。費用の全体像の表を移行先についても作る。
  • データ移行を軽く見る:長く使ったCRMには重複データ、表記の揺れ、使われていない項目が大量にある。移行前の整理に時間を確保する。手順は顧客データ移行の手順を参照。
  • 今のカスタマイズをそのまま再現しようとする:使われていない機能まで移行先で作り直すと、費用も期間も膨らむ。移行は機能を絞り込む機会と捉える。
  • 営業現場を巻き込まない:管理側だけで決めると、移行後に入力されなくなる。現場の代表者を選定段階から参加させる。
  • 並行稼働の期間を決めない:新旧両方に入力する期間がずるずる延びると現場が疲弊する。切り替え日と旧システムの読み取り専用化の日を決めておく。
  • 契約の解約条件を確認していない:更新の自動延長や解約の通知期限を見落とすと、移行後も費用が発生する。契約内容を早めに確認する。

移行前に確認するチェックリスト

  • 費用の全体像(ライセンス、外部アプリ、パートナー費用、社内工数)を一覧にしたか
  • 使っている機能と使っていない機能を分けたか
  • ユーザーごとの利用状況と項目ごとの入力率を確認したか
  • 「残る」場合の削減策を試算したか
  • 移行先で連携先(会計、請求、マーケティング、フォーム)をつなげられるか確認したか
  • データ移行の対象範囲と、移行しないデータの保管方法を決めたか
  • 現場の代表者を選定に参加させたか
  • 契約更新日と解約の通知期限を把握しているか
  • 並行稼働の期間と切り替え日を決めたか

よくある質問

Q. Salesforceから移行すると、過去のデータはすべて持っていけますか?

顧客情報、商談、活動履歴などの主要なデータは、エクスポートして移行先に取り込むのが一般的です。ただし、添付ファイル、メールの履歴、項目の変更履歴、独自オブジェクト間の関係などは、移行先の構造によってそのまま移せないことがあります。すべてを移すのではなく、移行するデータと、エクスポートして保管だけしておくデータを分けて考えると、作業量を抑えられます。

Q. 自社開発すれば、ライセンス費用がかからない分だけ安くなりますか?

必ずしもそうではありません。自社開発には開発費用のほか、サーバー費用、セキュリティ対応、機能追加、障害対応などの継続費用がかかります。ライセンス費用と比べるべきなのは、こうした数年分の総費用です。自社開発が有利になるのは、必要な機能を絞り込めて、かつ独自の業務に合わせることで業務効率や事業上の価値が上がる場合です。

Q. 移行の検討はいつから始めればよいですか?

契約更新の半年以上前から始めるのが目安です。棚卸しと比較、移行先の選定、データ移行の準備、並行稼働を考えると、短期間で終わらせるのは難しいためです。更新直前になって慌てて決めると、比較が不十分なまま判断することになります。

Q. 移行せずに費用を下げる方法で、まず何から手をつければよいですか?

ユーザーごとのログイン状況と、退職・異動者のライセンスの確認から始めるのが手軽です。管理画面のレポートで確認でき、外部に頼まなくても進められます。次に、使われていない追加製品や外部アプリがないかを確認します。

Otsumuに相談できること

ライセンスの棚卸し、使われていない機能の整理、退職者のアカウント削除といった「残る」ための見直しは、社内の管理者で十分に進められます。業務が標準的で、軽いCRMへの移行で済む場合も、製品の導入支援を受けながら自社で進めるのが合理的です。まずはこの記事のチェックリストに沿って、費用の全体像と使われ方を把握してみてください。

一方で、独自の業務フローがSalesforce上に複雑に作り込まれている、どこまでを既製ツールに残しどこを自社開発にすべきか判断がつかない、移行先と会計や請求システムとの連携を作り直す必要がある、といった状況では、業務とシステムの両方を見られる外部の視点が役に立ちます。移行の判断を誤ると、費用だけでなく営業現場の混乱という形で負担が返ってくるためです。

Otsumuでは、現在の使われ方と費用の全体像を整理したうえで、残る・移行・併用・自社開発のどれが合うかを一緒に判断します。自社開発や併用型を選ぶ場合は、目的から逆算して必要な機能に絞り込み、AIを活用した少人数の開発体制で短期間に形にします。詳しくはCRM開発やシステム開発のページをご覧ください。

どの選択肢が自社に合うか迷っている段階でも構いません。30分の無料相談で、現在の状況を伺いながら検討の進め方を整理します。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆:Otsumu株式会社 / 編集日 2026.10.01

あわせて読む

次の一手を、一緒に。

事業の検証から開発・運用まで、現在の段階に合わせて支援します。

事業について相談する ↗
FROM KNOWLEDGE TO ACTION

知識を、次の一手へ。

30分の無料診断で、次の一手を整理する ↗