SalesForce導入支援・改修のPoC・プロトタイプ・モックアップ開発について

SalesForce（Salesforce）は、Salesforce.com社が提供するクラウド型のCRM（顧客関係管理）・SFA（営業支援）プラットフォームであり、営業支援に特化した「Sales Cloud」、カスタマーサービスに特化した「Service Cloud」、B2Bマーケティングオートメーションの「Marketing Cloud Account Engagement」（旧称Pardot）といった複数の製品群で構成されています。本記事で扱う「SalesForce導入支援・改修」は、CRM・SFAという機能そのものの一般的な解説ではなく、Salesforceという特定クラウドプラットフォームを対象にした導入プロジェクト、すなわち標準機能のセットアップからApex（Salesforce独自のプログラミング言語）やLightning Web Components（LWC）によるカスタマイズ開発、既存Salesforce環境の改修・再構築までを含む実装プロジェクトに焦点を当てます。本格的な契約・開発に着手する前に、「本当に自社の業務に適合するのか」「現場担当者は実際に使いこなせるのか」を検証したいというニーズは非常に強く、SalesForceの導入・改修担当者からは「PoCやプロトタイプはどのような形で行うのか」「無料トライアルとSandbox環境はどう使い分ければよいのか」といった疑問がよく挙がります。

本記事では、SalesForce導入支援・改修におけるPoC・プロトタイプ・モックアップ開発に焦点を当て、Salesforce文脈でのPoC・プロトタイプ・モックアップの位置づけ、30日間無料トライアルを使った現場検証の進め方、Sandbox環境を使ったプロトタイプ・モックアップ構築、そしてよくある失敗パターンと本開発への接続のポイントまでを体系的に解説します。SalesForceのようなクラウド型SaaSプラットフォームは、フルスクラッチ開発とは異なり、契約前・契約直後の段階で実際の画面や機能に触れながら検証できる環境が整っている点が大きな特徴です。この特徴を活かした検証プロセスを設計できるかどうかが、後工程での「こんなはずではなかった」という手戻りを防ぎ、プロジェクト全体を成功に導く鍵になります。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・SalesForce導入支援・改修の完全ガイド

SalesForceにおけるPoC・プロトタイプ・モックアップ開発の位置づけ

PoC（概念実証）、プロトタイプ、モックアップは、いずれも本開発前に検証を行う手法ですが、目的と粒度が異なります。モックアップは画面イメージや操作フローを可視化した「見た目の確認」に近く、プロトタイプはモックアップよりも一歩進んで実際に一部の機能が動作する試作品を指します。PoCはさらに踏み込んで、実際の業務データや業務プロセスを使い「この方式で本当に自社の課題を解決できるか」を検証する工程です。SalesForceの文脈では、これら3つの検証手法が明確に切り分けられて語られることは少なく、実務上は「無料トライアルでの操作性確認」「Sandbox環境での画面・自動化フローの試作」「限定スコープでの実データを使った現場検証」という一連のプロセスとして、モックアップ・プロトタイプ・PoCに相当する検証が段階的に行われるのが実態です。SalesForce導入・改修プロジェクトにおいてこの検証工程が重要視される理由は、標準機能の完成度が非常に高い一方、自社の業務プロセスとの適合度（フィット感）は実際に触ってみないと分からない部分が多いためです。パンフレットやデモ画面だけでは判断できない「現場の実務に本当に馴染むか」という問いに答えるのが、PoC・プロトタイプ・モックアップ開発の役割です。

SalesForceプロジェクトにおけるモックアップは、標準のページレイアウトエディタやLightning App Builderを使って、実際の入力画面やダッシュボードのレイアウトを試作し、関係者間で「こういう画面になる」というイメージを共有する工程です。プロトタイプは、モックアップに加えて簡易的な自動化フロー（承認プロセスや自動通知等）を組み込み、一連の業務フローが実際にどう動くかを試作する工程を指します。そしてPoCは、限定した部門・プロセスを対象に、実際の商談データや顧客データ（あるいはそれに近いテストデータ）を投入し、一定期間の実運用に近い形で使ってもらい、本当に効果があるか、現場が使いこなせるかを検証する工程です。標準機能の範囲であればモックアップ・プロトタイプの多くはノーコード・ローコードの設定だけで実現でき、Apex・LWCによるカスタム開発が必要な部分についてのみ、簡易的な実装をSandbox環境上で試作するという分業が、効率的な検証の進め方になります。

SalesForce導入・改修でPoCが重要視される理由は大きく2つあります。1つ目は「標準機能適合検証」です。フィット&ギャップ分析は要件定義段階の机上検討ですが、実際にシステムを操作してみて初めて見えてくるギャップも少なくありません。例えば、自社の典型的な商談パターンや部門特有の承認フローが、標準機能の設定だけで無理なく表現できるかは、実際に触ってみないと判断が難しい部分です。2つ目は「現場受容性検証」です。SalesForceは高機能である分、操作を誤ると入力の手間が増えてしまうこともあり、UIが自社の業務スタイルに合わないと現場で定着しません。経営層や情報システム部門だけで導入を決定し、現場の意見を聞かずに進めた結果、「以前のExcelの方が早かった」と反発を受け、システムが形骸化してしまう失敗事例は少なくないとされています。選定・PoCの段階から必ず現場のキーパーソンを巻き込み、実際に操作してもらいながらフィードバックを得ることが、本開発後の定着を左右する重要なプロセスになります。既存Salesforce環境の改修プロジェクトにおいても、改修後の画面・フローを現場に事前に触ってもらうことで、「使われない改修」になるリスクを大きく減らすことができます。

