Salesforceを業務に合わせる——標準機能の限界とカスタマイズの判断基準・実装アプローチ

「Salesforceに業務を合わせる」——その前提が現場定着を妨げている

Salesforceを導入したにもかかわらず、現場から「入力が面倒」「使いにくい」という声が上がり続けるケースは少なくありません。システムの問題ではなく、現場の意識の問題として片づけられることもありますが、その診断は多くの場合、正確ではありません。

根本にあるのは、「業務をSalesforceに合わせる」という前提そのものが抱える矛盾です。

導入したのに使われない——よくある失敗パターンの共通点

Salesforceの標準機能は、あらゆる業種・規模の企業に対応できるよう、汎用性を最優先に設計されています。言い換えれば、特定の業務フローに最適化されているわけではありません。

たとえば、商談に紐づく承認フローが社内の決裁ルートと一致しない、顧客情報の入力項目が自社の営業プロセスと噛み合わない、といった状況はよく起こります。こうしたギャップに直面したとき、「Salesforceの作法に業務を合わせてください」と現場に求めるアプローチを取ると、現場は二重の手間を強いられます。Salesforceへの入力作業と、従来の業務フローの両方を並行させるケースも生まれやすく、結果としてシステムが形骸化します。

定着しない運用に共通するパターンは、主に以下の3点に整理できます。

• 標準の入力画面が自社の商談ステップと合っておらず、必要な情報を登録するために複数画面を行き来しなければならない
• 承認・確認のフローがSalesforce外（メール・Excelなど）で動いており、Salesforceが「記録を残す場所」にとどまっている
• 現場の入力粒度と、マネージャーが見たいデータの粒度がずれており、レポートが活用されない

これらはいずれも、標準機能の設計思想と自社業務フローのギャップから生じています。意識や習慣の問題ではなく、設計の問題です。

本記事で解説すること——判断基準・技術手段・設計思想の3層で整理する

このギャップを解消するための選択肢は、大きく「標準機能の範囲内で業務を整理し直す」か「カスタマイズで業務に合わせる」かの二択になります。しかし、どちらを選ぶべきかの判断基準が曖昧なまま進むと、カスタマイズが過剰になってアップグレードの障壁になったり、逆に我慢を重ねて現場の不満が蓄積したりします。

本記事では、この判断を適切に行うために必要な情報を3つの層に分けて整理します。まず標準機能がどこまでカバーできてどこから限界が生じるかを確認し、次にカスタマイズに踏み切る際の判断基準を示します。そのうえで、ApexやLWC（Lightning Web Components）といった技術手段の概要と、実際に現場負荷を下げた事例を紹介します。最後に、個別の改修を積み重ねるだけでは陥りがちな設計の落とし穴と、Salesforceを企業の業務基盤として機能させるための設計思想に触れます。

Salesforceの導入効果を最大化したいと考えている情報システム担当者や経営企画担当者にとって、カスタマイズの是非を判断するための実践的な指針として活用できる内容を目指しています。

Salesforce標準機能の限界——どこまでカバーできて、どこから無理が生じるか

標準機能で対応できる範囲——Flow・承認プロセス・数式項目でできること

Salesforceの標準機能は、多くの営業管理業務をカバーできる水準にあります。たとえば、商談ステージに応じた自動タスク生成はFlowで実現できます。見積承認を上長に回すフローは承認プロセス機能で構成できます。金額や日数の自動計算は数式項目で対応できます。

レポートとダッシュボードを組み合わせれば、案件の進捗管理や売上予測の可視化もノーコードで実現できます。こうした定型業務に関しては、標準機能だけで十分に運用が成立するケースも少なくありません。

限界が生じる3つの典型シーン——複雑な業務ロジック・独自UI・外部連携

一方で、業務の複雑さが一定の水準を超えると、標準機能では対応しきれない局面が現れます。典型的なシーンは以下の3つです。

