Salesforceが現場に定着しない3つの理由と、FDE型という解き方

ライセンスは買った。構築も終わった。それでも現場で使われない。 Salesforceの定着が進まない現場に共通する原因は、たいてい機能ではなく業務設計と運用の側にあります。

理由1：業務設計を飛ばして構築に入っている

いちばん多いのがこれです。現行業務とデータの流れを可視化しないまま、 「とりあえず商談オブジェクトを作る」ところから始めてしまう。 結果、現場の実際の進め方とオブジェクト構成がずれ、二重入力が発生します。

最初に決めるべきは、システムに載せる範囲と載せない範囲です。 すべてを載せようとすると入力項目が増え、入力されなくなり、データが溜まらず、 レポートが信用されなくなる——という順番で崩れていきます。

理由2：入力の負荷が、得られる価値を上回っている

現場から見れば、SFAへの入力は「自分のための作業」ではなく「上に報告するための作業」に見えがちです。 入力コストが、そこから得られるメリットを上回っている限り、精神論では定着しません。

「入力してください」と言い続けるより、入力しなくても済む設計にするほうが早い。

いまは生成AIで、商談メモや議事録からの自動起票、長文データの要約、 ネクストアクションの提案までを業務フローに組み込めます。 人が入力する前提そのものを減らすアプローチが現実的になりました。

理由3：リリースがゴールになっている

構築ベンダーの契約がリリースで切れると、そこから先の改善が止まります。 しかし、現場が本当に困りごとを言語化できるのは、使い始めてからです。 いちばん重要な情報が出てくるタイミングで、直せる体制がなくなっている。

解き方：FDE型で「実装 ↔ フィードバック」を短く回す

私たちが取っているのはFDE型の伴走支援です。現場のフィードバックと実装を短スパンで往復させ、 使われている状態を確認できるまでを支援範囲に含めます。

• 週次で現場ヒアリングを行い、詰まっている箇所を吸い上げる
• 小さく直して、すぐリリースする
• 利用状況をレポートでモニタリングし、使われていない機能は削る
• 社内の推進担当者を育て、最終的に自走できる状態にする

実際にこの進め方で、上場準備に向けた内部統制の要件と、現場での定着を両立させた事例があります。 与信管理・反社チェックはAppExchangeで、採算管理はSales Cloudで実装・自動化する、という切り分けも同時に行いました。