30日間無料トライアルを使った現場検証

SalesForceには、契約前に全機能をひと通り試せる30日間の無料トライアルが用意されており、これが本格導入前の最も手軽な現場検証手法として広く活用されています。無料トライアル環境にサンプルデータや自社の一部データを投入し、実際の営業担当者・カスタマーサービス担当者に操作してもらうことで、机上のデモでは分からない操作性・自社業務との適合度を確認できます。以下では、無料トライアルを使った検証で押さえるべき論点と、検証にかけるべき期間の目安を解説します。

無料トライアルを最大限活用するには、あらかじめ検証すべき論点を明確にしておくことが重要です。具体的には、自社の典型的な商談パターンや問い合わせパターンを標準機能の項目・画面レイアウトで無理なく表現できるか、日々の入力作業が現場にとって過度な負担にならないか、既存のExcel帳票や他システムとのデータのやり取り（CSVエクスポート・インポート等）がスムーズに行えるか、モバイル端末からの操作性に問題がないか、といった点を確認します。UIが自社に合わないと現場で使われなくなるため、実際の担当者に触ってもらい、操作性のギャップを事前に洗い出しておくことが特に重要だとされています。また、複数のエディション・製品（Sales CloudとService Cloudの組み合わせ等）を比較検討している場合は、それぞれのトライアル環境で同じ業務シナリオを試し、機能面だけでなく操作感の違いも含めて比較することが望まれます。

無料トライアルの期間は30日間ですが、実務上はこの期間の全てを検証に充てられるわけではありません。初期設定・サンプルデータ投入に数日、実際の現場テストに1〜2週間、フィードバックの整理と次のアクション（本契約に進むか、追加のトライアルを行うか）の判断に数日、という配分が現実的です。複数のツール・エディションを比較検討する場合は、1つのトライアルにかけられる期間がさらに短くなるため、検証したい論点を事前に絞り込んでおくことが効率的な検証の鍵になります。また、無料トライアルはあくまで標準機能の範囲での検証であり、Apex・LWCによるカスタマイズ部分の検証は別途Sandbox環境（後述）で行う必要がある点にも注意が必要です。無料トライアルでの検証結果をもとに、標準機能で対応できる範囲とカスタマイズが必要な範囲を切り分けられれば、その後の要件定義・見積もり依頼がスムーズに進みます。

Sandbox環境を使ったプロトタイプ・モックアップ構築

契約後、あるいは既にSalesforceを契約している既存ユーザーがPoC・プロトタイプ開発を行う場合は、本番環境ではなくSandbox（検証用の複製環境）を使うのが基本です。Sandboxを使うことで、本番データや本番運用に影響を与えることなく、自由に試作・検証を繰り返すことができます。以下では、Sandboxの種類とPoCでの使い分け、そしてApex・LWCによるプロトタイピングの進め方を解説します。

Salesforceには用途に応じて4種類のSandboxが用意されています。個人開発者向けの「Developer Sandbox」はメタデータのみを複製し（本番データは複製されない）、ストレージ容量は200MBと小さいものの無料で利用でき、1日1回リフレッシュ可能なため、モックアップやプロトタイプの初期試作に向いています。複数人での開発向けの「Developer Pro Sandbox」はストレージ容量が1GBまで拡張され、チームでの結合開発に適しています。「Partial Copy Sandbox」は、メタデータに加えてテンプレートで選択した本番データのサンプル（データ最大5GB、対象オブジェクトごと最大1万レコード）を含み、5日ごとにリフレッシュ可能で、実データに近い環境での現場検証・ユーザー受入テストに向いています。PoCとして現場担当者に実際の業務データに近い形で試してもらいたい場合は、このPartial Copy Sandboxが有力な選択肢になります。「Full Copy Sandbox」は本番環境の完全な複製で、29日ごとにしかリフレッシュできないため、PoCの初期段階よりも、本開発後の最終リハーサルや大規模な回帰テストに向いた環境です。PoC・プロトタイプの段階では、まずDeveloper（Pro）Sandboxで試作し、現場を交えた検証の段階でPartial Copy Sandboxへ移行する、という段階的な使い分けが効率的です。

