Salesforce標準機能『変更セット』とは？～仕組みと課題について～
こんにちは、クロステックサービス事業部所属のCです。
今回の記事では、Salesforceの標準機能『変更セット』を主軸とし、開発環境、本番環境の分離に関する考え方、および『変更セット』を活用していく中で生じやすい課題について取り上げます。
■あわせて読まれている資料：
対応事例やソフトウェアサービス一覧を掲載！
⇒ソフトウェアテクノロジーサービス
目次[非表示]
Salesforceについて
Salesforceの標準機能である『変更セット』の本題に入る前に、まずはSalesforceそのものの概要からご紹介いたします。
Salesforceとは、Salesforce社が提供しているクラウド型の業務アプリケーションプラットフォームです。
顧客情報を中心に、カスタマーサポート、マーケティングなど、企業の顧客接点に関わる業務を横断的に管理・共有するために利用されます。
営業に関わる業務を例とすると、営業活動に必要な顧客情報や案件情報、商談の進捗、営業活動履歴、売上予測などをSalesforce上で管理・共有し、部門やチーム間での情報分断を防ぐとともに、業務の効率化を目的とした活用が可能になります。
このSalesforceの特長のひとつに、利用するユーザーやその業務内容に応じて柔軟なカスタマイズが可能な点が挙げられます。
利用者の業務内容に合わせたカスタマイズについて、代表的なものを挙げると、以下の図のように画面内のレイアウト設定をGUI操作で変更する機能があります。
図1-1：画面設定サンプル_変更前と設定画面
図1-2：画面設定サンプル_設定変更後
上記の例以外にも様々な変更・改善を継続的に行い、利用者とその業務にとって便利な形、かつ利用者のニーズの変化に合わせた最適化も行うように開発・運用が行われるケースが一般的です。
この記事では、そんなSalesforceの開発・運用にあたって土台となる考え方、そして運用に欠かせない機能『変更セット』について説明していきます。
Salesforceにおける環境分離の考え方
「業務内容に応じて各種設定の変更・改善を継続的に行う」という特徴から、Salesforceの開発・運用に携わる場合、その設定や機能の変更をどのように管理および反映していくかが重要になります。
特にSalesforceの本番環境は、ユーザーの日常業務そのものを支える基盤です。そのため、本番環境への設定変更は、例え小さな変更であっても、常に不具合や業務停止に繋がる重大なリスクを伴います。
また、設定や機能の変更履歴が不明確になることも、管理統制上の問題に繋がります。
Salesforceでは、そのリスクや問題を回避するために
「Sandbox (開発・検証用環境)」
「本番環境」
と、明確に環境を分離して運用する設計が採られています。
■開発のための環境と本番環境の分離
Sandboxとも呼ばれる開発および検証のための環境は、基本的には本番環境を複製し作成された環境です。
このSandboxを使うことによって、本番環境にある各種設定やオブジェクトに直接アクセスすることなく、本番環境上で変更を行った場合と同条件での開発および検証を行うことが可能になります。
図2：Sandboxと本番環境のイメージ
Salesforceにおいて開発を行う場合、こうした環境の分離を前提とすることが一般的です。
そして、本番環境と同条件であるSandbox上で、以下の作業を行います。
新規作成/変更を行う対象の事前確認
新規作成/変更を行う対象による業務影響の洗い出し
新規作成/変更の実施、および実施後の動作確認
これらの実施後、十分に品質が担保できることを確認してから本番環境へと移行していくことになります。
このように、開発・検証を行う環境と本番環境を分離する仕組みによって、本番環境の設定変更に伴う業務影響を抑え、高い品質を保つ管理を実現します。
このような仕組みの環境で開発・運用を行っていくための機能の代表的なものとして、Salesforce標準機能『変更セット』について後述します。
運用に欠かせない標準機能『変更セット』
Salesforceの標準機能として備わっている『変更セット』とは、Sandbox内で行った変更の内容を、そのまま本番環境へ移行する仕組みです。
大きな特徴のひとつとして、複雑なコマンドを記述する必要がありません。かつ、GUIによる直感的な操作で環境間の移行ができるため、誰にでも比較的容易に利用できる点が挙げられます。
図3-1：『変更セット』作成画面
また、標準機能のため、事前インストールなく利用できるという点もあり、長年に渡り多くの開発者達にはこの『変更セット』が主要な移行手段として使われてきました。
■『変更セット』による移行の仕組み
Sandboxから別環境へ移行するプロセスを簡単に説明すると、Sandboxでの変更内容を『変更セット』というパッケージ単位にまとめ、その単位ごとに移行の実施を行うものです。
以下、『変更セット』を利用した本番環境への移行のイメージを簡単に図示します。
図3-2：変更前のSandboxと本番環境
図3-3：Sandbox内で変更を実施
図3-4：本番環境へ移行したい分を『変更セット』としてまとめ、移行を実施
図3-5：本番環境への移行完了
更に、『変更セット』を活用した例として、
「新規作成の項目B」「変更された項目C-α」を包括する変更セット2
というように別々の単位を作成し、変更セット1は翌日に、変更セット2は翌週に本番環境へ移行する、という管理も可能になります。
図3-6：複数の変更セットを作成した活用例
また、先述した通り、『変更セット』の作成はGUI操作であり、移行対象の項目をクリックで選択することで作成が可能です。
図3-7：変更セット内へ移行対象の追加開始
図3-8：変更セット内へ追加可能な項目一覧の表示
図3-9：対象項目を選択し、変更セット内への追加
図3-10：変更セット内へ選択した対象の追加が完了
こうして作成した変更セットを、移行先の環境を選択して送信し、送信先の環境で適用することで移行完了となります。
■『変更セット』を使用する利点
本番環境への移行に『変更セット』を用いることで、以下のような利点が生まれ、不具合のリスクを回避することにもつながります。
設定漏れや手順差異の防止
変更内容とその履歴を『変更セット』単位で管理
また、変更内容が『変更セット』としてパッケージングされるため、業務統制の観点からも「変更内容と履歴、および本番環境への移行タイミング」が把握・管理しやすくなる、という利点も挙げられます。
こうした、上記に挙げたようにリスクや統制上の問題の回避も適うといった点からも、『変更セット』はSalesforceの運用において基本的な機能のひとつとして多くの開発者達に知られています。
開発規模の拡大に伴う『変更セット』の課題
標準機能であるから利用しやすく、GUI操作で比較的容易に扱えるといった特徴もあり親しみやすい『変更セット』ですが、その一方、多くの現場で課題が指摘されています。
開発の規模が拡大するにつれ、「作業負荷の高さ」「ヒューマンエラーの多発」「内容や履歴の透明性不足」といった問題が顕在化し、『変更セット』による運用は限界が見えるようになっていきました。
その主な要因として、以下のような点が挙げられます。
①最近変更された対象を把握できない
『変更セット』には、直近に更新されたオブジェクト等を表示する、といった機能は備わっていません。
作業者側でExcel等による一覧表を別途作成し、変更内容等を手動で管理する必要がありました。
以下の『変更セット』の設定画面では、『変更セット』に含む対象の名称や種別は表示されますが、最終更新日などの情報は表示されません。
図4-1：変更セットの詳細画面
『変更セット』への追加対象項目の一覧についても、項目の名称のみとなっており、最終更新日でソートを行うといった操作はできません。
図4-2：選択可能な項目一覧画面
②差分確認ができない
現在の環境と移行先の環境とを比較し、変更対象の差分を確認する、ということが出来ません。
既に別の開発者が移行済みである場合などを把握出来ず、意図せぬ上書きや競合が発生するなど、品質面のリスクが高くなります。
③操作に要するクリック数が多い
操作がGUIであり、対象をクリックで選択するという仕様上、移行対象が増えるほどに必要なクリック数も膨大になります。
細かな変更によって対象が数百件に及ぶならば、数百の対象選択、および対象項目一覧のページ送り等の操作を含めて、非常に多くのクリックが発生します。
④自動化が行えない
『変更セット』は複製こそ可能であるものの、基本的には移行の都度作り直す必要があります。
例えば、前回使った変更セットをコピーし、そこから不要で削除するものや追加するものを選択するといった操作が発生します。その結果として操作の増加や、意図しない対象の選択など、品質リスクの要因となりました。
このように、利用しやすく扱いやすい一方、開発規模の拡大に伴い運用上の負担やリスクが顕在化しやすいものでした。
同時にこれらの課題は、『変更セット』そのものの欠陥というよりは、Salesforce上の開発規模に合わせた適切な運用設計を行っていく必要があることを示しています。
『変更セット』の課題から考える、開発規模に合わせた運用設計
『変更セット』は、開発環境と本番環境の分離、本番環境への開発物の安全な移行を実現するための標準的な仕組みとして、多くの開発者達に活用されてきました。
その一方で、開発規模が拡大するにつれて様々な課題が顕在化することも、同様に広く認識されるようになっています。
しかし、『変更セット』が抱える課題の多くは、以下に挙げるような、Salesforce活用の活発化の結果として生じたものでもあります。
- 開発規模の拡大に合わせて開発者の参画も増えたことによる、変更管理の複雑化
つまり、『変更セット』による運用に限界を感じるようになった状況は、今後の規模に合わせた運用設計を行っていくタイミングとも言えます。
規模の大きな開発になると課題が顕在化しやすい『変更セット』ですが、「標準機能ゆえの利用しやすさ」、「少数の対象を移行する場合であれば、容易さも含めて即時性が高い」といった利点は変わりません。
そのため、『変更セット』を利用するケースを適切に見極めた上での活用も含め、開発現場に合わせた運用設計を検討していくことが重要です。
■運用設計における選択肢 - 公式の拡張機能『Salesforce DevOps Center』
Salesforceでの開発規模が拡大し、運用設計の再検討が必要になった際の選択肢のひとつとして、『Salesforce DevOps Center』という拡張機能が挙げられます。
『Salesforce DevOps Center』とは、Salesforce公式から提供されている変更/リリース管理ツールです。
図5：『Salesforce DevOps Center』の画面
今回の記事では詳細に触れませんが、Sandboxと本番環境間の移行に『変更セット』を利用した場合に対し、『Salesforce DevOps Center』は以下のような特徴を持っています。
①『変更セット』と同様にGUI操作で直感的に扱える
操作にコマンド記述の知識が不必要である点は『変更セット』と同様です。
②変更履歴の追跡、変更の競合の早期検出が更に容易になる『変更セット』での「直近の変更対象が分からない」「差分が確認できない」課題を解消できます。
③GitHubと連携したバージョン管理によって、チーム内での変更や移行の状況共有が簡便に行える
多数の開発者による並行作業と複雑な管理を要する場合でも運用しやすくなります。
Salesforce公式より提供されているツールである安心感に加え、『変更セット』による運用において課題となっていた点を多く解消し、効率的かつ高品質な変更/リリース管理の実現に繋がるツールだと言えるでしょう。
ただし、『Salesforce DevOps Center』を導入するとなると、標準機能であるためほとんど準備なく即時に扱える『変更セット』に対し、GitHubとの連携や環境の同期といった事前準備が必要になるほか、GitHubを無償プランと有償プランのどちらで利用するか等の検討が必要になってきます。
また、『変更セット』を利用する場合と比べて習熟難易度が高くなるため、作業者の教育にかかるコストも上がるとされています。
そのため、それぞれのメリットやデメリット、プロジェクトの規模や環境間移行の頻度などの実態を理解し、『変更セット』による運用との使い分けをしていく必要があると考えられます。
まとめ
今回は、Salesforceの開発・運用業務に携わる多くの開発者が一度は触れただろう標準機能『変更セット』、その仕組みと課題についてご紹介いたしました。
後半で述べたように、開発規模が拡大すると運用に限界が現れやすい機能ですが、標準機能のため事前準備なしでも扱えることや容易に対応できる即時性など、明確な利点も存在しています。
そのメリット・デメリットを理解しながら活用していくための第一歩として、今回の記事が役に立てば幸いです。
■サービス一覧はこちら↓
引用元
Salesforce公式ヘルプページ
