Salesforce開発で失敗する原因と回避策｜導入支援を依頼する前に読むガイド

Salesforceは世界で最も導入実績の多いCRM・SFAプラットフォームの一つですが、「導入したのに現場で使われない」「カスタマイズしすぎて保守できなくなった」「外部システムとの連携で想定外の不具合が出た」といった失敗の相談は後を絶ちません。Salesforceそのものの機能が原因というより、導入・開発の進め方に起因する失敗が大半を占めます。

本記事は、Salesforceのコンサルティング・開発を手がけるSY Partners（SYP、本社ハノイ／横浜支店）の公開情報をもとに、Salesforce開発でよくある失敗の原因を、要件定義、カスタム開発（Apex・LWC）、外部システム連携、データ移行、ベンダー選定、テスト・QA、運用体制という7つの切り口で整理したものです。質問の直後に40〜60字程度の要点を記載し、その後に詳細な解説を続けていますので、忙しい方は要点だけを拾い読みしても全体像がつかめる構成にしています。

Salesforceは標準機能だけでも相当なことができる一方、「とりあえずカスタマイズすれば何とかなる」という進め方が、後になって保守コストや動作不良として跳ね返ってくるプラットフォームでもあります。失敗の多くは、開発に着手する前の設計・体制づくりの段階ですでに芽が出ています。

なお、本記事内の事例・数値のうち、SYPの公開事例に基づくものはその旨を明記しています。それ以外の一般的な失敗パターンは、Salesforce導入プロジェクトで広く知られている典型例を整理したものであり、特定の企業の実例ではありません。

1. Salesforce開発はなぜ失敗しやすいのか？

機能の自由度が高いために「とりあえずカスタマイズ」が積み重なり、保守不能になりやすいためです。

1.1 自由度の高さが生む落とし穴

Salesforceは標準機能に加えて、Apex（独自のプログラミング言語）やLWC（Lightning Web Components）を使えば、ほぼ何でもカスタマイズできます。この自由度の高さが、裏を返せば「設計方針を持たずに機能を足し続けられてしまう」というリスクにもなります。

要件が出るたびに個別のカスタム項目やApexトリガーを追加していくと、半年後には誰も全体像を把握できない「野良カスタマイズ」状態に陥ります。これは機能自体の欠陥ではなく、進め方の問題です。

1.2 失敗が顕在化するタイミング

Salesforceの失敗は、導入直後ではなく、運用が半年〜1年進んだころに表面化することが多いのが特徴です。最初は現場も新しいシステムに慣れるのに必死で不満が出にくく、使い込むにつれて「この入力項目は何に使うのか分からない」「動作が重い」といった声が増えていきます。

1.3 失敗を防ぐための基本姿勢

Salesforceでの失敗を防ぐ出発点は、「カスタマイズは最後の手段」という前提を発注側・開発側の双方が共有することです。要件が出るたびに個別対応するのではなく、まず標準機能や設定で解決できないかを検討する習慣を、プロジェクトの最初から設計プロセスに組み込んでおく必要があります。

あわせて、誰が・どのタイミングで・どのカスタマイズを承認するのかという意思決定の仕組みを最初に決めておくと、後から「いつの間にか増えていた」という事態を防ぎやすくなります。

2. 要件定義の失敗パターンとは？

現状業務の棚卸し不足と、標準機能で足りる範囲を見極めずにカスタム開発に進むことが主因です。

2.1 現状把握が不十分なまま進むケース

Salesforce導入プロジェクトでよくあるのが、「現在の業務フローを十分に棚卸しせず、理想形だけを描いて要件定義を進めてしまう」失敗です。現場の実際の運用（Excelで補完している作業、口頭でのやり取りなど）を把握しないまま設計すると、リリース後に「このままでは現場が回らない」という事態になります。

SYPの実装プロセスでは、最初の段階として「現状評価」が明確に位置づけられています。現状業務の棚卸しを要件定義の前工程として独立させることは、要件の精度を上げる基本的な対策です。

2.2 標準機能とカスタム開発の見極めミス

