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

Salesforce Platformの発注は、業務とデータを整理し、開発範囲を決め、委託先を選ぶ順に進めると、運用に合った形になります。

発注形態の選び方から、RFPと要件整理、契約形態、費用相場、委託先の比較まで、順を追って説明します。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Salesforce Platformのシステムの概要

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

CRM以外で作れる業務

CRM以外にも、Salesforceでは次のような業務を構築できます。

• 顧客・取引先・商談：契約更新や見積承認、問い合わせ受付の管理
• 社内外の業務：代理店との案件共有、保守作業、プロジェクト進捗を扱えます。
• 申請・会計連携：フォーム申請の上長承認と、承認済みデータの会計システムへの連携

申請の流れはオブジェクト、Flow、権限、APIを組み合わせて実現します。

一方で、大量データの高速集計や複雑な基幹計算まですべてをSalesforceに担わせると、設計・性能・保守の負担が増えます。そのため、Salesforceを業務プロセスのハブとして使い、基幹や会計に残すデータとの切り分けを発注前に決めておきます。

標準機能と独自開発の分け方

まず、業務をFit to Standardの考え方に沿って、対応方法ごとに分けます。

• 標準機能：標準オブジェクト、権限、レポートの活用
• 設定・Flow：標準機能だけで不足する業務を補います。
• 独自開発：Apex・Lightning Web Components（LWC）・APIで実装します。

標準機能で対応できる業務は、独自開発を抑えられます。さらに、独自開発を抑えるほど、短納期と低コストにつながります。

独自開発は、競争力に直結する業務や、標準機能では実現できない連携に絞ります。見積を依頼する際は、標準機能では足りない理由と将来の変更頻度を業務単位で伝えます。そうすると、設定で済む機能までコード化されるのを防げます。

複数サービスを組み合わせた導入事例

Salesforce公式のIDOM事例では顧客接点をデジタル化しました（出典: セールスフォース・ジャパン「IDOM、顧客接点のデジタル化を推進するためSalesforceを導入」、2025年）。

• 顧客接点のサービス：Service Cloud、Digital Engagement
• 組み合わせたサービス：Lightning Platform、Heroku

この事例からは、Salesforceの発注が単一画面の制作にとどまらないことが分かります。事例を自社の発注に生かす際は、次の観点を自社の案件と照らし合わせます。

• 設計対象：単一画面ではなく、問い合わせチャネル、業務データ、外部サービスのつなぎ方。
• RFPへの反映：製品名に加えて、対象業務と連携方式を書き、データ所有者と運用体制も確認します。
• システムの分担：同じ構成をそのまま使わず、Salesforceに集約する業務と既存側に残す業務を分けます。

Salesforce Platformの発注形態の選び方

発注形態は、一括委託、社内とベンダーの共同開発、専門人材の補完の中から選びます。その際に大切なのは名称よりも、業務判断と、設計・設定・開発・テスト・運用を誰が担うかを書面に残しておくことです。

一括外注が向いている企業

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

業務の優先順位や承認者、データの正しさ、受入基準は、社内で決めて持ち続けます。週次で意思決定する担当者を社内に置けば、ベンダーの推測による不適切な画面や過剰なカスタマイズを防げます。

共同開発・伴走型が向いている企業

業務知識があり、一定のIT担当者もいる企業では、社内と外部で役割を分ける伴走型が有効です。

• 業務判断：社内のプロダクトオーナーが優先順位を決めます。
• 技術支援：外部が標準機能、データモデル、権限、FlowやApexの設計を支援します。
• 段階導入：小さなMVPをSandboxで試し、代表ユーザーの反応を見て範囲を広げます。

社内にノウハウが残る一方で、会議の参加者や判断期限、仕様変更の扱いが曖昧だと、進行が長引きます。そのため、着手前に成果物と毎月の稼働範囲を合意しておきます。

スポット支援と内製化支援の使いどころ

課題の範囲が限られているなら、スポット支援が適しています。