標準機能だけでは実現できない独自ロジックや専用画面が必要な場合は、Sandbox環境上でApex・Lightning Web Componentsを使った簡易的な実装を試作します。この段階では、本開発のような堅牢なエラーハンドリングやパフォーマンスチューニングまでは求めず、「このロジックで業務要件を満たせるか」「この画面構成で現場が直感的に操作できるか」を確認することに主眼を置きます。プロトタイプ段階で現場からのフィードバックを反映し、画面構成やロジックの方向性を固めてから本開発に入ることで、本開発工程での手戻りを大幅に減らすことができます。また、複数のカスタマイズ案がある場合は、Sandbox上に複数のパターンを用意して現場担当者に比較してもらうことも可能です。例えば、承認フローを1画面で完結させる案と、ステップごとに分割する案の両方をプロトタイプとして用意し、実際に触った現場担当者に「どちらが直感的か」を判断してもらうといった進め方は、机上の議論だけで決めるよりも精度の高い意思決定につながります。この試作・比較のプロセスに一定の工数はかかりますが、本開発後に「やはり別の方式の方が良かった」と大規模な作り直しが発生するリスクを考えれば、費用対効果の高い投資だと言えます。

PoC失敗パターンと本開発への接続

PoC・プロトタイプ検証を実施しても、進め方を誤ると本開発に活かせないまま終わってしまうことがあります。ここではよくある失敗パターンと、本開発へのスムーズな接続のポイントを解説します。

SalesForceのPoC・プロトタイプ検証でよく見られる失敗パターンの1つ目が、検証対象を広げすぎることです。「どうせなら全部門・全機能を一度に検証しよう」と対象を広げると、限られたトライアル期間・Sandbox環境の中で検証しきれず、結局どの論点も中途半端なまま契約・本開発に進んでしまいます。検証対象は「1部門・1プロセス」程度に絞り込むのが鉄則です。2つ目が、経営層や情報システム部門だけで検証を進め、現場のキーパーソンを巻き込まないケースです。実際に日々システムを操作する現場の声を反映しないまま導入を決定すると、本開発後に「使いにくい」と現場から反発を受け、定着しない事態に陥りやすくなります。3つ目が、「月額数千円のプランで何でも実現できる」といった過大な期待を持ったまま検証に入り、標準機能でカバーできる範囲とカスタマイズが必要な範囲の切り分けが曖昧なまま契約に進んでしまうケースです。この場合、契約後にカスタム開発費用が想定以上に膨らみ、当初の予算感と乖離するトラブルにつながります。4つ目は、既存Salesforce環境の改修プロジェクトに特有のパターンで、現行環境の複雑さを十分に把握しないままプロトタイプだけを先行させてしまうことです。改修前のPoCでは、新しい画面・フローの試作と並行して、現行環境のどの設定・カスタム項目が実際に使われているかの現状分析も並走させないと、いざ本開発に入った段階で「この項目を廃止したら別部署の集計が壊れた」といった想定外の依存関係が発覚し、手戻りの原因になります。

PoC・プロトタイプの成果を本開発に確実につなげるためには、検証で得られたフィードバックを構造化して記録しておくことが重要です。口頭でのフィードバックだけに頼ると、担当者の記憶違いや伝聞による情報の劣化が生じやすく、後になって「そんな要望は聞いていない」といった認識齟齬の原因になります。「標準機能で問題なく対応できた部分」「軽微な設定変更で対応できた部分」「Apex・LWCによるカスタム開発が必要だと判明した部分」の3つに分類し、それぞれ本開発の見積もり依頼時の要件として明文化しておくことで、検証で得た知見が要件定義書に正しく反映されます。また、既存Salesforce環境の改修プロジェクトの場合は、PoC・プロトタイプの段階で現行環境との比較（改修後の画面・フローの方が現場にとって分かりやすいか）を明確に行っておくことで、改修の意義を現場・経営層双方に説明しやすくなります。運用開始後を見据えて、PoCの段階からマニュアル・運用ルールの雛形を作り始めておくことや、社内のアドミニストレーター候補となる担当者にPoCの企画・実施に関わってもらうことも、本開発から本番稼働後の定着までを見据えた効果的な進め方です。

まとめ

本記事では、SalesForce導入支援・改修におけるPoC・プロトタイプ・モックアップ開発について、Salesforce文脈での位置づけ、30日間無料トライアルを使った現場検証、Sandbox環境を使ったプロトタイプ・モックアップ構築、そしてよくある失敗パターンと本開発への接続のポイントを解説しました。改めて強調しておきたいのは、本記事が扱っているのはCRM・SFAという機能そのものの解説ではなく、Salesforceという特定クラウドプラットフォームを対象にした導入・カスタマイズ・改修プロジェクトの検証プロセスであるという点です。SalesForceは契約前の30日間無料トライアルと、契約後・既存契約者向けの4種類のSandbox環境という、他のシステム導入にはない充実した検証環境を備えており、これらを段階的に使い分けることで、本開発前に標準機能適合検証と現場受容性検証の両方を効率的に行うことができます。検証対象を絞り込み、現場のキーパーソンを巻き込み、標準機能とカスタマイズの切り分けを明確にすることが、PoC・プロトタイプを本開発の成功につなげる鍵です。導入・改修を検討される際は、まず無料トライアルやSandbox環境を活用した小さな検証から始め、得られた知見をもとに本格的な要件定義・見積もり依頼に進むことをお勧めします。

▼全体ガイドの記事
・SalesForce導入支援・改修の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。