northernforce #49レポート：成果を生み出すためのSalesforce運用ガイド輪読会

「northernforce #49」レポート

2025年4月15日（火）に開催された「northernforce #49」のイベントレポートです。
イベントURL
https://northernforce.connpass.com/event/346431/

課題図書「成果を生み出すためのSalesforce運用ガイド」

著者：佐伯 葉介氏

X：https://x.com/yonyonsaeki?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor
note：https://note.com/yonyon_saeki

northernforceってどんなコミュニティ？

northernforceは、北海道を拠点としたSalesforceのTrailbrazerコミュニティです。
2017年6月から活動を開始しており、Salesforceのシステム管理者（アドミン）、開発者、ユーザー、幅広い層を対象としているのが特徴です。

「北海道を元気にする」というミッションを掲げ、IT人材の不足や技術共有の場が少ないという北海道における課題に対して、学びの場所を作っています。
参加者はここでの学びを持ち帰ってもらい、それぞれの現場で活かすことで、北海道、ひいては日本の活性化に貢献したいという思いで活動しています。

第49回が先日開催され、佐伯 葉介氏著『Salesforce運用ガイド』（翔泳社、2023年刊行）の輪読会を通じて、Salesforceの本質に迫る深い議論が交わされました。

QAパートが盛り上がり、1時間30分の予定を大幅に過ぎての開催となりました。
佐伯さん、ご登壇者、参加者のみなさま、長時間お付き合いいただき本当にありがとうございました！

この記事では、イベントの様子をお伝えします。

『成果を生み出すためのSalesforce運用ガイド』輪読会の議論

当日のメイントピックは「成果を生み出すためのSalesforce運用ガイド」の輪読会です。佐伯 葉介氏著『成果を生み出すSalesforce運用ガイド』の第4章から第9章までを参加者が分担して発表する形式で進行しました。
「システム管理者の役割を明確にして、攻めのシステム管理者を目指していく」というテーマのもと、実践的なSalesforce運用のノウハウが共有されました。

第4章：Salesforceの標準モデルを抑える

登壇者：Shigeruさん

• Salesforceを参考にした型との新業務：Salesforceの型 × 自社の業務の型を組み合わせ
  • いいとこ取りをするには・・・
    • Salesforceの標準や基本を理解する
    • 自社のビジネスの課題を理解する
• Salesforceの狭義の標準機能と広義のカスタマイズ可能性の両方を理解することで、本来の価値を引き出せる
• カスタマイズできるからといって何でもカスタマイズすればいいわけではない。技術的負債を増やさないためにも標準機能の理解が重要
• 課題を解決するためにはSalesforceありきではなく本質を見極めたうえで価値やアウトカムに対して柔軟に考えて評価する
  • 検索結果を5000件出したその先、そもそも何がほしくて検索結果が5000件必要なのか？
  • 母数の把握とリストが知りたいのであればCSVエクスポートでOK

第5章：会社のビジネスモデルとSalesforceの適用を考える

登壇者：佐藤さん

• SFAの本質から見えるSalesforceの価値 = 目標達成のためのマネジメントを当たり前にすること

  • Salesforceの本質はSalesforce社がSalesforceを使い、ビジネスを拡大・成長させた歴史にあり
    • 目標達成のためのマネジメント
    • それを組織に根付かせるノウハウ
    • SFA以外の領域への展開

• プロセス管理 = 視る化

  • 視える化（可視化）のループに陥ることがよくある
  • 可視化されたデータをもとに実際にアクションして予測→行動→分析→改善を回す

• 機能を表面的に使うだけでなく、自社のビジネスに合わせてデータドリブンな意思決定を促す組織文化を作ることが重要

第6章：定常的なSalesforce運用作業をいかに効率化できるか

登壇者：土田さん

• システム管理者の多岐にわたる業務をいかに効率化し、「コストセンター」から価値創造を行う「プロフィットセンター」への転換を目指す

• システム管理者の理想の時間の使い方：改善に向けたアクション＞定常業務

  • そのためのステップ
    • 定常業務（お問い合わせ対応＋運用業務）の効率化
    • 改善活動を増やす
    • 緊急度の高い不具合対応を抑制する

• お問い合わせ対応は「さばく作業」と「量を減らす」ことで効率化する

• 自動化は目的ではなく手段。本当に必要なのは顧客価値を創造するための時間を確保すること

第7章：重要な課題への対応と負債の抑制

登壇者：うたまろさん

• 「重要度は高いが緊急度は低い課題」への取り組み方
  • 例：集めたデータを活用したプロセス改善
  • 課題を曖昧なものではなく明確にする。ゴールと現状の差分を埋めるためにどんな要素や活動テーマがあるか？
