SalesForce導入支援・改修の開発期間・スケジュール・納期について

SalesForce（Salesforce）は、Salesforce.com社が提供するクラウド型のCRM（顧客関係管理）・SFA（営業支援）プラットフォームであり、営業支援に特化した「Sales Cloud」、カスタマーサービス・問い合わせ対応に特化した「Service Cloud」、B2Bマーケティングオートメーションの「Marketing Cloud Account Engagement」（旧称Pardot）といった複数の製品群で構成されています。本記事で扱う「SalesForce導入支援・改修」は、CRM・SFAという機能そのものの一般的な解説ではなく、Salesforceという特定クラウドプラットフォームを対象にした「導入プロジェクト」、すなわち標準機能のセットアップからApex（Salesforce独自のプログラミング言語）やLightning Web Components（LWC）を用いたカスタマイズ開発、さらには既存Salesforce環境が複雑化・属人化してしまった場合の改修・再構築までを含む実装プロジェクトに焦点を当てます。実際に導入を検討する担当者や、既にSalesforceを運用していて改修を検討している情報システム部門の方からは、「新規導入はどのくらいの期間で立ち上がるのか」「Apex・LWCのカスタム開発が入るとスケジュールはどう変わるのか」「すでに複雑化した既存環境の改修にはどれくらい時間がかかるのか」といった、開発期間・スケジュール・納期に関する疑問が数多く挙がります。

本記事では、SalesForce導入支援・改修における開発期間・スケジュール・納期に焦点を当て、規模別の期間目安、要件定義からフィット&ギャップ分析・設計・カスタマイズ開発・データ移行・トレーニング・本番稼働までの工程別の期間配分、Apex・LWCによるカスタマイズ範囲の確定やSandbox環境を使った段階的な検証プロセスといったSalesforce固有の工程がスケジュールに与える影響、そして納期遅延の典型要因と対策までを、具体的な数値とともに体系的に解説します。クラウド型のSaaSプラットフォームであっても「システムを契約してから使えるようになるまでの時間」よりも「自社の営業・カスタマーサービスプロセスを標準機能にどこまで乗せられるかを見極め、現場が実際に使いこなせる状態を作り込むまでの時間」がスケジュールの大半を占めるという特性は、新規導入・既存改修のいずれにも共通します。これから導入パートナーを選定する方はもちろん、社内でスケジュールを策定する立場の方にとっても、現実的な計画を立てるための判断軸が身に付くはずです。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・SalesForce導入支援・改修の完全ガイド

SalesForce導入・改修の開発期間の全体像

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による複雑な自動化処理まで見据える場合は、より長期のスケジュールになる点に留意が必要です。重要なのは、SalesForceのようなクラウド型SaaSプラットフォームであっても「契約してシステムが使える状態になるまでの時間」だけでなく「自社の営業・カスタマーサービスプロセスを標準機能にどこまで乗せられるかを見極め、現場が実際に使いこなせる状態を作り込むまでの時間」がスケジュールの大半を占めるという点であり、この構造は新規導入・既存改修のどちらでも変わりません。

SalesForce導入の期間は、プロジェクトの規模とカスタマイズの程度によって大きく3つのレンジに分けて考えると計画が立てやすくなります。まず小規模なスモールスタートのケースです。単一部門・単一プロセス（例えば営業部門の案件管理のみ）で、Sales Cloudの標準機能を中心とした構成であれば、最短2週間〜1〜3ヶ月程度で最初の稼働にたどり着けます。標準的な導入支援パートナーへの依頼費用も50万〜300万円程度に収まりやすく、Apex・LWCのプログラミング開発を伴わない範囲であれば比較的短期間で立ち上げられます。次に中規模のケースです。Sales Cloudに加えてService Cloudの導入や、Apex・LWCによる自社独自の業務ロジック・画面のカスタマイズ、既存の基幹システムとのデータ連携を伴う構成では3〜6ヶ月程度が目安になります。この場合、カスタム開発を伴うため費用は300万円以上になることが多く、要件定義段階でのフィット&ギャップ分析の精度がその後のスケジュールを大きく左右します。最後に大規模なケースです。Sales Cloud・Service Cloud・Marketing Cloud Account Engagementを組み合わせた全社導入、あるいは複数の外部システムとの複雑な連携・大規模なApex開発を伴う場合、さらには後述する既存環境の全面的な改修・再構築を伴う場合は、6ヶ月〜1年、対象部門・拠点数が多い場合は1年を超えることもあります。いずれの規模でも、標準機能と自社業務の適合度の見極めと、現場への定着・データ移行の検証がクリティカルパスになるという構造は共通しています。