• スポット支援：権限整理、API連携調査、障害原因分析、管理者教育など。
• 既存環境の引継ぎ：別会社が構築した環境は、全面改修の前に設定・メタデータ・データ辞書を調査します。
• 内製化支援：外部が設計とレビューを担い、社内担当者が設定変更やテストを行います。
• 成果物：研修回数、権限マトリクス、命名規則、リリース手順、変更履歴、障害対応手順。

成果物を残しておけば、担当者が変わっても運用を続けられます。

RFPと要件整理の進め方

RFPは、目的や変える業務、正とするデータ、受入条件をまとめ、候補会社が同じ条件で見積もれるようにする資料です。

As-Is・To-Beと目的の整理

まず、業務上の課題が何かを明らかにするところから始めます。

• 現状業務を洗い出す：課題と業務の流れを一覧にします。
• 改善目的と指標を定める：導入後の成果を測れる形にします。

業務で使っているExcelや既存CRMを中心に、メールや紙の申請、会計システムなども調べます。案件登録から受注、請求、保守までを時系列に並べると、二重入力や承認待ちが明らかになるほか、検索できない情報や属人作業も見えてきます。

改善後は、入力回数を減らし、承認状況を一覧で追えるようにして、顧客情報の重複をなくすことを目指します。そのうえで、Salesforce導入そのものを目的にせず、処理時間や入力率を指標にします。

指標の候補には、失注理由の記録率や問い合わせの初回対応時間もあります。リリース後に測れる指標は、2〜5個に絞ります。

RFPに含める項目

RFPには、候補会社が同じ条件で見積もれるよう、次の項目をそろえます。

• 業務範囲：対象部門・業務、業務フロー、画面・項目、承認ルール。
• 規模・データ：ユーザー数、データ件数・形式、連携先、月間登録数、ピーク量。
• 導入前提：希望時期、社内体制、予算。閲覧者と入力者は分けて記載。
• 非機能要件：個人情報、最小権限、監査ログ、バックアップ、障害連絡、復旧目標。

あわせて、Sandboxの利用とリリース承認者も明記します。Lightning Web Securityなどの安全機能があっても、共有設定までは自動で整いません。さらに、接続アプリやAPIユーザーの権限設計も必要です。

MVPと受入基準

最初のリリースにすべてを詰め込むと、費用と納期が膨らみます。

• MVP：効果が大きい一業務を選び、顧客・案件・承認などを先行稼働させます。
• 段階と優先度：周辺機能を第2段階に分け、必須・希望・将来検討で見積もります。
• 受入基準：誰がどのデータで操作し、どの結果なら合格かを決めます。

テスト項目には、移行データの照合件数や承認通知の到達を含めます。さらに、権限ごとの閲覧範囲や連携エラーの再処理、帳票の合計値も確認項目にします。

請負と準委任の使い分け

要件が固まった範囲は請負とし、要件整理や継続改善は準委任とする組み合わせが現実的です。

責任の範囲は、成果物や作業範囲、検収をどう決めるかで定まります。そのため、契約前に、これらを具体的に決めておきます。加えて、変更管理、再委託、情報管理は契約書と別紙に記載します。

完成物が明確な範囲に使う請負契約

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

業務フローや対象項目が変わると、追加費用や納期の変更をめぐって争いになりやすくなります。そこで、変更の受付から影響調査、見積提示、承認、リリース判断までの手順を決めておき、未確定の要件を一括で請け負わないようにします。

要件定義や伴走支援に使う準委任契約

準委任は、専門家として注意を払いながら、合意した業務を進める契約です。

• 使いやすい工程：要件定義、現状調査、標準機能評価、プロトタイプ。
• 支援内容：データクレンジングや運用改善など、進行中に内容が具体化する業務。

IPAのモデル取引・契約書は、責務やひな型を整理しています。さらに、アジャイル版では、変動機能に準委任がなじみやすいと説明しています（出典: IPA「情報システム・モデル取引・契約書」、2025年更新）。