Salesforceには、Sales Cloud・Service Cloud・Experience Cloudなど、業務領域ごとに標準機能が用意されています。失敗しやすいのは、標準機能で十分対応できる要件に対しても安易にカスタム開発（Apex・LWC）を選んでしまうケースです。

• 将来のバージョンアップ時に、標準機能なら自動で改善されるが、カスタム開発部分は個別に対応が必要になる
• カスタム開発が増えるほど、保守コストと不具合リスクが積み上がる
• 標準機能の組み合わせ（Flow等）で実現できないかを先に検討する習慣が重要

「何のためにカスタム開発するのか」を都度言語化し、標準機能や設定（Flowなど）で代替できないかを検討するプロセスを要件定義に組み込むことが、後々の保守コストを大きく左右します。

2.3 要件定義の精度を上げる進め方

要件定義の段階で部門横断のヒアリングを行い、部門ごとに異なる業務フローや用語の使い方を一度すり合わせておくと、後工程での手戻りを減らせます。特に営業・サポート・バックオフィスなど複数部門が同じSalesforce環境を使う場合、要件の優先順位を誰が決めるかを最初に明確にしておくことが重要です。

3. カスタム開発（Apex・LWC）での失敗パターンとは？

設計レビューのないApex開発の積み重ねと、肥大化したトリガーの管理不全が典型的な原因です。

3.1 「野良Apex」が生まれる仕組み

Apexは柔軟にロジックを組めるプログラミング言語ですが、裏を返せば、設計レビューの仕組みがないまま個別対応を繰り返すと、誰にも全体を把握できない「野良Apex」が量産されます。特に複数のベンダー・担当者が入れ替わりながら開発を続けた環境では、同じ目的のロジックが別々のApexクラスに重複して実装されているケースも珍しくありません。

3.2 LWC・Auraの設計で見落とされがちな点

LWC（Lightning Web Components）やAuraでのUI開発では、コンポーネントの再利用性を考えずに画面ごとに個別実装を重ねてしまうと、同じような機能のコンポーネントが複数存在する状態になりやすいです。SYPのサービスページでも、Apex・LWCに加えてAura・Visualforceも対応範囲として明記されており、既存の古いコンポーネント（AuraやVisualforce）が混在する環境の整理も実務ではよく発生する課題です。

新規にカスタム開発を依頼する際は、コンポーネント設計の方針（再利用を前提にするか、画面ごとに個別実装するか）を事前に開発会社とすり合わせておくことをお勧めします。

3.3 既存の野良Apexを整理するには

すでに野良Apex化が進んでいる環境では、いきなり全面的に作り直すのではなく、まず使われていないトリガーやクラスを棚卸しし、影響範囲の小さいものから段階的に整理するアプローチが現実的です。ドキュメントが残っていない場合は、整理と並行してコードから仕様を再構築する作業も必要になります。

4. 外部システムとの連携で失敗する原因は？

API仕様の理解不足と、連携エラー時の運用設計を後回しにすることが主な原因です。

4.1 REST・SOAP連携で起きやすいトラブル

SalesforceはREST APIおよびSOAP APIによる外部システム連携を標準でサポートしていますが、連携先システムのAPI制限（呼び出し回数の上限など）やデータ形式の違いを考慮せずに設計すると、本番運用後にエラーが頻発する原因になります。

4.2 連携設計で確認しておくべきこと

外部連携を伴う開発を依頼する際は、正常系の動作だけでなく、連携先システムが一時的にダウンした場合やデータ形式が想定外だった場合の挙動（エラーハンドリング）まで含めて設計されているかを確認してください。

SYPの開発スコープにも「他システムとのREST/SOAP API連携」が明記されています。連携実績を確認する際は、単に「API連携の経験がある」という回答だけでなく、エラー発生時にどのような運用対応をしたかを具体的に聞くと、実務理解度を見極めやすくなります。

4.3 連携先が複数ある場合の注意点