• 課題管理を課題候補管理として捉える
  • 中長期の課題は抽象的になりがち
  • 課題候補 = 課題をより具体化する。実行可能なレベルに落とし込むプロセスが重要
  • その中で重要度、優先度の軸で比較できるようにする
  • 何がどうよくなるのか？というインパクトを経営者や決裁者の目線で明確にすることが優先度をつけるうえで重要
• 設計的負債と運用的負債の違い
  • 設計的負債：データモデルやデータフローの課題。中長期で深刻な影響を及ぼす
  • 運用的負債：使われていない機能やデータ。日々の運用における小さな問題を引き起こす
• レコードトリガーフローは便利だが、条件設定を間違えると技術的負債になりやすい
  • 便利なぶん、怖い
  • 開始条件や検索条件を「徹底的」に見直す
• 目先の業務に追われるだけでなく、長期的な視点を持って技術的負債を意識した課題管理とシステム構築を行うことが安定したSalesforce運用とビジネスの成長に繋がる

第8章：Salesforceシステムの未来の姿をイメージする

登壇者：吉松

• システム管理者はシステムを担当するだけにあらず
  • 顧客の成功や会社の成功のための協業者
  • Salesforceに付加価値をつけていく
• あるべき関係性
  • Salesforceを通じてユーザー（経営者、マネージャー、メンバー）と共通認識を作る
  • その先に改善、顧客の成功、会社の成功がある
    -　改善活動が最重要テーマだが、3つの対立がある
  • 時間（短期/中長期）、視点（自社/顧客・市場）、場所（分散/統合）
  • 対立が起こる枠組みを理解しておく
• 3つの壁：定着の壁、拡張の壁、統合の壁
  • 定着の壁：ユーザーと向き合う。手を広げすぎない。目指すゴールを小さく絞りシンプルに。まずはルーティーンを変えることを最優先
  • 拡張の壁：現場からの欲が出てくる。他の業務プロセスにもSalesforceを使っていきたい。システム管理者の仕事が一気に複雑化する。開発要件が出てきたときは外部のパートナーを頼るなどして保守・運用のプロセスを整える
  • 統合の壁：企業のIT基盤の課題の行きつく先。課題が高度化するため全社で取り組む課題になる。現状を把握して不便さや不満を俯瞰して見る
• 目の前の仕事だけでなく俯瞰して現状を把握し、今後起こりうる未来を想定した上で課題に向き合う

第9章：成長に向けた準備

登壇者：権守さん

• Salesforce管理者をどうやって組織化・育成していくか？
  • 経営者目線で考える：ROI追及型Salesforceへシフトして先行投資を引き出す
  • コスト削減には限界がある。Salesforceによってアウトプット（売上）が上がる状況が作れれば業務向上系の施策が打てる
  • 投資によって増員が実現可能
• 非機能要件を知っておく（詳しくは書籍で！）
• 作業を切り出すのではなく、きちんと育てる仲間としてキャリア設計を含めて設計する
  • 1人任せの状態が続くと仲間が増やせにくくなる。1人に負担がどんどん掛かる
  • 早期に増員の正当性を経営者に示す。ただし、スキルの定義や業務分担を設計しておく
  • Salesforceを活用する領域、メンバーに求める人物像や役割
  • Salesforce管理者のその後の成長する部分の設計まで考えておく：データアナリストやCIO、Biz/SalesOpsやCOOなど
• 育成が俗人化して再現性が低い理由を知る
  • 任せられない→教えられない→俗人化の連鎖
  • なぜやるか？が抜け落ちている
  • OJTが「ついで」や「空き時間」に偏る
• 視座 × OJT設計
  • 何のための作業かを理解させる
    ‐ OJTの設計アプローチ：手が空いた時に教える、フォワードチェイニング、バックワードチェイニング
  • それぞれ一長一短あるので、うまくいかなかったらアプローチを変えてみる
• 一人で勝つな、一人で負けるな
  • 自身の抱えている課題をうまく整理できない：SalesforceのAEやパートナー企業を頼ってみる

佐伯さんとのQAセッション

• 執筆に至った経緯は？
  佐伯さん）長年Salesforceに関わり、いいシステムを作ってもうまく使われなかったりした。システムの高度さが価値に転換されていないことへのの課題感があった。

Salesforceはパッケージと思われがち（定義難しいが、、、）
プリセットとしてパッケージを捉えられがちだが、プリセットであればテンプレートシステムでよい。
これだけだとSalesforceは売れない。
Salesforceに関わっているのであれば、なんでSalesforceが売れるのかを見つめなおさないといけない。

