Salesforceカスタマイズの落とし穴｜「作りすぎ」が招く運用崩壊と脱出法
- Salesforceのカスタマイズが膨大で、誰も全体像を把握できなくなった…
- ベンダーに作ってもらったApexコードが何をしているかわからない
- バージョンアップのたびに動かなくなる機能がある
「Salesforceをカスタマイズしすぎて、誰も全体像を把握できなくなった」「ベンダーに作ってもらったApexコードが何をしているかわからない」「バージョンアップのたびに動かなくなる機能がある」——Salesforceのカスタマイズに起因する問題は、導入から2〜3年経った企業で急速に顕在化します。
Salesforceの強力なカスタマイズ機能は、自社の業務に合わせた柔軟な開発を可能にする一方で、計画性のないカスタマイズは「技術負債」として蓄積し、運用コストの増大と現場の混乱を招きます。
この記事では、Salesforceカスタマイズの種類と複雑度を整理したうえで、「カスタマイズ沼」にハマる原因、標準機能との判断基準、技術負債の棚卸し手順、そしてカスタマイズに依存しないSFA運用の選択肢までを解説します。
Salesforceカスタマイズの種類と複雑度マップ
Salesforceのカスタマイズは、大きく「宣言的カスタマイズ」と「プログラム的カスタマイズ」の2種類に分かれます。両者の違いを理解することが、カスタマイズの適切な判断の第一歩です。
宣言的カスタマイズ（ノーコード / ローコード）
コードを書かずに、Salesforceの管理画面上の操作だけで実現するカスタマイズです。
カスタマイズの種類 | 具体例 | 複雑度 | 保守負荷 |
|---|---|---|---|
カスタム項目の追加 | 商談に「競合情報」項目を追加 | 低 | 低 |
ページレイアウトの変更 | 営業担当者向けの画面に表示する項目を整理 | 低 | 低 |
レコードタイプの設定 | 商材別に異なる入力フォームを用意 | 中 | 低 |
入力規則（バリデーション） | 金額が0円の場合にエラーを表示 | 中 | 低 |
フロー（Flow Builder） | 商談フェーズ変更時にタスクを自動生成 | 中〜高 | 中 |
承認プロセス | 値引き率10%以上の見積を上長承認に回す | 中 | 中 |
プログラム的カスタマイズ（コード開発）
Apex（Salesforce独自のプログラミング言語）やLightning Web Components（LWC）を使った開発です。
カスタマイズの種類 | 具体例 | 複雑度 | 保守負荷 |
|---|---|---|---|
Apexトリガー | レコード保存時に外部システムへデータを自動送信 | 高 | 高 |
Apexクラス | 独自の計算ロジック（手数料計算、スコアリング等） | 高 | 高 |
Visualforceページ | 標準UIでは実現できない独自の入力画面 | 高 | 最高 |
Lightning Web Components | 独自のダッシュボードウィジェット、カスタムUI | 高 | 高 |
外部API連携 | 基幹システムや会計ソフトとのリアルタイム連携 | 最高 | 最高 |
複雑度×保守コストのマトリクス
保守コスト：低 | 保守コスト：高 | |
|---|---|---|
複雑度：低 | カスタム項目、ページレイアウト、レコードタイプ | — |
複雑度：中 | 入力規則、承認プロセス | フロー（条件分岐が多い場合） |
複雑度：高 | — | Apex、LWC、Visualforce、外部API連携 |
ポイント：右下（複雑度：高×保守コスト：高）に位置するカスタマイズほど、技術負債化するリスクが高くなります。このゾーンのカスタマイズを行う前に、「本当に標準機能では実現できないか」を必ず検証しましょう。
「カスタマイズ沼」にハマる5つの構造的原因
Salesforceのカスタマイズが制御不能になる背景には、5つの構造的原因があります。
原因1：要件定義なしの場当たり開発
「営業部長がこの項目を追加してほしいと言った」「経理から承認フローを入れてくれと依頼された」——個別の要望に場当たり的に対応し続けた結果、カスタマイズが乱立するパターンです。
何が起きるか：
- カスタム項目が100個以上に膨れ上がり、入力画面がスクロールしないと見えない
- 同じ目的のフローが複数存在し、どれが有効かわからない
- 項目間の依存関係が複雑になり、1つ変更すると別の場所が壊れる
原因2：「標準機能で代替できる」ことを知らない
Salesforceは年3回のメジャーアップデートで新機能を追加しています。過去にApexで開発した機能が、現在は標準機能やフローで実現できるケースは少なくありません。
よくある例：
- 数年前にApexで作った自動メール送信 → 現在はフローの標準機能で実現可能
- Visualforceで作った独自画面 → Lightning App Builderで代替可能
- プロセスビルダーで作った自動化 → フローへの移行が推奨（プロセスビルダーは廃止予定）
原因3：ベンダー任せで社内にナレッジが残らない
導入時にSIerやコンサルティング会社にカスタマイズを依頼し、「何をどう作ったか」のドキュメントが社内に残っていないケースです。
何が起きるか：
- ベンダーとの契約が終了した後、カスタマイズの意図や仕様がわからなくなる
- 軽微な修正でも外部に依頼する必要があり、1件あたり数万〜数十万円のコストが発生する
- ベンダーの担当者が変わると、引き継ぎが不十分で品質が低下する
原因4：バージョンアップの影響を考慮しない
Salesforceは年3回（Spring / Summer / Winter）のメジャーリリースで機能追加・仕様変更を行います。カスタマイズ時にバージョンアップの影響を考慮していないと、リリースのたびに不具合が発生します。
影響を受けやすいカスタマイズ：
- Apex APIバージョンが古いまま放置されているコード
- 廃止予定の機能（プロセスビルダー、ワークフロールール）に依存した自動化
- Salesforceの内部仕様に依存したVisualforceページ
原因5：「作ったら終わり」で保守計画がない
カスタマイズの開発時には予算と工数を確保するが、リリース後の保守・運用にはリソースを割かないケースです。
何が起きるか：
- 作成者が退職した後、誰もメンテナンスできないカスタマイズが「遺跡」として残る
- エラーが発生しても原因調査に時間がかかり、現場の業務が止まる
- 保守コストが年々増大し、新しいカスタマイズに投資する余裕がなくなる
原因 | 結果 | 予防策 |
|---|---|---|
要件定義なしの場当たり開発 | カスタマイズの乱立 | 変更管理プロセスの導入 |
標準機能の見落とし | 不要なコード開発 | リリースノートの定期確認 |
ベンダー任せ | ナレッジの喪失 | 設計書・仕様書の社内保管 |
バージョンアップ未考慮 | リリース後の不具合 | Sandbox環境での事前テスト |
保守計画なし | 技術負債の蓄積 | 保守予算・体制の事前確保 |
標準機能 vs カスタマイズの判断基準｜意思決定フレームワーク
「カスタマイズすべきか、標準機能で運用すべきか」を判断するための3つの軸を紹介します。
判断軸1：標準機能で80%カバーできるか
業務要件の80%以上を標準機能でカバーできるなら、残り20%は運用で補うほうが長期的にコストが低くなります。
判断の手順：
- 実現したい業務要件をリストアップする
- 各要件に対して「標準機能で実現可能か」を○/×で判定する
- ○の割合が80%以上 → 標準機能＋運用で対応
- ○の割合が50〜80% → 宣言的カスタマイズ（フロー等）で補完
- ○の割合が50%未満 → そもそもSalesforceが自社に合っていない可能性を検討
判断軸2：Salesforceのロードマップで標準化予定はないか
Salesforceは年3回のリリースで新機能を追加しています。今カスタマイズで実現しようとしている機能が、近い将来に標準機能として提供される可能性があります。
確認方法：
- Salesforceの公式リリースノート（Release Notes）を確認する
- IdeaExchange（ユーザーからの機能要望サイト）で該当機能の投票状況を確認する
- Salesforceのロードマップ（公式サイトで公開）を確認する
- 担当のアカウントエグゼクティブに直接確認する
実際に標準化された例：
- 動的フォーム（Dynamic Forms）：以前はVisualforceで作っていた条件付き表示が標準機能に
- フローのスケジュールトリガー：以前はApexのバッチ処理で実装していた定期処理が標準機能に
- Einstein活動キャプチャ：以前は外部ツール連携で実装していたメール・カレンダー同期が標準機能に
意思決定フローチャート
質問 | Yesの場合 | Noの場合 |
|---|---|---|
標準機能で80%以上カバーできるか？ | → 標準機能＋運用で対応 | → 次の質問へ |
宣言的カスタマイズ（フロー等）で実現できるか？ | → フローで実装 | → 次の質問へ |
5年間のTCOを試算して、投資対効果が見合うか？ | → Apex/LWCで開発（保守計画必須） | → 次の質問へ |
Salesforceのロードマップに類似機能の予定があるか？ | → 標準化を待つ（暫定運用で対応） | → 開発を実行（ただし最小限に） |
カスタマイズの棚卸し方法｜技術負債を可視化する実践手順
すでにカスタマイズが蓄積している場合は、棚卸しを行って技術負債を可視化します。
棚卸しの4ステップ
ステップ1：カスタマイズの全量を把握する
Salesforceの「設定」メニューから、以下の項目を一覧出力します。
棚卸し対象 | 確認場所 | 把握すべき情報 |
|---|---|---|
カスタムオブジェクト | 設定 → オブジェクトマネージャー | オブジェクト数、レコード数、最終更新日 |
カスタム項目 | 各オブジェクトの項目一覧 | 項目数、データ型、入力率 |
Apexクラス/トリガー | 設定 → Apexクラス | クラス数、APIバージョン、最終更新日 |
フロー | 設定 → フロー | フロー数、種類（レコードトリガー/画面等）、有効/無効 |
プロセスビルダー | 設定 → プロセスビルダー | プロセス数、有効/無効（廃止予定のため要移行） |
ワークフロールール | 設定 → ワークフロールール | ルール数、有効/無効（廃止予定のため要移行） |
ステップ2：各カスタマイズの利用状況を調査する
棚卸しシートに以下の情報を記録します。
項目 | 記録内容 |
|---|---|
カスタマイズ名 | 例：「見積承認フロー」「手数料計算Apex」 |
種類 | フロー / Apex / カスタム項目 / etc. |
作成者 | 誰が作ったか（不明の場合は「不明」と記録） |
作成日 / 最終更新日 | いつ作られ、最後にいつ更新されたか |
目的 | 何のために作られたか（不明の場合は「不明」と記録） |
利用状況 | 現在も使われているか / 使われていないか |
依存関係 | 他のカスタマイズとの依存関係はあるか |
ステップ3：削除・統合・維持を判断する
判断基準 | アクション |
|---|---|
6ヶ月以上使われていない | 削除候補（Sandbox環境で削除テスト後に本番削除） |
同じ目的のカスタマイズが複数ある | 統合（1つに集約し、残りを無効化→削除） |
標準機能やフローで代替できる | 移行（標準機能に置き換え、旧カスタマイズを削除） |
現在も使われており、代替手段がない | 維持（ドキュメントを整備し、保守計画を策定） |
作成者も目的も不明 | 調査→判断（Sandbox環境で無効化し、影響を確認） |
ステップ4：保守計画を策定する
「維持」と判断したカスタマイズについて、保守計画を策定します。
保守項目 | 内容 | 頻度 |
|---|---|---|
ドキュメントの整備 | 目的・仕様・依存関係を文書化 | 初回＋変更時 |
APIバージョンの更新 | Apexコードのバージョンを最新に保つ | 年1回以上 |
Sandbox環境でのリリース前テスト | Salesforceのメジャーリリース前に動作確認 | 年3回（リリースごと） |
廃止予定機能の移行 | プロセスビルダー→フローへの移行など | 廃止スケジュールに合わせて |
注意：棚卸しは必ずSandbox環境で検証してから本番環境に反映しましょう。「使われていない」と判断したカスタマイズが、実はバックグラウンドで重要な処理を行っていたケースがあります。
カスタマイズに依存しないSFA運用という選択肢
棚卸しと改善を試みても、カスタマイズの保守コストが経営を圧迫し続ける場合、根本的な問いを立てる必要があります。
「そもそも、カスタマイズ前提のSFAが自社に合っているのか？」
カスタマイズが必要になる構造的理由
Salesforceでカスタマイズが膨らむ背景には、「汎用プラットフォームを自社専用に仕立てる」というアプローチがあります。これは大規模な営業組織や複雑な業務プロセスを持つエンタープライズ企業には適していますが、営業5〜30名規模の組織にとっては過剰な投資になりがちです。
組織の特徴 | カスタマイズ前提のSFA | ノーコードで完結するSFA |
|---|---|---|
営業50名以上、複雑な承認フロー | 適している | 機能不足の可能性 |
基幹システムとの深い連携が必須 | 適している | API連携の範囲を要確認 |
営業5〜30名、標準的な営業プロセス | オーバースペック | 適している |
IT専任者がいない | 運用が困難 | 適している |
乗り換えを検討すべき判断基準
以下の3つに該当する場合、カスタマイズに依存しないSFAへの乗り換えが合理的な選択肢になります。
判断基準1：カスタマイズの保守コストが年間ライセンス費用を超えている
Apexの保守、フローの修正、バージョンアップ対応にかかる年間コスト（外部委託費＋社内人件費）が、SFAのライセンス費用を上回っている場合、コスト構造自体に問題があります。
判断基準2：カスタマイズの80%以上が「標準機能の補完」である
独自の業務ロジックではなく、「画面のレイアウトを変えたい」「入力項目を整理したい」「簡単な自動化をしたい」といった要件のためにカスタマイズしている場合、ノーコードで柔軟に設定変更できるSFAのほうが適しています。
判断基準3：管理者不在でカスタマイズのメンテナンスができない
Salesforce認定管理者を社内に確保できず、外部委託に依存し続けている場合、管理者不要で運用できるSFAへの移行が根本的な解決策になります。
カスタマイズに依存しないSFAへの乗り換えを検討する場合、データ移行の手順や失敗しない進め方については、SFA乗り換えガイドの記事で詳しく解説しています。
よくある質問（FAQ）
Q: Salesforceのカスタマイズはどこまでが「適正」ですか？
A: 明確な基準はありませんが、目安として「カスタムオブジェクト10個以内」「Apexクラス20個以内」「有効なフロー15個以内」であれば、一般的な営業組織では管理可能な範囲です。これを大幅に超えている場合は、棚卸しによる整理を検討しましょう。
Q: カスタマイズの棚卸しは自社だけでできますか？
A: 宣言的カスタマイズ（カスタム項目、フロー等）の棚卸しは、Salesforceの管理画面から情報を取得できるため、社内で実施可能です。ただし、Apexコードの棚卸しにはプログラミングの知識が必要です。Apexが多数存在する場合は、Salesforceパートナー企業に「技術負債の診断」を依頼するのが効率的です。
Q: カスタマイズを減らすと、業務に支障が出ませんか？
A: 「使われていないカスタマイズ」を削除しても業務に支障は出ません。棚卸しの結果、6ヶ月以上使われていないカスタマイズが全体の30〜50%を占めるケースは珍しくありません。削除前にSandbox環境でテストすれば、リスクを最小限に抑えられます。
まとめ
Salesforceのカスタマイズは強力な武器ですが、計画性なく積み重ねると「技術負債」として運用を圧迫します。
本記事のポイントを振り返ります：
- カスタマイズは2種類：宣言的（ノーコード）とプログラム的（コード開発）。複雑度と保守コストのマトリクスで、右下（高複雑度×高保守コスト）ほど技術負債化リスクが高い
- カスタマイズ沼の5つの原因：要件定義なしの場当たり開発、標準機能の見落とし、ベンダー任せでナレッジ喪失、バージョンアップ未考慮、保守計画の不在
- 標準 vs カスタマイズの判断基準：標準機能で80%カバーできるか、5年間のTCOで投資対効果が見合うか、Salesforceのロードマップで標準化予定はないか、の3軸で判断
- 棚卸しの4ステップ：全量把握→利用状況調査→削除・統合・維持の判断→保守計画の策定。必ずSandbox環境で検証してから本番に反映
- 根本的な選択肢：カスタマイズの保守コストが経営を圧迫し続ける場合、カスタマイズに依存しないSFAへの乗り換えも合理的な選択肢
カスタマイズは「作ること」よりも「維持すること」のほうがはるかにコストがかかります。新たなカスタマイズを検討する際は、必ず「5年後もこのカスタマイズを保守し続けられるか」を自問してから判断しましょう。
SFA導入を検討中の方は、まず自社の営業課題を整理し、「何を解決したいのか」を明確にすることから始めてみてください。
いま、BtoB企業がリプレイス先に選ぶのは、現場に定着する国産ツール「ferret SFA/CRM」。
高機能SFAと同等の営業管理を、Excel感覚のシンプルさで、圧倒的な低コストで実現します。ぜひご検討ください。