準委任であっても、稼働時間や担当者、成果物を合意します。加えて、会議体や報告方法、上限工数も決めて、作業が無制限にならないよう管理します。

契約書と見積書で確認する項目

契約前には、成果物と費用、情報管理、引継ぎの条件を確認します。

• 成果物と検収：形式、納期、検収期間、不具合の扱い。
• 契約条件：追加改修単価、再委託可否、秘密保持、個人情報、知的財産。
• 引継ぎ資産：ソースコード、メタデータ、権限設計書、オブジェクト定義、データ辞書、リリース手順、変更履歴。
• 費用・解約：契約当事者を分けたうえで、利用料、ストレージ、API、AppExchange、追加AI機能、保守契約の扱いを確認します。
• 解約時：データ返却や移行支援を確認し、ベンダー変更に備えます。

Salesforce Platformのシステム開発費用相場の目安

費用は、ライセンス料、導入・開発費、運用保守費に分けて見ていきます。

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、サポートの費用も確認する

公式の導入ガイドも、初期構築やサポートを含む総コストの確認を促しています（出典: セールスフォース・ジャパン「2026年版 Salesforce導入ガイド」、2026年）。

導入・開発費の規模別レンジ

導入・開発費は、対象規模と機能の範囲で幅があります。

• 標準機能中心：5〜10ユーザーで初期30万〜100万円程度
• 中規模：複数部門のFlowなどを含め150万〜600万円程度
• 大規模・複雑：連携や独自開発を含むと1,000万円以上の可能性

標準機能中心で想定するのは、5〜10ユーザーの権限と画面設定、簡易的なデータ移行の範囲です。

中規模では、標準オブジェクトの拡張や複数部門のFlowに加えて、帳票やデータクレンジングも含まれます。なお、これらの金額は国内支援会社の公開相場を参考にした目安で、固定価格ではありません。

たとえば、会計・基幹・ECとの連携や、ApexやLWCによる独自画面を含むと、1,000万円以上になる可能性があります。また、複雑な権限や複数組織、監査対応も費用に影響します。

大規模なシステムでは、数千万円規模になることもあります。ただし、Salesforceだからといって自動的にその金額になるわけではありません。対象業務と連携本数、移行件数を分けて比べ、テスト範囲や社内の参加度も見ます。

初年度TCOと保守費

初年度TCOには、ライセンスや要件定義、設定・開発を含めます。さらに、データ移行や外部連携に加えて、教育、テスト、稼働後の保守も合算します。

開発費だけを比べると、移行リハーサルや操作研修が別請求になり、予算超過を招きます。

費用項目は、ライセンスを年額、開発を初期費用、保守を月額に分けて見積もります。

• 保守費：公開相場には月額10万〜50万円程度の例があります
• 保守の対象：作業範囲、月の対応時間、緊急対応の条件を確認する

この公開相場の出典は、株式会社ナインテック「Salesforce導入の費用相場」（調査時点）です。

保守費は、設定変更、障害対応、リリース影響調査、ユーザー教育をどこまで含むかで変わります。さらに、データ品質管理やSLAについても、対象範囲を確認します。

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

委託先は、認定資格や導入社数を判断材料の一つにとどめ、同じRFPをもとに比べます。比べる観点は、標準機能を優先して業務を理解できるか、移行と連携を担えるか、稼働後の運用を支援できるかです。

自社に近い導入経験と設計力

自社に近い条件の案件経験があるか、事例でどう進めたかを確認します。

• 案件条件：ユーザー数、業界規制、部門数、データ量、基幹連携、移行難易度。
• 事例の中身：標準機能と独自開発の境界、体制、期間、移行件数、稼働後支援。

Salesforceは6月に、Agentforceの本番稼働を支えるFDEの国内初期9社を発表しました（出典: Salesforce「FDE Partner Networkを日本で本格展開」、2026年）。