• Salesforce導入パートナーの立場として、お客様にも能動的に考えていただきたいと思ってる。エンジニアとして、これからSalesforce使っていただくお客様にどのように工夫して働きかけるか？
  佐伯さん）うまく質問できるのが重要。一緒に働いた先輩の切り返しがすごかった。お客様とのシステム導入に関する会話で、要望に対して予約キャンセル時の対応や業務がどう変わるか、エンドユーザー様の体験がこう変わる、など様々な質問を顧客に投げかけ、顧客が困惑する場面があった。それに対して先輩が「困ってください。それらをシステムで作ることですから」と発言し、顧客に深く検討してもらうことを促した。この経験から、顧客に的確な質問をするためには、業務全体を理解し、想定外のケースも把握しておく必要がある。また、システムに関する具体的な体験をイメージして顧客に伝えることも有効。

• Salesforceで成果を上げられたと感じた瞬間は？
  　- 佐伯さん）製造業の顧客が全国で開催する展示会におけるセミナー運営管理の仕組みをSalesforceで構築したこと。これまでは、セミナー後のフォローアップに時間がかかっていたけれど、SalesforceとiPad、レシートプリンターなどを連携させることで、受付、名刺管理、アンケート回収、フォローアップまでを効率化した。実際にセミナーで運用した際にはセミナー終了後すぐに営業担当者が顧客の要望を把握し、翌日から迅速なアクションが可能になるなど、効果を目の当たりにできた。カスタマーサクセスを叫びつつ、現場や成功を知らないのはやばい。

• 「しない」という判断をするのは難しい。開発や運用で「しない」と判断した話
  吉松）費用対効果をふまえて今じゃないと伝えることはある。
  佐伯さん）お客様に営業したときに夢の詰まった画面イメージをもらい、Salesforceと一致しないから断ったことがあった。ただ、大変そうだからやんないのは違うと思っている。
  しない判断は大変だからしないという風に聞こえちゃうのかも。
  時系列で増えていくデータ量や管理コストなどの見えないコストを織り込んで言語化していく。
  そうすると、やらないほうがいいかもという感覚の部分をお客様の目線に立ったうえでやらない方がいいと言える。
  機能軸だけでなく時間軸でも全体を捉える。1年後、3年後をイメージしてお客様に伝える。

• 改善業務の時間をどう確保するか？
  佐伯さん）足回りを整えることの重要性を語る。足回りが悪い（業務や人事などのインフラなど）、筋が悪いものが会社の中にある。それが3年後とかの計画を考えたときに影響が出る、という説明をしないと改善業務に時間を確保させてもらえない。
  足元がおぼつかない中で飛び道具（AIなど）を入れたいとなっても基盤が整っていないから入れられない問題が起きる。
  データ基盤を整えたり名寄せをしたりリファクタリングする活動ができないことで、AIを入れられない、みたいな話をしないと時間や予算を組めない。改善に向けてのアジェンダが必要。

• 長文でのツイートが勉強になっています。長文ツイートを各きっかけや習慣化されてることはありますか？
  佐伯さん）長文ツイートは僕が向いていただけ。短く書こうと思っても気づいたら3000文字とかになっている（笑）。自分で壁打ちをしている感じ。起業して社会的接点が減ったから繋がる場所としてSNSを始めた。反応があるから楽しくできている。

• 自社運用してる際に、経営陣は何でもデータとしてあるから分析抽出出来るだろうと言ってくる。連携してる販管ツールが複雑すぎてベンダーに一々問い合わせしないといけない状態に陥っている。売上粗利管理を連携してSalesforce上で出来ず、どう上に進言していくべきか悩んでいる
  佐伯さん）経営陣が何をすべきかを言わないといけない。データあるからできるのは分かるが、そこが難しい理由。部門ごとに売り上げの粒度が違う等、細かいケースを具体的に上げていく。ツールの問題だけではない。売上粗利管理ができていないそもそもの理由は？組織階層、マネージャー層へ渡しているフォーマットが悪い等。経営陣が困っていると思うのでニーズに寄り添えば協力してくれるはず。

• Salesforce導入直前の会社です。導入前にSalesforceで実現したいことを伝えると、「なんでもできますので、どうしたいか御社で決めてください。そのシステムは作ります」と言われ困っています。ベンダーさんに、仕組み化の部分から伴走お手伝いをお願いすることは、無理なことをお願いすることになっているのでしょうか？
  佐伯さん）ベンダーによる。抽象的なところから入ると価格は上がる。何をしたいか決めてくれればやるというタイプのベンダーもいれば、コンサル的な会社もいる。ミスマッチを避けるために何をすべきか？から入ってほしい場合はコンサルティングをしているベンダーになるし、自分たちが何をすべきかが明確な場合はシステムに落とし込んでくれるベンダーがマッチする。