Salesforce導入・改修の検証は、30日間の無料トライアル、Sandboxでの試作、現場の評価を順に進めると、本開発の手戻りを減らせます。検証の進め方を先に設計しておくと、後工程で「こんなはずではなかった」と気づく事態を防ぎ、プロジェクトの成功にもつながります。
Salesforceはクラウド型のCRM・SFAプラットフォームで、営業支援のSales Cloudと、カスタマーサービスのService Cloudを提供しています。また、B2Bマーケティングオートメーションには、Marketing Cloud Account Engagement（旧称Pardot）があります。検証手法の違いから本開発への接続まで、順に説明します。
▼全体ガイドの記事
・SalesForce導入支援・改修の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
SalesForceにおけるPoC・プロトタイプ・モックアップ開発の位置づけ
PoC（概念実証）、プロトタイプ、モックアップは、本開発の前に行う検証の手法で、目的と作るものの細かさがそれぞれ異なります。モックアップは画面イメージや操作フローを形にして、見た目を確かめるものです。プロトタイプは一部の機能が動く試作品で、PoCは実際の業務データや業務プロセスを使い、その方式で自社の課題を解決できるかを検証します。
ただし、Salesforceでは3つの検証手法を明確に分けず、一連のプロセスとして段階的に進めることがあります。たとえば、無料トライアルで操作性を確かめ、Sandboxで画面や自動化フローを試作したうえで、限定範囲の実データで現場検証を行います。
なお、Salesforceは標準機能の完成度が高い一方で、自社の業務プロセスとの適合度（フィット感）は、実際に触れてみないと分からない部分があります。
PoC・プロトタイプ・モックアップの違い（Salesforce文脈での定義）
Salesforceの検証は、画面の確認から実運用に近い検証へと段階を進めます。段階ごとに目的が違うため、作るものも目的に応じて分けます。
- モックアップ：ページレイアウトエディタやLightning App Builderで入力画面やダッシュボードを試作し、関係者と完成イメージを共有する段階。
- プロトタイプ：モックアップに承認・自動通知などの簡易フローを加え、業務フロー全体の動きを試す段階。
- PoC：限定部門・プロセスでデータを使い、実運用に近い形で効果を検証する段階。
PoCでは、商談・顧客データ、またはそれに近いテストデータを使います。一定期間使ってみることで、効果と現場の使いやすさを確かめられます。
標準機能で作る試作品の多くは、ノーコード・ローコードの設定で対応できます。さらに、ApexやLWCが必要な部分だけは、Sandbox上で簡易的に実装します。
SalesForce導入・改修でPoCが重要な理由
Salesforce導入・改修でPoCが重視されるのは、標準機能適合と現場受容性の2つを確かめる必要があるからです。この2つは、導入後の定着に関わります。
- 標準機能適合検証：自社の典型的な商談や部門特有の承認フローを、標準設定で表現できるかを試す。
- 現場受容性検証：担当者が無理なく操作でき、業務に使えるかを確かめる。
フィット&ギャップ分析は、要件定義の段階で机上で行う検討です。加えて、実際に操作して初めて分かるギャップもあります。
操作を誤ると入力の手間が増えることがあります。また、UIが業務スタイルに合わないと、現場で定着しません。
経営層や情報システム部門だけで決めて、現場の意見を聞かずに導入すると、「以前のExcelの方が早かった」と反発されることがあります。こうした形骸化による失敗も少なくありません。
このため、選定やPoCの段階から現場のキーパーソンを巻き込み、操作後の意見を集めます。
既存のSalesforce環境の改修でも、変更後の画面やフローを現場に事前に触ってもらえば、使われない改修になるリスクを減らせます。
30日間無料トライアルを使った現場検証
Salesforceには契約前に標準機能を試せる30日間の無料トライアルがあり、導入前の現場検証に活用できます。期間が30日間に限られるため、確認すべき論点と期間の目安を事前に押さえておきます。
サンプルデータや自社データの一部を入れ、営業やカスタマーサービスの担当者に実際に操作してもらいます。この検証によって、操作性と業務との適合度を確かめられます。
無料トライアルの活用法と検証すべき論点
無料トライアルを生かすには、検証論点を事前に明確にしておく必要があります。業務を想定したシナリオを使って、各項目を確かめていきます。
- 画面と項目：商談・問い合わせを標準機能で表現できるか。
- 入力負担：日々の入力が現場にとって過度な負担にならないか。
- データ連携：Excel帳票や他システムとのCSVエクスポート・インポートがスムーズに行えるか。
- モバイル操作：モバイル端末での操作に問題がないか。
UIが自社の業務に合わないと、現場で使われなくなります。実際の担当者に事前に触ってもらい、操作性のずれを洗い出します。
複数のエディションや製品を比べる場合は、どの環境でも同じ業務シナリオを試し、機能と操作感の両方を比べます。
検証期間とスケジュール感
トライアルは30日間ですが、初期設定や検証後の判断にも日数がかかるため、全期間を現場検証に充てられるわけではありません。
- 初期設定とサンプルデータの投入に数日。
- 現場テストに1〜2週間。
- 意見の整理と、本契約か追加トライアルかの判断に数日。
複数のツールやエディションを比べると、1つの環境に使える期間は短くなります。そのため、検証論点を事前に絞っておく必要があります。
無料トライアルで確認できるのは標準機能で、Apex・LWCによるカスタマイズは、後述するSandboxで検証します。
結果をもとに、標準機能で対応する範囲とカスタマイズが必要な範囲を分けます。この区分を、その後の要件定義や見積もり依頼にそのまま使えます。
Sandbox環境を使ったプロトタイプ・モックアップ構築
契約後や既存ユーザーが検証する場合は、本番環境とは別のSandbox（検証用の複製環境）を使うのが基本です。本番データや運用に影響を与えずに試作できます。
4種類のSandboxとPoCでの使い分け
Sandboxは4種類あり、複製するデータ量や用途が異なります。試作から現場検証へ、段階に応じて選びます。
- Developer Sandbox：メタデータのみを複製し、容量は200MB。モックアップやプロトタイプの試作向け。
- Developer Pro Sandbox：容量が1GBまで拡張され、複数人での結合開発向け。
- Partial Copy Sandbox：テンプレートで選択した本番データのサンプルを含み、実データに近い現場検証向け。
- Full Copy Sandbox：本番環境を完全に複製し、本開発後の最終リハーサルなど向け。
リフレッシュの頻度と容量は、種類によって異なります。Developerは無料で利用でき、1日1回リフレッシュできます。Partial Copyは最大5GBのデータを含み、対象オブジェクトごとに最大1万レコードで、5日ごとにリフレッシュできます。
また、Full Copyは29日ごとにしかリフレッシュできず、大規模な回帰テストにも向きます。現場担当者に業務データに近い形で試してもらう場合は、Partial Copyが有力です。
Apex・LWCによるプロトタイピングの進め方
標準機能で実現できない独自ロジックや専用画面は、Sandbox上でApex・Lightning Web Componentsを使って試作します。
- 業務要件：試作したロジックで、要件を満たせるかを確かめる。
- 操作性：画面構成を直感的に使えるかどうか。
- 複数案：Sandbox上で複数案を試作し、現場担当者に比べてもらう。
試作の段階では、堅牢なエラーハンドリングや性能調整よりも、業務要件と操作性を確かめることを優先します。
承認フローは、1画面で完結させる案と、段階ごとに分ける案の2つを用意できます。現場で実際に触れて比べると、机上の議論より判断しやすくなります。
現場のフィードバックを画面やロジックに反映し、方向性を固めてから本開発に進めば、手戻りを減らせます。
複数案の試作には工数がかかります。一方で、本開発後に別方式へ大規模に作り直すリスクを考えると、費用対効果の高い投資といえます。
PoC失敗パターンと本開発への接続
PoC・プロトタイプ検証も、進め方を誤ると本開発に活かせないまま終わることがあります。そこで、対象を絞り、現場の意見と検証結果を次の工程へつなげます。
よくある失敗パターン
検証範囲や参加者、費用への期待に問題があったり、既存環境の把握が不十分だったりすると、失敗につながります。
- 対象の広げすぎ：全部門・全機能を扱うと、論点を検証しきれません。
- 現場不在：経営層や情報システム部門だけで進め、現場のキーパーソンを外すと、本開発後に「使いにくい」と反発され、定着が難しくなります。
- 期待の過大化：標準機能とカスタマイズの境界が曖昧なまま契約してしまう。
- 現行環境の未把握：環境の複雑さや設定・項目の依存関係を把握せず、試作を先行させる。
検証対象は「1部門・1プロセス」程度に絞ります。範囲を絞れば、限られたトライアル期間やSandboxの中でも論点を確かめられます。
月額数千円のプランで何でもできると期待すると、契約後のカスタム開発費用が想定を超え、当初の予算とずれることがあります。
既存環境の改修では、試作と並行して現行の設定やカスタム項目の利用状況を分析します。項目の廃止で別部署の集計が壊れるような依存関係もあります。
本開発（改修含む）へのスムーズな接続のポイント
口頭だけでは、記憶違いや伝聞による情報の劣化が起きやすいため、検証のフィードバックは構造化して記録し、本開発の要件に引き継ぎます。
- 標準機能：問題なく対応できた内容。
- 設定変更：軽微な変更で対応できた内容。
- カスタム開発：Apex・LWCが必要と分かった内容。
この分類は見積もり依頼の要件として文章に残し、検証で得た知見は要件定義書に反映します。
既存環境の改修では、変更後の画面やフローが現場にとって分かりやすいかを比べます。比較結果があれば、改修の意義を現場と経営層に説明しやすくなります。
PoCの段階からマニュアルや運用ルールの雛形を作り始める方法もあります。社内のアドミニストレーター候補にも、企画や実施に加わってもらいます。
まとめ
Salesforce導入・改修のPoCについて、手法の違い、現場検証、Sandboxでの試作、失敗を本開発へつなぐ方法を見てきました。
Salesforceは契約前の30日間無料トライアルと、契約後・既存契約者向けの4種類のSandbox環境を備えています。他のシステム導入にはない環境を段階的に使い、標準機能適合と現場受容性を本開発前に効率よく検証できます。
検証対象を絞り、現場のキーパーソンを巻き込みます。標準機能とカスタマイズの範囲を分け、結果を要件定義や見積もりにつなげます。
まず無料トライアルやSandboxで小さく試し、得られた知見をもとに本格的な要件定義と見積もり依頼に進みます。
▼全体ガイドの記事
・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を創業。