• 複雑な業務ロジック：複数のオブジェクトをまたいだ条件分岐や、段階的な計算ロジックが絡む場合、FlowやApexトリガーなしでは実装が困難になります。たとえば「顧客の契約種別・購入履歴・与信ステータスに応じて承認経路を動的に変える」といった要件は、標準の承認プロセスでは表現できないことがほとんどです。
• 独自UIの必要性：標準の画面レイアウトは汎用的に設計されているため、現場の操作手順とかみ合わないことがあります。たとえば、複数の関連レコードを1画面で同時入力したい、特定のステップのみを順番に案内するウィザード形式で入力させたいといった要件は、標準のページレイアウトでは実現できません。
• 外部システム連携：基幹システムや会計システム、独自の在庫管理システムとリアルタイムで連携する場合、標準のデータインポート機能では対応が難しくなります。APIを介した双方向の同期や、エラー時のリトライ処理が必要な場合は、カスタム開発が現実的な選択肢になります。

「標準に業務を合わせる」コストは見えにくい——現場工数と離脱率の問題

標準機能の限界として見落とされがちなのが、「業務をSalesforceに合わせるために発生する現場コスト」です。システムとしては動いていても、現場担当者が本来の業務フローとは異なる手順で操作しなければならない場合、入力漏れや転記ミスが増加します。操作が煩雑であれば、Salesforceへのログイン自体が後回しになり、データの鮮度が下がります。

こうした「Salesforce画面が使いにくい」という現場の声は、単なる慣れの問題ではなく、標準機能と業務設計の不一致が原因であるケースが多くあります。定着率の低下は、システムの活用価値を直接損なうため、導入後に放置することのリスクは小さくありません。

カスタマイズに踏み切る前の判断基準——「やるべき場合」と「やるべきでない場合」

カスタマイズの検討を始める前に、まず押さえておくべき前提があります。Salesforceのカスタマイズは「業務に合わせる手段」である一方、実装後の保守負荷やバージョンアップへの影響を伴う「負債」にもなり得ます。判断を誤ると、開発コストをかけたにもかかわらず、現場の使い勝手が改善しないままシステムだけが複雑化するケースも少なくありません。

カスタマイズが有効な条件——業務ロジックの固定度・頻度・影響範囲で考える

カスタマイズへの投資が回収できるのは、次の条件が重なる場合です。

• 業務ロジックが固定されている：承認フローや与信判定のルールなど、社内で明文化・標準化されており、今後も変わりにくい業務プロセスであること
• 利用頻度が高い：営業担当が毎日繰り返す入力作業や、週次で走るバッチ処理など、頻度が高いほど自動化・最適化の効果が大きくなります
• 影響範囲が広い：複数部門や多数のユーザーが恩恵を受ける改修は、費用対効果が出やすい傾向があります

たとえば、受注確定時に複数のオブジェクトを連携更新する処理は、標準機能では対応が困難で、かつ毎日数十件発生するような業務であれば、カスタマイズによる自動化が明確に正当化されます。

カスタマイズを避けるべきケース——保守コストとアップグレードリスク

一方、以下に該当する場合はカスタマイズを見送るか、最小限に抑えることを検討すべきです。

• 業務ルールが頻繁に変わる：カスタマイズのたびに改修が発生し、保守コストが膨らみます
• Salesforceのバージョンアップで影響を受けやすい領域：UIに深く依存したカスタマイズは、年3回のリリースサイクルによって動作が不安定になるリスクがあります
• 標準機能で8割以上カバーできている：残り2割のために開発コストを投じると、費用対効果が合わないケースがほとんどです

判断を助ける簡易チェックリスト——標準で粘るか、開発に踏み切るか

意思決定の場で活用できる判断軸を以下に整理します。すべての項目が「はい」に近いほど、カスタマイズへの投資を検討する根拠が強まります。