SalesForce導入支援・改修という本キーワードが対象とするのは、真っさらな状態から始める新規導入だけではありません。すでに数年間にわたり運用してきたSalesforce環境が、担当者の異動・退職を経て設定の意図が分からなくなり、標準機能を使わない独自ロジックが積み重なって複雑化した状態から立て直す「改修・再構築」プロジェクトも重要な対象です。新規導入と既存環境の改修では、期間の組み立て方が異なります。新規導入では要件定義から着手できますが、改修・再構築の場合はまず「現状の可視化」という追加工程が必要になります。既存のオブジェクト構成・カスタム項目・Apexコード・自動化フロー（ワークフロールール、Flow等）を棚卸しし、どの部分が標準機能で代替可能か、どの部分が業務上どうしても必要なカスタマイズなのかを判定する現状分析には、通常の要件定義に加えて2週間〜1ヶ月程度の追加期間を見込む必要があります。この現状分析を省略して見切り発車で改修に着手すると、後工程で「実は誰も使っていないと思っていた機能が特定部署の基幹業務だった」といった想定外の依存関係が発覚し、大幅な手戻りにつながるリスクが高まります。改修・再構築プロジェクトでは、この現状分析フェーズをスケジュールの序盤にきちんと確保できるかどうかが、プロジェクト全体の納期を左右する最初の分岐点になります。

要件定義から本番稼働までの工程別スケジュール

SalesForce導入プロジェクトの標準的な工程は、大きく「要件定義・フィット&ギャップ分析」「設計・Sandbox構築」「カスタマイズ開発・データ移行」「トレーニング・本番移行」という流れで進みます。一般的な3〜6ヶ月の導入では、1ヶ月目に要件定義・フィット&ギャップ分析（解決したい営業課題の整理、対象プロセスの選定、標準機能で満たせる範囲とApex・LWCでの追加開発が必要な範囲の切り分け）、2ヶ月目に設計とSandbox環境での初期構築（オブジェクト設計、権限設計、Sandbox上でのカスタマイズ実装）、3〜4ヶ月目にカスタマイズ開発・データ移行・テスト（Apex・LWCによる実装、既存顧客データ・商談データの移行、結合テスト）、5〜6ヶ月目にトレーニング・本番移行（現場担当者への操作研修、並行運用による検証、本番稼働開始）という配分が一般的です。この配分の中で特にボリュームが大きいのが3〜4ヶ月目のカスタマイズ開発・データ移行フェーズであり、既存の顧客・商談データを新しいオブジェクト構造にマッピングする作業と、現場が実際に操作を習熟するまでの研修に相応の工数がかかります。さらに見落とされがちなのが、本番移行後の定着支援フェーズの隠れ工数です。稼働開始直後は入力が定着せず、現場から「以前のExcelの方が早かった」という反発が出ることも珍しくなく、初期見積もりの段階からこの定着支援期間をあらかじめスケジュールに織り込んでおく必要があります。ここでは、この一連の流れを前半（要件定義・フィット&ギャップ分析）と後半（設計・開発・データ移行・本番移行）に分けて解説します。

