ユーザベースのSalesforce構成を振り返ってみた

はじめに

竹本)

こんにちは、株式会社ユーザベース Biz System Management Teamの竹本(あだ名:たけたけ)です!

僕は、ユーザベースでSalesforceを中心に周辺ツールのアドミン/デベロッパーだったり、セールス領域のシステムリードを担当しています。

今回のブログでは、同チームメンバーのしかさんと一緒に、ユーザベースのSalesforce環境の変遷をご紹介できればと考えています。

石川)

こんにちは、株式会社ユーザベース Biz System Management Teamの石川(あだ名:しか)です!

たけたけと同じく、Salesforce周りのアドミン/デベロッパー・システムリードを担当しています。

試行錯誤を繰り返して今の形にいきついたので、大変だったことも含めて紹介させてください!

竹本)

事業規模が大きくなると「Single Orgにするか」「Multi Orgにするか」迷うことがあると思います。

今回は改めて自分たちのSalesforce環境の変遷の振り返りと、どちらも経験した僕たちのブログがなにか1つでも参考になればと考えました。

石川)

そうですね!

最近、他社のSalesforceアドミンの方々と「Single Org」「Multi Org」についてお話しさせてもらうことも多く、気になっている人も多いのかなと感じています。

このブログを通して、「わたしたちはこんな構成を採用してるよ!」などなど、よりよいSalesforce環境を作るきっかけ、ディスカッションのきっかけになると嬉しいです!

ユーザベースのSalesforceが担っている業務領域

竹本)

まずは、ユーザベースにおけるSalesforceの活用範囲をご紹介します。

一般的に、SalesCloudの場合、Salesforceが担う業務領域は、見込客管理 〜 商談受注までを管理することが多いと思います。

ユーザベースの場合は、その先の「売上管理」や「請求管理」までSalesforce上で管理しているのが特徴になっています。

また、MAツールや会計システムとも連携し、CRM・SFAの枠を超えて、ユーザベースのセールス領域における基幹システム的な立ち位置を担っています。

石川)

「売上管理」や「請求管理」の部分は、スクラッチで開発することもありますし、AppExchangeのパッケージを導入して実現することもあります。

直近で立ち上げたOrgの場合は、AppExchangeパッケージと比較検討した上で最終的にスクラッチを選択しました。

まずは、2022年ごろまで採用していたMulti Org期をご紹介します。

その1:Multi Org 期(2018年?〜2022年初めごろ)

竹本)

この時期は、プロダクトごとにOrgが分かれてましたね!

僕は2022年入社なので、社内にSalesforceのOrgがたくさんあることにビックリした記憶があります(笑)

石川)

そうでしたね!

元々はプロダクトごとに法人が分かれていたこともあり、それぞれでSalesforceを持っていたという経緯があります。

その後、法人統合を経て、私たちのチームで全Orgのアドミンを担当することになりました。

竹本)

最初のキャッチアップ、設計・開発の統一は大変ですが、個別最適で運用できることはとても大きいメリットだったと思います!

石川)

そうですね!一方で、ユーザベースとして顧客情報・商談情報をプロダクト横断で見ることが出来ないのが主なデメリットになるかなと思います。

このアーキテクチャのメリット・デメリットをまとめると以下の通りです。

メリット デメリット
Orgごとに最適なオペレーションを組める Org横断で顧客情報や商談情報の共有ができない
Orgに合った手段で開発ができる
例)事業規模が小さいOrgの場合パッケージ導入で小さく始める など
1人が複数Org利用する場合にSalesforceライセンス費用が重複して掛かってしまう
新機能をスモールリリースしやすい
例)事業規模が小さいOrgで問題ないことを確認し徐々に他Orgに展開する など
共通対応の改修でも複数Orgに実施しないといけない
例)オフィス引越しに伴う住所変更対応、法改正対応 など
開発チーム作りが大変になる
例)Orgごとにキャッチアップが必要となる、採用に苦戦する など
利用するツールがバラバラとなり、顧客体験が悪くなってしまう
例)見積書の見た目が異なる、プロダクトごとに見積書が分かれてしまう など

竹本)

その後、一番の課題だった「顧客情報や商談情報の共有ができない」を解消するため、Multi Org + マスタOrgの構成にスライドしていきました。

ここも、物理統合なのか論理統合なのか、様々な議論をしましたね!

結果的に「個別最適 + 全体最適のいいとこ取りにチャンレジしよう」となり論理統合なアーキテクチャを実現する流れになりました。