1. 該当業務のルールは、今後2〜3年変わらない見通しがあるか
2. その業務に関わるユーザー数は10名以上か、または1人あたりの操作頻度が高いか
3. 標準機能での対応を検討したが、運用回避策（手動補完・Excel併用など）でのカバーが限界に達しているか
4. カスタマイズ後の保守を担える社内担当者またはパートナー企業が確保できているか

このチェックリストで「いいえ」が複数出る場合は、まず設定変更・標準機能の再検討・運用フローの見直しを先に行うことが、結果的にコストを抑える判断につながります。

Salesforceカスタマイズの技術手段——ApexとLWCを中心に整理する

Salesforceのカスタマイズを検討する際、「Apex」「LWC」「API連携」といった技術用語が出てきて、判断に迷う担当者は少なくありません。ここでは技術の詳細ではなく、「何のためにどの技術を使うのか」という意思決定に必要な視点を整理します。

Salesforceの開発言語とは——Apex・LWC・JavaScriptの役割分担

Salesforceのカスタマイズで登場する主な技術は、大きく3つに分かれます。

• Apex：サーバーサイドで動くビジネスロジックの記述に使います
• LWC（Lightning Web Components）：画面・UIのカスタマイズに使います
• REST API・外部連携：他システムとのデータ交換に使います

この3つは競合するものではなく、課題の種類に応じて組み合わせて使います。「何が問題か」を整理することが、技術選定の出発点になります。

Apex（エイペックス）とは何か——サーバーサイドのビジネスロジックを担う言語

ApexはSalesforce独自のプログラミング言語で、Javaに近い構文を持ちます。主に「標準機能では実現できない業務ルールの自動化」に使います。たとえば、「受注金額が一定額を超えたら承認フローを分岐させる」「取引先に紐づく複数オブジェクトのデータを一括更新する」といった処理が典型的な用途です。

Apexはクラウド上のSalesforceサーバーで実行されるため、端末環境に依存しません。一方で、Salesforceが定めるガバナ制限（処理件数や実行時間の上限）の範囲内で設計する必要があります。この制限を無視した実装は、本番環境でエラーを引き起こすリスクがあるため、設計段階での考慮が重要です。

LWC（Lightning Web Components）とは——画面・UI層のカスタマイズを担うフレームワーク

LWCはSalesforceの画面カスタマイズに使うフレームワークで、JavaScriptをベースに構築されています。「現場が使いにくい」という声の多くは、標準画面の表示項目や操作フローが業務に合っていないことに起因します。LWCを使うことで、業務の流れに沿った独自画面を構築できます。

たとえば、「商談登録画面で関連する製品情報を同一画面内で確認・入力できるようにする」「モバイル向けに入力項目を絞った簡易フォームを用意する」といった対応が可能です。Salesforce プログラミングの観点では、LWCとApexをセットで使うケースが多く、LWCが画面を担い、Apexがデータ処理を担う構成が一般的です。

外部システムとのAPI連携——標準コネクタとカスタム開発の使い分け

Salesforceは標準でREST APIを提供しており、外部の基幹システムやMAツールとのデータ連携が可能です。まず確認すべきは、Salesforceが提供する標準コネクタやAppExchangeのアドオンで要件が満たせるかどうかです。標準手段で対応できる場合、開発コストと保守負荷を大幅に抑えられます。

一方、連携先のシステムが独自仕様であったり、リアルタイム性や処理量に特別な要件がある場合は、カスタム開発が必要になります。この判断は「標準で何%カバーできるか」を先に見極めてから行うことが、コスト管理の観点でも重要です。

LWC・Apexカスタマイズの実装事例——現場負荷を下げた具体的なアプローチ

ここでは、CLANEが手がけたSalesforce開発プロジェクトの中から、LWC（Lightning Web Components）およびApexを活用した代表的な3つの事例を紹介します。いずれも「標準機能では対応しきれなかった業務上の課題」に対して、技術的な手段を選択する前に業務フローを整理し、実装範囲を絞り込んだ上で着手したプロジェクトです。

