Salesforceの“ひとり管理者”が消耗しない運用設計｜兼任でも回す5つの型
Salesforceを「ひとり」もしくは「他業務と兼任」で見ている方の中には、
- 設定変更や質問の依頼が、すべて自分に集中する
- 自分が動けないと、対応がそこで止まってしまう
- 引き継ぎ資料もなく、気づけば“自分しか分からない”状態になっている
- 改善したいことは山ほどあるのに、手が回らない
といった状態に、心当たりがあるのではないでしょうか。
これは、担当者の能力や気合の問題ではありません。ひとり（兼任）で回すことを前提にした「運用設計」ができていないだけ、というケースがほとんどです。
この記事では、専任のSalesforce管理者がいない・兼任で見ているという方に向けて、消耗せずに回すための運用設計を「5つの型」に整理して解説します。
実際の現場でつまずいたこと・効いたことも交えて紹介するので、今まさに一人で抱えている方の参考になればと思います。
結論｜ひとり管理者の問題は「気合」ではなく「仕組み」で解く
先に結論を言うと、ひとり管理者が消耗しないために必要なのは、頑張りを増やすことではなく、依存を減らす仕組みです。
ポイントは、大きく3つに整理できます。
- 依頼を減らす・整える：思いつきの口頭依頼に振り回されない受け方をつくる
- “自分しか分からない”を減らす：命名・記録・自動化で、属人化を薄くする
- 現場に合わせて作る：押し付けではなく、使われる形にして定着させる
この記事の「5つの型」は、すべてこの3つのどれかに対応しています。
なぜ“ひとり管理者”は消耗するのか
ひとり管理者がしんどくなるのは、たいてい次のような構造があるからです。
1. 依頼が無限に湧き、しかも割り込みで来る
「この項目足して」「この数字どうやって出すの」といった依頼が、口頭・チャット・思いつきでバラバラに飛んできます。
1件1件は小さくても、割り込みが続くと本来やりたい改善が一向に進みません。
2. 自分が止まると、業務も止まる
管理者が稼働していないと、対応がそのまま遅れます。さらにやっかいなのが、気づかれない抜け漏れです。
たとえば退職者のユーザー無効化のようなセキュリティ対応は、自分が忘れると誰も気づけません。
3. “正解”が用意されていない
リードや商談にどんな項目を持たせるべきか、入力漏れをどう防ぐか——こうした「組織としての正解」が無いところから、一人で考えて決めていかなければならない場面も多くあります。
つまり消耗の原因は、努力不足ではなく、「依頼の受け方」「属人化」「正解のなさ」が設計されないまま運用が回っていることにあります。
【事例】“正解がない”ところから始めた現場で起きたこと
あるBtoB企業の運用に関わったとき、最初にぶつかったのは「そもそも組織として“正解”がない」状態でした。
リードや商談にどんな項目を持たせるか、入力漏れをどう防ぐか——そういった土台から一緒に考える必要があり、ルールづくり自体に時間がかかりました。
さらに難しかったのが、決めたルールがなかなか定着しないことです。
人数が増えるほど、“情報を入力しない人”が一定数出てくるのは避けられません。ルールを作って終わり、では現場は動きませんでした。
転機になったのは、やり方を「押し付け」から「現場に合わせる」に変えたことです。具体的には、
- Salesforceに関する依頼・質問は、専用のSlackチャンネルに一本化する
- 口頭で来た依頼も、必ず文章に起こしてもらう
- 新しいレポートやルールを作る前に、営業部に現場ヒアリングをする
この3つを徹底したことで、ようやく「使われる」状態に近づきました。
逆に、こちらが「便利だから使ってよ」と一方的に提示したものは、ほぼ使われませんでした。
レポートでもダッシュボードでもフローでも、現場の声を聞かずに作ったものは定着しない——これは何度も痛感したポイントです。
兼任でも回る運用設計：5つの型
ここからは、上の経験を踏まえて「ひとり（兼任）でも回る」ための具体的な型を5つ紹介します。全部を一度にやる必要はありません。
できそうな1つから始めるのがおすすめです。
型1｜依頼の窓口を1つにする（口頭をやめ、文章にする）
まず効くのが、依頼の入口を1か所にまとめることです。
おすすめは、Salesforce専用のSlackチャンネルを作り、「Salesforceのことは必ずここで聞く」というルールにすること。
チャンネルなら画面キャプチャも一緒に共有できるため、状況が伝わりやすく、双方にとってラクになります。
ポイントは、口頭依頼を文章に起こしてもらうこと。口頭だと細かい条件が詰め切れず、後から「思っていたのと違う」と手戻りが発生しがちです。
文章にしておくだけで、認識ズレも、後から見返す手間もかなり減ります。
型2｜命名ルールと項目設計で“事故”を防ぐ
次に、項目の命名と設計です。ここが緩いと、後から確実に苦しくなります。
たとえば、カスタム項目のAPI参照名が Field4__c のような自動採番のままになっていると、後から見たときに「これは何の項目だっけ？」となり、調べ直しが発生します。
最初に、
- 参照名の付け方（例：用途が分かる英単語にする）
- 似た項目を増やさない（“とりあえず追加”をしない）
- 最低限のメモを残す（何のための項目か）
といったルールをゆるくでも決めておくと、未来の自分の調査時間を大きく減らせます。
命名ルールは、共有レポートの運用でも同じように効きます（参考：Salesforceのダッシュボード表示が急におかしくなる原因No.1）。
型3｜変更管理で「誰が何を触ったか」を追えるようにする
属人化を薄くするうえで地味に効くのが、変更を記録・把握できる状態にしておくことです。
Salesforceには「設定変更履歴の参照（Setup Audit Trail）」があり、誰がいつ何を変えたかを確認できます。トラブル時に「何が変わったのか」を切り分ける起点になります。
あわせて、棚卸しの観点も決めておくと安心です。
たとえば退職者のユーザー無効化のように「忘れると誰も気づけない」対応は、月次でチェックする運用にしておくと、ヒヤッとする事故を防げます。
型4｜自動化で“手作業の依頼”と入力漏れを減らす
「入力を忘れる」「毎回手で直す」といった作業は、Flowで自動化することで依頼そのものを減らせます。
たとえば、レコード作成時に必須項目が入っているかをチェックする、といった仕組みを作っておけば、入力漏れを人の注意力に頼らずに防げます。
自動化は「自分がやる作業」だけでなく、「自分に来る依頼」も減らしてくれます。
手作業で対応している繰り返しタスクがあれば、自動化の候補です。
型5｜現場ヒアリングをしてから作る（定着の肝）
最後が、いちばん大事な型です。作る前に、現場の声を聞くこと。
レポートもダッシュボードもフローも、こちらが「いいでしょ、使ってよ」と提示しただけでは、ほぼ使われません。それは結局、作り手側のポジショントークだからです。
「どの数字を、いつ、何のために見たいのか」を現場にヒアリングしてから作ると、同じものでも定着率がまるで変わります。
少し遠回りに見えても、ヒアリング → 作る → 使われるの順番を守るのが、結局いちばんの近道です（そもそも「見たいデータがレポートで出せない」ときは、「そのデータ、レポートで取れません」を解決するカスタムレポートタイプ入門 もあわせてどうぞ）。
メニューや画面の見せ方を業務に合わせて整えるのも、この「現場に合わせる」発想の一部です（参考：Salesforceの「アプリケーション」とは？表示メニューを整理する基本設定）。
それでも一人で抱えないために
ここまで5つの型を紹介しましたが、ひとり管理者の本当の難しさは、「これを全部、一人で考えて回す」こと自体にあります。
なお、SalesforceだけでなくAccount Engagement（旧Pardot）も兼任で見ている場合、同じ「運用設計が無いまま」の状態に陥りがちです。
AEが“高いメール配信ツール”で止まっているときの立て直しは、Account Engagement（旧Pardot）が“高いメール配信ツール”で終わる3つの原因と立て直し方にまとめました。
「何から手をつければいいか分からない」「決めたいけど壁打ち相手がいない」というときは、外部の伴走を使うのも一つの手です。
ただ、外部に頼むといっても「作業だけ代行してもらう」のと「一緒に運用を回す伴走型」では結果が大きく変わります（参考：「設定代行」で失敗しないために｜代行と伴走支援の違いと向き不向き）。
Steadmarkでは、Salesforceの運用整理・属人化の解消を、週1の定例とSlack相談で一緒に進める伴走支援をしています。
詳しくはサービスページをご覧ください。
まとめ
ひとり（兼任）でSalesforceを回すなら、頑張りを増やすより、依存を減らす仕組みをつくるのが近道です。
今回の5つの型を整理すると、次のとおりです。
- 型1：依頼の窓口を1つにする（口頭をやめ、文章＋キャプチャで受ける）
- 型2：命名ルールと項目設計で“事故”を防ぐ
- 型3：変更履歴で「誰が何を触ったか」を追えるようにする
- 型4：自動化で手作業の依頼と入力漏れを減らす
- 型5：現場ヒアリングをしてから作る（定着の肝）
すべてを一度にやる必要はありません。まずは**型1の「窓口を1つにする」**だけでも、依頼の混乱はぐっと減ります。できる1つから始めてみてください。
