Salesforceの開発依頼において、最も多いトラブルは技術的な不具合ではなく「コミュニケーションの相違」です。「思っていたものと違う」「追加費用を請求された」といった問題は、多くの場合、プロジェクト初期の「要件定義」に原因があります。
この記事では、ITエンジニアを200名以上抱え、システム開発を25年以上経験する株式会社エフ・ディー・シー、DX部 佐々木舞美が、現場で起きたリアルな失敗事例を基に、リスクを回避しプロジェクトを成功させるための鉄則を解説します。
- Salesforce開発依頼で後悔した企業が共通して陥る「丸投げ」の罠
- 事例1：要件定義の曖昧さが招いた「使いにくい画面」と「低い利用率」
- 事例2：Salesforceの標準仕様を知らずに「無理な作り込み」をした末路
- salesforce 開発依頼で「言った・言わない」を根絶する議事録と承認フロー
- 【解決策】株式会社エフ・ディー・シーの「sfsolution」
- FAQ：開発トラブル回避に関する一問一答
- デモ（プロトタイプ）を早期に確認することの重要性
- UAT（ユーザー受け入れテスト）でチェックすべき項目リスト
- 契約締結前に合意しておくべき「瑕疵（かし）」の定義
- 次のステップ：[Salesforce開発費用相場の再確認]
- まとめ
Salesforce開発依頼で後悔した企業が共通して陥る「丸投げ」の罠
結論から述べると、開発会社に「自社の業務をすべて理解しているはずだ」と期待し、要件を丸投げすることが最大の失敗要因です。
なぜ丸投げは失敗するのか？
開発会社はSalesforceのプロですが、貴社の「独自の商習慣」や「現場の暗黙の了解」までは把握できません。要件定義とは、貴社の業務知識と開発会社の技術知識を「融合させる作業」であることを認識する必要があります。
「パッケージだから簡単」という誤解
Salesforceは柔軟すぎるがゆえに、設定一つで業務フローが劇的に変わります。標準機能でできること・できないことの線引きを曖昧にすると、納品後に「こんなはずじゃなかった」という事態を招きます。
事例1：要件定義の曖昧さが招いた「使いにくい画面」と「低い利用率」
【失敗事例】 ある企業では、営業効率化のためにSalesforceを導入しましたが、要件定義で「管理したい項目」をすべて詰め込みすぎた結果、現場が1回の商談で入力すべき項目が50個を超えてしまいました。
- 結果： 入力が面倒になり、現場がSalesforceを使わなくなった。
- 教訓： 開発依頼時には「何を入力するか」だけでなく、「入力者の負担」を考慮した優先順位付けが不可欠です。
事例2：Salesforceの標準仕様を知らずに「無理な作り込み」をした末路
【失敗事例】 「今のエクセルと全く同じ見た目にしてほしい」という要望に応え、Apex（プログラム）でフルスクラッチの入力画面を構築しました。
- 結果： Salesforceのバージョンアップのたびに画面が崩れ、修正に多額の保守費用が発生。
- 教訓： 無理なカスタマイズは「技術負債」となります。標準機能に業務を寄せる勇気も、コストを抑えるためには重要です。
合わせて読みたい：AppExchange活用vsスクラッチ開発。どちらが安くて効率的か？｜Salesforce開発手法の正解
salesforce 開発依頼で「言った・言わない」を根絶する議事録と承認フロー
トラブルを防ぐ最強の武器は、リアルタイムな議事録の共有と、フェーズごとの「記名押印（または承認）」です。
口頭での合意は後で必ずトラブルになります。打ち合わせ中、画面を共有しながらその場で議事録を作成し、決定事項と宿題事項を可視化することで、認識のズレをその場で修正できます。
【解決策】株式会社エフ・ディー・シーの「sfsolution」
お客様と「同じ目線」でプロジェクトを進めるのが、弊社のsfsolution（https://www.fdc-inc.co.jp/sfsolution/）です。
- 25年の経験が裏打ちする「ヒアリング力」 単に要望を聞くのではなく、「なぜそれが必要なのか？」という背景まで深掘りし、潜在的なニーズを掘り起こします。
- 200名のエンジニアによる確実な実装 要件定義で決まった内容を、正確にシステムへ落とし込む高い実装力。曖昧さを残さないドキュメント作成を徹底しています。
FAQ：開発トラブル回避に関する一問一答
Q：開発途中で仕様変更をしたくなった場合、どうすればいいですか？
A： 早急に申し出てください。ただし、変更がスケジュールや費用に与える影響（インパクト）を必ず提示してもらい、正式な変更合意書を交わすことが、後の「追加費用トラブル」を防ぐ鍵です。
Q：開発会社が提示する「検収」とは何ですか？
A： 納品物が依頼通りに作られているかを確認し、プロジェクトの完了を認める作業です。ここを適当に済ませると、後の不具合が「有償」になる可能性があるため、テスト計画をしっかり立てて臨む必要があります。
Q：エンジニアと話が噛み合わない時の対処法は？
A： 図解（フローチャート）やプロトタイプ（試作画面）の提示を求めてください。言葉の定義は人によって異なるため、常に「視覚化」された資料で会話するのが鉄則です。
デモ（プロトタイプ）を早期に確認することの重要性
「百聞は一見に如かず」です。開発の最終段階まで動くものを見ないのは極めて危険です。
弊社では、開発の初期段階からSandbox（テスト環境）を用いて、主要な機能のデモを行います。早い段階で実機を確認することで、認識の相違を早期に発見し、修正コストを最小限に抑えることができます。
UAT（ユーザー受け入れテスト）でチェックすべき項目リスト
本番公開前に、必ず現場ユーザーがテストを行う工程（UAT）を設けてください。
- 業務フロー通りに動くか： 異常系のデータ（不適切な入力など）でもエラーにならないか。
- レポートは正しいか： 必要な集計が正確に行われているか。
- 操作性はどうか： マニュアルなしでも直感的に操作できるか。
契約締結前に合意しておくべき「瑕疵（かし）」の定義
「納品後に不具合が見つかった場合、いつまで無償で対応してくれるか」を明確にしておきましょう。
通常、請負契約では3ヶ月〜6ヶ月程度の瑕疵担保期間が設けられますが、この期間の定義や、何が「バグ」で何が「仕様変更」なのかの線引きを契約時に握っておくことで、無用な衝突を避けられます。
次のステップ：[Salesforce開発費用相場の再確認]
トラブル回避の術を身につけたら、改めて「適正な価格」での依頼ができているかを確認しましょう。無理な安値もまた、トラブルの温床となります。
→Salesforce開発の費用相場と見積もりシミュレーション｜予算別カスタマイズガイド
【筆者情報：株式会社エフ・ディー・シー】
この記事を執筆した株式会社エフ・ディー・シーは、Salesforce開発において以下の強みを持つ技術者集団です。
- 25年以上のシステム開発実績： 数多のプロジェクトの「修羅場」をくぐり抜けてきた経験から、トラブルの芽を未然に摘むリスク管理能力に長けています。
- 200名以上の現役エンジニア集団： 「エンジニアが足りなくて納期が遅れる」「担当者がいなくて不具合に対応できない」といったリソース起因のトラブルを防ぎます。
- DX部 佐々木舞美による監修： 「お客様のビジネスを成功させること」をゴールに掲げ、単なる受注者ではなくパートナーとしての誠実なコミュニケーションを監修しています。
まとめ
Salesforce開発依頼の成功は、要件定義における「徹底した可視化」と「責任範囲の明確化」にかかっています。「言った・言わない」を防ぐためのプロセスを惜しまないパートナーを選びましょう。
もし、現在のプロジェクトの進め方に不安がある、あるいは確実な開発を求めるのであれば、25年の実績を持つ株式会社エフ・ディー・シーへご相談ください。