プロジェクトの前半は、課題整理と要件定義、そしてフィット&ギャップ分析です。課題整理フェーズでは、既存の営業活動・カスタマーサービス業務がExcelや別のツールでどのように回っているかを棚卸しし、SalesForceで何を実現したいのか（属人化した営業プロセスの標準化なのか、問い合わせ対応の一元管理なのか、マーケティングとの連携強化なのか）という目的を明確にします。要件定義フェーズでは、Salesforce運用に関わる各部門の知見を集約し、通常2週間〜1ヶ月程度（週1〜2回の打ち合わせを想定）かけて必要な項目・レポート・自動化フローを整理します。要件定義書自体の作成には1〜2週間程度を要するとされ、この「業務の棚卸し」に十分な時間をかけることが、結果的に開発期間全体の短縮につながるという指摘があります。そして、SalesForce導入において特に重要なのがフィット&ギャップ分析です。これは、契約前あるいは契約直後の段階で、実際の業務データを使い「これだけは譲れない要件」が標準機能だけで満たせるか、満たせない部分をApex・LWCによるカスタマイズ開発でどこまでカバーするかを検証する工程で、ここを丁寧に行わないと契約後に想定外の追加開発が頻発する原因になります。標準機能で不足する自社独自要件へのカスタム開発は、費用面でも300万円〜という水準に達することがあり、フィット&ギャップ分析の精度が後半工程の手戻りとコストの両方を大きく左右します。この前半工程に十分な時間を確保し、標準機能でカバーできる範囲とApex・LWCでの拡張が必要な範囲を早期に切り分けておくことが重要です。

プロジェクトの後半は、実際にSalesForce上でオブジェクト・画面・自動化フローを設計・構築し、データを整備して、現場が使いこなせる状態を作り、本番へ切り替える工程です。まず設計・初期構築では、Sandbox環境（本番とは別の検証用環境）上でオブジェクト構成・項目・権限設計を行い、フィット&ギャップ分析で洗い出した差分をApex・LWCで必要な範囲で実装します。続くデータ移行フェーズでは、既存の顧客・商談・活動履歴といったデータをSalesforceの標準オブジェクトにマッピングして移行します。この移行では、旧システムとSalesforceでデータ構造が異なることが多く、特に既存Salesforce環境の改修プロジェクトでは、過去に積み重なった重複データ・不整合データのクレンジングに相応の工数がかかります。トレーニングフェーズでは、現場の営業担当者やカスタマーサービス担当者が実際にSalesforceを操作できるよう研修を行い、実データを使ったテスト運用で業務が問題なく回ることを確認します。この段階で「マニュアルが膨大で現場がパニックになる」という失敗を避けるため、対象プロセスや機能を絞り込んで段階的に慣れてもらう進め方が有効です。最後の本番移行では、旧来の運用（Excel管理や別ツール）との並行稼働期間を設け、データの整合性や日々の業務プロセスに問題がないかを確認したうえで本番稼働に切り替えます。並行稼働期間は、想定外の運用上の問題を本番稼働前に洗い出せる貴重な期間であり、ここを短縮しすぎると稼働直後に現場が混乱するリスクが高まります。

SalesForce固有でスケジュールに影響する工程

一般的なクラウド型SaaS導入の工程に加えて、SalesForce導入・改修には固有の判断や作業が存在し、これらがスケジュールに影響します。とりわけ「Apex・Lightning Web Componentsによるカスタマイズ範囲の確定」と「Sandbox環境を使った段階的な開発・検証プロセス」は、期間を左右する重要な論点です。これらはSalesforceが高いカスタマイズ性を持つプラットフォームであるがゆえに、一般的なクラウドサービス導入とは異なる考慮が必要になる部分です。ここではこの2つの工程がスケジュールに与える影響を掘り下げます。

