Salesforce Platformのシステム開発の発注/外注/依頼/委託方法について

Salesforce Platformのシステム開発を発注・外注するなら、ライセンスを契約してから機能を足すのではなく、対象業務とデータを整理し、標準機能・設定・開発・外部連携の範囲を決めてから委託先と契約することが重要です。

SalesforceはCRMだけでなく、顧客管理、案件・契約、申請、代理店管理、保守受付などの業務システムを構築できるクラウド基盤です。本記事では、発注形態の選び方、RFPと要件整理、請負・準委任の使い分け、費用相場、委託先の比較方法、見積書の確認ポイントまで、2026年時点の情報をもとに解説します。

▼全体ガイドの記事
・Salesforce Platformのシステム開発の完全ガイド

Salesforce Platformのシステムとは何ですか？

Salesforce Platformのシステムとは、Salesforceのクラウド基盤に、自社の業務データや承認手順を組み合わせて構築する業務アプリケーションです。サーバーや認証の基盤を一から用意するのではなく、標準オブジェクト、権限、Flow、レポートなどを活用し、不足する部分だけを拡張します。

顧客・取引先・商談の管理に加えて、契約更新、見積承認、問い合わせ受付、代理店の案件共有、保守作業、プロジェクトの進捗管理などを構築できます。たとえば申請者がフォームに入力し、上長が承認し、承認済みデータを会計システムへ連携する流れを、オブジェクト、Flow、権限、APIの組み合わせで実現できます。

一方で、大量データを高速集計する処理や、複雑な基幹計算をすべてSalesforce内に寄せると、設計・性能・保守の負担が増えます。Salesforceを業務プロセスのハブにし、基幹や会計に残すデータとSalesforceで扱うデータを分ける判断も、発注前に必要です。

最初にFit to Standardの考え方で、業務を「標準機能で対応する領域」「設定やFlowで補う領域」「Apex・Lightning Web Components（LWC）・APIで開発する領域」に分けます。標準オブジェクトや権限、レポートに合わせて業務を見直せる部分は、独自開発を抑えるほど短納期と低コストにつながります。

独自開発は、競争力に直結する業務や標準機能では実現できない連携に絞ります。見積依頼の段階で「画面を独自にしたい」とだけ伝えると、設定で済む機能までコード化されることがあります。なぜ標準では足りないのか、将来の変更頻度はどの程度かを業務単位で説明できる状態にすると、不要な開発を減らせます。

Salesforce公式の事例では、IDOMがService Cloud、Digital Engagement、Lightning Platform、Herokuを組み合わせ、顧客接点のデジタル化を進めています（出典: セールスフォース・ジャパン「IDOM、顧客接点のデジタル化を推進するためSalesforceを導入」、2025年）。この事例からも、Salesforce Platformの発注は単一画面の制作ではなく、問い合わせチャネル、業務データ、外部サービスをどうつなぐかの設計として考える必要があります。

同じ構成をそのまま導入するのではなく、自社で残すシステムとSalesforceへ集約する業務を切り分けます。事例を見積依頼に使うときは、採用製品名だけでなく、対象業務、連携方式、データの所有者、導入後の運用体制を確認し、自社のRFPに落とし込みます。

Salesforce Platformの発注形態はどれを選びますか？

発注形態は、丸ごと任せるか、社内とベンダーが共同で進めるか、専門人材を補うかで考えます。重要なのは、発注形態の名前よりも、誰が業務判断をし、誰が設計・設定・開発・テスト・運用を担当するかを明文化することです。

社内にSalesforceの管理者やシステム企画担当者が少なく、短期間で業務を立ち上げたい企業には、要件整理から構築、移行、教育、保守までを一括で委託する形が向いています。窓口が一本化されるため、責任範囲を整理しやすいことが利点です。

ただし、一括外注でも業務の優先順位、承認者、データの正しさ、受入基準まで丸投げしてはいけません。ベンダーが業務を推測すると、現場に合わない画面や過剰なカスタマイズが増えます。週次の意思決定者を社内に置き、判断が止まらない体制を作ります。

社内に業務知識と一定のIT担当者がいる場合は、社内のプロダクトオーナーと外部パートナーが共同で進める伴走型が有効です。社内が業務の優先順位を決め、外部パートナーが標準機能の活用、データモデル、権限、FlowやApexの設計を支援します。

