Salesforce Platformのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Salesforce Platformのシステム開発は、標準機能を土台に業務データ・権限・自動化・外部連携を段階的に設計し、要件整理から定着化までを一つのプロジェクトとして進める方法が基本です。

SalesforceはCRMとして知られていますが、顧客管理だけでなく、案件・契約・申請・代理店・保守受付などの業務システムも構築できます。一方で、ライセンスを契約して画面を作るだけでは、データ移行の不備、権限設定の漏れ、現場で使われない入力項目、想定外の追加費用が起こりやすくなります。この記事では、Salesforce Platform上でシステムを開発する際の進め方を、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズに分け、各段階の成果物と判断基準、費用相場、見積もりの確認ポイントまで解説します。

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

Salesforce Platformのシステム開発とは？全体像を整理します

Salesforce Platformのシステムとは、Salesforceのクラウド基盤に用意されたデータ、認証、権限、画面、ワークフロー、API、運用機能を使い、自社の業務に合わせてアプリケーションを構築する仕組みです。インフラをゼロから用意するフルスクラッチ開発とは異なり、共通基盤を活用しながら自社固有の部分に設定やコードを追加します。

構築対象は、顧客・取引先・商談の管理に限りません。カスタムオブジェクトを使えば、契約、申請、案件、保守受付、プロジェクト、代理店、設備など、自社固有のデータを管理できます。Flowを使えば、登録内容に応じた通知、承認依頼、項目更新、期限のリマインドなどを自動化できます。担当者が入力した案件情報をもとに上長へ承認を依頼し、承認後に契約管理へ引き継ぐような流れも、データと処理を一つの基盤でつなげられます。

標準画面で不足する操作性はLightning Web Components（LWC）で拡張できます。複雑な計算や独自ルールにはApex、外部システムとの連携にはREST API、SOAP API、Bulk API、Platform Events、MuleSoftなどを使います。つまり、標準機能、設定、自動化、パッケージ、カスタム開発、外部連携を組み合わせて業務に合う形を作る仕組みです。

最初に「何でも自由に作る」と考えず、Fit to Standardの考え方で標準に合わせる領域と、独自開発する領域を分けます。標準オブジェクト、項目、画面レイアウト、権限セット、Flow、レポートで解決できる業務は、将来のアップデートや保守を考えると標準寄りに設計する方が安全です。自社の競争力に直結する独自の審査ロジックや画面体験だけをLWCやApexで作ると、開発量と保守負債を抑えやすくなります。

判断に迷う場合は、機能の便利さだけでなく、5年後にも変更しやすいかを確認します。コードを増やすほど自由度は上がりますが、テスト、ガバナ制限、担当者の引き継ぎ、リリース影響調査が必要になります。逆に標準機能だけに寄せすぎると、現場がExcelへ戻ったり、重要な例外処理を手作業で補ったりします。業務上の差別化要因、変更頻度、データ量、セキュリティ要件の4点で選択すると、過不足を判断しやすくなります。

Salesforce Platformのシステム開発の進め方｜6フェーズで解説します

Salesforce Platformの開発は、要件を聞いて一気に実装するのではなく、業務の目的とデータの流れを固めてから、段階的に作って検証します。ここでは、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズに分けます。プロジェクトの規模によって期間は変わりますが、中規模の連携・移行込みでは3〜6か月、複数部門や独自コードが多い場合は6〜12か月以上を計画値とすることがあります。期間は機能数だけでなく、意思決定の速さ、データの品質、ユーザー受け入れの体制で変動します。

最初に決めるのは画面ではなく、解決したい経営・業務課題です。「顧客情報を一元化する」だけでは抽象的なので、二重入力をなくす、承認時間を短縮する、問い合わせ履歴を担当者がすぐ確認できるようにするなど、現状の問題を業務単位で言語化します。現場へのヒアリングでは、現在のExcel、台帳、メール、承認書式、既存CRMを集め、As-Isの業務フローとデータ項目を可視化します。