事例①：複数オブジェクトをまたぐ入力フローをLWCで一画面に統合——営業担当の入力工数を削減

背景・課題：商談・見積・納品先という3つのオブジェクトに対して、営業担当者が画面を行き来しながら個別に入力を行っていました。標準のページレイアウトではオブジェクトをまたいだ入力を1画面にまとめることができず、入力漏れや画面切り替えのストレスが現場で慢性化していました。

解決策：LWCを用いて、3オブジェクトへの入力を1画面で完結させるカスタムコンポーネントを開発しました。入力値のバリデーションも画面内でリアルタイムに行い、保存時には各オブジェクトへの書き込みをまとめて実行する設計にしています。

成果：1件あたりの入力操作が従来の約3分の1の時間に短縮されました。入力漏れによる差し戻しも大幅に減少し、営業担当者からの改善要望が解消されています。

事例②：Apexによる自動計算ロジックの実装——手入力ミスと承認待ち時間を削減

背景・課題：見積金額の算出に複数の変動係数（数量・割引率・為替レートなど）が絡むため、担当者がExcelで計算してからSalesforceに転記するという二段階の運用が定着していました。転記ミスが月に数件発生しており、承認フローが差し戻しで滞るケースが少なくありませんでした。

解決策：Apexのトリガーおよびサービスクラスとして計算ロジックを実装し、入力値が更新されると自動で金額が再計算される仕組みを構築しました。計算式はビジネスルールとして管理者がカスタムメタデータで管理できるように設計し、Apexの改修なしにルール変更へ対応できる柔軟性も確保しています。

成果：Excelによる手計算と転記作業がゼロになり、計算ミスに起因する承認差し戻しが解消されました。承認リードタイムが平均で1.5日短縮されています。

事例③：外部基幹システムとのリアルタイム連携——二重入力の撲滅と情報鮮度の改善

背景・課題：在庫情報と受注ステータスを管理する基幹システムと、顧客管理を担うSalesforceが独立して運用されていました。担当者が両システムを交互に確認しながら顧客対応を行う必要があり、情報のタイムラグによる誤案内が問題になっていました。

解決策：ApexのCallout機能を使って基幹システムのAPIと接続し、Salesforceの商談画面から在庫状況・受注ステータスをリアルタイムで参照できるLWCコンポーネントを実装しました。書き込みは基幹システム側を正とし、Salesforceには参照表示のみを許可する設計でデータの二重管理を防いでいます。

成果：顧客対応中のシステム切り替え操作がなくなり、誤案内件数がゼロになりました。二重入力に費やしていた時間が削減された結果、担当者一人あたり週に約2時間の業務工数が削減されています。

「企業OSとしてのSalesforce」——カスタマイズ設計で意識すべき思想

Salesforceのカスタマイズは、単発の「困りごと解消」で終わらせると、後々の運用を圧迫します。現場の要望に都度対応した結果、誰も全体像を把握できない複雑な構成になっているケースは少なくありません。意思決定者が意識すべきは、Salesforceを自社業務の基盤——いわば「企業OS」として育てていくという視点です。

カスタマイズ負債を生まないための設計原則——疎結合・命名規則・ドキュメント管理

カスタマイズ負債とは、短期的には動くが、変更・拡張のたびに影響範囲の把握に時間がかかる状態を指します。これを防ぐには、初期設計の段階から以下の原則を守ることが重要です。

• 疎結合の設計：カスタムオブジェクト・Apex・フローはそれぞれ依存関係を最小化する。一つの変更が別の箇所に予期せず影響しないよう、役割を明確に分離する。
• 命名規則の統一：オブジェクト・項目・クラス名に一貫したプレフィックスや命名ルールを設ける。「何のために作ったか」が名前から読み取れると、引き継ぎコストが大幅に下がります。
• ドキュメントの継続管理：設計意図・変更履歴・判断の根拠を残す仕組みを作る。Salesforce側の仕様変更（バージョンアップ）への追従も、記録があれば格段に対応しやすくなります。