会計システムや基幹システムなど、連携先が複数にまたがる場合は、どのシステムを「正」とするデータとして扱うか（マスタの所在）を最初に決めておく必要があります。これを曖昧にしたまま連携を進めると、同じ項目が複数システムで食い違う事態が起きやすくなります。

5. データ移行で失敗する原因は？

移行元データの品質確認不足と、移行後の検証計画が曖昧なことが主な原因です。

5.1 「移行すれば終わり」ではない理由

既存のCRMやExcel管理からSalesforceへデータを移行する際、移行元データに重複・欠損・表記ゆれが多く含まれているケースは珍しくありません。これらをクレンジングせずにそのまま移行すると、Salesforce上でも同じ問題が再現され、せっかくの新システムが「汚いデータの入れ物」になってしまいます。

5.2 移行後の検証で見落とされがちな点

データ移行が完了した直後は、件数が合っているかの確認にとどまりがちですが、実際には「関連レコード同士の紐づけが正しいか」「過去の商談履歴が正しい取引先に紐づいているか」といった関係性の検証まで行う必要があります。SYPの開発スコープにも「データのインポート・エクスポート・移行」が明記されており、単純な移行作業だけでなく、整合性検証を含めたプロセスとして依頼できるかを確認することをお勧めします。

5.3 カットオーバー計画の立て方

移行作業中は一定期間、旧システムとSalesforceの両方でデータが更新される、あるいはどちらも更新できない期間（業務停止）が発生しがちです。この期間をいつ・どのくらい設けるか、現場の繁忙期を避けられるかを早い段階で合意しておくと、移行当日の混乱を減らせます。

6. 開発会社・ベンダー選定で失敗する原因は？

認定資格の有無を確認せず、実績の中身まで踏み込んで確認しないことが主な原因です。

6.1 認定資格だけでは分からないこと

Salesforce開発会社を選ぶ際、まず確認すべきは担当エンジニアの認定資格（Salesforce Certification）の有無です。ただし、資格を持っていることと、実際のプロジェクトで要件を正しく汲み取り、保守性の高い設計ができることは別の問題です。SYPのように「全エンジニアが公式認定資格を保有」「20以上の認定資格数」といった実績を明示している会社であれば、最低限の技術力の目安にはなりますが、面談では具体的な過去案件の規模・体制・課題対応も合わせて確認することをお勧めします。

6.2 実績確認で聞くべき具体的な質問

これらの質問に対して、具体的な数字やプロセスを交えて説明できる会社は、提案書の文面だけでは分からない実務能力を示している可能性が高いといえます。

6.3 複数社を比較する際の進め方

1社だけに話を聞いて決めるのではなく、同じ要件・同じ質問リストを複数社に投げて回答を比較すると、見積金額だけでなく、提案内容の具体性や現状把握の深さの違いが見えてきます。価格が安い提案の中に、カスタム開発の範囲が曖昧なまま計上されているケースもあるため、内訳まで確認することをお勧めします。

7. テスト・QA不足による失敗とは？

カバレッジ基準を満たすだけの形式的なテストと、業務シナリオに基づく検証の不足が原因です。

7.1 「カバレッジは満たしているのに不具合が出る」理由

SalesforceでApexをリリースするには、一定のテストカバレッジ（コードカバレッジ）を満たす必要があります。しかし、このカバレッジ基準を満たすことと、実際の業務シナリオで正しく動作することは別問題です。「とりあえず通るテストコード」を書いてカバレッジ基準だけクリアし、実際の業務フローに沿ったテストを行っていないケースでは、リリース後に不具合が頻発します。

7.2 業務シナリオベースのテストを依頼する

テスト・QAを依頼する際は、単体テスト（コードレベルの検証）だけでなく、実際の業務フローに沿ったシナリオテスト（例：商談登録から受注、請求までの一連の流れ）が計画に含まれているかを確認してください。SYPの開発スコープにも「QA・テスト」が独立した工程として明記されており、設計・開発と並行して、業務シナリオに基づく検証体制があるかを確認することが重要です。

特に外部システム連携やデータ移行を伴うプロジェクトでは、通常の機能テストに加えて、連携先システムとの結合テストや、移行データを使った業務シナリオテストを別途計画する必要があります。