次に、To-Beの業務フロー、KPI、データ所有者、利用者区分、最初のリリース範囲を決めます。特に重要なのは、初回リリースに含めないものを明示することです。全社の要望を一度に取り込むと、スコープクリープが起こり、設計のやり直しと追加費用につながります。成果物として、業務一覧、要件一覧、画面・帳票一覧、データ項目表、課題・リスク一覧、優先順位表を残し、業務部門と情報システム部門の双方が合意します。

要件整理のチェックでは、対象ユーザー数、部門ごとの業務差、現行データの件数と欠損、外部システム、法令・監査要件、希望リリース日、社内管理者の有無を確認します。個人情報や要配慮情報を扱うなら、誰がどの項目を見られるかをこの段階で決めます。後から権限を足すと、画面や連携の設計が変わるためです。

要件をもとに、Salesforceのエディション、必要な製品、AppExchangeのパッケージ、開発会社、社内の担当範囲を選びます。ライセンスはユーザー数だけで決めず、カスタムオブジェクト、Web API、Sandbox、データ容量、AI機能、サポートの必要性を確認します。Free SuiteやStarter Suiteで始められても、カスタムアプリや外部連携が必要ならPro Suite以上が候補になる場合があります。契約前に、必要な機能が標準で含まれるか、追加オプションや年間契約の条件を確認します。

実装方式は、(1)標準設定中心、(2)FlowやApp Builderによる自動化、(3)AppExchangeの管理パッケージ、(4)LWC・Apexによるカスタム開発、(5)基幹や会計を外部に残すハイブリッド連携の順に検討します。標準機能で業務価値を出せる部分を無理に開発しないことが、短納期と将来の保守性につながります。大量データを扱う基幹処理をSalesforce内に押し込むのではなく、Salesforceを顧客・業務プロセスのハブにする設計も有効です。

ベンダーを選ぶときは、Salesforceの認定資格数だけでなく、同じ業種・同じ規模のデータ移行事例、標準機能を優先する提案力、連携とテストの責任範囲、導入後の運用体制を見ます。2026年6月にSalesforceが日本で発表したFDE Partner Networkには、初期パートナーとして9社が参画しています（出典: Salesforce公式「FDE Partner Networkを日本で本格展開」、2026年）。これはAgentforceの本番実装に関する最新動向ですが、すべてのPlatform案件に最適という意味ではありません。自社の課題に必要な経験を確認することが重要です。

設計では、画面より先にデータモデルと権限モデルを固めます。標準オブジェクトとカスタムオブジェクトの関係、必須項目、重複判定、履歴の持ち方、ファイルの保管方針、データの所有者を決めます。権限は、プロファイルだけでなく権限セット、ロール階層、共有設定、項目レベルセキュリティ、外部ユーザーのアクセスを組み合わせて設計します。管理者用の強い権限を一般ユーザーへ流用しないことが基本です。

連携設計では、どのシステムが正となるか、連携方向、同期頻度、エラー時の再送、重複防止、APIユーザー、監視担当を決めます。会計や基幹システムとの連携で、Salesforceと外部側の両方が同じ顧客情報を更新すると、どちらが正しいか分からなくなります。項目対応表とエラー処理を先に作り、正常系だけでなくタイムアウト、認証失敗、部分成功、再送時の重複まで確認します。

開発はSandboxで行い、設定変更、Flow、Apex、LWC、テストデータを管理します。Flowで解決できる処理にApexを書かない、画面の都合でデータ構造を歪めない、同じロジックを複数箇所にコピーしない、といったルールを設けると、将来の変更に強くなります。LWCを使う場合は、Lightning Web SecurityやCSPなどのセキュリティ境界を前提に設計します。Salesforce公式の解説でも、LWSは名前空間ごとの分離を担い、CSPやプラットフォーム制限とは別の層として働くと説明されています（出典: Salesforce Developers、2026年確認）。

