非エンジニア出身者向けSandboxの使い分け：Salesforce
Sandboxをどう使い分ければいいかがわからないアドミニストレーターの方へ
この記事は非エンジニア出身のSalesforceアドミニストレーターがSandboxを使い分けられるようにすることを目的とした記事です。Salesforceの改修にあたって、直接本番環境を触っているという方、よくわからないけれどもとりあえずDeveloper/Partial Sandbox環境を使っているという方、いらっしゃると思います。
そうせざるを得ない体制・リソースなど、コスト面での事情があることも重々承知していますが、トラブルが発生したときのコストはそれをはるかに上回ります。
今回はシステム開発の考え方から、どのようにSandboxを使っていくのかを解説していきます。
もちろん、本番を直接書き換えるな、ということではありません。Sandboxを適切に運用した場合の負荷と、直接本番を書き換えた場合のリスクを比較して、コストが最小となるようにと考えて行動できるようにしましょう、というのが目的です。
この記事を見てSandboxの運用が面倒だな、と思われる方はぜひSFDX+VS Codeでの開発環境を整えていきましょう。
ついでに環境間の設定の移行についても記載していますのでそちらはおまけで。
この記事の中身
- 失敗しないための開発とは
- それをSandboxに適用すると
- 環境と環境とで設定を移すには
- まとめ
失敗しないための開発とは
レイヤーを意識する
開発をするときには、レイヤーとも呼ぶべきものを意識することが重要です。価値・プロセス・機能のレイヤーからそれを考えてみましょう。まずはレイヤーを意識してモデル化した図をご覧ください。
ポイントは、検討手順は左から右へと流れていくこと、そして、問題が見つかった場合には同じレイヤーの一つ左に戻る必要があることです。
極端な場合、実証段階で戻らなければならなくなった場合には価値分析まで立ち戻る必要が生じます。
価値
まず、私たちが最優先で考えるべきことは「提供しなければならないものは価値である」ことです。ここを忘れてしまうと、相手が希望するものを実現したはずなのになぜか悪い評価を受けてしまう、なんてことになります。相手自身、欲しい価値を言語化できているとは限らず、機能でしか相手に要望を伝えることができないかもしれないからです。
プロセス
次に考えるべきことはプロセスです。価値を提供するにはどんなプロセスを踏む必要があるのかを考えます。このプロセスには、定型のものはあれど、最適なものというのは利用者の状況によって異なります。必ず、利用者のリテラシー等を考慮したうえで検討することを心がけます。
機能
プロセスはどのような機能の組み合わせによって成り立っているかを検討します。どんな画面で入力するか、利用するオブジェクトは何か、そのときにどんな自動化処理が行われていればよいかを考えてみるとよいでしょう。
本番環境は実証されるまで変えないのが基本
本番環境を直接変えてしまうと、先ほどのモデルを無視して開発することとなります。結果起こることは、
- 単体の機能の不都合
- プロセスとしての不整合
- 価値認識のずれ
と複合的なものとなります。悲しいもので、いくら成功が続いていたとしても、1回の失敗でユーザの信頼感は大きく下がります。理不尽だ！という心の叫びは通じません。
ということで、リリースの失敗を避けるための方法を考えましょう。
機能開発時点でその開発を検証し、次にプロセスの検証、最後に価値を提供できているかを検証することでそのリスクを低減しようと考えます（実際には、機能を開発しながらプロセスや価値提供が実現できるかを考えたりと、先のことは常に意識します）。これをSandboxを使って実現できないでしょうか？
これをSandboxに適用すると
その前にSandboxってどんなものがあるの？
SandboxにはDeveloper、Developer Pro、Partial Copy、そしてFullがあります。機能の詳細はヘルプを確認してください。
簡単にまとめると以下のようになります。
- Developer：ストレージも小さいし、データは持ってこれないけど更新は1日間隔
- Developer Pro：Developerとほぼ同じでストレージがそこそこ
- Partial Copy：ストレージはさらに大きく、本番からデータを持ってこれる。更新は5日間隔
- Full：ストレージは本番組織と同じ。すべての本番データを持ってこれる。更新は29日間隔
必要なのは機能開発・単体テストの環境、結合テスト環境、実証環境
一方、機能開発において必要な環境はなんでしょうか。一つ一つの機能を開発・検証する単体テスト環境が必要です。機能が問題ないことが確認できれば、それらをつなげて一つのプロセスとして動かすことができるか検証する結合テスト環境が必要となります。それもできれば、実際にユーザに試してもらって望んでいた価値が提供されているかを確認する実証（ユーザ受け入れテスト）環境が必要となります。
開発手順とSandbox環境とをマッピングする
これらをSandboxにマッピングすると以下のようになります。実際には組織の大きさによって使い分けたほうが効率的であったりするのですが、それをいきなり考えてというのも厳しいので、まずはこんなもんか程度に認識してください。
- 単体テスト：Developer/Developer Pro
- 結合テスト：Partial Copy/Full
- ユーザ受け入れテスト：Partial Copy/Full
（Fullを持っていない環境が多いかなと思っての構造なので、気になる方もお目こぼしを）
この考え方に基づくと、以下のような流れで開発を進めることになります
- Developer環境で機能を開発する
- Developer環境で機能を実行して問題がないことを確認する
- Developer環境の機能をPartial Copy/Full環境に適用する
- Partial Copy/Full環境でプロセスを実行して問題がないことを確認する
- Partial Copy/Full環境でユーザがプロセスを実行して価値が提供されているかを確認する
- Partial Copy/Full環境の設定を本番環境に適用する
となると、3、6の別環境に設定するのはどうすればいいのか、という疑問が出てくると思います。次にこの方法についてみてみましょう。
特定の環境の設定を別の環境に適用するには
こちらには3通りの方法があります。
- 設定画面から全く同様の設定を行い、環境を合わせる
- 変更セットを用いて設定を別の環境にリリースする
- VS Code + SFDXを使って（Metadata APIを使って）設定を別の環境にリリースする
どれがよいのか、というと基本的には変更セットかVS Code + SFDXが王道です。とはいえ、直接環境を合わせるというのは、諸々の事情からしょうがなくやることがありますので選択肢には残したいところです（しかし、あくまでそういった建付けです）。
基本的には同じものを2回行うというのは、作業時間もかかるためリリースに時間がかかってしまうこともありますし、その中での漏れ・ミスも発生するため推奨できないというのがその理由です。
もしこれを見ている方は、ぜひVS Code + SFDXで環境移行をできるようにすることを検討してください。最初は非エンジニアの方には難しいかもしれませんが、慣れるともう手放せなくなります。
終わりに
今回はSandboxの種類について、それぞれの役割の観点から書きました。テストの世界は非常に奥深いので、それはまた別の記事にしたいとは思いますが、レイヤーについてまずは意識できるようにしていただけばこの記事としてはGoodです。
次回はDeveloper Sandで機能を開発したぜ！けど、本番データを色々もってこないとテストもできないぜ！という方向けのSFDMUを使ったデータ移行についてお話をしたいと思います。
Discussion