その2:Multi Org + マスタOrg 期(2022年初めごろ〜2024年) 〜 顧客情報や商談情報の共有ができない…を解消するために 〜

竹本)

このタイミングでさらにOrgを1つ増やすことになります(笑)

プロダクトごとに分かれたMulti Orgから「取引先」「契約」「商談」データあたりを集約するためのSalesforceを立ち上げました。

このデータ集約のOrgを、マスタ情報が集まるため「マスタOrg」と呼んでいます。

Salesforce間のデータ連携も当時は初めてのチャレンジで、Herokuを用いてスクラッチでデータ連携の仕組みを開発しました。

少し詳細をお話しすると、「契約」「商談」は、プロダクト別Org → マスタOrgの単方向な連携になっています。

「取引先」はマスタOrgをハブにして、プロダクト別Org間で同期する方針を採用しました。

取引先を同期連携することにより、いくつかの取引先関連のオペレーションをマスタOrgに統一することができましたね!

石川)

ですね!

ひとつ例をあげると、プロダクト別Orgそれぞれで取引先の反社チェックをしていたのですが、マスタOrgに反社チェック機能を移管し各Orgに結果を連携することで、機能の集約・オペレーションの効率化を実現できました。

もちろん、プロダクト別Orgから「取引先」「契約」「商談」情報がマスタOrgに集まることによって、ユーザベースグループ横断で取引先ごとに各プロダクトの契約や商談の情報をぱっと見れるようになりました!(念願…!!)

社内ユーザーが複数Orgにログインして情報を見るのは大変だったので、この構成になって以降は、基本的には各プロダクト別Orgで業務をしていただき、集約した情報はTableau経由でマスタOrgの情報を見てもらっています。

竹本)

反社チェック機能の集約はとても便利になりましたよね!

他にも、「売上管理」や「請求管理」までをSalesforceが担っている関係で、予算コードや計上管理コードのような数値管理に利用するマスタがあるのですが、ここもプロダクト別Orgをひとつずつメンテしていたのが、マスタOrgの1カ所をメンテすればよくなったりしました。

このアーキテクチャのメリット・デメリットをまとめると以下の通りです。

メリット デメリット
個別最適と全体最適の良いとこ取りができる Adminの管理工数が増える
Org横断しての顧客分析が可能になる サマリの集約しかできないため「契約」「商談」の詳細情報を見たい場合は、変わらず各Orgにログインする必要がある
Org横断のマスタ管理が可能になる Salesforce間でデータ連携する仕組みを開発しないといけない(維持管理工数が増える)
レベニュー組織の動き方を変えることなく、Multi Orgの課題が解決できる
※物理統合と異なり、システムリプレースに伴うデータ移行などは発生しない

石川)

その後少し経ってから、Herokuを用いてスクラッチでデータ連携の仕組みは、費用面と保守性を観点からMulesoft Composerにリプレースしました。

HerokuからMulesoft Composerに置き換えたことで、以下のメリットがあったと感じています。

  • 費用を約半分に削減することができた
  • GUIでデータ連携の開発ができるようになり、対応できるメンバーが増えた

竹本)

Mulesoft Composerへのリプレースもこのタイミングでしたね!

ジャパンローンチに伴うパイロットプログラムにも参加させてもらって、改善出来ただけでなくチームにとっても良い経験になりましたよね!

パイロットフェーズにも関わらず、セールスフォース・ジャパンの方々にユースケースが評価され、Salesforce World Tour Tokyoに登壇したのも良い経験になったと思います。

その3:Single Orgへ(2024年〜) 〜 お客様軸の組織に変換するために 〜

竹本)

その後、レベニュー組織の体制変換やプロダクト間でシナジーを出していく戦略に伴い、2024年からプロダクト別Orgの統合をスタートしました。

複数プロダクトを一緒に提案する場合に、ユーザベースのMulti Org構成だと、複数Orgにログインし商談登録をしないといけません。

これだと、単純に手間がかかりUXが最悪ですし、見積書や申込書も別になったりと顧客体験も悪く、組織としてもフォーキャスト管理が難しくなります。

こういった背景から、Multi Org構成からSingle Org構成へと歩み始めました。

一方で、PMIのしやすさなど組織のスケール観点を考慮し、マスタOrgは据え置きとしました!

例えば、「請求管理」は、統合するOrg上に構築するのではなくマスタOrg上に構築し、M&Aなどにより急遽他Orgが増えた場合でもマスタOrgにさえ接続すれば、すぐに債権管理や顧客管理を統合できるようなアーキテクチャになっています。