AIエージェントやデータ統合の案件では、最新領域の実装経験も候補になります。ただし、AI案件の実績がすべての業務システムに合うとは限りません。自社の課題との適合で判断します。

見積書の作業単位と前提条件

見積書は、合計額だけでなく、作業と見積前提をそろえて比べます。

• 作業範囲：要件定義、設計、設定、Apex・LWC、連携、移行、テスト、教育、リリース、保守。
• 見積前提：工数、役割、期間、成果物、対象外。移行やテストの有無も確認。
• 提案内容：3社程度に同じRFPを渡し、回答の具体性やリスク提示を比べます。

金額が近くても、総額は変わることがあります。月額保守や追加改修単価、緊急対応、再委託の有無によって差が出るためです。

保守体制とベンダー変更のしやすさ

Salesforceでは設定変更やリリースが続くため、稼働後の支援体制が重要です。

• 保守窓口：問い合わせ先、回答時間、障害優先度、月次報告
• 変更管理：設定変更承認、Sandbox検証、リリースノート確認、教育担当
• 引継ぎ：設定、メタデータ、テストケース、データ辞書と社内向け説明
• 委託条件：再委託先、海外拠点からのアクセス、個人情報の保管場所

将来の内製化や委託先の変更に備えて、契約の段階から引継ぎ条件を検討します。担当者の知識やベンダー独自の管理表に頼りきりだと、変更時に追加費用が発生します。

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

外注では費用のほかにも、業務判断や契約、データ、運用の責任分担が疑問になりがちです。発注前によく確認される点を、順に見ていきます。

Salesforceの開発は自社と外注のどちらがよいですか？

業務要件を決める責任は社内に置いたうえで、専門性が必要な設計、開発、移行、テストは外注できます。

小規模な設定変更は社内で行い、データ連携や権限設計のようにリスクの高い部分を任せる方法もあります。いずれの場合も、経験のあるパートナーと工程単位で分担を決めます。

要件が決まっていなくても開発会社に相談できますか？

相談はできますが、要件が決まっていない段階では、総額見積より、現状調査や要件定義を準委任で依頼するほうが適しています。部門や課題業務、利用者数、既存データ、連携先、希望時期を整理して渡したうえで、調査の成果物と次の判断材料を合意します。

見積を比較するときに一番注意することは何ですか？

合計金額を見る前に、含まれる作業と含まれない作業をそろえて比べることが大切です。

要件定義、データクレンジング、移行リハーサル、権限テストが含まれるかを確認します。そのうえで、ユーザー教育や稼働後保守の別料金、対象外となる条件を書面で残します。

Salesforceのライセンス料に開発費は含まれますか？

通常、ライセンス料と導入・開発費は別です。

• ライセンス料：ユーザーや製品の利用料です。
• 別途確認する費用：業務設計、設定、開発、移行、連携、教育、保守。

契約プランと支援会社の見積は分けて考え、初年度と2年目以降の総額を確認します。

まとめ

発注時は、As-IsとTo-Be、KPI、対象ユーザーを決めます。加えて、正とするデータと初回リリースの範囲も決めておきます。続いて、標準機能と設定、独自開発、連携の境界を整理し、同じRFPを複数社に渡します。

発注成功のために最初にそろえるもの

発注前に必要なのは、完璧な仕様書よりも意思決定の材料です。現状業務や改善目的、ユーザー数、移行件数を押さえ、連携先と非機能要件、希望時期、社内責任者もあわせてまとめます。そのうえで、未確定の事項は明記します。

金額より長く使える体制

標準機能中心なら初期30万〜100万円程度、中規模なら150万〜600万円程度、連携や独自開発が大きい場合は1,000万円以上の可能性があります。いずれも、要件をもとにした推定のレンジです。

保守や教育、データ品質、メタデータの引き渡し、内製化支援まで見たうえで、2年目以降も運用できる委託先を選ぶことが、価値につながります。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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