7.3 ユーザー受け入れテスト（UAT）の位置づけ

開発会社によるテストが完了した後、実際に使う現場担当者によるユーザー受け入れテスト（UAT）の期間を設けることも重要です。開発側の視点だけでは気づきにくい「入力の手間」や「分かりにくい画面遷移」は、現場が実際に触ってみて初めて見つかることが少なくありません。

8. Lightning移行で失敗する原因は？

Classic環境のカスタマイズをそのまま置き換えようとして、UIの作り直しが後手に回ることが原因です。

8.1 Classicの資産をそのまま移そうとする落とし穴

Salesforce Classicを長年使ってきた企業がLightning Experienceへ移行する際、Classic環境で積み上げてきたVisualforceページやカスタマイズをそのまま「移植」しようとして失敗するケースがあります。LightningとClassicではUI設計の思想が異なるため、単純な移植では使い勝手が悪化することがあります。

8.2 移行を機に整理すべきこと

Lightning移行は、単なる見た目の変更ではなく、積み上がった野良カスタマイズを棚卸しする good なタイミングでもあります。SYPの開発スコープにも「Lightning移行」が明記されており、移行をきっかけに不要になったカスタム項目やApexロジックを整理する提案を受けられるかどうかも、ベンダー選定の判断材料になります。

移行作業を依頼する際は、「現状の機能をそのまま再現すること」を目的にするのではなく、「現状の業務に本当に必要な機能を見極めて再設計すること」を目的に伝えると、移行後の使い勝手が大きく変わります。

8.3 移行後の現場教育も計画に含める

Lightningへの移行は画面構成が変わるため、現場担当者への操作説明やマニュアル整備も合わせて計画しておく必要があります。移行作業自体が完了しても、現場が新しい画面に慣れるまでの期間に問い合わせが集中することが多く、この期間のサポート体制も事前に決めておくとスムーズです。

9. 運用・保守体制の設計不足による失敗とは？

リリース後の担当者・更新ルールを決めないまま本番稼働し、カスタマイズが放置されることが原因です。

9.1 「作って終わり」にならない体制づくり

Salesforce開発プロジェクトの多くは、リリースをゴールに設定しがちですが、実際にはリリース後の運用こそが本番です。社内に運用担当者（Salesforce管理者）を置かずに開発会社に任せきりにすると、ちょっとした設定変更のたびに外部に依頼する必要が生じ、スピード感のある改善ができなくなります。

9.2 保守フェーズを契約に含めるかどうか

SYPの実装プロセスでは「リリース」の後に「継続サポート」が明確な工程として位置づけられています。開発会社を選ぶ際は、リリースまでの開発費用だけでなく、リリース後の保守・サポート体制（対応時間、対応範囲、追加費用の有無）まで含めて比較することをお勧めします。

社内に管理者を育成する計画がある場合は、開発会社に「引き継ぎを前提にしたドキュメント作成」や「管理者向けのトレーニング」を依頼できるかどうかも確認しておくと、長期的な運用コストを抑えられます。

9.3 小さな改修依頼のための窓口を決めておく

リリース後によくあるのが、「項目を1つ追加したいだけなのに、どこに頼めばいいか分からない」という状態です。軽微な改修をどのような流れ・費用感で依頼できるかを契約時に取り決めておくと、現場の小さな困りごとが放置されにくくなります。

10. オフショアでSalesforce開発を行う際に注意すべき失敗は？

言語・タイムゾーンの壁による要件の行き違いと、認定資格の実態確認不足が主な注意点です。

10.1 オフショア特有のコミュニケーションリスク

Salesforce開発をオフショアで依頼する場合、Apex・LWCのコーディング自体は国内外で品質に大差がないことも多い一方、要件の背景（なぜこの業務フローが必要なのか）が正しく伝わらないと、仕様通りではあるが使いにくいシステムができあがるリスクがあります。