石川)

Single Org化に向けては一気に変更するのではなく、開発 → リリースを繰り返すアジャイル開発を採用しました!

各プロダクトの事業規模も大きくなっていたため、ビッグバンリリースにならないように、なるべく小さい単位で開発 → リリースをしたいと考えたことがきっかけです。

アジャイル開発で進めることでリスクヘッジにもなりますし、出来るところ・優先度が高いところから価値を早く届けることを実現できたかと思います。

ユーザーから都度フィードバックをもらい、改善もしつつ新機能開発も行うのは大変ですが、結果よりよいモノを作り上げることが出来たと感じています。

アジャイル開発に関してはまだまだ道半ばですが、振り返りをしつつ、今後も継続していきたいと考えています。

また、Orgごとのプロセスやオペレーションも、Single Org化に合わせて統一していきました。

このアーキテクチャのメリット・デメリットをまとめると以下の通りです。

メリット デメリット
1Orgで商談管理・契約管理が完結するため、入力手間の削減でき、フォーキャスト管理がしやすくなる イレギュラーな運用プロセス・オペレーションを取り込みにくい
帳表ツールをはじめ周辺ツールが統一されるため顧客体験が向上する 開発要件を決める際のステークホルダーが多く、要件整理の難易度が高くなる
運用プロセス・オペレーションを統一することができる データ量・イベント量が増えるため、設計/開発の難易度が高くなる
例)ガバナ制限に引っ掛かりやすくなるため、上手くフォローする必要が出てくる
Salesforceライセンス費用が重複しない
共通対応の改修が1Orgで完結する
例)オフィス引越しに伴う住所変更対応、法改正対応 など

竹本)

アジャイル開発は本当にチャレンジして良かったですね!

まだ改善中ではありますが、開発チームのパフォーマンスや開発見込みの管理がとてもしやすくなりました。

今までは、根拠が曖昧なガントチャートでスケジュールを引いていたのですが、根拠がしっかりした計画で進めることができたなと感じています。

今後もアジャイルをベースにした開発スタイルでやっていきたいですね!

今後やりたいこと

竹本)

今後はプロダクトとSalesforceとの連携を強めたいなぁと妄想しています!

例えば、プロダクト側に溜まっているアクセスログをSalesforceに連携し、取引先や契約ページを見ると活用状況がパッと見えたり。

お客様がプロダクト画面から直接商談を登録して見積もりを作成できたり。

ただの業務システムに留まらず、お客様とも接続できるような世界観を作れると面白いなぁと考えています。

また、お恥ずかしい話なのですが、Salesforceの開発プロセスが未だに変更セットベースの運用になっています。。

DevOpsCenterやScratch Orgを用いた、新しい開発プロセスに転換出来たらなと考えています。

というのも、組織ベースの開発スタイルだと複数人が1つのSandboxを触るため、どうしてもデグレなどの問題が時々発生しちゃっています。。

レベニュー組織に貢献しつつ自分たちの開発サイクルもセットで改善していきたいです。

自動テストツールも導入したいし、、、やりたいことはたくさんありますね!(笑)

石川)

そうですね!

国内のスピーダ事業についてはSingle Orgへの移行が完了したため、ディスカウント設計の大幅な見直しなど今までは取り組むのが難しかった課題にも取り組んでいけるのが嬉しいです。

実はまだNewsPicks事業は別Orgのままになっています。

異なるビジネスモデルの販売管理をSingle Orgで実現できるのか、引き続きよいアーキテクチャを検討していきたいです!

また、ユーザベースのSalesforceには質の高い商談データが集まっていると思うので、Agentforceなど生成AIの活用にもチャレンジしていきたいです!

おわりに

石川)

いかがでしたでしょうか?

今回はユーザベースのSalesforce環境の変遷をご紹介しました。

会社の戦略や組織の変更に合わせてSalesforceの構成も大きく変わってきました。

中々、他社のSalesforce環境について見れる機会は少ないと思い、改めて自分たちのSalesforceについて振り返ってみました。

私たちの試行錯誤の様子も少し感じていただけたかな、と思います。

私たちも皆さまのSalesforce環境や取り組みを知れると勉強になるので、ぜひ機会があればお話しを聞かせていただきたいです!

竹本)

そうですね!

改めて自分たちの振り返りが出来て良かったです!そして、1つでも何かの参考になれば嬉しいと思います!

話のネタはたくさんあるので、今後も定期的にブログで情報発信していきたいですね!(次回は未定ですが…笑)

Page top