Salesforceの導入支援・改修は、要件定義から継続改善まで、5つの工程で進みます。Salesforceは、世界No.1のCRM（顧客関係管理）プラットフォームとして、国内外の多くの企業で営業支援・顧客管理・マーケティング自動化に活用されています。
準備が不足したまま進めると、現場に定着しなかったり、期待した効果が出なかったりします。工程ごとに何を決め、誰が動くかを押さえておくことが大切です。
▼全体ガイドの記事
・SalesForce導入支援・改修の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Salesforce導入支援・改修の全体像
Salesforceの導入支援・改修は、大きく分けて「新規導入」と「既存環境の改修・カスタマイズ」の2種類があります。どちらの場合も、プロジェクトとして体系的に管理することが大切です。
場当たりの対応では、現場が混乱したりコストが超過したりしやすくなります。そこで、全体像を把握したうえで、各フェーズの目的と成果物を決めて進めることが、成功への第一歩です。
新規導入と改修の違い
新規導入は、これまでSalesforceを使っていなかった企業が、初めてシステムを立ち上げるプロジェクトです。業務要件の整理から始まり、標準機能の活用範囲を決めて、カスタム開発の要否を判定します。そのうえで、データ移行やユーザートレーニングまで、幅広い工程を経る必要があります。
一方、改修（既存環境のカスタマイズ）は、すでに稼働しているSalesforce環境に対して、機能の追加や設定の変更、不具合の修正などを行うものです。改修では既存環境への影響を慎重に見極める必要があるため、サンドボックス（テスト環境）を使った検証が欠かせません。
新規導入は白紙の状態から設計できる自由度がある反面、方向性を誤ると大規模な手戻りが生じるおそれがあります。どちらの場合も、最初に「何のために実施するのか」というビジネス目標を決めておくことが、後の判断の基準になります。
開発手法の種類（アジャイル・ウォーターフォール）
Salesforceのプロジェクトでは、主にウォーターフォール型とアジャイル型、両者を組み合わせたハイブリッド型のいずれかが使われます。ウォーターフォール型は、要件定義から始めてリリースまでの工程を順番に進めます。そのため、要件が明確で変更の少ないプロジェクトに向いています。
一方、アジャイル型は、短いサイクル（スプリント）で開発とフィードバックを繰り返します。要件が変わりやすいプロジェクトや、現場と一緒に作り上げる場面に向いています。
実際の現場では、要件定義はウォーターフォール的に進め、設計と開発はアジャイル的にプロトタイプを繰り返す進め方が多く採られています。Salesforceは標準機能が豊富なので、プロトタイプを早い段階で作ってユーザーに確認してもらえば、手戻りを大きく減らせます。手法は、プロジェクトの性質とチームの体制に合わせて選びます。
要件定義・企画フェーズの進め方
要件定義は、Salesforceプロジェクトの中でもっとも重要な工程です。ここで手を抜くと、後から大きな手戻りや失敗を招きかねません。このフェーズでは、「業務上の課題は何か」「Salesforceで何を実現したいのか」を関係者全員で整理し、システムに求める機能や非機能の要件を文書にまとめます。
導入目的と業務課題の明確化
まずは、発注側が導入・改修の目的をはっきりさせます。「営業活動を見える化して成約率を上げたい」「顧客情報を一か所にまとめて部門間の連携を強めたい」「データをもとに経営判断を行えるようにしたい」など、具体的なビジネスゴールを決めておきます。目的が曖昧なままだと、どの機能を使うか、どこまでカスタマイズするかを判断できず、結果として「どれも使われない機能」が増えていきます。
次に、現状の業務課題をヒアリングで洗い出します。経営層、営業マネージャー、現場担当者など複数の立場から話を聞くと、立場によって異なる課題が見えてきます。
業務フロー図を描きながら、「どこで仕事が滞っているか」「どこでデータが途切れているか」を確認すると効果的です。そのうえで、ヒアリングの結果をもとに業務要件定義書を作り、関係者全員の合意を取っておきます。
システム要件の整理と優先順位付け
業務要件が整理できたら、次はそれをシステム要件に落とし込みます。業務フローをもとに担当者ごとの業務シナリオを作り、システム機能の一覧にまとめます。このとき、「標準機能で対応できるもの」と「カスタム開発が必要なもの」を分けておくと、後の見通しが立ちます。
Salesforceは標準機能が豊富なので、カスタム開発の範囲を最小限に抑えておくと、長期的な保守の負担を軽くできます。機能には、MoSCoW分析（Must have / Should have / Could have / Won’t have）などの枠組みを使い、優先順位を付けておきます。
すべての要望を最初から実装しようとすると、対象範囲（スコープ）が膨らみ、スケジュールや予算の超過を招きます。そのため、フェーズ1ではコアとなる機能を実装し、フェーズ2以降で追加機能を広げていく段階的な進め方が現実的です。
設計・開発フェーズの進め方
要件定義が終わったら、設計・開発フェーズに進みます。このフェーズでは、要件を具体的なシステム設計に落とし込み、Salesforceの環境を組み上げていきます。Salesforceでは、設計と並行してプロトタイプを作り、早い段階から画面のイメージをユーザーに確認してもらうのが一般的です。
プロトタイプ作成と設計書の作成
Salesforceはローコード・ノーコードで多くの機能を設定できるため、設計の段階から実際の画面を動かして要件を確認できます。サンドボックス環境（本番とは切り離したテスト用環境）にプロトタイプを作り、ユーザーと一緒に画面を見ながら、方向性の合意を取っていきます。
文書だけでは伝わりにくい操作感やUIの課題も、早い段階で見つけられるため、手戻りを防ぎやすくなります。設計書には、基本設計書と詳細設計書があります。
- 基本設計書：オブジェクト設計やデータモデル、権限設計などを固め、連携設計も含めます。
- 詳細設計書：項目定義やバリデーションルール、ワークフロー設計などを具体的に書きます。
特に権限設計（プロファイル・権限セット）は、後から変更すると影響範囲が広くなります。そのため、初期段階で丁寧に設計しておくことが大切です。また、他システムとのAPI連携が必要な場合は、インターフェース設計書も別途作ります。
カスタム開発（Apex・LWC）の実装
標準機能で足りない場合は、カスタム開発で対応します。主な技術には、サーバー側の処理を実装する「Apex（Java類似のオブジェクト指向言語）」があります。ほかに、画面部品を作る「Lightning Web Components（LWC）」や、ページ構成を自由に変えられる「Lightning App Builder」などもあります。これらを組み合わせると、業務要件に合った独自機能を実装できます。
カスタム開発では、コードの品質管理が非常に重要です。Salesforceでは、本番リリース時にApexのコードカバレッジ（テストクラスによる実行率）75%以上が必須です。そのため、開発と並行してテストクラスを作っておく必要があります。また、開発環境から本番環境への反映は、変更セットやSalesforce CLIを使って安全に管理します。
データ移行の計画と実施
新規導入の場合は、Excel、旧CRM、基幹システムなどの既存システムから、Salesforceへデータを移す必要があります。データ移行では、移行対象データを選び、重複排除や表記ゆれ修正（データクレンジング）、旧項目と新項目の対応づけ（マッピング設計）を行ったうえで、テスト移行から本番移行へと進みます。
Salesforceには、データインポートウィザードやデータローダーといった標準ツールがあり、数万件規模のデータなら比較的容易に移せます。大量のデータや複雑な変換が必要な場合は、ETLツールや外部連携ツールの利用も検討します。
データの品質が低いまま移すと、移行後もデータを信頼できず、現場での活用が進まない原因になります。そのため、移行作業は必ずサンドボックスでリハーサルを行い、件数の照合や整合性の確認を経てから本番に臨みます。
テスト・リリースフェーズの進め方
開発が終わったら、品質を確かめるテストのフェーズに入ります。テストは、単体テスト、結合テスト、UAT（ユーザー受入テスト）の順に行い、問題をすべて解消してから本番リリースに進みます。リリース後の初動1〜2週間は、開発ベンダーのサポートを手厚くしておくと、スムーズな立ち上がりにつながります。
テストの種類と実施方法
単体テストでは、個々のApexクラスやトリガーが正しく動くかを、テストクラスで確かめます。特に、Salesforceではコードカバレッジ75%以上が本番デプロイの条件です。そのため、開発者は実装と同時にテストクラスを作る習慣をつけておくことが大切です。
次に結合テストでは、複数の機能やシステム連携を組み合わせた状態で、正しく動くかを確認します。データ連携や外部API連携がある場合は、実際のデータの流れに沿って検証します。
UAT（ユーザー受入テスト）は、業務シナリオごとのテストケースをもとに、現場のユーザーが実際の操作を試すフェーズです。ここで「使いにくい」「業務の実態と合っていない」といった声が出たら、リリース前に対応します。UAT後の修正が多いと、リリース日程が延びかねないため、プロトタイプの確認を開発途中から徹底して、問題を前もって潰すのが有効です。
本番リリースの準備と移行手順
本番リリースに向けて、リリース計画書を事前に作成します。リリース計画書には、リリース日時と作業担当者を書き、作業手順、切り戻し手順（問題発生時に元の状態に戻す手順）、確認項目も明記します。
本番環境への設定反映は、変更セットまたはSalesforce CLIを使い、サンドボックスで検証済みの内容をそのまま適用します。手作業での設定変更は設定ミスのリスクがあるため、できる限り変更セットによる自動適用を推奨します。
リリース後の初動サポートも、あらかじめ計画に含めておきます。リリース直後は、「操作がわからない」「期待した動きと違う」といった問い合わせが集中しやすいためです。そこで、ヘルプデスク体制を整え、すぐに対応できるように備えておきます。加えて、リリース後の初動1〜2週間は開発ベンダーのサポートを手厚くすると、現場の不安が和らぎ、定着化をスムーズに進められます。
リリース後の定着化支援の進め方
Salesforceの導入でもっとも難しく、同時にもっとも重要な段階が「定着化」です。どれほど優れたシステムを作っても、現場のユーザーが使わなければ、投資対効果は限りなくゼロに近くなります。定着させるには、技術面のサポートに加えて、組織や文化の面からも取り組むことが欠かせません。
ユーザートレーニングの実施
ユーザートレーニングは、管理者向けと一般ユーザー向けに分けて行います。管理者向けでは、設定の変更、ユーザー管理、レポートやダッシュボードの作成を習得してもらいます。
また、簡易カスタマイズの方法も身につけてもらいます。一般ユーザー向けには、商談登録、活動記録、顧客情報の更新など、日常業務で使う操作に絞ったシナリオベースの研修が効果的です。
トレーニングは座学だけでなく、実際のシステムを操作するハンズオン形式にすると、定着度が高まります。さらに、操作マニュアルや動画を作って、リリース後もいつでも見返せるようにしておくと役立ちます。トレーニングのあとは、よくある質問集（FAQ）を作って共有したり、Salesforceのチャター機能で社内のQ&Aチャンネルを設けたりするのも有効です。
業務ルール化とKPI設定
Salesforceが定着しない大きな原因のひとつは、使わなくても仕事が回ってしまうことです。そこで、業務プロセスにSalesforceを使う手順を組み込み、ルールとして決めておきます。
たとえば、営業会議の進捗確認はSalesforceのダッシュボードだけで行う、日報や夕礼の報告はSalesforceの活動履歴から行う、受注した案件は必ずSalesforceに登録してから処理を進める、といった形です。こうした決まりによって、Salesforceを使わざるを得ない仕組みをつくります。
加えて、Salesforce活用のKPIを決めて見える形にすると、現状を把握しやすくなります。データ入力率、ログイン率、商談の更新頻度といった指標をダッシュボードに表示し、マネージャーが日常的に確認できる体制をつくります。KPIを「業績評価の一部」と位置づけると、現場担当者が活用する意欲も高まります。
改修・継続改善の進め方
Salesforceは、導入して終わりにせず、継続して改善や拡張を重ねることで投資対効果を高めていけます。そのため、リリース後も現場からの改修要望を適切に管理し、優先順位を付けながら段階的に対応する仕組みを整えておくことが大切です。
改修要望の収集・優先順位付け
リリース後は、現場からさまざまな改修要望が上がってきます。「この項目を追加してほしい」「このフロー処理を自動化したい」「このレポートの集計方法を変えてほしい」といった声を、漏れなく受け付けて管理する体制を整えます。
改修要望は、BacklogやJiraなどのプロジェクト管理ツール、あるいはSalesforceのケース機能を使って一か所で管理するのがおすすめです。収集した要望は、ビジネスインパクト、実装工数、緊急度をもとに優先順位を付けます。
すべての要望にすぐ対応するのは現実的ではないため、月次または四半期ごとに改修リリースの計画を立てて対応します。軽微な設定変更（項目追加、バリデーションルール修正など）は社内の管理者が受け持ち、コードの変更を伴う改修はベンダーに依頼します。どこまでを社内で行い、どこからベンダーに頼むかを決めておくと、対応コストを抑えられます。
Salesforceバージョンアップへの対応
Salesforceでは、年3回（Spring・Summer・Winter）のメジャーバージョンアップが自動的に適用されます。各バージョンアップには、新機能の追加だけでなく、既存機能の変更や廃止も含まれます。そのため、事前に内容を確認し、既存のカスタマイズへの影響がないかを検証しておく必要があります。
バージョンアップ前には、Salesforceがリリースノートを公開します。定期的に目を通す習慣をつけておくと、変更点を早く把握できます。特にApexのAPIバージョンやLWCの仕様変更は、カスタム開発への影響が大きいため注意が必要です。
また、Salesforceのサンドボックスには、新しいメジャーバージョンが先に適用されます。このため、本番環境に反映する前に、サンドボックスで既存機能の動作を確認しておくことが推奨されます。社内にSalesforce管理者を育て、バージョンアップへの対応を自社で行える体制を作ると、長期的なコストを抑えられます。
Salesforce導入・改修で失敗しないためのポイント
Salesforceの導入・改修プロジェクトが失敗するケースには、共通したパターンがあります。失敗事例から学んで事前に対策を講じておけば、成功の確率を大きく高められます。
よくある失敗パターンと原因
もっとも多い失敗パターンは「目的の曖昧化」です。「営業効率を上げたい」といったざっくりした目標だけでプロジェクトを進めると、何を成功とするかが定まらないまま機能が増え、使われないシステムになります。導入前に、「成約率を現在の20%から25%に引き上げる」「営業日報の記載時間を1時間から15分に短縮する」など、具体的な数値目標を決めておくことが大切です。
2番目に多い失敗は「過剰なカスタマイズ」です。Salesforceの標準機能で解決できる課題でも、「自社独自の業務に合わせたい」という理由でカスタム開発を行うと、初期費用が膨らみます。さらに、バージョンアップ時の対応や将来の保守にかかる費用も増えていきます。
まずは標準機能で試し、どうしても対応できない場合だけカスタム開発を検討するという原則を守ることが大切です。3番目に多いのは「現場の関与不足」です。経営層や情報システム部門だけで設計を進め、実際に使う現場担当者の意見を取り入れないと、「使いづらい」「業務に合っていない」というシステムが完成してしまいます。
パートナー選定と社内体制の整備
プロジェクトの成否は、パートナー（導入支援ベンダー）の選び方にも大きく左右されます。選定のポイントのひとつは、Salesforceの認定パートナー資格（AppExchange上の評価・Navigatorプログラムの認定）を確認することです。
そのほか、導入実績件数、顧客満足度スコア（CSAT）、自社業界での専門性も、重要な選定基準になります。また、構築して終わりにせず、リリース後の定着化支援や運用サポートまで一貫して対応できるパートナーを選ぶことが、長期的な成功につながります。社内体制の整備も欠かせません。
プロジェクトオーナー（経営層または役員）、プロジェクトマネージャー、Salesforce管理者候補の3役を早期に任命し、それぞれの役割と責任を明確にします。特にSalesforce管理者は、リリース後の運用を担う重要な役割です。導入中から管理者候補をベンダーと一緒に参画させ、設計の意図や設定方法を引き継いでおくことで、ベンダー依存を減らしてコストを抑えられます。
まとめ
Salesforce導入支援・改修は、要件定義・企画から継続改善まで5つの工程を、体系的に進めることが成功への近道です。各フェーズでは、目的を明確にすること、関係者と合意を取ること、プロトタイプで早めに検証することを徹底します。こうすることで、手戻りを抑えながら、質の高いシステムを作れます。
もっとも大切なのは、導入後の定着化を最初から計画に組み込むことです。どれほど優れたシステムを作っても、現場で使われなければ、投資は無駄になります。
そのため、ユーザートレーニングや業務ルールの整備、KPIの設定を通じて、Salesforceを組織に根づかせていくことが、長期的な投資対効果を高めるうえで欠かせません。信頼できるパートナーと組み、社内の管理者を育てながら計画的に進めれば、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を創業。