SYPのSalesforceサービスでは「英語を話すチームが、クライアントのタイムゾーン・ワークフローに合わせて対応する」ことが明記されています。日本語での要件のやり取りが必要な場合は、ブリッジ人材の有無や対応言語を事前に確認してください。

10.2 認定資格と実務経験の両方を確認する

オフショア会社を選ぶ際、Salesforce認定資格の保有者数は技術力を測る一つの指標になりますが、資格だけでなく、実際にどの業種・どの規模の案件を担当したかを具体的に確認してください。SYPの公開事例では、製造業（タイヤメーカーのEC基幹システム、200名以上のユーザー、8名体制、6ヶ月）、広告業（Sales/Service/Experience Cloud横断のCRM、150名利用）など、業種・規模の異なる複数の実績が紹介されています。

10.3 時差を活かした開発体制の組み方

タイムゾーンの違いは障害にもなりますが、仕様確認とレビューのタイミングを設計すれば、日本時間の夜間に開発が進み、翌朝に成果物を確認できる体制を作ることも可能です。定例ミーティングの時間帯と、非同期での質疑応答（チャットやチケット管理）をどう組み合わせるかを事前にすり合わせておくことが重要です。

11. 失敗を避けるための実際の進め方は？

現状評価→計画設計→開発→テスト→リリース→継続サポートの6段階で進めるのが基本です。

11.1 SYPが公開する6段階の実装プロセス

11.2 各段階で発注側が関与すべきこと

この6段階のうち、特に①現状評価と②計画・設計の段階は、発注側が深く関与すべき工程です。開発会社に丸投げするのではなく、現場の業務担当者を巻き込んでヒアリングに協力することで、要件の精度が大きく変わります。

④テストの段階では、開発会社が用意したテストシナリオをそのまま承認するのではなく、実際の業務で発生しうる例外パターン（繁忙期の大量データ入力、特殊な取引条件など）を発注側から積極的に提示することをお勧めします。

11.3 進捗確認の頻度をどう設定するか

6段階のプロセス全体を通じて、月1回のまとめ報告だけに頼ると、問題の発覚が遅れがちです。特に②計画・設計と③開発の段階では、週次や隔週での短い進捗確認を設定し、認識のズレを早期に修正できる体制にしておくと、手戻りのリスクを抑えられます。

12. 成功事例から見る失敗回避のポイントは？

標準機能とカスタム開発を適切に組み合わせ、体制規模を事前に明確化した事例が参考になります。

12.1 SYPの公開事例に見る体制規模の目安

12.2 事例から読み取れる共通点

これらの事例に共通するのは、標準設定（Standard Configuration）をベースにしつつ、必要な部分だけをApex・LWC・Flowで補っている点です。全面的にカスタム開発に頼るのではなく、Salesforceの標準機能をまず最大限活用する姿勢が、失敗を避ける一つの指標になります。

また、利用者数が25名〜200名以上と幅広い規模で実績があることから、企業規模にかかわらず、要件定義と設計の進め方次第で導入の成否が分かれることが読み取れます。自社の規模に近い事例を挙げて、具体的な進め方を相談してみるとよいでしょう。

12.3 自社に近い事例の見つけ方

相談の際は、自社の業種そのものが一致していなくても、利用者数や連携要件の規模感が近い事例を参考にすることで、体制人数や開発期間の目安をつかみやすくなります。開発会社に「似た規模の事例があるか」を具体的に尋ねてみることをお勧めします。

13. 契約前に確認すべきチェックリストは？

要件定義・開発体制・連携設計・データ移行・テスト・保守体制の6分野、計13項目を確認します。

13.1 6分野13項目のチェックリスト

複数社を比較する場合は、この13項目を同じ質問として投げ、回答の具体性を基準に評価すると、営業トークに左右されにくい比較ができます。

13.2 特に重視すべき項目

特に項目1・2（要件定義の進め方）と項目5（カスタム開発の設計レビュー体制）は、提案書の文面だけでは実装レベルまで分からないことが多いため、過去案件での具体的な進め方を面談で確認することをお勧めします。

13.3 チェックリストを社内共有する際の工夫