小さなMVPをSandboxで試し、代表ユーザーの反応を見ながら段階的に範囲を広げる場合にも適しています。社内にノウハウが残りやすい一方、会議の参加者、意思決定期限、仕様変更の扱いが曖昧だと、検討だけが長引きます。成果物と毎月の稼働範囲を先に合意します。

既存環境の権限整理、API連携の調査、リリース障害の原因分析、管理者への教育など、課題が限定されている場合はスポット支援が適しています。すでに別会社が構築したSalesforceを引き継ぐときも、最初から全面改修せず、設定・メタデータ・データ辞書を調査する支援から始めると安全です。

内製化支援では、外部パートナーが設計とレビューを担い、社内担当者が設定変更やテストを担当します。契約書には、トレーニングの回数だけでなく、権限マトリクス、命名規則、リリース手順、変更履歴、障害対応の手順を成果物として含めると、担当者が変わっても運用しやすくなります。

RFPと要件整理はどのように進めますか？

RFPは、機能一覧を並べるだけの資料ではありません。なぜ作るのか、どの業務を変えるのか、どのデータを正とするのか、どの状態になれば受け入れるのかを、候補会社が同じ条件で見積もれるようにまとめる資料です。

まず現状の業務を、Excel、既存CRM、メール、紙の申請、会計システムなどの単位で棚卸しします。案件登録から受注、請求、保守までの流れを時系列で書き、二重入力、承認待ち、検索できない情報、担当者しか分からない作業を明らかにします。

次に、改善後の業務を「入力回数を減らす」「承認状況を可視化する」「顧客情報の重複をなくす」などの目的で表現します。Salesforceを導入すること自体を目的にせず、処理時間、入力率、失注理由の記録率、問い合わせの初回対応時間など、リリース後に測れる指標を2〜5個に絞ります。

RFPには、対象部門とユーザー数、対象業務、業務フロー、必要な画面と項目、承認ルール、既存データの件数と形式、連携先、希望リリース時期、社内体制、予算の考え方を記載します。ユーザー数は閲覧者と入力者を分け、月間の登録件数やピーク時の処理量も書くと、ライセンスや性能の前提がそろいます。

非機能要件も省略しません。個人情報の扱い、最小権限、監査ログ、バックアップ、障害時の連絡、復旧目標、Sandboxの利用、リリース承認者を明記します。Lightning Web Securityなどの基盤側の安全機能があっても、共有設定や接続アプリ、APIユーザーの権限設計まで自動で適切になるわけではありません。

最初のリリースにすべての部門・帳票・連携を詰め込むと、費用と納期が膨らみます。最も効果が出る一つの業務をMVPにし、顧客・案件・承認などの核を先に稼働させ、周辺機能を第2段階に分けます。候補会社には、必須、できれば欲しい、将来検討の3段階で見積もってもらいます。

受入基準は「使えること」ではなく、「誰が、どのデータで、どの操作を行い、どの結果になれば合格か」で表します。移行データの照合件数、承認通知の到達、権限ごとの閲覧範囲、連携エラー時の再処理、帳票の合計値などをテスト項目にします。

契約形態は請負と準委任をどう使い分けますか？

Salesforce Platformの委託では、要件が固まった部分を請負、要件整理や継続的な改善を準委任とする組み合わせが現実的です。契約形態だけで責任が決まるわけではないため、成果物、作業範囲、検収、変更管理、再委託、情報管理を契約書と別紙で具体化します。

請負契約は、合意した成果物を完成させ、検収を受ける範囲に向いています。確定した画面、設定、Flow、Apex、連携処理、テスト仕様書、移行手順書などを対象にし、固定価格と納期を定めやすい点が利点です。

ただし、請負にした後で業務フローや対象項目が変わると、追加費用や納期変更の争いになりやすくなります。変更要求の受付、影響調査、見積提示、承認、リリース判断の手続きをあらかじめ決めます。未確定の要件まで一括請負に含めることは避けます。

準委任契約は、専門家としての注意を払いながら、合意した業務を遂行する支援に向いています。要件定義、現状調査、標準機能の評価、プロトタイプ、データクレンジング支援、運用改善のように、作業を進めながら内容が具体化する工程で使いやすい契約です。