テストは、開発会社が画面を操作して終わりではありません。単体テスト、結合テスト、システムテスト、ユーザー受け入れテストを分け、要件と対応づけて実施します。正常な登録だけでなく、必須項目の未入力、重複データ、承認差し戻し、権限外の閲覧、API障害、想定以上のデータ量、日付やタイムゾーンのずれも確認します。テスト結果には、再現手順、期待値、実績、担当者、修正期限を記録します。

特に重要なのが権限テストです。営業、管理職、経理、外部委託先、システム管理者など、役割ごとのテストユーザーを用意し、「見えるべき情報が見えるか」と「見えてはいけない情報が見えないか」を両方確認します。接続アプリやAPIユーザーも、人の権限と同じように棚卸しします。個人情報を扱う場合は、ログ監視、項目監査履歴、保持・削除ルール、Platform Encryptionなどを要件に応じて確認します。

本番稼働前には、データクレンジングと移行リハーサルを行います。移行対象を「すべて」と決めるのではなく、現行データの所有者、利用目的、保存期間、重複・欠損の扱いを決め、不要な履歴を持ち込まないことも検討します。件数、主要項目、関連関係、添付ファイル、日付、文字コードを照合し、移行後に業務画面から検索・集計できるかを確認します。

切替手順には、停止時間、最終差分の取り込み、担当者、確認項目、切戻し条件を明記します。例えば、顧客件数の照合が一定割合を下回る、重要な承認が動かない、外部連携のエラーが解消できない場合は切替を中止する、といった判定条件を事前に合意します。リリース当日に初めて移行するのではなく、少なくとも1回は本番に近いデータで通し、作業時間と問題点を見積もりへ反映します。

稼働した日がプロジェクトの終わりではありません。現場が入力しなければデータは蓄積されず、管理者が運用ルールを守らなければ権限や自動化も崩れます。リリース直後は問い合わせ窓口を設け、操作説明会、短い手順書、よくある質問、管理者向けの変更手順を用意します。部門ごとに推進役を置き、現場の困りごとを改善 backlog に集めると、個別の要望を場当たり的に直す状態を避けられます。

定着化の評価指標は、ログイン数だけでは不十分です。必須項目の入力率、重複率、承認の処理時間、問い合わせの初回解決率、二重入力の削減時間、営業・保守のKPIなど、導入目的に直結する数値を測ります。毎月の運用会議で、利用されていない項目、失敗しているFlow、増えた手作業、不要な権限を見直します。Salesforceのリリースや新機能に合わせて、変更の影響とテスト範囲を確認する体制も必要です。

Salesforce Platformの費用相場とコストの内訳

費用は、Salesforceのライセンス、初期の要件整理・設計・設定開発、データ移行・連携、教育、稼働後の保守に分けて考えます。ライセンスに開発費が含まれるわけではなく、開発費に追加ストレージや外部サービスが含まれるとも限りません。見積もりを比較するときは、初期費用だけでなく、1年目と2年目以降の総保有コストを並べます。

2026年時点のSalesforce公式価格では、Free Suiteは0円、Starter Suiteは月額3,000円、Pro Suiteは月額12,000円、Enterpriseは月額21,000円、Unlimitedは月額42,000円、Agentforce 1 Salesは月額66,000円です。いずれもユーザー単位の表示価格で、契約期間や製品構成、追加オプションによって条件が変わるため、最終的には個別見積もりで確認します（出典: Salesforce公式「2026年版 Salesforceの料金プラン」、2026年）。

例えば10ユーザーで単純計算すると、Starter Suiteは月額3万円、年間36万円、Pro Suiteは月額12万円、年間144万円、Enterpriseは月額21万円、年間252万円です。ただし、Platform上で独自の業務システムを作る場合は、カスタムオブジェクト、Web API、Sandbox、データ容量、AIや外部製品の利用条件が関係します。ユーザー数を減らしても、開発・移行・保守の費用が同じ割合で下がるとは限りません。

標準機能中心の小規模導入は、要件整理、初期設定、権限、簡易移行を含めて初期30万〜100万円程度を一つの目安にできます。標準オブジェクトの追加、複数部門のFlow、帳票、データクレンジングを含む中規模では150万〜600万円程度、外部システム連携、ApexやLWC、複雑な権限、複数組織、監査対応まで含む場合は1,000万円以上になる可能性があります。これらはSalesforceが一律に定めた価格ではなく、公開相場と業務システム開発の一般的な費用感をもとにした推定レンジです。

