Salesforceの運用ルールの決め方：変更を誰がどう決めるか

運用ルール（ガバナンス）で決めること

Trailhead では、Salesforce のガバナンスを、人・プロセス・ツールを組み合わせて、組織の今と先の成功を支える枠組みと説明しています。決まりで動きを遅くするためのものではなく、ルールがはっきりしているほど、変更を迷わず速く進められるという考え方です。[1]

ガバナンスで答えを用意しておく問いとして、次のようなものが挙げられています。[1]

• どの機能を作るか、どれから作るか、それはなぜかを誰が決めるか[1]
• 管理者や開発者が守る基準は何か[1]
• 今ある機能を壊さないよう、変更をどう設計してリリースするか[1]

こうしたルールを作り、守り、必要に応じて変えていく集まりを、Trailhead では Center of Excellence（CoE）と呼んでいます。CoE の仕事は、方向性（Vision）、基準（Standards）、利用者の支援（Enablement）の 3 つに分かれます。[2]

使い始めたときから決めておくのが望ましいとされますが、すでに運用中の組織でも、遅れてでも取り入れるほうがよいとされています。[1]

変更を決める役割

• 役割 1責任者経営層に近い立場の人が担い、方向性を示して予算を取りまとめます。[4]
• 役割 2とりまとめ役CoE の会議を回し、活動を整え、関係する部署との窓口になります。[4]
• 役割 3アーキテクト技術の基準が守られているかを確かめ、たまった要望からロードマップを作ります。社内でいちばん経験のある管理者が担うこともあります。[4]
• 役割 4リリース担当本番へ出す流れを見て、同時に進む作業どうしがぶつからないようにします。[4]

変更の受付と優先度

CoE がない状態では、要望を先に来た順に片付け、問題は放っておけなくなってから直す、受け身の進め方になりやすいと説明されています。[2]

そこで、要望を出すときに何が要るかを決め、優先順位を公平に決める手順を作ります。受付の窓口を設けて見守り、届いた要望を作業できる項目に直してバックログに積むのが、受付（Demand Intake）の役目です。[3][4]

優先度は、声の大きさではなく、投資に見合う効果や戦略上の価値で付けます。保守や細かな手直しの時間もリリースの予定に組み込み、緊急時には予定を動かせる余地を残しておきます。[2]

設計の審査役（Design Authority）は、要望ごとの作りを見て、データ構造の重複や、自動化と連携の思わぬ影響がないかを確かめます。フローと Apex のどちらを使うかといった指針を作るのも、この役目です。[3]

リリースの流れと Sandbox

ヘルプでは、本番組織で直接変更を作ることは、業務や利用者に大きなリスクがあるため、通常は勧めないとしています。項目の型を変えるような小さな変更でも、思わぬ影響が広がることがあるためです。[5]

変更は Sandbox で作って試します。Sandbox は別の環境に作る組織の写しで、本番のデータやアプリケーションを損なわずに、開発、テスト、研修に使えます。試し終えた変更は、変更セットなどで本番へ送ります。[6][7]

一方で、メールテンプレートの作成、ユーザーの作成や編集、権限セットやプロファイルの作成や編集のような管理の作業は、本番で直接行っても問題ないものとして挙げられています。本番で直接行ってよい変更を、ルールとして書き分けておくと迷いません。[5]

ヘルプが挙げるルールの例は次のとおりです。[5]

• 本番で開発できる人を絞り、「アプリケーションのカスタマイズ」の権限をシステム管理者に限る[5]
• プログラムでのリリースを実行できる権限を、少数の管理者に限る[5]
• Partial Copy や Full の Sandbox で、関係者が変更を試す機会（ユーザー受け入れテスト）を設ける[5]
• ピークの時間帯や、休日・大事な行事の直前を避け、決まった曜日に定期的にリリースする[5]

Trailhead では、大きな変更は月 1 回、小さな手直しは週 1 回といった定期の予定を例に挙げています。予定が分かると、利用者も変更に備えられます。ただし、緊急の修正は別に扱えるよう、予定に縛られすぎないこととされています。Sandbox から本番までの手順を決め、全員が同じ流れで進むように見るのも CoE の役目です。[3]

命名・説明のルールと設定変更履歴での見守り

基準（Standards）の一つが、名前と説明の付け方です。Trailhead では、部署ごとに言葉の使い方がずれていないかを見つけ、そろえることも CoE の役目に入っています。[3]

カスタム項目には、管理者向けの [説明] と、利用者に見せる [ヘルプテキスト] があります。[説明] はレコードの詳細ページや編集ページには出ない、管理のための欄です。何のための項目かをここに残すルールにしておくと、後から見る人が判断しやすくなります。[9]

Salesforce Architects の資料でも、名前の分かりやすいフロー変数と明確な説明が、後の保守担当に伝わる記録になるとしています。設定は、何をしたかだけでなく、なぜそうしたかを残すよう勧めています。命名ルールに沿っているかといった機械的な確認は、自動で行うことも勧めています。[10]

決めたルールが守られているかは、[設定変更履歴の参照]（設定監査履歴）で見守ります。画面には直近 20 件の変更が、日時・実施者・内容とともに出ます。管理者が複数いる組織で特に役立つ機能です。[8]

[ダウンロード] で取り出せるのは過去 180 日分で、それより古い記録は消えます（2026年10月時点）。長く残す必要があるときは、書き出して保管するよう案内されています。[8][10]

定期的な見直しと少人数の組織での始め方

ルールは作って終わりではありません。Trailhead では、CoE の中心メンバーと各チームが集まる頻度を決め、運用や技術の話は毎週、戦略やロードマップの話は毎月を目安にするよう勧めています。効果を測る指標（KPI）を決めておき、見直しの材料にします。[4]

Salesforce Architects の資料では、本番の設定が記録とずれていないかを四半期ごとに確かめて直すことも挙げています。[10]

少人数の組織では、「小さく始めて、育てていく」という Trailhead の考え方が手がかりになります。数人と少しの手順からでも始めてよく、新しく人を雇わずに、今いるメンバーで主な役割を埋めればよいとされています。組織が 1 つなら、1 つの CoE がまとめて決める集中型が合うとされています。[4]

承認の人数も、チームの大きさとつり合わせます。5 人のチームで 3 人の承認を求めると、そこで作業が詰まると指摘されています。小さな範囲では、手作業のリリースと、出来事のあとの振り返りといった軽い形から始め、規模に応じて仕組みを足していく考え方が示されています。[10]