Salesforce Platformのシステム開発は、要件整理と製品・実装方式の選定から始まり、設計・開発、テスト、移行リハーサルと本番稼働、定着化の順に進みます。
稼働後も利用状況を見ながら支援と改善を続けると、業務に合う仕組みを保てます。
▼全体ガイドの記事
・Salesforce Platformのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Salesforce Platformのシステム開発の全体像
Salesforce Platformのシステムは、クラウド基盤が持つデータと認証、権限の仕組みを使って作ります。そこに画面やワークフローを組み合わせ、APIや運用機能も加えます。
フルスクラッチで一から作る場合と違い、共通基盤を活かして、自社固有の部分に設定やコードを加えます。
顧客管理以外に作れる業務システム
顧客管理を越えて扱える業務は、次の3つの面から整理できます。
- 業務データ：顧客管理以外の業務に関する情報も扱えます。
- 業務自動化：Flowで通知や承認を自動で行えます。
- 拡張・連携：標準機能に、コードと外部連携を組み合わせる方法。
カスタムオブジェクトでは、契約、申請、案件を扱えます。保守受付やプロジェクトも扱えますし、代理店や設備も対象にできます。たとえば、案件情報から上長へ承認を依頼し、承認後は契約管理へ引き継ぐ流れも作れます。
標準画面の操作性が足りない場合は、Lightning Web Components（LWC）で画面を拡張できます。複雑な計算や独自ルールには、Apexを使います。
外部連携には、REST APIやSOAP API、Bulk APIを使います。加えて、Platform EventsやMuleSoftなども使います。
標準機能とカスタム開発の境界
標準と個別開発をどこで分けるかは、保守のしやすさと現場の使いやすさを踏まえて判断します。
- 標準機能：標準で解決できる業務は、標準寄りの設計にします。
- 独自開発：競争力に直結する審査や画面を、個別に作る部分。
- 判断の基準：差別化や変更頻度を見て、データ量やセキュリティも加味します。
その分け方には、Fit to Standardを使います。
標準オブジェクトや項目、権限セットで解決できる業務は、標準寄りに設計します。また、Flowやレポート、画面の設定で解決できる場合も、標準の範囲に収めます。
競争力に直結する独自の審査ロジックや画面体験は、LWCやApexで作ると、開発量を抑えやすくなります。
ただし、LWCやApexでコードを増やすほど自由度は上がります。その分、テストやガバナ制限、引き継ぎも必要になります。
標準に寄せすぎると、現場がExcelへ戻ったり、例外処理を手作業で補ったりする事態になります。
判断に迷うときは、機能の便利さだけでなく、5年後にも変更しやすいかを確かめます。
Salesforce Platformのシステム開発の進め方と6フェーズ
業務の目的とデータの流れを固めてから、段階的に作って検証します。主な流れは次の6フェーズです。
- 要件整理で目的と現状、将来像をそろえる
- 製品とライセンス、実装方式を選定する
- データと権限、連携を設計して開発する
- 業務と権限、連携をテストする
- 移行リハーサルを行い、本番稼働する
- 利用状況を確認し、定着化を進める
期間の計画値として、中規模で連携や移行を含む場合は3〜6か月、複数部門や独自コードが多い場合は6〜12か月以上を置くことがあります。ただし、期間は意思決定やデータ品質、受け入れ体制によっても変わります。
フェーズ1：要件整理と目的・As-Is・To-Beの統一
要件整理では、まず現状を把握し、そのうえで初回リリースの合意と確認事項を固めます。
- 課題と現状：業務課題を言葉にし、現行フローとデータを一覧にします。
- 将来像：To-BeとKPIを決め、所有者と利用者、初回の範囲も定めます。
- 合意事項：必要な資料と優先順位を整理し、両部門で話をまとめます。
- 確認事項：利用者やデータ、連携、監査、希望日の条件を確かめます。
「顧客情報を一元化する」といった目的だけでなく、二重入力の解消や承認時間の短縮を業務単位で示します。ヒアリングでは、Excelや台帳、メールを集めます。承認書式や既存CRMも集めます。
初回に含めない要望も明示しておけば、スコープクリープによる設計のやり直しや追加費用を防げます。作成する資料には、業務一覧や要件一覧、画面・帳票一覧があります。データ項目表や課題・リスク一覧、優先順位表も含みます。
現行データの件数や欠損、部門ごとの業務差も確かめます。法令や監査の要件、社内管理者の有無も確認します。特に、個人情報や要配慮情報を扱う場合は、項目ごとに閲覧者を決めます。
フェーズ2：製品・ライセンス・実装方式の選定
製品と開発会社は、機能要件を満たし、運用まで見通せるかを基準に選びます。
- 製品・ライセンス：必要な機能と契約条件を突き合わせます。
- 実装方式：標準設定から始め、ハイブリッド連携まで順に検討します。
- ベンダー：移行事例や提案力、責任範囲、運用体制を見ます。
選定の時点で、Salesforceのエディションと、AppExchangeのパッケージ、社内の担当範囲も決めておきます。
ライセンスは、ユーザー数だけでなく、カスタムオブジェクトやWeb API、Sandboxも考慮に入れます。データ容量やAI機能、サポートの必要性も確かめます。
Free SuiteやStarter Suiteで始めることもできます。ただし、カスタムアプリや外部連携が必要な場合は、Pro Suite以上が候補になることがあります。
実装方式は、FlowやApp Builder、管理パッケージを見て、最後にLWC・Apexを検討します。
基幹や会計は外部に残すハイブリッド連携も候補になります。標準機能を無理に開発しないことは、短納期と保守性につながります。
また、大量データを扱う基幹処理は外部に残し、Salesforceを顧客と業務プロセスの中心にする設計も有効です。
2026年6月、Salesforceは日本でFDE Partner Networkを発表しました。初期パートナーは9社です（出典: Salesforce公式「FDE Partner Networkを日本で本格展開」、2026年）。
ただし、これはAgentforceの本番実装の動向で、すべてのPlatform案件に最適とは限りません。認定資格の数に加えて、自社の課題に必要な経験があるかも見極めます。
フェーズ3：データ・権限・連携の設計と開発
設計・開発では、データとアクセス、外部接続の前提を先に決めておき、そのうえで実装に進みます。
- データ・権限：データモデルとアクセス範囲を、実装より先に固めます。
- 連携：正となるシステムとエラー処理を決めます。
- 開発：Sandboxで設定やコード、テストデータを管理します。
データモデルでは、オブジェクトの関係と必須項目、重複判定を決めます。さらに、履歴やファイル保管、所有者も決めます。
権限セットやロール階層、共有設定を組み合わせ、項目レベルのセキュリティも加えます。
外部ユーザーのアクセスも設計し、管理者の権限を一般ユーザーに使い回さないようにします。
連携の方向や同期の頻度、再送と重複防止の方法を決めます。APIユーザーや監視担当も決めます。双方が同じ顧客情報を更新すると正誤が分からなくなるため、項目対応表とエラー処理を用意します。
タイムアウトや認証失敗の扱い、部分成功や再送時の重複も確認します。Flowで足りる処理はApexで書かず、画面の都合でデータ構造を曲げず、ロジックも重複させないようにします。こうした設計にすると、変更しやすくなります。
LWCは、Lightning Web SecurityやCSPといった境界を踏まえて設計します。Salesforce公式の説明では、LWSは名前空間ごとに分離します。LWSは、CSPやプラットフォーム制限とは別の層で働きます（出典: Salesforce Developers、2026年確認）。
フェーズ4：業務・権限・連携のテスト
テストでは、工程と確認対象を分けたうえで、業務上の不具合やアクセス漏れを洗い出します。
- テスト工程：各テストを分け、要件と対応づけます。
- 業務・障害：入力や承認、連携、データ量などの検証。
- 権限・個人情報：役割別のアクセス範囲と監査要件。
開発会社の画面操作の確認で終わらせず、単体、結合、システム、ユーザー受け入れの各テストを実施します。
正常な登録に加えて、未入力と重複のケースを検証します。承認の差し戻しや権限外の閲覧も対象です。API障害や想定以上のデータ量も確認し、日付やタイムゾーンのずれも見ます。
テストの結果は、再現手順と期待値、実績を記録します。担当者と修正期限も残します。
テストユーザーには、営業や管理職、経理などを使います。外部委託先や管理者も含め、見えるべき情報と見えてはいけない情報を確かめます。
接続アプリとAPIユーザーも一覧にして洗い出します。個人情報を扱う場合は、ログ監視や項目監査履歴、保持・削除ルールなどを確認します。Platform Encryptionも、要件に合わせて確かめます。
フェーズ5：移行リハーサルと本番稼働
本番移行では、持ち込むデータと、切替を中止する条件を事前に明確にしておきます。
- 移行対象：所有者や保存期間を踏まえ、移行する範囲を決めます。
- 照合：件数や項目、関連、ファイルを突き合わせます。
- 切替判定：停止と切り戻しの条件を、事前に合意しておきます。
本番の前には、データクレンジングと移行リハーサルを行います。そのうえで、利用目的を確かめ、重複や欠損、不要な履歴の扱いを決めます。
照合では、日付や文字コードも確かめます。業務画面で検索や集計ができるかも確認します。切替手順には、停止時間と最終差分を記し、担当者と確認項目も明記します。
顧客件数が一定の割合を下回る場合や、重要な承認が動かない場合、外部連携のエラーを解消できない場合は、中止します。本番に近いデータで少なくとも1回は通し、そこで得た作業時間と問題点を見積もりに反映します。
フェーズ6：定着化による利用率と業務成果の向上
稼働後の利用と業務成果を保つため、支援と測定、改善を続けます。
- 利用支援：窓口や手順を整え、現場の困りごとを集めます。
- 成果測定：業務目的に直結するKPIで効果を見ます。
- 継続改善：運用会議で、設定やテスト範囲を見直します。
稼働日から先も、支援を続ける必要があります。たとえば、現場が入力しなければデータは蓄積されず、管理者が運用ルールを守らなければ、権限や自動化も崩れます。
リリース直後は、問い合わせ窓口や操作説明会を用意します。短い手順書やFAQ、管理者向けの変更手順も用意します。部門ごとの推進役が困りごとを改善バックログに集めると、要望を場当たり的に直す状態を避けられます。
測る指標は、必須項目の入力率や重複率、承認処理時間などです。問い合わせの初回解決率や二重入力の削減時間、営業・保守のKPIも含みます。定着は、ログイン数よりも業務に直結する指標で見ます。
毎月、未利用の項目や失敗しているFlowを見直します。増えた手作業や不要な権限も見ます。また、Salesforceのリリースや新機能に合わせて、影響を確かめるテスト体制も必要です。
Salesforce Platformの費用相場とコストの内訳
費用は、ライセンスや要件整理・設計・設定開発、データ移行・連携で分けて考えます。教育や稼働後の保守も、費用の項目として別に見ます。ライセンス料に開発費が入っているとは限らず、開発費に追加ストレージや外部サービスが含まれるとも限りません。
比較のときは、初期費用だけでなく、1年目と2年目以降の総保有コストも並べて見ます。
公式ライセンス価格とユーザー数・契約条件
ライセンス費用を比べるときは、料金表示に加えて、契約条件と独自開発に必要な機能も確かめます。
- 表示価格：Free Suiteは0円で、有料プランはユーザー単位の料金です。
- 契約条件：期間や構成、追加オプションによって料金が変わります。
- 開発利用：ユーザー数以外の機能条件。
2026年時点の月額表示は、Starter Suiteが1ユーザーあたり3,000円です。Pro Suiteは1ユーザーあたり月額12,000円、Enterpriseは月額21,000円です。
Unlimitedは1ユーザーあたり月額42,000円です。Agentforce 1 Salesは1ユーザーあたり月額66,000円です。最終価格は、契約期間や製品構成、追加オプションで変わるため、個別見積もりで確認します（出典: Salesforce公式「2026年版 Salesforceの料金プラン」、2026年）。
10ユーザーで単純に計算すると、Starter Suiteは月額3万円・年間36万円です。同じ条件で、Pro Suiteは月額12万円・年間144万円、Enterpriseは月額21万円・年間252万円です。
独自開発では、カスタムオブジェクトやWeb API、Sandboxの条件も関係します。データ容量やAI、外部製品の条件も関係します。ユーザー数を減らしても、開発・移行・保守費が同じ割合で下がるとは限りません。
導入・開発・移行の費用と作業範囲
導入規模と作業範囲によって初期費用は変わります。保守費用も、依頼内容に応じて決まります。
- 小規模導入：初期費用の目安は30万〜100万円程度です。
- 中規模導入：初期費用の目安は150万〜600万円程度です。
- 複雑な開発：1,000万円以上になる可能性があります。
- 保守・運用：公開されている相場は、月額10万〜50万円程度です。
小規模の目安は、標準機能中心で、要件整理や初期設定、権限を含みます。さらに、簡易移行も入ります。
中規模は、標準オブジェクトの追加や複数部門のFlowを含む場合です。また、帳票やデータクレンジングも入ります。
これらは、公開相場と開発費用感に基づく推定のレンジです。1,000万円以上の可能性があるのは、外部連携やApex・LWC、複雑な権限を含む場合です。複数組織や監査対応が加わる場合も、この範囲に入ります。
保守費は、設定変更だけを任せるか、障害対応や影響調査まで任せるかで変わります。さらに、データ品質管理や教育まで含めるかでも差が出ます（出典: ナインテック株式会社「Salesforce導入の費用相場」、2026年確認）。
外注しない場合も、社内管理者の工数や資格取得に加え、バックアップや監査運用にコストがかかります。
初年度TCOの試算範囲
初年度に必要な費用は、ライセンスだけでなく、導入作業や運用支援も含めて整理します。
- 合算項目：導入支援や移行、連携・アドオン、教育、保守を含めます。
- 追加条件：移行件数や連携先数、独自画面、追加容量、AIクレジット。
- 見積比較：作業範囲と別料金を、見積もりごとに確かめます。
テストケースや定着支援の範囲も、予算に反映します。
Enterpriseを10ユーザーで使う場合、公式の表示価格だけで見ると年間252万円です。ただし、これは業務システムを稼働させるまでの総額ではありません。
要件定義が提案作業に含まれ、契約後に詳細設計が追加になる場合もあります。移行リハーサルや操作教育、稼働後の伴走、ドキュメント納品まで含めると、初期費用が高くても総額が逆転することがあります。
Salesforce Platformの見積もりを取る際のポイント
見積もりの精度は、依頼時に業務とデータの条件を伝えられるかで決まります。対象部門や利用者、現行データをそろえておくと、会社ごとの前提差を減らせます。
連携先や希望時期、運用体制も、同じようにそろえておきます。安い見積もりを選ぶ前に、同じ範囲で比べられる状態を作ることが先です。
依頼前に用意する業務・データ・連携の資料
見積もりの前提をそろえるため、発注の前に資料を準備します。
- 業務資料：目的やフロー、利用者、画面・帳票を一覧にします。
- データ・連携：項目や移行件数、API条件をまとめます。
- RFP：要件の優先度と受け入れ、納品範囲を明示します。
利用者ごとの権限も整理しておきます。連携先や非機能要件、希望のリリース日もまとめます。
既存データは、サンプルや項目定義、重複・欠損の状況に加えて、添付ファイルの扱いも伝えます。
API連携では、送受信項目や件数、頻度をまとめます。障害時の運用や接続環境の制約も書き出します。
RFPでは、必須要件と希望要件、初回リリース後に回す要件を分けます。PoCやMVPの範囲と管理方法を明示し、窓口や社内作業も示します。移行支援のみか、連携先の改修は対象外か、本番切替はユーザー側かといった境界条件も、文書に残します。
複数社の同条件での比較と提案内容の確認
複数社の提案の違いを見極めるには、見積もりの範囲と各社の実績を同じ条件で比べます。
- 見積条件：同じ資料をもとに、工程別の費用を比べます。
- 提案内容：何を納めるか、前提、除外事項、変更単価を確かめます。
- 会社選定：近い実績や支援体制、担当チームを見ます。
各社には同じ質問を渡して、見積もりの前提をそろえます。
見積もりは工程ごとに分けてもらい、要件整理から保守までの各工程で、担当人数と作業時間を比べます。
選定では、資格や同業種の事例、近いユーザー数・データ量の実績も確かめます。内製化支援や保守SLA、再委託の有無も見ます。
AppExchangeには、サンブリッジの検証済みプロジェクト409件と、認定資格保有者100人が掲載されています。創業は1999年と記されています（出典: Salesforce AppExchange、2026年確認）。
公開情報に加えて、担当予定チームの経験も面談で確かめます。
追加費用とプロジェクトリスクの確認
追加費用や引き継ぎのリスクは、契約条件と納品物を具体的に確かめて抑えます。
- 追加費用：変更の進め方や追加単価、納期への影響、承認者を決めます。
- 契約条件：契約形態と検収の方法、納めるものの範囲を確かめます。
- 納品・引き継ぎ：設定資料や運用手順も受け取ります。
追加費用は、要件の変更やデータの欠損・重複、連携先仕様の変更で生じやすいものです。また、権限の追加や帳票の作り直し、テストデータの準備、教育の拡大でも、費用が増えます。
納品物は、ソースコードに加えて、設定やメタデータも業務の動きを形づくります。権限設計書やデータ辞書、連携仕様書を受け取り、テスト結果や変更履歴も含めます。
運用手順書や管理者向けの教育資料も含めて、設定を説明できる状態にしておきます。こうしておくと、ベンダーを変えるときや社内に移すときも、ロックインを抑えられます。
よくある質問（FAQ）
開発では、CRM導入との違いや期間、標準機能とカスタム開発の境界がよく質問されます。社内で作れる範囲も、よく挙がる話題です。費用や期間は要件によって変わるため、判断の基準を先に持っておきます。
SalesforceのCRM導入とPlatformのシステム開発は何が違いますか？
CRM導入は、営業や顧客対応の標準機能を設定して、早く使い始めることが中心です。一方、Platform開発では、自社固有のデータモデルや業務フローも設計します。
外部連携や独自画面、ロジックまで扱う点も異なります。はっきりした境界線はないため、標準利用と開発の範囲を要件整理で決めます。
Salesforce Platformの開発期間はどれくらいですか？
標準SFA・CRMの設定が中心なら2〜3か月、中規模で移行や外部連携を含む場合は3〜6か月が目安です。複数部門や複数システム、ApexやLWCを含む場合は、6〜12か月以上になります。
これは一般的な計画値で、期間はユーザー数以外の条件でも決まります。要件の確定やデータクレンジング、意思決定も含めて、受け入れテストや切替リハーサルまで見積もります。
Salesforce Platformの開発を社内だけで進められますか？
社内で対応できるかは、作業範囲と、運用を担う体制を分けて考えます。
- 社内で進める範囲：研修を受けた管理者なら、標準設定や項目、簡単なFlow、レポートを進められることもあります。
- 専門会社の支援：要件整理や複雑な権限、既存データ移行、Apex・LWC、外部API連携、監査対応を含む場合は、支援を受けるほうが安全です。
- 役割分担：データ所有者や変更管理、テスト、バックアップ、問い合わせ対応の役割を決めます。
Salesforce Platformを使ったシステム開発の事例はありますか？
IDOMの事例では、顧客接点のデジタル化のために、複数のSalesforce製品と業務機能を組み合わせています。
- 導入製品：Service Cloud、Digital Engagement、Lightning Platform、Heroku。
- デジタル管理：LINEミニアプリの来店予約や商談内容。
- 設計の特徴：顧客接点とデータ、業務プロセスを組み合わせる設計。
この事例は、2025年1月のSalesforce公式の発表で紹介されています（出典: Salesforce公式「IDOM、顧客接点のデジタル化を推進するためSalesforceを導入」、2025年）。
まとめ｜Salesforce Platformの開発における段階設計と定着化
まず、目的と現状（As-Is）、目指す姿（To-Be）、KPIを決めます。データの所有者や初回リリースの範囲も定めます。そのうえで、標準機能やFlowを中心に、AppExchangeやApex・LWC、外部連携を使い分けます。
要件整理から定着までを、一つの流れとして管理します。
着手前に確認したい最終チェックリスト
着手前には、対象業務と利用者、現行データと連携先を確かめます。標準と開発の境界や、権限、監査、保持の要件も確認します。
移行リハーサルや受け入れテスト、切戻し条件に加えて、納品物と保守体制、追加変更の単価まで合意できていれば、契約後の認識違いを抑えられます。
小さな業務範囲でのPoCと見積もり
全社一括での置き換えは避け、小さな範囲で検証してから本番計画へ広げます。
- 小さく試す：代表部門の業務を、Sandboxで検証します。
- 結果を反映：操作性や権限、連携を確かめ、範囲を決めます。
- 全体で計画：設計から保守までを含めた見積もり。
対象は、効果が見えやすい申請や顧客対応などにします。実データに近い条件で試します。
不確実性を小さくしてから、本開発へ進みます。標準機能を活かして重要業務を広げ、KPIを見ながら改善を続けると、投資効果と現場定着につながります。
ライセンス料金に加えて、業務設計や移行、権限を計画に入れます。連携、テスト、教育、保守の計画も立てます。
▼全体ガイドの記事
・Salesforce Platformのシステム開発の完全ガイド
▼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を創業。