SalesForceの導入・改修では、標準機能で満たせない要件をApex（サーバーサイドのロジックを実装するSalesforce独自のプログラミング言語）やLightning Web Components（Web標準技術をベースにした画面用のUIコンポーネントフレームワーク）でどこまでカバーするかの判断が、その後のスケジュール全体を大きく左右します。カスタマイズ範囲を最初から広く取り、複雑な承認フローや独自の自動計算ロジックを同時に複数構築しようとすると、要件定義と設計の対象範囲が広がり、前半工程だけで数週間〜1ヶ月以上を要することも珍しくありません。一方、まずは標準機能とノーコードの自動化機能（Flow等）のみで稼働させ、定着を確認したうえで段階的にApex・LWCでの拡張を追加していく進め方であれば、最初の稼働までの期間を圧縮できます。重要なのは、Salesforceは高機能である分、学習コストが高く、専任のアドミニストレーター（管理者）の育成・配置という人的な準備も並行して進める必要があるという点です。また、過度なカスタマイズを行った部分はSalesforceの標準保守の対象外になりやすく、将来のバージョンアップのたびに自社側での追加対応が発生しやすくなります。最初から複雑なカスタマイズを作り込めば、後から機能を追加する手間そのものは避けられますが、その分、初回の要件定義・検証の負荷は増します。逆に段階導入を選ぶ場合でも、将来的にどこまでApex・LWCで拡張する計画かをあらかじめ描いておかないと、後から追加する機能のデータ構造が最初の設計と整合しない、という手戻りにつながりかねません。カスタマイズ範囲の確定は、SalesForce導入・改修における最初の、そして重要な意思決定の一つと言えます。

もう一つSalesForce固有でスケジュールに影響するのが、Sandbox（本番環境とは別に用意する検証用の複製環境）を使った段階的な開発・検証プロセスです。Salesforceには用途に応じて複数種類のSandboxが用意されており、個人開発者向けの小規模なもの（メタデータのみを複製し、リフレッシュも1日1回程度可能なタイプ）から、本番データの一部をサンプルとして含み外部システム連携テストやユーザー受入テストに向くタイプ、本番環境の完全な複製として全社的な回帰テストや性能検証に使うタイプまで幅がありますが、後者になるほどリフレッシュ（最新の本番状態への更新）に日数を要する点に注意が必要です。開発チームはまず個人・小規模開発用のSandbox上でApex・LWCの実装を進め、複数開発者が合流する結合開発の段階でより大きなSandboxへ移行し、最終的に本番相当のデータを使った受入テストへと段階を上げていきます。この段階的なSandbox活用そのものが、品質を担保しながら開発を進めるうえで重要な工程である一方、Sandboxの種類選定とリフレッシュのタイミングを見誤ると、「テストしたい最新データが反映されていない」「複数の開発者の変更が競合する」といった手戻りが発生し、スケジュールが後ろ倒しになることがあります。特に、本番規模のデータを使った最終リハーサルに使うタイプのSandboxはリフレッシュに一定の日数を要するため、本番移行の直前になって「最新データで再検証したいのにできない」という事態を避けるべく、Sandbox戦略をプロジェクトの初期段階で計画しておくことが望まれます。

納期遅延の典型要因と対策

SalesForce導入・改修プロジェクトで納期が遅延する原因の多くは、プラットフォームそのものの技術的問題ではなく、カスタマイズ範囲の見極め不足、そして既存環境特有の技術的負債の過小評価に起因します。「何でもカスタマイズできると聞いていたので要件を詰め込んだが、Apex開発だけで想定以上の時間がかかった」「月額数千円のプランで何でも実現できると思っていたが、実際には追加のカスタム開発費用と期間が必要だった」「現場が新しい入力ルールを受け入れられず定着しなかった」といった、カスタマイズ範囲と現場定着に関わる部分でスケジュールが押すケースが目立ちます。ここでは代表的な2つの遅延要因とその対策を解説します。