IPAの情報システム・モデル取引・契約書では、システム開発の責務や契約書のひな型が整理され、アジャイル開発版では変動する機能に準委任がなじみやすいと説明されています（出典: IPA「情報システム・モデル取引・契約書」、2025年更新）。ただし準委任でも、稼働時間、担当者、成果物、会議体、報告方法、上限工数を合意し、作業が無制限にならないよう管理します。

契約前には、成果物の形式と納品時期、検収期間、瑕疵や不具合の扱い、追加改修の単価、再委託の可否、秘密保持、個人情報、知的財産、設定情報の引渡しを確認します。Salesforceではソースコードだけでなく、メタデータ、権限設計書、オブジェクト定義、データ辞書、リリース手順、設定変更履歴が引継ぎ資産になります。

また、ライセンス契約の当事者と開発会社の契約を分けて記載します。Salesforceの利用料、ストレージ、API、AppExchange製品、追加のAI関連機能、保守契約が見積に含まれるかを確認し、解約時のデータ返却や移行支援も確認しておくと、将来のベンダー変更に備えられます。

Salesforce Platformのシステム開発費用相場はいくらですか？

Salesforce Platformの費用は、ライセンス料と導入・開発費、運用保守費を分けて考えます。Salesforceが一律の開発価格を公開しているわけではないため、以下は公式料金と国内支援会社の公開相場、業務システムの工程データをもとにした推定レンジです。機能数、ユーザー数、データ移行、連携、権限、契約条件によって変動します。

Salesforce公式の2026年版料金案内では、Starter Suiteは1ユーザーあたり月額3,000円、Pro Suiteは12,000円、Enterpriseは21,000円、Unlimitedは42,000円、Agentforce 1 Salesは66,000円と案内されています（いずれも税別、出典: セールスフォース・ジャパン「2026年版 Salesforceの料金プラン」、2026年）。10ユーザーで単純計算すると、Starter Suiteは年間36万円、Enterpriseは年間252万円が目安ですが、これはライセンスの試算であり、開発費や追加製品を含みません。

利用者ごとに必要な権限や製品が異なるため、全員に同じ上位プランを割り当てるとは限りません。読み取り中心の利用者、入力する利用者、管理者、外部連携用のユーザーを分け、ストレージ、API、AppExchange、サポートプランの追加費用も確認します。Salesforce公式の導入ガイドは、ライセンスだけでなく初期構築・サポートを含めた総コストを確認する重要性を示しています（出典: セールスフォース・ジャパン「2026年版 Salesforce導入ガイド」、2026年）。

標準機能中心で、5〜10ユーザーの権限設定、画面設定、簡易的なデータ移行に絞る場合は、初期30万〜100万円程度が一つの目安です。標準オブジェクトの拡張、複数部門のFlow、帳票、データクレンジングなどを含む中規模では、150万〜600万円程度のレンジで見積もられることがあります。これらは公開されている国内支援会社の相場を参考にした目安で、固定価格ではありません。

会計・基幹・ECとの連携、ApexやLWCによる独自画面、複雑な権限、複数組織、監査対応まで含めると、1,000万円以上になる可能性があります。大規模な業務システムでは数千万円規模となることもありますが、Salesforceだから自動的にその金額になるわけではありません。対象業務、連携本数、移行件数、テスト範囲、社内の参加度を分解して比較します。

初年度TCOは、ライセンス、要件定義、設定・開発、データ移行、外部連携、教育、テスト、稼働後の保守を合算して見ます。開発費だけを比較すると、移行リハーサルや操作研修が別請求になり、予算超過を招きます。ライセンスを年額、開発を初期費用、保守を月額に分けた見積書を依頼します。

公開されている国内支援会社の相場では、Salesforceの運用保守は月額10万〜50万円程度とされる例があります（出典: 株式会社ナインテック「Salesforce導入の費用相場」、調査時点）。設定変更、障害対応、リリース影響調査、ユーザー教育、データ品質管理、SLAのどこまでを含むかで上下するため、月の対応時間や緊急対応の条件まで確認します。

Salesforceの委託先選定と見積比較のポイント

委託先は、Salesforceの認定資格や導入社数だけで決めません。標準機能を優先しながら自社の業務を理解できるか、データ移行と連携に責任を持てるか、稼働後に運用を支えられるかを、同じ質問と同じRFPで比較します。