国内の公開情報では、Salesforce導入後の保守・運用を月額10万〜50万円程度とする相場が示されています（出典: ナインテック株式会社「Salesforce導入の費用相場」、2026年確認）。設定変更だけを頼むのか、障害対応、リリース影響調査、データ品質管理、ユーザー教育まで任せるのかで金額は変わります。保守を外注しない場合でも、社内管理者の工数、資格取得、バックアップや監査の運用にコストがかかります。

初年度TCOは、ライセンス、導入支援、データ移行、連携・アドオン、教育、保守、追加ストレージ、AIクレジットなどを合算します。例えばEnterpriseを10ユーザーで使う場合、公式表示価格だけなら年間252万円ですが、これは業務システムとして稼働するための総額ではありません。移行対象の件数、連携先の数、独自画面の数、テストケース、利用定着の支援範囲を加えることで、実態に近い予算になります。

相場を見るときは、金額の大小だけでなく、何が含まれ、何が別料金かを確認します。要件定義を無償の提案作業に含めた結果、契約後に詳細設計が追加になる場合もあります。反対に、初期費用が高く見えても、移行リハーサル、操作教育、稼働後の伴走、ドキュメント納品まで含むなら、総額では比較対象と逆転することがあります。

Salesforce Platformの見積もりを取る際のポイント

見積もりの精度は、依頼時にどれだけ業務とデータの条件を伝えられるかで決まります。機能一覧だけを渡すより、対象部門、利用者、現行データ、連携先、希望時期、運用体制をそろえた方が、会社ごとの前提差を減らせます。安い見積もりを選ぶのではなく、同じスコープで比較できる状態を作ることが先です。

最低限、対象業務の目的、現状フロー、将来フロー、利用者と権限、画面・帳票、データ項目、移行件数、連携先、非機能要件、希望リリース日を整理します。Excelや既存CRMがある場合は、サンプルデータだけでなく、項目定義、重複や欠損の状況、添付ファイルの扱いも伝えます。API連携がある場合は、送受信する項目、件数、頻度、障害時の運用、接続環境の制約をまとめます。

RFPには、必須要件、できれば実現したい要件、初回リリース後に回す要件を分けて記載します。加えて、PoCやMVPの範囲、受け入れ基準、納品物、プロジェクト管理方法、問い合わせ窓口、社内側の作業を明示します。特に「データ移行は支援のみ」「連携先の改修は対象外」「本番切替はユーザー側」などの境界条件は、口頭で済ませず文書に残します。

複数社へ相談する場合は、同じ資料と質問を渡し、見積もりを工程別に分けてもらいます。要件整理、設計、設定、Flow、Apex・LWC、データ移行、連携、テスト、教育、切替、保守を一式にまとめられると、価格差の理由が見えません。成果物、担当人数、作業時間、前提条件、除外事項、追加変更の単価まで確認します。

選定では、Salesforce認定資格、同業種の事例、似たユーザー数・データ量の実績、内製化支援、保守のSLA、再委託の有無を確認します。2026年時点のAppExchange掲載情報では、サンブリッジにSalesforce検証済みプロジェクト409件、認定資格保有者100人、創業1999年という情報があります（出典: Salesforce AppExchange、2026年確認）。このような公開情報も参考になりますが、自社と近い業務の実績や、担当予定チームの経験を面談で確かめることが大切です。

追加費用が発生しやすいのは、要件変更、データの欠損・重複、連携先仕様の変更、権限の追加、帳票の作り直し、テストデータの準備、利用者教育の拡大です。見積もりに含まれる変更管理の方法、追加開発の単価、納期への影響、承認者を契約前に決めます。準委任か請負か、検収条件は何か、成果物の範囲はどこかも重要です。

