この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
大阪オフィスの玉井です。
2022年10月17日〜21日に行われたCoalesce 2022というハイブリッド（オンライン+オフライン）カンファレンスが開催されました。主催はdbt labs社です。
本記事は、その中で発表されたSalesforcelandia: A magical land of data and revOps harmonyというセッションについて、レポートをお届け致します。
セッション概要
登壇者
- Erika Pullum
- Sr. Analytics Engineer, Hex
- Sean Heisler
- RevOps, Hex
超概要
Hex社がこれまで取り組んできたRevOpsとモダンデータスタックの良い併用方法を紹介するセッションです。
つきましては、先に下記の用語について理解しておいた方が良いです。
- RevOps（レベニューオペレーション）
- Go-to-Market
セッションレポート
※このセッションは2人が混じって話すため、発言者を色で分けています。
- 黒：Erika氏
- 青：Sean氏
前段
私はErikaです。Hex社から来ました。
本日は、Salesforcelandiaという、データとRevOpsが調和する魔法の国にご案内します。
今回はSalesforceに焦点を当てますが、これらのコンセプトは、あなたの会社が使用しているあらゆるCRMや業務用ツールに拡張することができます。データチームが接続する必要のある、あらゆるCRMや業務ツールに適用できます。
Salesforceやその他の業務システムは敵ではありません。が、敵のように感じることはあります。特に、自分のチームが管理しているレポートやダッシュボードの数字と、Salesforceの数字が一致しない理由を尋ねるために、誰かがあなたを怠け者扱いしたとき等はそうです。
私は、もう二度と一致しない数字を調査することなく、楽しく余生を過ごしたいのですが、皆さんはどうでしょうか。
データチームにいると、このような運用ツールと競争しているように感じられることがあります。データチームにはビジネスパーソンがいて、彼らがマインドシェアを持っています。彼らは真のデータ源を持っていますが、データウェアハウスとの整合性を保つのは難しいのです。
しかし今日は、そんなことはありません。ビジネスツールとモダンデータスタックの間の複雑なインターフェースを管理する方法があるのです。
データスタックとSalesforceのような運用ツールの間のインターフェースにアプローチする方法は様々です。運用ツールとデータスタックは、それぞれが得意とする分野で使用します。ビジネスチームは、業務や意思決定に必要なものを手に入れることができます。システム構築者は、契約と保守可能なシステムを手に入れることができます。
ビジネスチームが必要なものを手に入れ、対立ではなく調和を保つことができるのです。あなた方や私、そしてSeanのように、すべてを一致させようとするあまり、気が狂いそうになることはないでしょう。
Salesforcelandiaを紹介する前に、私たちのことを説明しましょう。
私はErikaです。当社初のアナリティクスエンジニアとして採用されました。営業チームとGo to Marketチームがビジネスで何が起こっているか理解することを支援しました。私の役割は、企業が自社を理解し、適切な意思決定を行えるようにするだと考えています。
そして今日、Seanと一緒にここにいることにとても興奮しています。彼は、私のSalesforceに対する考え方を変えてくれました。そして、この講演の残りの時間で、皆さんもSeanに考えを変えてもらうことをお勧めします。
私はSeanです。私はRevOpsと最初のRevOps採用をやっています。RevOpsが何であるかに説明する前に、RevOpsに詳しい人、またはそのチームと交流がある人は手を挙げてください。
（何人か挙手）
私はSalesforceの資格を持っているわけでもなく、Salesforceの管理者の下でインターンをしたわけでもありません。それを逆の立場から学ぶのです。
私は、チームを成功に導くために、戦略、プロセス、システムを導入することが、RevOpsだと考えています。そうすれば、最強のセールスリーダーが営業活動を行い、プロセス変更の方法や優れたデータレポートの作成方法を知っているかどうかを心配する必要がなくなるということです。データチームとぶつかる緊張感の源になるかもしれませんし、ちょっと変な感じもします。
Salesforceの真実
まずは私が見たままの真実から話を始めたいと思います。
まず1つ目は、Salesforceは絶対にどこにも行かないということです。大きな存在です。CRMは他にもたくさんありますが、結局のところ、GTM（Go-to-Market）を担当している側の誰もがSalesforceをすでに知っていて、使っています。
Salesforceの得意分野は悪くないですが、他の多くの分野は不得意です。私はSalesforceを全面的に支持しているわけではありません。しかし、Salesforceが必要とするもの、つまりデータスタックを持つGTMチームのためのインターフェイスとしては、非常に優れています。
申し訳ありませんが、Salesforceが変わるとは思えませんし、魔法のようにモダンデータスタックと完璧に統合されるとも思えません。なぜなら、Salesforceはチームと連携することに重点を置いており、必ずしもデータイメージの完璧な一部である必要はないからです。しかし、私たちは、それを実現する手助けをすることができます。
データとRevOpsの関係がうまくいかなくなる方法はたくさんあるのです。RevOpsが何であるかについて手を挙げなかった数名の皆さんは、おそらくこれが横道にそれるというトラウマを抱いたことがないのだろうと推測します。うらやましい。
うまくいかなくなる原因の1つは、人間関係がうまくいっていないことです。フェンスの向こう側にいる人を信用しないのは、本当に簡単なことです。ロボットの立場からすると、営業部門を率いるアンドリューから、ある日突然、緊急に必要なものがあるという連絡が入るかもしれません。そのとき、私はその要求を解決するために、データについて十分に知っておく必要があります。もしErikaが私を社外パートナーのように扱い、「いやいや、それは私がカバーしますよ、私の仕事ですから」と言ったとしたら、私は自分の仕事の中核を担うことができなくなってしまうでしょう。だから、実際のパートナーとして扱われることで、突然、お互いを嫌いにならずに済むようになったんです。また、衝突がなかったとは言いませんが、私たちはそれを乗り越える方法を見つけました。そこが面白いところです。
データサイロは、意思決定には絶対に有害です。なぜなら、「この数字がよくわからない」「この違いが何なのか理解したい」といった理由で隠れてしまうからです。データチームとしては、ビジネス上の意思決定に影響を与えないような差異を説明するよう求められることがよくあります。したがって、組織内の意思決定の速度を上げるには、モダンデータスタックとSalesforceなどの運用ツールの間で、データサイロが発生しないようにすることが非常に重要なのです。
Salesforceを2つの方向から「解釈」する
このような問題の多くは、私たちと一緒にSalesforcelandiaに参加さえしていただければ、回避できるものだと考えています。
これから紹介するSalesforcelandiaの4つの原則に入る前に、一歩踏み込んでSalesforceに対する考え方を揃えておきましょう。
データチーム向けのSalesforceについて、私の立場からまず申し上げたいのは、SalesforceはコードレスなUIを持つ、実に単純なデータベースであるということです。多くの制約があります。実際、それは良いことで、ある種のレーンに留まることができます。
私たちが得た大きな学びのひとつは、「人間関係を理解するのは一度きり」ということです。だから、他のことをするように説得してはいけません。また、オブジェクトをデータとして扱うので「オブジェクト＝テーブル」「レコード＝行」のような表現になります。しかし、これらのオブジェクトはデフォルトでいくつか用意されており、必要に応じて追加していくことができます。
自動化とレポート機能について。現実的には、デフォルトのものは素晴らしいものではありません。でも、これはみなさんが価値を与えてくれる素晴らしい場所です。突然、このツールの外に出て、より良い場所で物事を行うことに関心を持つ理由ができたのですから。
しかし、最後に、最も重要なことですが、このツールはあなたの囚われの身であることを忘れないでください。すでに営業マネージャーの一団が、すべての担当者にSalesforceを更新するように叫んでおり、彼らはこのツールに入ってデータを見たり触ったりすることになるのです。
ですから、このツールを以上のように考えてみると、多くのことが見えてくると思います。
さて、では逆にデータチームはSalesforceについてどのように考えるべきでしょうか？
まず、Salesforceをデータスタックで再現しようとしてはいけません。営業担当者はこのソリューションに満足しないでしょう。意思決定をする際に、2つの画面を切り替えるのは誰でも嫌なものです。ですから、Salesforceが得意とする業務については、Salesforceに任せてしまいましょう。その代わり、データ担当者として追加できる価値は、Salesforceにデータを持ち込むことで、すでに人々が生活している場所で仕事をすることができるようになります。そして、Salesforceからデータスタックにリンクバックすることで、単純な1対多の関係よりも深いところにいるアカウント担当者に価値を提供することができます。
Salesforceのデータベースのような性質をうまく利用することもできます。例えば、Seanと私はdbt seedの代わりにSalesforceで売上目標を管理しています。というのも、いずれにせよSeanは売上目標を必要とすることになるからです。このように、私たちはマスターデータを共有することで、営業チームがSalesforceで見ているものと、データウェアハウスで見ているものが常に一致するようにすることができるのです。
もう一つ、Salesforceの優れた点は、他の多くのGTMツールと連携していることです。つまり、Salesforceとカスタマーサポートツールの顧客IDなど、お客様が必要とする様々なツールのエンティティマッピング関係を維持することができます。
Salesforceは、ソースとデスティネーションのような役割を果たし、自分自身と他のツール、自分自身とデータスタックの間の複雑なインタフェースであるため、これらのインタフェースの構築方法と関係の設計方法について十分に考慮する必要があります。
Salesforcelandia〜4つの原則
Salesforcelandiaの4つの原則をご紹介します。
You’re more alike than you think
最初にお話しする原則は、自分が思っているよりもずっと似ている、ということです。つまり、このような設計上の決定をすることは、技術だけでなく、人とプロセス、つまり信頼についても重要なのです。
RevOpsの担当者と仕事をするときは、彼らもあなたと同じような頭脳を持っていると考えてみてください。彼らは構造を求めており、秩序を求めています。彼らは市場投入前の混沌とした状況に慣れています。ゼロから始めるのであれば、まず可能にすることに集中しなければなりません。多くの質問をし、意見を確認し、チームメンバーが本当に重要だと思うことをしたときに、あなたはなぜそれが必要なのか理解していませんが、彼らにとって重要だからそうしてあげるのです。
ノーよりイエスと言ってください。問題解決のための話し合いでは、質問をし、意見を確認し、障壁ではなく橋を架けることが重要です。「このシナリオではどうしますか？」「今、一番必要なものは何ですか？」
スライドに映るさまざまな猫のように、見た目は違うけど、みんな猫です。外から見ると、あなたはロボットの相手とは違うように見えるかもしれませんが、実際には同じ目標や価値観をたくさん共有しているのです。そして、一緒に何かを作り始めるときには、この信頼関係が必要になってきます。次の原則で、その構築について話します。
But what is it really?
この原則は、私が愛情を込めて名付けたものですが、実際のところ、いくつかの問題を経験し、他の人々が問題に直面するのを見て、私はアーキテクチャの重要性をこの部屋で説教する必要はないだろうと思ったのです。しかし、特にデータスタックとSalesforceの統合を開始する場合、初期の段階で多くの選択肢があり、それはあまり重要ではないように思えるかもしれません。しかし、その選択を誤ると、将来的に大きな痛手を負うことになります。このような場合、もう一度、「最初に構築した方法は正しかったか」と問い直してみる価値があります。
まず最初に「Salesforceに取り込みたいデータがある」「このツールを使っている企業は素晴らしい」「Hexは素晴らしい」というような統合を開始したいと考えます。何人のユーザーがいて、現在のMRRをSalesforceに放り込んで、担当者がそれを非常に見やすい形で見ることができるようにしましょうか。その答えは簡単で、既に全ての企業のアカウントを持っているので、そこに投下すればいいのです。
しかし、それでは「何について話しているのか」という問いを飛び越えてしまうことになります。
この場合、私たちが見ているのは、私たちの製品のインスタンスからのデータなのです。たまたまその時点では、1つのインスタンスを持つ企業は1社だけでした。しかし、私たちが成長するにつれて、その状態が続くわけではありません。6～8ヵ月後には、採用チームと営業チームがそれぞれ別のものを導入するような状況にまでなっています。それをすべてアカウントレコードに押し込もうとすると、単純に流し込むだけでは、多くの問題が発生します。なぜなら、そのインスタンスやHexから得られる他のデータも知りたいからです。つまり、Salesforceがすでに持っている価値を使って、アーキテクチャを分解することができるのです。
Salesforceには、正直言ってそれほどひどくない”パンケーキミックス”があります。企業とは何か、人とは何か、という基本的な知識はすでに持っていますし、その他にもGTMのためのパーツがいくつかあります。また、親オブジェクトにロールインするサブオブジェクトをすばやく簡単に作成することができます。そのため、ErikaのHex Orgと呼ばれる別のオブジェクトを作成して、すべてのデータをすばやく同期させ、親からデータを引き出したり、子から親にロールアップしたりすることが簡単にできます。つまり、最終的な答えにたどり着くまでアカウントに、すべてのHex Orgをロールアップするフィールドを作るには、ボタンを7回クリックするだけでした。
営業担当者にとっては、欲しいデータを欲しい場所で盗むことができますが、そのデータの出所や真実は異なっているようです。私たちは、このようなケースにたくさん遭遇してきました。ですから、お互いに意見を交換することを恐れず、「このデータは本当は何なのか」という会話に飛び込んで、整合性を確認するようにしてください。そして、もし問題がたくさんあることに気づいたら、もう一度、自分自身に問いかけてみてください。
Salesforce doesn’t play well with others
3つ目は、Salesforceが他のツールとうまく連携できないことです。
Salesforceと連携しないツールがあるわけではなく、連携するツールはたくさんあります。しかし、Salesforceは、他のツールと連携した際のエラーレポートが非常にひどいことで有名です。また、Salesforceが望んでいないことを無理に実行させようとすると、あなたの人生は絶対に悲惨なものになるでしょう。
そこで、これらのことを考えるために、「3つのハッピーパス」を用意しました。私たちの場合、Fivetranのようなツールを使ってSalesforceからデータを引き出すこともできますし、CensusやHightouchのようなツールを使ってSalesforceにデータをプッシュすることも可能です。自分の幸せな道を歩んでいれば、それでうまくいくはずです。オフロードを走れないわけではありませんし、柔軟性もあります。
でも、もしオフロードを走っていて、段差にぶつかったら、それは自分でやったことです（なので自分で何とかしないといけない）。
最初のハッピーパスは、シンプルなもので、「更新のみのエンリッチメント」です。
この例では、すでにアカウントを持っていて、そのアカウントを企業という概念にマッピングしています。dbtのジョブが、この企業との関係や、顧客との関係会社、顧客の昨日までの解約を把握し、誰にも知られないようにするのは簡単です。データをフィールドに同期させるだけなので、レコードを作成したり、破棄したりする必要はありません。超ハッピーなパスです。フィールドのそれであれば、この操作を行ってもほとんどエラーは発生しません。一度テストすれば、かなりうまくいくはずです。
もうひとつのハッピーパスは、「フルオブジェクトコントロール」です。これは、私がRevOpsで、自分のシステムの一角を切り取って、そこを自分のものにする、というものです。例えば、Hexユーザー（Hexにログインしている人）たちのために、このようなことをしました。連絡先とは違いますが、複数のHexインスタンスにログインして、Hexユーザーとして見つけるためにカスタムオブジェクトを作って、そのツールやErikaのデータスタックを使って、新しいレコードを作ったり、削除が必要なら削除したり、更新して最新の状態に保つことが自由にできるようにしました。また、スタックで見ているものはすべてシステムで見ているものなので、すべての担当者がそのデータを見ることができ、そこでコンテキストを利用することも可能です。すべてのユースケースをこの2つに当てはめることができるとは言いませんが、時には他のことが必要になることもあるからです。
3つ目のハッピーパスは、おそらく多くの人がこれまで遭遇したことのないものです。それは、「ランディングテーブルを作成すること」です。この方法をデザインしたのは、私の手柄ではありません。私はこの方法をCalendlyとの統合で初めて目にしました。そして、これはすごい、どこでも使ってみようと思いました。
エラーの多くは、このUPSERT処理に起因しており、これによって、誰もがおかしくなってしまいます。そこで、UPSERTはやめましょう。
代わりに、RevOps担当者とデータ担当者だけが見ることのできるカスタムオブジェクトを作成し、それをイベントストリームのように扱います。この場合、新しい HexOrgが登録されたので、その HexOrgをピックアップして、すでに話をしている会社のどれかと一致するかどうかを調べ、一致する場合はそのようにマージさせ、一致しない場合は新しいものを作ってそこに住まわせるという使い方が考えられます。そのためには、システムでやらなければならないことがたくさんあります。
でも、それを全部統合して解決しようとすると、たぶんたくさんのエラーが出るでしょう。例えばErikaが「新しいHexOrgができました。これがそのデータです。」と言ってきた場合、他の誰もこれを見ることはありません。しかし、作成されたレコードを受け取るフローや自動化を構築し、Salesforceのエコシステムの中で奇妙な操作や変換を行い、レコードを必要な場所に移動して、すべてを最新に保つことができます。エラーが発生した場合は、どこが悪かったのかが完全に分かるので、別のレコードを複製してフロー全体を再始動させることも非常に簡単です。このことは、RevOpsチームがすべての操作を正しく行えることを信頼しているようなものでもあります。そしてそれは、もしかしたら不快なことかもしれません。
しかし、私はこうも言います。信頼することはできますが、検証する力も必要です。
Erikaは私にすべての材料を渡し、私は正しいセットアップを行う必要があります。でも、Erikaは素敵なテストを用意してくれていて、「あなたが作った絵は、私が期待したとおりの絵になったでしょうか」と聞いてくれます。それがうまくいかなかった場合は、素敵なアラートが表示されます。
これは、彼女が威張ったりしているわけではなく、とても役に立っているのです。このおかげで、テストを活用することができます。残念ながら、Salesforceの内部でテストを行うことは非常に困難です。そこで、余分なデータを提供することで、私の仕事を助けてくれるのです。
Keep the Goal the Goal
Salesforcelandiaの最後の原則は、私の大好きなDan Johnというストレングスコーチの言葉からそのまま引用したものです。このようなものを作っているとき、Seanと私はよくぶつかると言いますが、このような場合、私たちは簡単に衝突してしまい、自分たちの機能領域のために戦い、一日の終わりに何をしようとしているのかを忘れてしまうというパターンに陥ってしまいます。
あなたはビジネスの問題を解決しようとし、ビジネスをより良いものにしようとしているはずです。そして、理想的には、他のビジネス部門にとって最も重要な問題に取り組んでいるのです。データチームとしては、それが何であるかを知る必要があり、彼らにとって何が重要かを知る必要があります。そして、あなたが支援しようとしている機能部門を本当に苦しめているのは何なのかを知る必要があります。Salesforcelandiaは、リーダーが意思決定をするために必要なデータを持っていたり、担当者が必要なものを見つけるために必要なデータを手元に置いていたりする、素晴らしい場所なのです。
そして、私にとって重要なのは、データウェアハウスが依然として（データの）真実の源であるということです。顧客とは何か、顧客は誰か、売上はどのくらいか、などを定義する場所はひとつしかありません。しかし、このデータを必要とする弊社の社員は、Salesforceでもこのデータにアクセスすることができます。また、よりリッチなインサイトにアクセスすることも可能です。例えば、Salesforceのアカウントから360Hexアプリにリンクさせることができます。そして、SalesforceのアカウントからHexの入力パラメータを使ってリンクをたどると、そのアカウントにたどり着けるのです。営業担当者からは、この機能がいかに貴重であるかということをいつも聞かされています。
Seanと私は、2週間に1度、GTMメトリックレビューを開催し、Salesforcelandiaのエコシステムからのデータを使って、GTMのためのさまざまな機能の進捗をHexアプリに出力しています。そうすることで、自分たちの状況を確認し、必要なときに軌道修正することができるのです。
まとめ
あなたのSalesforcelandiaは、私たちのものとは全く違うかもしれません。しかし、これらの原則に従えば、いいところに行き着くはずです。
だから覚えておいてください、あなたたちは思っている以上に似ているのです。そして、後で忘れた頃にまた思い出してください。もう一度思い出してください。Salesforceは他人とうまくやれないが、自分のために変わることもないということを本当によく考えて、あなたが取り組んでいるその共通の目標に集中することです。
私たちの旅を締めくくるに当たり、私たちがたどり着いた責任の所在を個別にお伝えします。
このリストは、当講演を通してお聞きになったと思います。あなたの場合は、このリストとは少し違って見えるかもしれませんね。
Seanがやってくれることで、私が特に気に入っているのは、Salesforceでのエンティティ作成管理です。彼らはそれを知っているのかどうか、私にはわかりません。でも、彼らはそれを望んでいるので、私たちが代わりにやってあげます。信頼関係を築くには良いことですよね。
Seanは、現場の営業チームとSalesforceから正確なデータを取得するよう心がけています。また、彼が話していた自動化やフローは、私の担当でなくて本当によかったです。
データ面では、Erikaを使うことで、他の方法ではアクセスできないような指標を明らかにすることができます。これまで、製品データをCRMに取り込むために多くの会社と戦ってきましたが、その戦いに勝つことはあまりありませんでした。しかし、Hexではそれが可能です。これは素晴らしいことです。私たち2人は、これをさらに発展させることに大きな期待を寄せています。Erikaの存在なくして、この成功はあり得ませんでした。
私はデータチームにも目を向けていて、データの変換や、データ源としてのデータウェアハウスの保守を手伝ってもらっています。Salesforceでできることよりも、データウェアハウスでできることの方がはるかに多いからです。繰り返しになりますが、私はあまり参考にはしていません。でも、スタックが得意なことにはスタックを使おうという感じです。エンティティの作成にも、エンティティの更新にも、絶対に役立ちます。
また、私が最も気に入っていることのひとつは、テストがきちんと実行され、物事が横道にそれたときに教えてくれるという安心感です。この場で言うのも変ですが、このようなことは海外ではあまり言う機会がありませんから。
インターフェースデザインを一緒に決めていきます。時には、同僚というより家族のような、ちょっとしたドラマもありながら。マスターレコードの設計の正確さを保証し、ランディングテーブルを維持します。Seanは、これらのエンティティについて、本当によく考えていると言っていました。そして、私たちが見ているものに誰もが自信を持てるように、私たちの測定基準に対するビジネスの信頼を維持するのです。そして、私たちのステージにいる他の企業よりも、私たちの方が優れた測定基準の成熟度を持っているということを、常に耳にすることになります。それは、私たちのリーダーシップ、取締役会、そして最前線の営業チームからも聞こえてきます。
私たちは、あなたが心からあなたとSalesforcelandiaの旅を楽しんだことを願っています。
おわりに
Salesforceの良い点と悪い点をしっかり把握しつつ、そこをデータ基盤側で補う考え方は私も賛同するところです。
ただ、セッション自体、どちらかというと内面的・心構え的な内容が多く、もっと具体的な技術内容（アーキテクチャなど）が知りたかったところです。
4
