English
Tiếng Việt会社のSalesforceシステムに大きな変更を思いついたとする。新しい承認プロセスの追加、見積もりフローの見直し、あるいはマーケティングツールの新規統合。しかしそこでふと立ち止まる。顧客データが毎日動いていて、営業チームが案件を成約させるために使っているシステムに、もし直接適用してエラーが起きたらどうなるのか、と。
これは、長年Salesforceを運用してきたほとんどの中小企業が抱える、非常にリアルな不安だ。システムに蓄積されたデータが多く、依存する部署が多いほど、本番環境で直接テストするリスクは大きくなる。幸い、Salesforceにはこの状況のために特別に設計されたツールがすでに用意されている。それがSalesforce Sandboxだ。しかし多くのベトナム企業は、まだこれを正しく活用できていない。
この記事では、Salesforce Sandboxとは何か、企業の規模ごとにどの種類が適しているか、そして本番稼働中のシステムに変更を加える前に踏むべき安全なテストプロセスを詳しく解説する。
目次
基本概念
Salesforce Sandboxとは何か？
Salesforce Sandboxとは、企業が利用しているSalesforce組織（Salesforce Org）の独立したコピーのことだ。設定、自動化プロセス、画面構成のすべてを含み、Sandboxの種類によっては実データも含むが、稼働中のProduction環境からは完全に分離されている。Sandbox内で行った変更は、正式にProductionへデプロイされるまで、会社の実際のデータや運用には一切影響を与えない。
SandboxはIT部門や導入パートナー専用のラボのようなものだとイメージするとよい。テスト中に発生するあらゆる試行やエラーは、この空間の中に収まる。変更が十分に検証され、実際の業務シナリオで試され、担当者の承認を得て初めて、全社員が使う本番環境に反映される。
実際のリスク
なぜ本番システムで直接テストすべきでないのか？
多くの中小企業にとって、Salesforceは単なるソフトウェアではない。取引履歴のすべて、顧客の連絡先情報、日々動いている営業パイプラインが置かれている場所だ。会社が成長するにつれ、必須項目を一つ編集するような、一見小さく見える設定変更でも、連鎖的なエラーを引き起こすことがある。レポートの数値が狂う、自動化プロセスが止まる、データが上書きされて復元できなくなる、といった具合だ。
実際のところ、CRM運用における重大なトラブルの多くは、ソフトウェア自体の不具合ではなく、中間のテスト工程を省いて変更を急いで適用したことが原因だ。Production環境で直接エラーが起きると、最初に影響を受けるのは営業チームやカスタマーサポートチームだ。トラブル対応に時間を取られ、業務が中断し、場合によっては日々使っているシステムそのものへの信頼を失うことにもなる。
これこそがSandboxが存在する理由だ。フォーマットの誤ったデータ、大量負荷、ワークフローの競合といった、あらゆる最悪のシナリオを、安全な環境の中で試すことができる。社内の誰かが実際の影響を受ける前に。
種類
よく使われる4種類のSalesforce Sandbox
すべてのSandboxが同じというわけではない。Salesforceは主に、実データをコピーするかどうかと、最大ストレージ容量の違いによって、Sandboxを4種類に分けている。これは、企業がテスト目的ごとにどの種類を選ぶべきかに直接関わってくる。
Developer Sandbox
設定とメタデータのみをコピーし、実データは含まない。4種類の中で最も容量が小さいが、最も頻繁にリフレッシュできる。開発者がコードを素早く書いてテストしたり、実データを使わずに簡単な設定変更を試したりするのに適している。
Developer Pro Sandbox
Developer Sandboxと同じ仕組み（設定のみコピー、実データなし）だが、ストレージ容量が大幅に大きい。複雑なインテグレーションの構築や、数週間にわたる機能開発の準備など、より大きなサンプルデータセットでのテストが必要な技術チームに適している。
Partial Copy Sandbox
設定に加えて、企業が事前に定義したサンプルテンプレートに基づき、実データの一部もコピーする。上記2種類よりリフレッシュ周期は遅いが、その分テストデータが実態に近くなる。実際のシステム挙動を正確に確認できるだけの実データがありつつ、構築にかかる時間もそれほど長くならない、最もバランスの取れた選択肢であることが多い。
Full Sandbox
最も完全なコピーで、データ、添付ファイル、操作履歴のすべてがProductionからそのままコピーされる。4種類の中でリフレッシュ周期が最も長いため、大規模なGo-Live前の総合テスト（UAT）や、通常より大きな負荷を想定したパフォーマンステストなど、重要なテストの際にのみ使われることが多い。
ベトナムのほとんどの中小企業にとって、Developer SandboxとPartial Copy Sandboxで日常的なテストニーズの大部分をカバーできる。Full Sandboxが必要になるのは通常、大規模なアップグレードや複雑なシステム統合を控えていて、Production環境を最も正確に再現する必要がある場合に限られる。
プロセス
Go-Live前の安全なテストプロセス
Sandboxがあるだけでは十分ではない。より重要なのは、あらゆる変更が本番システムに触れる前に必ずテスト工程を通る、明確なプロセスがあることだ。標準的なプロセスは通常5つのステップからなる。変更の範囲に合ったSandboxを作成する、変更を行い初期チェックを行う、実際のユーザーに日常業務のシナリオでテストしてもらう、発生した問題を記録し修正する、そしてすべてのテストシナリオが基準を満たしてからProductionにデプロイする、という流れだ。
最も見落とされがちなステップは、IT部門だけでなく実際のユーザーにテストに参加してもらうことだ。技術的には正しい変更でも、営業担当者の実際の業務では使いづらいということがある。経験豊富な導入パートナーが、ランダムなテストではなく詳細なテストシナリオをきちんと構築するのはこのためだ。適切に設定されたシステムが営業チームをどう支援できるか、御社でも検討中であれば、始める前に全体像をつかむためにSalesforce内のEinstein AIについての記事も参考になる。
よくある質問
小規模企業にもSandboxは必要か？
会社が大きくなるまでSandboxを待つ必要はない。Salesforceに実際の顧客データが入り始め、日常的に依存するユーザーが複数人いる時点で、どんなに小さな設定変更であっても、まずSandboxを通すべきだ。特に新しい自動化プロセスの追加、外部システムとの統合、そしてSalesforceがリリースする大型アップグレードの前には欠かせない。
Salesforce専任のIT部門を持たない中小企業にとって、Sandboxプロセスの構築と維持は最も見落とされがちな部分だ。それは重要でないからではなく、最初から正しく設定できる経験者がいないからだ。標準化されたプロセスを持つ導入パートナーと一緒に取り組むことで、上記のリスクの大部分を回避できるのは、まさにこの場面だ。
問題は予算やツールが不足していることではない。Salesforceにはもともとライセンスに無料のSandboxが含まれている。問題は、ほとんどの中小企業が、変更のたびにそれを正しく使うプロセスを一度も構築したことがなく、より安全な選択肢があることに気づかないまま、いまだに実データで直接テストを続けているという点だ。
御社に合った正しいSandbox運用の構築サポートが必要ですか？
無料相談をご予約ください。Sonixチームが、稼働中のSalesforceシステムに変更を加える前の安全なテストプロセス構築をお手伝いします。
Sonix: Your success is our happiness.
コメントを残す