これらは開発者だけの問題ではありません。発注側の意思決定者が「ドキュメントの納品」を要件として明示するかどうかで、プロジェクト後の保守性は大きく変わります。

「作って終わり」にならないための伴走開発という考え方

Salesforceの開発を外部に依頼する場合、要件定義・納品・検収という一括請負モデルが一般的です。しかしSalesforceは業務とともに継続的に育てるプラットフォームであり、「納品後は自社で対応」という体制が機能しないケースがほとんどです。

伴走開発とは、初期構築後も継続的に改善・拡張を支援するモデルです。業務の変化や現場フィードバックを受けながら、スモールステップで機能を積み上げていくアプローチは、大規模な作り直しリスクを減らす効果があります。CLANEはSalesforce開発においてこの伴走モデルを採用しており、要件確定から運用定着まで一貫して関与する体制を取っています。

内製化・外注・伴走の選択基準——体制と目的に応じた判断軸

カスタマイズの開発体制は、自社の状況に応じて選択する必要があります。以下を判断の目安にしてください。

• 内製化が向くケース：Salesforce認定資格を持つエンジニアが在籍し、継続的な改善サイクルを回せる体制がある。長期的なコスト最適化を重視する場合。
• 一括外注が向くケース：要件が固まっており、完成後は大きな変更が見込まれない。初期構築のスピードを優先する場合。
• 伴走開発が向くケース：業務プロセスが変化しやすい、あるいは段階的に機能を拡張したい。社内にSalesforce専任担当がおらず、設計判断を外部と一緒に行いたい場合。

体制の選択を誤ると、開発コストだけでなく、システムの属人化や運用停滞につながります。「誰が継続的に責任を持つか」を起点に、体制を設計することが重要です。

まとめ——Salesforceを「業務に合わせる」ための判断フロー

ここまで解説してきた内容を、意思決定の流れとして整理します。Salesforceを業務に合わせるうえで求められる判断は、大きく4つのステップに分けられます。

1. 標準機能の限界を確認する
2. カスタマイズの要否を判断する
3. 技術手段を選択する
4. 設計思想を確立する

最初のステップは、「標準機能で本当に対応できないのか」を見極めることです。Salesforceの標準機能は、設定変更・Flow・承認プロセスなどで広範な業務をカバーできます。現場の「使いにくい」という声がある場合でも、まずは設定の最適化や運用フローの見直しで解決できるケースが少なくありません。標準機能の限界を正確に把握することが、カスタマイズの出発点になります。

次に、カスタマイズが本当に必要かどうかを判断します。カスタマイズは業務適合性を高める一方で、アップグレード対応コストや属人化リスクも伴います。「業務上の制約が定量的に確認できる」「標準機能では代替手段がない」「長期的に運用・保守できる体制がある」といった条件を満たす場合に限り、カスタマイズに踏み切ることを検討するのが適切です。

技術手段の選択では、Apex（カスタムロジックの実装）とLWC（Lightning Web Components：画面のUI構築）を中心に、目的に応じた組み合わせを決めます。複雑な業務ロジックにはApex、現場の入力負荷を下げるUIの改善にはLWCが適しています。どちらも「標準機能ではカバーできない領域を補う手段」として位置づけることが重要です。

最後に、設計思想の確立です。個別の業務課題に対応するだけでなく、Salesforceを「企業全体の業務基盤（OS）」として捉え、データの一元管理・部門横断の情報連携・将来の拡張性を意識した設計を行うことが、長期的な運用品質を左右します。

この4ステップを社内で共有し、現場の要望を整理したうえで要件定義に臨むことが、Salesforceカスタマイズを成功に導く第一歩になります。