納品物はソースコードだけでは足りません。Salesforceでは設定やメタデータが業務の動きを作るため、メタデータ、権限設計書、データ辞書、連携仕様書、テスト結果、変更履歴、運用手順書、管理者向け教育資料の引き渡しを確認します。ベンダーを変更したり社内運用へ移行したりする可能性を考え、設定を説明できる状態にしておくことが、ロックインのリスクを下げます。

よくある質問（FAQ）

Salesforce Platformのシステム開発では、CRM導入との違い、開発期間、標準機能とカスタム開発の境界、社内で作れる範囲がよく質問されます。費用や期間は要件で変わりますが、判断の軸を持っておくと、必要以上の開発や、後からの作り直しを防げます。

CRM導入は、営業や顧客対応に必要な標準機能を設定し、早く使い始めることが中心です。Platformのシステム開発は、標準機能に加えて、自社固有のデータモデル、申請・契約・保守などの業務フロー、外部システム連携、独自画面やロジックまで設計する点が異なります。両者に明確な境界線があるわけではないため、どこまでを標準で使い、どこからを開発するかを要件整理で決めます。

標準SFA・CRMの設定中心なら2〜3か月、中規模でデータ移行や外部連携を含む場合は3〜6か月、複数部門・複数システム・ApexやLWCを含む場合は6〜12か月以上が計画上の目安です。これは一般的な計画値であり、ユーザー数だけで決まりません。要件の確定、データクレンジング、意思決定、受け入れテスト、切替リハーサルの期間を含めて見積もります。

標準機能の設定、項目作成、簡単なFlow、レポートであれば、研修を受けた社内管理者が進められる場合があります。ただし、業務要件の整理、複雑な権限、既存データの移行、Apex・LWC、外部API連携、監査対応まで含む場合は、専門会社の支援を受ける方が安全です。社内で進める場合も、最初にデータ所有者、変更管理、テスト、バックアップ、問い合わせ対応の役割を決めます。

あります。Salesforce公式の2025年1月の発表では、IDOMが顧客接点のデジタル化を目的にService Cloud、Digital Engagement、Lightning Platform、Herokuを導入し、LINEミニアプリの来店予約や商談内容などをデジタル管理する構成が紹介されています（出典: Salesforce公式「IDOM、顧客接点のデジタル化を推進するためSalesforceを導入」、2025年）。この事例からも、製品を単体で導入するのではなく、顧客接点、データ、業務プロセスを組み合わせて設計することが分かります。

まとめ｜Salesforce Platformの開発は段階設計と定着化が重要です

Salesforce Platformのシステム開発では、最初に目的、As-Is、To-Be、KPI、データ所有者、初回リリース範囲を決めます。そのうえで、標準機能、Flow、AppExchange、Apex・LWC、外部連携を適切に使い分け、要件整理から選定、設計開発、テスト、稼働、定着までを一貫して管理します。

着手前は、対象業務と対象ユーザーが明確か、現行データと連携先を棚卸しできているか、標準と開発の境界を説明できるか、権限・監査・保持要件を決めているかを確認します。さらに、移行リハーサル、受け入れテスト、切戻し条件、納品物、保守体制、追加変更の単価まで合意できていれば、契約後の認識違いを抑えられます。

初めから全社の業務を一度に置き換えるのではなく、代表部門の業務や最も効果が見えやすい申請・顧客対応などを対象に、SandboxでPoCやMVPを試す方法が現実的です。実データに近い条件で、利用者が迷わず使えるか、権限が安全か、連携が安定するかを確認し、その結果を本番範囲と見積もりへ反映します。要件と費用の不確実性を小さくしてから本開発へ進めることが、Salesforce Platformを長く使うための近道です。

Salesforce Platformのシステム開発を検討している場合は、ライセンス料金だけで判断せず、業務設計、データ移行、権限、連携、テスト、教育、保守まで含めた全体像で計画してください。標準機能を活かしながら自社の重要業務だけを拡張し、稼働後もKPIを見ながら改善を続けることが、投資効果と現場定着の両方につながります。

▼全体ガイドの記事
・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を創業。