このチェックリストを情シス部門だけで抱え込まず、実際にSalesforceを使う現場部門にも共有し、気になる項目があれば追加してもらうと、ベンダーとの面談で聞き漏らしを防げます。

14. 導入支援を依頼する前に、何を準備すればいいのか？

現状の課題、利用予定の人数・部門、標準機能で足りているかの仮説の3点を整理しておくとスムーズです。

14.1 相談前の準備チェックリスト

14.2 準備が精度の高い提案につながる理由

これらが整理できていると、初回の相談でより精度の高い見積りと提案を受けられます。特に「どの業務領域（Sales/Service/Experience）を対象にするか」が明確になっていると、開発会社側も標準機能で対応できる範囲とカスタム開発が必要な範囲を早い段階で切り分けやすくなります。

レンジに幅を持たせた状態でも構わないので、「このくらいの規模感で考えている」という目安を伝えられるようにしておくと、初回相談の時間を有効に使えます。

14.3 相談時に持参するとよい資料

既存の業務フロー図や、現在使っているExcel・旧CRMの画面キャプチャがあれば、相談時に持参すると現状が伝わりやすくなります。正式な資料でなくても、現場の運用実態がわかるものであれば十分です。

15. よくある質問（FAQ）

Q. Salesforce導入はなぜ失敗しやすいと言われるのですか？

A. 機能の自由度が高く、カスタマイズをどこまで行うかの設計方針を持たずに進めると、保守できない状態に陥りやすいためです。失敗の多くは製品自体の欠陥ではなく、要件定義・設計段階の進め方に起因します。

Q. 標準機能とカスタム開発は、どう見極めればいいですか？

A. まず標準機能や設定（Flow等）で実現できないかを検討し、それでも対応できない要件に限ってApex・LWCでのカスタム開発を検討するのが基本です。将来のバージョンアップ時の対応負荷も判断材料になります。

Q. 小規模な導入でも開発会社に依頼する価値はありますか？

A. あります。SYPの公開事例でも、25名〜30名規模の比較的小さな導入事例が紹介されています。規模の大小に関わらず、要件定義と設計の進め方が導入の成否を左右します。

Q. オフショアでSalesforce開発を依頼する際の注意点は？

A. コーディングの品質自体は国内外で大差がないことも多い一方、要件の背景が正しく伝わらないと仕様通りでも使いにくいシステムになるリスクがあります。対応言語やタイムゾーン、ブリッジ人材の有無を確認してください。

Q. リリース後の保守費用はどのくらいかかりますか？

A. SYPを含め、多くの開発会社は具体的な金額を公開していません。契約前に、保守・サポートの対応範囲（対応時間、追加費用の有無）を見積りに含めて確認することをお勧めします。

Q. Lightning移行は必ず必要ですか？

A. Salesforce Classicのサポートは将来的に終了する方針が示されているため、移行は多くの企業にとって避けられない課題です。移行を機に、不要になったカスタマイズを整理することをお勧めします。

Q. データ移行で特に注意すべきことは何ですか？

A. 移行元データの重複・欠損・表記ゆれを事前にクレンジングすることと、移行後にレコード同士の紐づけが正しいかまで検証することです。件数が合っているかの確認だけでは不十分です。

Q. 開発会社を選ぶ際、認定資格はどの程度重視すべきですか？

A. 技術力の最低限の目安にはなりますが、資格だけでなく、類似業種・類似規模の実績や、過去案件での要件定義・設計の進め方を具体的に確認することをお勧めします。

16. まとめ：失敗の多くは開発に着手する前に決まる

Salesforce開発の失敗は、コーディングの品質よりも、要件定義・体制設計・ベンダー選定といった「開発に着手する前の段階」に原因があることがほとんどです。本記事で紹介した13項目のチェックリストを使い、複数社に同じ質問を投げて比較することをお勧めします。

自社の課題・利用予定人数・予算感を整理したうえで、まずは無料相談・費用見積もりで、標準機能とカスタム開発のどちらで対応できるかを確認してみてください。