最も頻度が高い遅延要因が、カスタマイズ範囲の見積もり誤りです。「せっかくならApex・LWCで全部作り込もう」と欲張ってスコープを広げすぎると、要件定義と設計の負荷が一気に膨らみ、稼働開始が大幅に後ろ倒しになります。逆に、スコープを小さく見積もりすぎて後から独自機能を追加しようとすると、最初の設計で拡張性を考慮していなかったために、追加開発時にオブジェクト構造を作り直す手戻りが発生することもあります。また、フィット&ギャップ分析が不十分なまま契約・構築を進めると、当初は軽微だと思われたカスタマイズが積み重なり、結果的に大規模な追加開発に近い工数がかかってしまうケースもあります。標準機能で不足する要件へのカスタム開発は、費用面で300万円以上に達することもあり、これは同時にスケジュール遅延の最大要因でもあります。この手戻りを抑えるには、契約前の段階で「最初にApex・LWCで作り込む範囲」と「将来的に追加する範囲」を明確に切り分けたロードマップを描き、最初の設計段階から将来の拡張を見据えたオブジェクト構造を検討しておくことが有効です。

もう一つの遅延要因が、既存環境の改修プロジェクトに特有の「技術的負債の過小評価」です。長年運用されてきたSalesforce組織では、標準機能を使わずに構築された独自ロジックや、担当者の異動・退職によって設定意図が分からなくなったカスタム項目・自動化フローが積み重なっていることが少なくありません。設定の意図が分からない後任担当者が、既存の設定を触ることを恐れて新しい設定を重ねて追加し続ける「増築の繰り返し」が起きている場合、着手前の現状分析でその複雑さを正確に見積もれず、想定以上の解きほぐし作業が発生してスケジュールが遅延することがあります。特に、専任のシステム管理者が1名しかいない「一人情シス」的な体制で運用されてきた環境では、その担当者の頭の中にしか存在しない暗黙知が多く、ヒアリングだけでは全容を把握しきれないリスクもあります。この遅延要因を抑えるには、着手前の現状分析フェーズに十分な期間を確保し、変更ログの記録や命名規則の統一といった可視化作業を先行させること、そして必要に応じてリブート（部分的な作り直し）・リビルド（大部分の再構築）・リデザイン（設計思想からの見直し）といった改修レベルの選択肢を早期に整理し、対象範囲に応じた現実的なスケジュールを引くことが重要です。自社だけで抱え込まず、既存環境の改修・再構築を専門とする外部のSalesforceパートナー企業に早い段階で相談することも、遅延を防ぐ有効な手段です。

まとめ

本記事では、SalesForce導入支援・改修の開発期間・スケジュール・納期について、規模別の期間目安、工程別のスケジュール、SalesForce固有でスケジュールに影響する工程、そして納期遅延の典型要因と対策を解説しました。改めて強調しておきたいのは、本記事が扱っているのはCRM・SFAという機能そのものの解説ではなく、Salesforceという特定クラウドプラットフォームを対象にした導入・カスタマイズ・改修プロジェクトであるという点です。全体の期間は標準機能中心のスモールスタートでおおむね最短2週間〜1〜3ヶ月、Apex・LWCのカスタマイズを含む本格導入では3〜6ヶ月が目安で、複数製品への展開や大規模な改修を伴う場合は6ヶ月〜1年前後、あるいはそれ以上に伸びます。SalesForceは高いカスタマイズ性を持つクラウドプラットフォームという立ち位置にあり、Apex・LWCによるカスタマイズ範囲の確定とSandbox環境を使った段階的な開発・検証プロセスが期間を左右する固有工程です。また、新規導入だけでなく、複雑化・属人化した既存Salesforce環境の改修・再構築というテーマでは、着手前の現状分析（技術的負債の可視化）に十分な期間を確保できるかどうかが納期を左右する最初の分岐点になります。納期を守るためには、フィット&ギャップ分析を丁寧に行いカスタマイズ範囲の過小・過大評価を防ぐこと、そして改修プロジェクトでは既存環境の複雑さを見誤らないことが不可欠です。導入・改修を検討される際は、自社が実現したい営業・カスタマーサービスプロセスと、既存環境がある場合はその複雑さの度合いを整理したうえで、SalesForce導入実績が豊富なパートナーに相談することをお勧めします。

▼全体ガイドの記事
・SalesForce導入支援・改修の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。