SalesForce導入・改修の期間は、規模、カスタマイズ範囲、新規か既存環境の改修かで決まります。Apex・LWCの開発を含む本格導入では、3〜6ヶ月程度が目安です。この期間は、導入パートナーを選ぶ方や社内で日程を立てる方が、現実的な計画を組むときの判断軸になります。
SalesForce（Salesforce.com社）は、クラウド型CRM・SFA基盤です。製品には、Sales Cloud、Service Cloud、Marketing Cloud Account Engagement（旧称Pardot）があります。
▼全体ガイドの記事
・SalesForce導入支援・改修の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
SalesForce導入・改修の開発期間の全体像
期間は、Sales Cloudのみか、Service CloudやMarketing Cloud Account Engagementも含むかで変わります。さらに、Apex・LWCの範囲や、新規導入か既存環境の改修・再構築かも期間に影響します。
標準機能中心の小規模導入は、最短2週間から1〜3ヶ月程度が目安です。Apex・LWCの開発を含む本格導入は3〜6ヶ月程度で、複数部門・製品への展開や大規模改修は、6ヶ月〜1年以上かかることがあります。
工程別に見ると、要件定義・フィット&ギャップ分析には2週間〜1ヶ月程度を要します。続いて、Sandboxでの実機検証に数週間〜1〜2ヶ月程度、その後の開発・移行・研修に1〜3ヶ月程度かかります。
単一部門でSales Cloudの標準機能を使う場合は、数週間〜数ヶ月で立ち上がります。一方、複数製品や基幹システム連携、複雑なApex処理を含む場合は、より長期になります。
期間の大半を占めるのは、契約後にシステムを使える状態にする作業より、営業・カスタマーサービス業務を標準機能に合わせ、現場で使える状態にする時間です。これは新規導入にも既存環境の改修にも共通します。
規模別の開発期間の目安
規模別の期間は、部門数とカスタマイズ範囲を基準に見積もります。区分は、対象部門の数とカスタマイズの広さで3つに分かれ、区分ごとに期間の幅が変わります。
- 小規模：標準機能中心で最短2週間〜1〜3ヶ月程度
- 中規模：独自開発や連携を含み3〜6ヶ月程度
- 大規模：複数製品や大規模改修を含み6ヶ月〜1年以上
まずは小規模なスモールスタートから確認します。小規模に当たるのは、単一部門・単一業務でSales Cloudの標準機能を使う場合で、営業部門の案件管理のみを対象にする構成もあります。
導入支援費用は50万〜300万円程度に収まりやすい傾向があります。また、Apex・LWCのプログラミング開発を伴わない範囲なら、比較的短期間で立ち上がります。
中規模は、Service Cloudの追加や独自ロジック・画面のカスタマイズを含む構成です。基幹システムとのデータ連携を含む構成も中規模になります。カスタム開発を伴うため、費用は300万円以上になることが多くあります。
大規模は、複数製品の全社導入や、複数の外部システムとの複雑な連携を含みます。大規模なApex開発や既存環境の全面改修・再構築も、この区分に含まれます。対象部門・拠点数が多い場合は、1年を超えることもあります。
要件定義でのフィット&ギャップ分析の精度が、その後の期間を左右します。いずれの規模でも、加えて標準機能と自社業務の適合度、現場定着、データ移行の検証がクリティカルパス（最も長い工程の流れ）になります。
新規導入と既存SalesForce環境の改修・再構築での期間の違い
SalesForce導入支援・改修の対象は、真っさらな状態から始める新規導入だけではありません。担当者の異動や退職を経て設定の意図が不明になり、独自ロジックが積み重なった環境の改修・再構築も含まれます。
新規導入と既存環境の改修では、着手時に必要な工程が異なります。
- 新規導入：要件定義から入ります。
- 既存環境の改修：現状を把握し、オブジェクト、カスタム項目、Apexコード、自動化フローを一覧にします。
- 改修範囲の判断：ワークフロールールやFlowなどを確認し、標準機能で代替できる範囲と業務上必要なカスタマイズを切り分けます。
現状分析には、通常の要件定義とは別に2週間〜1ヶ月程度を見込みます。分析せずに見切り発車すると、未使用と思っていた機能が特定部署の基幹業務と判明し、大幅な手戻りになることがあります。そのため、現状分析の確保が、納期を左右する最初の分岐点になります。
要件定義から本番稼働までの工程別スケジュール
標準的な工程は、要件定義から始まり、設計を経て、本番移行に至ります。一般的な3〜6ヶ月の導入では、工程ごとに次のように期間を割り振ります。
- 1ヶ月目：要件定義とフィット&ギャップ分析
- 2ヶ月目：設計と、Sandbox環境での初期構築
- 3〜4ヶ月目：カスタマイズ開発、データ移行、テスト
- 5〜6ヶ月目：研修、並行運用による検証、本番稼働
1ヶ月目に営業課題を整理し、標準機能と追加開発の範囲を切り分けます。この切り分けが後の工程の前提となり、不十分だと後の工程で手戻りが生じることがあります。
特に開発・データ移行の工程は、全体の中でも作業量が大きくなります。顧客・商談データを新しいオブジェクト構造に対応させ、現場が操作に慣れる必要もあります。
本番移行後にも、見落とされがちな定着支援の工数が生じます。入力が定着せず「以前のExcelが早い」と反発が出る場合があるため、初期見積もりに支援期間を含めておく必要があります。
要件定義・フィット&ギャップ分析フェーズ
前半では、業務の課題を整理したうえで要件を固め、標準機能で満たせるかを確かめます。
- 課題整理：既存業務の流れと、SalesForceで実現する目的の明確化
- 要件定義：必要な項目、レポート、自動化フローの整理
- 適合確認：標準機能で満たせる要件と、追加開発の範囲の検証
課題整理では、営業やカスタマーサービスでExcelなどを使って行っている業務を一覧にします。目的には、営業標準化、問い合わせの一元管理、マーケティング連携などがあります。
要件定義は通常2週間〜1ヶ月程度で、週1〜2回の打ち合わせを想定します。また、要件定義書の作成には1〜2週間程度かかるとされます。
業務の洗い出しに時間をかけると、開発期間全体の短縮につながるという指摘があります。
フィット&ギャップ分析では、実際の業務データを使って要件を確かめます。そのうえで、標準機能で満たせるか、Apex・LWCで補うかを契約前後に検証します。
分析が不十分だと、契約後に追加開発が頻発する原因になります。さらに、標準機能で不足する独自要件は、開発費用が300万円〜となることがあります。
分析の精度は、後半工程の手戻りとコストを左右します。そのため、前半に十分な時間を確保し、標準機能とApex・LWCで拡張する範囲を早期に分けておく必要があります。
設計・カスタマイズ開発・データ移行・本番移行フェーズ
後半は、SalesForce上でオブジェクト、画面、自動化フローを設計・構築する段階です。そのうえで、データを整え、現場が使える状態にして本番へ切り替えます。
- 設計・初期構築：Sandboxでの構成・権限の設計と、初期の構築
- データ移行：既存データのSalesforce標準オブジェクトへの対応
- 研修・テスト：現場による操作の習得と、実データでの業務確認
- 本番移行：旧運用との並行稼働による問題確認と切り替え
フィット&ギャップ分析で見つかった差分は、必要な範囲でApex・LWCにより実装します。
顧客・商談・活動履歴は、旧システムとSalesforceでデータ構造が異なることがあります。さらに、既存環境の改修では、重複や不整合のあるデータのクレンジングに工数がかかります。
対象機能を絞って段階的に慣れてもらうと、膨大なマニュアルで現場が混乱する失敗を避けられます。
並行稼働では、Excel管理や別ツールを使った旧来の運用を、新しい仕組みと並べて動かします。本番前に、想定外の運用上の問題を洗い出せる貴重な期間です。ただし、並行期間を短縮しすぎると、稼働直後に現場が混乱するリスクが高まります。
SalesForce固有でスケジュールに影響する工程
Salesforceは高いカスタマイズ性があるため、一般的なクラウド導入とは異なる考慮が要ります。特に、Apex・Lightning Web Componentsの範囲確定とSandboxでの段階検証が、期間を左右します。
Apex・Lightning Web Componentsによるカスタマイズ範囲の確定
Apexは、サーバーサイドのロジックを実装するSalesforce独自のプログラミング言語です。Lightning Web Components（LWC）は、Web標準技術を基にした画面用UIコンポーネントのフレームワークです。
標準機能で満たせない要件を、ApexやLWCでどこまで補うかは、最初に下す大きな意思決定です。この判断が全体の期間を左右します。
- 初期から広く開発：要件定義と設計の範囲が広がります。
- 段階的に拡張：標準機能とFlowなどで先に稼働させ、定着後に追加します。
- 将来分も設計：追加機能と初期のデータ構造が合わなくなるのを防ぎます。
たとえば、複雑な承認や独自の自動計算を同時に作ると、前半だけで数週間〜1ヶ月以上かかることがあります。
ノーコードの自動化機能にはFlowなどがあります。ただし、高機能なSalesforceは学習コストも高く、専任のアドミニストレーター（管理者）の育成・配置も必要です。
過度なカスタマイズは、標準の保守対象から外れやすく、更新のたびに追加の対応が生じやすくなります。一方、初期に作り込めば後の追加作業を避けられますが、要件定義・検証の負荷は増えます。
Sandbox環境を使った段階的な開発・検証プロセスに要する期間
Sandboxは、本番とは別の検証用複製環境で、段階的な開発・検証に使います。種類によって複製する範囲が異なり、個人開発向けのものから、本番環境を完全に複製したものまであります。
- 小規模向け：メタデータのみを複製し、リフレッシュは1日1回程度可能
- 一部データを含む環境：外部連携やユーザー受入テスト向け
- 完全複製環境：全社的な回帰テストや性能検証向け
一部データを含む環境や完全複製環境ほど、最新の本番状態に更新するリフレッシュに日数がかかります。
開発チームは、小規模なSandboxでApex・LWCを実装します。複数の開発者で結合する段階では大きな環境へ移し、本番相当のデータで受入テストを行います。
段階的なSandboxの活用は品質を保つ工程ですが、種類や更新時期を誤ると、最新データが反映されません。また、開発者同士の変更が競合した場合も、手戻りで日程が遅れます。
本番規模のSandboxは更新に日数がかかるため、本番直前に最新データで再検証できない場合があります。そのため、Sandbox戦略はプロジェクト初期に立てておく必要があります。
納期遅延の典型要因と対策
遅延の多くは、技術問題よりも、範囲の見極め不足や既存環境の負債の過小評価に起因します。代表的な遅延要因は、範囲の見積もり誤りと、既存環境の技術的負債の過小評価の2つで、それぞれに対策があります。Apex開発が想定以上に長引く例もあります。
月額数千円で何でも実現できると思っても、追加のカスタム開発費用や期間が必要になる場合があります。さらに、新しい入力ルールが定着せず、日程が押すこともあります。
カスタマイズ範囲の過小・過大評価による手戻り
カスタマイズ範囲の見積もり誤りは頻度の高い遅延要因で、過大に見ても過小に見ても手戻りが生じます。誤り方には、大きく3つの型があります。
- 範囲を広げすぎる：Apex・LWCで作り込むと設計の負荷が膨らみ、稼働が遅れます。
- 範囲を狭く見積もる：初期設計で拡張性を欠くと、追加開発の際に構造を作り直すことがあります。
- 分析が不十分：契約・構築後に軽微な変更が積み重なり、大規模開発に近い工数になることがあります。
なかでも、標準機能で不足する要件のカスタム開発は、300万円以上に達することがあり、最大の遅延要因にもなります。
契約前に、Apex・LWCで初期開発する範囲と将来追加する範囲を分け、ロードマップを描きます。加えて、初期設計では、将来の拡張を見据えてオブジェクト構造を検討します。
既存SalesForce環境の改修特有の遅延要因（技術的負債の過小評価）
長年運用した環境では、独自ロジックや意図の不明な設定が蓄積し、技術的負債の過小評価が遅延につながります。
- 独自設定の蓄積：長年の運用で、標準機能を使わないロジックが残ることがあります。
- 意図が不明な設定：異動や退職で、カスタム項目や自動化フローの意図が分からなくなります。
- 暗黙知への依存：専任のシステム管理者が1人しかいない「一人情シス」体制では、担当者の頭の中に情報が偏ることがあります。
既存の設定に手を入れず、新しい設定を重ねる「増築の繰り返し」が起きることもあります。
現状分析で複雑さを把握できないと、想定以上の解きほぐし作業が発生します。担当者だけが知る暗黙知は、ヒアリングで拾いきれないことがあります。
そこで、着手前に分析期間を確保し、変更ログや命名規則を整理して、状況が見えるようにします。
改修のレベルには、部分的なリブート、大部分のリビルド、設計思想からのリデザインがあります。選択肢は早めに絞り、対象範囲に合わせて現実的な日程を組みます。
既存環境の改修・再構築を専門とする外部パートナーへ、早い段階で相談することも有効です。
まとめ
本文では、規模別の期間、工程別の日程、Salesforce固有の検討工程、遅延要因と対策を解説しました。CRM・SFA機能の一般論は対象外で、扱ったのはSalesforce基盤の導入・カスタマイズ・改修です。
期間の目安は、標準機能中心なら最短2週間〜1〜3ヶ月、本格導入なら3〜6ヶ月です。さらに、複数製品や大規模改修では、6ヶ月〜1年前後、またはそれ以上に延びます。
高いカスタマイズ性を持つSalesForceでは、Apex・LWCの範囲決定やSandboxでの検証が期間を左右します。既存環境の改修では、着手前に技術的負債を見えるようにする期間を確保します。
フィット&ギャップ分析の結果を範囲の見積もりに反映させ、既存環境の複雑さも確認します。最後に、自社の業務と既存環境を整理し、SalesForce導入実績のあるパートナーに相談します。
▼全体ガイドの記事
・SalesForce導入支援・改修の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。