確認するのは、同じ製品を使った実績だけではありません。自社と近いユーザー数、業界規制、部門数、データ量、基幹連携、移行難易度の案件を担当したかを聞きます。事例紹介では成果だけでなく、標準機能と独自開発の境界、体制、期間、移行件数、稼働後の支援内容を確認します。

2026年6月には、SalesforceがAgentforceの本番稼働を支援する国内初期9社のFDE Partner Networkを発表しました（出典: Salesforce「FDE Partner Networkを日本で本格展開」、2026年）。AIエージェントやデータ統合を含む案件では、このような最新領域の実装経験も候補の一つになりますが、AI案件の実績がすべての業務システムに適するとは限りません。自社の課題と合うかで判断します。

見積書は合計額の安さではなく、要件定義、設計、設定、Apex・LWC、連携、移行、テスト、教育、リリース、保守の行ごとに比べます。各作業の工数、担当者の役割、期間、成果物、対象外を確認し、安い見積に移行やテストが含まれていない可能性を調べます。

3社程度に同じRFPを渡し、見積の前提条件をそろえると比較しやすくなります。質問への回答が具体的か、リスクを先に指摘するか、追加費用の条件を隠していないかも評価します。見積金額が近くても、リリース後の月額保守、追加改修の単価、緊急対応、再委託の有無まで含めると総額は変わります。

Salesforceはリリースや組織設定の変更が継続するため、稼働後の支援体制が重要です。問い合わせ窓口、回答時間、障害の優先度、月次報告、設定変更の承認、Sandboxでの検証、リリースノート確認、ユーザー教育の担当を契約前に決めます。

将来の内製化や委託先変更を考えるなら、設定・メタデータ・テストケース・データ辞書を納品対象にし、社内が読める説明を残してもらいます。担当者個人の知識やベンダー独自の管理表に依存すると、引継ぎに追加費用が発生します。再委託先、海外拠点からのアクセス、個人情報の保管場所も確認します。

Salesforce Platformのシステム発注でよくある質問

Salesforce Platformの外注では、費用だけでなく、業務の決め方、契約、データ、運用の責任分担が疑問になりやすいです。ここでは発注前に確認されることの多い質問に、結論から回答します。

業務要件を決める責任は社内に置き、設計・開発・移行・テストなど専門性が必要な部分を外注する形が取り組みやすいです。小規模な設定変更は内製し、データ連携や権限設計などリスクの高い部分は経験のあるパートナーに任せるなど、工程単位で分担します。

相談できますが、いきなり開発費の総額を求めるより、現状調査や要件定義を準委任で依頼する方が適切です。対象部門、困っている業務、利用者数、既存データ、連携先、希望時期だけでも整理して渡し、最初の調査で成果物と次の判断材料を合意します。

合計金額ではなく、含まれる作業と含まれない作業をそろえることです。要件定義、データクレンジング、移行リハーサル、権限テスト、ユーザー教育、稼働後の保守が別料金になっていないかを確認し、対象外の作業は別見積の条件まで書面で残します。

通常、ライセンス料と導入・開発費は別に考えます。ライセンスはユーザーや製品の利用料であり、業務設計、設定、コード開発、データ移行、連携、教育、保守の費用が自動的に含まれるわけではありません。契約するプランと支援会社の見積を分けて、初年度と2年目以降の総額を確認します。

まとめ

Salesforce Platformのシステム開発を発注するときは、まずAs-IsとTo-Be、KPI、対象ユーザー、データの正、最初にリリースする範囲を決めます。そのうえで、標準機能・設定・独自開発・外部連携の境界を整理し、同じRFPを複数社へ渡します。

発注前にそろえるのは、完璧な仕様書ではなく、意思決定できる材料です。現状業務、改善目的、ユーザー数、移行件数、連携先、非機能要件、希望時期、社内の責任者を1枚にまとめ、未確定事項は未確定と明記します。

費用は、標準機能中心なら初期30万〜100万円程度、中規模なら150万〜600万円程度、連携や独自開発が大きい場合は1,000万円以上になる可能性があります。ただし、これらは要件から算出する推定レンジです。保守、教育、データ品質、メタデータの引渡し、内製化支援まで含め、2年目以降も運用できる委託先を選ぶことが、Salesforce Platformの価値を引き出す近道です。

▼全体ガイドの記事
・Salesforce Platformのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。