はじめに
普段は分析基盤／データ活用のクライアントワークに従事している私ですが、2023年11月～2024年2月にかけて、自社のマーケティング本部のデータ整備の支援をしました。
当時の責任者であるブライアンさんが入社後に、ツール選定を含め土台を整備してきていましたが（非常によくできていて私もとても勉強になりました）、手が回っていないところも多く、その部分を補完するような動きをしていました。
以前、「1年前の自分が読みたかった、データエンジニアリング入門」という記事で分析基盤の構築に関しては入門記事をまとめましたが、業務システムが関わる領域では違う考え方をすることも多くあります。
そこで、本記事では弊社株式会社primeNumber（pN）での業務システム／運用設計を事例に、Opsの領域におけるポイントをまとめてみようと思います。なお、3か月の取り組みのなかで整理してきた知見に限られているので、異論などあればどしどしご指摘ください！
こんな方におすすめ
- マーケティングやセールスの領域でデータ活用をしていきたいが、どういう形が望ましいのかイメージがわかない
- これまで分析基盤には関わってきたが、業務領域での知見がなくどう関わっていけばいいかがわからない
- MA／SFAがどういう役割のツールなのかを知りたい
記事タイトルは大きく出てしまいましたが（笑）、下記の通りいくつか制約があることはご認識ください。
- 当時の取り組みでの整理をベースにしているため、最新の情報というわけではありません。
- The Model型のプロセスを前提としています。ただし、このプロセスを取っていない組織にも参考になる部分はあるかと思います。
- Marketo／Salesforceを利用しているので、別のMA／SFAを利用している場合は別の方法を考える必要があるかもしれません。（特にネイティブ連携がない場合）
- マルチプロダクトの場合にどのような設計をするべきかは当時はまだ直面しておらず、これから挑戦していく課題になっています。
- 当時では新規リードの量＞＞既存リードの量であったためリサイクルの観点はまだ優先度が高くなく、これもこれから取り組んでいくべき課題になっています。
- 私の知見のある領域的にMOpsにやや寄った内容になっています。
むしろこの辺りに知見のある方、ぜひ勉強させてください！
MOps／SalesOpsとは？
はじめに、言葉の定義から確認しましょう。MOpsとは、Marketing Operationsの略称で、その内容を体系的にまとめている『マーケティングオペレーション（MOps）の教科書』では、「マーケティング組織のデータやシステムの活用を推進するために、マーケティング活用の管理体制やプロセスの構築、そしてその運用を行う役割」とされており、具体的な業務として下記が挙げられています。
- 自社に最適なマーケティングテクノロジーの選定・導入・管理・運用
- プロセスの策定とベストプラクティスの集約
- データマネジメントと分析
- マーケティングチームのテクノロジー教育
つまり、テクノロジーとオペレーションとデータの3つをフル活用しながら、業務側でITの力を最大限に発揮させていくための役割になっています。
SalesOps（Sales Operations）も同じようなもので、他にも最近ではBizOps（Business Operations）やCSOps（Customer Support／Success Operations）などの言葉も出てきていますが、いずれにせよ業務側でITとドメインの橋渡しを行います。
The Modelの基本とpNでの運用
次に、運用の前提となるThe Modelの基本と、pNでの運用について確認しておきます。
The Modelの基本
The Modelとは、マーケティング（マーケ）、インサイドセールス（IS）、フィールドセールス（FS）、カスタマーサクセス（CS）が顧客のフェーズに応じて対応をしていく共業プロセスのことで、下図のようにプロセスを分けながら営業プロセスをコントロールしていきます。
（出典：The Model（ザ・モデル）とは？用語と営業プロセスをSalesforceが解説）
全然聞いたことがなかった、またはちゃんと理解ができているのか怪しいという方は、このモデルのバイブルと言ってもいいであろう、『THE MODEL』を一読しておくことをおすすめします。
The ModelのpNでの運用
言葉の定義は個社で差異があると思いますが、pNではThe Modelを下記のように運用しています。
- マーケ：マーケティング施策でリードを獲得し、属性情報をもとにMAL（Marketing Accepted Lead）を判別しつつ、マーケティング施策に対する行動でMQL（Marketing Qualified Lead）を創出する
- IS：MQLを中心にマーケの創出したリードにアプローチし、商談に移行したいリードをSAL（Sales Accepted Lead）としてFSに引き渡す
- FS：ISから引き継いだ商談で商談を継続するかを見極め、SQL（Sales Qualified Lead）として契約／失注まで対応を続ける
MAL、MQL、SAL、SQLをどう定義しているのかの詳細は伏せますが、この定義は組織や市場環境、営業戦略によって変わってくるので、どのように設定するかあるいはどう変更していくかが重要になってきそうですね。
また、このプロセスに関連するのがシステムの位置づけで、マーケが担う1：NのアプローチがMAの対象とする領域で、営業が担う1：1のアプローチがSFAの対象とする領域となります。
業務システムの勘所
前段が長くなってきましたが、非常に重要になってくる業務システムの勘所について触れさせてください。
Salesforceと標準オブジェクト
Salesforce出身で弊社のSalesforce管理をしてきた新井さんが書いた記事「Salesforceの標準オブジェクトにこだわりながら、SaaSビジネスで活用する方法とメリット」に、大事な点が詰まっています。
まずこれに尽きるというのが、以下の記載です。
現行業務と標準オブジェクトが持つ機能の適合性を把握した上で、できる限り標準オブジェクトに寄せた運用の実現性を追求していくことが、システム管理者の腕の見せ所で、まさに標準オブジェクトへのこだわりと言えます。
そしてなぜこれが重要なのかについては、下記の通りです。
- Salesforceの年3回のバージョンアップの恩恵を最大限受けられる
- 画面上の機能やオブジェクト間のデータの整合性を保つ機能などが最初から備わっており、余計な設定や実装が不要で結果として運用上のコスト削減につながる
- 業務の拡張や変更があっても、標準機能で用意されている設定変更で対応できる可能性があり、拡張性が高い
これを実現するために、システムの設計思想を理解して、ときには運用の側を制限しつつシステムとの最適化を図っていくというのが重要になってくるのです。
Salesforceの基本的な流れ
少し具体の話をすると、Salesforceでは以下のような流れが標準として想定されています（見積や契約については略）。
- キャンペーンでリードを獲得することで、リード（見込顧客全体の1人）およびキャンペーンメンバー（特定のキャンペーンで獲得したリードの1人）になる
- キャンペーンでの行動をもとにISがアプローチし、リードのステータスを取引開始済に変更する
- リードの情報を取引先（Account）と取引先責任者（Contact）に移管する
- 商談（Opportunity）を作成し、主キャンペーンソースを設定する
上記の流れに乗ることで、以下のようなデータ連携が自動で実施されます。
- リードの各種情報が取引先／取引先責任者に連携される
- 商談には起点になったリードやキャンペーンと商談の関係が自動設定される
- キャンペーンインフルエンスを有効化している場合は、商談に対して複数のキャンペーンがどのように寄与しているかのアトリビューションを計測することができる
逆に言うと、標準の流れに乗らないとデータ連携が自動化されません。
- 個別にリードを作成し、キャンペーンメンバーに追加せずに商談化させる
- 運用プロセスが標準化されていないと、紹介系でありがち
- きっかけになったリードと別のリードから商談化
- エンタープライズ案件や、フリープラン起点ではあり得る話
- 取引先責任者のいない商談
- ステークホルダーが多すぎるときに、誰を入れるのが適切かわからないなど
これらは運用プロセスの標準化でできることもあれば、ある程度発生してしまうものでもあります。
余談）なぜリード→取引先＋取引先責任者という移行をするのか？
過去の私もそうでしたが、「リードの情報を取引先（Account）と取引先責任者（Contact）に移管する」という仕様が、初めて聞く人にはピンとこないかもしれません。ここはおそらくですが、前提としている市場環境と分業の考えが根底にあると思われます。
Salesforceが起点としてきたアメリカの市場では、リードのリストは購入することができます。そうすると、数万人以上の単位でリードのデータを手に入れることができます。すると当然リードの数＞＞取引先責任者の数という形になってきます。
もともとがジョブ型雇用だからというのもありますし、これだけの数量差があると、MAでアプローチする対象とSFAでアプローチする対象は明確に切り分けざるを得ず、商談化前後というタイミングでその切り分けがなされることになります。
加えて、リードのデータは必ずしも綺麗ではないというのがあります。複数のソースから取得しており、時には手入力のものも含まれるリードには、名称の揺れや不十分なフィールドなど、データ品質に課題があります。
そこで、リード→取引先＋取引先責任者の段階でデータの移行を入れ、この際に重複レコードのマージや不足情報の付加を行うように位置付けることで、SFAとしてセールスがアプローチするデータの品質を担保していると考えられます。
日本という市場特性を考えてみると、リードの購入ができないという制約から数的な側面は別な話になりますが、セールスがアプローチするデータの品質を担保するという側面では同様の意義を持つでしょう。
pNのデータ連携の流れ
ではここから、データ連携の流れを紹介していきます。
用語の整理
本題に入る前に、下記の点を抑えておいてください。
- Marketoの「プログラム」＝Salesforceの「キャンペーン」
- Marketoにも「キャンペーン」はという用語は存在するが、プログラムの配下に位置づけられる
- MarketoやSalesforceの「オブジェクト」＝DBにおける「テーブル」
- うち、デフォルトであるものが標準オブジェクト、カスタムで作るものがカスタムオブジェクト
- MarketoやSalesforceの「フィールド」＝DBにおける「カラム」
- 余談ですが、HubSpotではプロパティと呼ぶらしい
- Salesforceでは、カスタムオブジェクト／カスタムフィールドでは末尾に"__c"が付与される
データ連携の全体像
データ連携の全体像は下図の通りです。こちらの図を見ながら説明を読んでいただけると、どのようなことをやっているのかより理解しやすいかと思います。
Marketoの役割
データ連携のフローにおいて、Marketoは下記の役割を担っています。
- リードデータの取込
- セミナー／イベント管理
- メール配信
- アクティビティトラッキング
- SFAとのデータ連携
それぞれについて、以下で詳しく見ていきます。
①リードデータの取込
リードデータの取込としては、大きく分けて3つの経路があります。
- フォームによる取込
- リストからのデータ取込
- 名刺からの個別入力
データ基盤の考え方と同様に、MOps／SalesOpsにおいてもGarbage in, Garbage outで、取込データの品質が最も重要です。pNではリード獲得においてセミナーの割合が高く、またその運用をMarketoフォームに寄せることで、入力データの品質を担保しています。
- フォームによる取込：Marketoフォームを利用
- 自社LPセミナー／イベント、製品資料、ホワイトペーパー、フリープラン、問合せ
- リストからのデータ取込
- 他社LPセミナー、リード広告（送客ではなくリスト納品型の広告）
- 名刺からの個別入力
- イベント／展示会
フォームによる取込
Marketoのフォームを利用する際には、画面上に表示される「ラベル」に対して、Marketoのどの「フィールド」を対応させるかを設定することでデータを連携します。入力データのバリデーションもかけられるため、フィールドの設定と合わせて利用することでデータの品質を担保します。
このとき、非表示項目をどのように活用するかもデータを効果的に活用するときのポイントです。メール配信や広告のURLにUTMパラメータを付与した上で、フォームの取得項目としてUTMパラメータを入れておくと、フォームまでの流入経路についての情報を連携できます。
下記のURLを例にすると、
https://blog.trocco.io/seminar/trocco_practice-etl?utm_source=dm&utm_medium=email&utm_campaign=seminar__trocco__practice-etl__20240126&mkt_tok=NjUyLUlCRS05MDUAAAGQTk3DndfOfnUk-tpS4QEKMXF1JTSeHQmPHP8ygGK9di_nbhQvQYKIZzWjCzP7zN5NQTeHO2wLqT9WqTvYQsO3p-tA_gZQh21DjbIV-A5z
- utm_source: dm
- utm_medium: email
- utm_campaign: seminar__trocco__practice-etl__20240126
のデータが取得できることになります。
また、pNではサイトトラフィックの計測のためにtrocco®のWeb行動ログ収集SDKを利用していますが、このログにおけるIDも取得することで、MA／SFA上の行動とログデータとの紐づけができるようにしています。
これは方向は逆にはなりますが、ECサイトなどで注文IDをGoogle Analyticsに吐き出して紐づけするのと同様の考え方になっています。
そのほか、入力データの標準化のためにイチサンフォームを利用していますが、こちらについては後述します。
リストからのデータ取込
リストからのデータ取込については、取込対象のファイルを選択し、ヘッダーに対してどのフィールドを対応させるかの設定をすることで取込を行います。
（出典：人物のリストのインポート）
名刺からの個別入力
名刺からの個別入力については、名刺をAdobe Scanで読み取り、Google Formでデータを入力した上で、Spreadsheetを利用して上記同様にリストからのデータ取込を行っています。
現時点では数が多くないため課題ではありませんが、量が多くなってくるとSansanはデータ化に便利という話を聞きます。
②セミナー／イベント管理
セミナーはイベント管理サービスとAPI連携することで管理しています。
Zoom
小規模イベントの運用はZoomを利用しています。API連携により申込者へのURL自動通知や参加者管理、ステータス管理を行っています。また参加者向けアンケートもMarketoフォームを利用することで、データをMarketoに一元化しています。
EventHub
大規模オンラインイベントの運用はEventHubを利用しています。こちらも参加者管理を一元化でき、アンケートをMarketoフォームで行っていました。
API連携で視聴ログをMarketo Activityに連携することも可能ですが、少し癖があるということは過去の記事（「Marketoに連携された癖が強すぎるEventHub視聴ログをBigQueryで整理する」）にまとめていますので、参考までに。
③メール配信
MAというとマーケティングメールを送ることというイメージを持っている方も多いと思いますが、実際多くの目的でメール配信を行っています。
- 運用上必要なメール
- 申込完了通知、問合せ受付通知
- イベント集客メール
- ハウスリスト向けイベント告知
- イベントフォローメール
- アンケート御礼、アンケートリマインダ、コンテンツ紹介
- ナーチャリングメール
- コンテンツ紹介
なお、メールの配信には配信対象を動的に設定するスマートリストや、イベント駆動／バッチフロー処理なども可能です。この辺りのノウハウはなかなか検索しても出てこなかったのですが、「Marketo Tips Hour #11 _改めて知りたいスマートリスト、スマートキャンペーン」が大変参考になったので紹介しておきます。
④アクティビティトラッキング
Marketoを触り始めてめちゃくちゃ便利だと思ったのが、このアクティビティトラッキングの機能です。サイトトラッキングツールと比べると対象がリードのみに限定されますが、特定のアクションに対してSlack通知をするなどが非常に簡単に設定できます。
これによって、フォームで申込があった際の申込情報をSlackに飛ばすことで申込後の対応を行うようにしていたり、メール配信後のリンクのクリック状況を見ながらISからコールをしたりといったイベント駆動での対応を円滑に行うことができます。
これはWebhookの投稿条件を設定して、そのWebhookをイベントトリガーのフローで呼び出すことで実現できます。
⑤SFAとのデータ連携
Marketo＆Salesforceの一緒に使うメリットとして、ネイティブ連携が充実しているというのがあります。5分ごとに連携が行われ、
- リード、コンタクト、プログラム（キャンペーン）：双方向
- アカウント、ユーザ、商談＋カスタムオブジェクト：Salesforce→Marketo
の流れでデータが同期されます。
（出典：Salesforce 同期について）
なお余談ですが、Contact（取引先責任者）が自動翻訳で「連絡先」と表示されていることがしばしばあるので、公式ドキュメントを確認の際にはご注意ください。
通常の連携
デフォルトのSalesforceフィールドは勝手にマッピングされ、連携対象はSalesforceで設定することができます。
（出典：デフォルトの Salesforce フィールドマッピング）
一方、カスタムフィールドはSalesforce側でフィールドを作成し、同期の設定をすることで同期可能です。Salesforceのリード／取引先・取引先責任者のAPI名（表示名ではなくシステム用の名称）を同一にすると、両方に同期することができます。というかこうしないと非常に面倒なのでご注意ください。
下記のようにすると、MarketoのJobRole__cがSalesforceのリード／取引先責任者のJobRole__cにマッピングされます。
キャンペーンメンバーへの書き込み
こちらは別途記事にしようと思いますので、この場では簡単に記載します。特定のマーケティング施策への参加者の情報を保持するキャンペーンメンバーのデータの書き込み方法として、2つの方法を使い分けています。
キャンペーンメンバーに直接書き込む
Marketoにはプログラムメンバーカスタムフィールド（PMCF）というMarketoのプログラムメンバー→Salesforceのキャンペーンメンバー同期用のフィールドがあり、ここにマッピングすることでキャンペーンメンバーに直接書き込みができます。
対象としては、アンケート回答日時、アンケート回答内容、セミナー満足度、セミナーに関する質問や要望など、当時情報としてキャンペーンメンバーのみに保持しておきたいものをこちらで処理します。
リード／取引先責任者に連携し、Salesforceでキャンペーンメンバーに書き戻す
上記とは別の方法として、いったんリード／取引先責任者に連携したあと、Salesforce側でキャンペーンメンバーに書き戻すこともできます。
PMCFは20個しか利用できないため別で処理したい、または属性情報系などキャンペーンメンバーだけでなくリード／取引先責任者にもストックしたい場合は、こちらの方法で処理します。
アクティビティの同期
イベントドリブンの対応のために出てきたアクティビティですが、このデータをSalesforceに連携することもできます。これにより、MA側で実施／計測した活動情報をSalesforceで確認することができるようになります。
※注意点
ネイティブ連携機能はリッチですが、いくつか注意点もあります。
- 一意性とマージの取扱い
- 「MarketoとSalesforce連携について～リード（責任者）の新規作成～」、「ヘルプにないMarketo＆Salesforce連携の仕様」の記事が非常によくまとまっていたので、ご参考までに。
- Marketoの一意キーは通常はメールアドレスですが、Salesforce連携するとSalesforce IDになります。これに関連するハマりどころは整理し切れていないです・・・（参考：重複した人物の検索と結合）
- 手順を間違えるとマッピングが上手くいかずに要Marketoサポート案件になるようなので、ご注意ください。
- Salesforceの受入条件は姓＋企業名ですが、Marketoの企業名のデフォルトを[unknown]にするとNullのときに[unknown]でSalesforceに連携されてしまいます。
- Salesforceで固定選択式にしているフィールドに対して、Marketoでリスト外の値を入力すると同期エラーになります。
trocco®でバッチ連携する
ここまでMarketo／Salesforce間のデータ連携について説明してきましたが、さらに別システムとの連携にあたりtrocco®によるバッチ処理も利用しています。用途としては、キャンペーン情報のSpreadsheet→Salesforce連携であったり、trocco®ユーザーのサービス利用状況としてサービスDB→Salesforceの連携になります。ここでは、前者について解説します。
マーケやセールスといったビジネスユーザーの業務インターフェースとしては、Spreadsheetを利用することは多いでしょう。pNのマーケでも正にそうで、実施日やLPのURL、予算や費用といったイベントやセミナーの管理をSpreadsheetで行っています。
このデータに対して、転送元Spreadsheet→転送先Salesforceでデータ転送を行うことで、Salesforceのキャンペーンデータの更新をかけています。
転送先Salesforceでは、オブジェクトの一意キーをベースにAPI名でフィールドを指定すると、レコードの更新を行うことができます。例えば、ID: 1, name: hogeのデータに対して、ID: 1, name: fugaのデータで更新をかけてあげると、内部のデータが後者に更新されます。
管理表の列にSalesforceのCampaignのIDを追加しておくことで、Campaignオブジェクトに対してIDベースで更新をかけて、SpreadsheetのデータをSalesforceに同期しているのです。
pNのデータ連携の流れまとめ
ここまで大枠の流れを整理してきましたが、その内容をまとめておきます。
- 基本としてはAPIベースのネイティブ連携を活用する
- 運用がシンプルになる
- 即時性が担保される
- ただし、連携仕様に由来するハマりどころに注意が必要
- ネイティブ連携で不十分なものを、trocco®によるバッチ連携で補完する
- MAを1:Nの施策実施のプラットフォームとして位置づけ、データで運用を簡素化するとともに、計測／通知／連携基盤とする
- SFAはMAのデータを流しこみ、1:Nでのアプローチ状況を踏まえながら1:1の対応時の文脈／タイミングを掴めるようにする
- MA／SFA／Spreadsheet／Slackなどの業務上のインターフェースをシンプルにし、利用者の認知負荷を下げる
なお、Salesforce側の詳しい設計についてはそもそも私に管理権限がないのでよくわからないので個社の事業によって差異が大きいと思うので、省略させていただきます。Salesforceでのデータ処理フロー一般については、「Salesforce標準機能マスターガイド」が良くまとまっていました。
汚れるデータにいかに対処するか
円滑な施策には高品質なデータが望ましく、その基本は入口のデータをいかにきれいにするかというのは前述した通りですが、それでもデータは汚れてしまいます。
- メールアドレスをご記入する
- 同一人物が企業アドレスとフリーアドレスを使い分ける
- 申込と違うメールアドレスでZoomセミナーに登録する／アンケート回答する
- 申込者が別の人に配信URLを共有する
- 企業名の前株／後株、日本語／英語
- スペースの有無
- 半角／全角
個人の情報としてはこれらを綺麗にするのは難しく、フォームのバリデーションで一定の品質を担保する前提で、ある程度は手動でレコードをマージするしか方法はないのではというのが現段階の見解です。
とはいえ、組織情報の方はどうにかしようがあり、その方法がここからの話です。
取引先情報の仕様の再確認
前述した通り、Salesforceではリード→取引先／取引先責任者にデータを移行するという
仕様があり、これは品質を問わない大量のリードデータと一定の品質を担保した商談相手のデータを分けるためという話をしました。
この仕様に由来して、1つ面倒なところがあります。それは、流入したリードには取引先情報がないので、「新規リードだけれども取引先単位では商談化している」というのがわからないということです。この対応のためには、3つ対応方法があります。
リードを使わない
リードを使わずに、全リードを取引先と取引先責任者に転換します。そもそもデータの移行はリードが膨大に獲得できる米国の市場環境を前提としたものなので、獲得できるリードの数に制約がある日本では、こちらの方法も選択肢になります。
なお、標準オブジェクトに期待されるデータ連携ができなくなるのでそういった設計を自前でやる必要があるのと、転換時にクレンジングをかけることになると思うので、そのコストを負担する必要はあります。
MQLの段階で取引開始済にする
ISが個別アプローチをかける段階で判別ができるようになるため、クレンジングのコストとバランスを取った際にこちらも選択肢になるでしょう。少し前の記事ですが、SmartHRがこの方法を取っているそうです。（参考：『Salesforceのデータの重複は、誤った架電にも繋がってしまう悩ましい問題だった』 株式会社SmartHR様 ”mergency”導入事例インタビュー）
この方法では、ISアプローチ前のクレンジングになるので、クレンジングにあたって十分なデータが存在するのかという点は気がかりです。
リードデータ取得時に法人番号で揺らさない
こちらは運用はそのまま、データの品質を向上させることで組織情報を標準化する方法です。pNではこちらの方法で対応をしています。
法人番号とは？
法人番号は法人を識別するための一意IDです。このIDがあればマスタ管理できるようになるので、入力されるデータは揺れないようになります。また、リードと取引先／取引先責任者の間に一本軸を通すこともできるようになります。
pNではこれまでFORCASを利用して、データ取込後の名称ベースで名寄せ（企業名称の入力揺れの補正）を行っていましたが、法人番号があればその精度はさらに向上することになります。
また、名称の揺れの補正だけでなく、FORCASを利用すると企業セグメント（規模や売上高等）が付与できるので、企業セグメントに応じたマーケティング／営業戦略の立案／実行にも役立つことになります。
ということで、現在はイチサンフォームを利用してデータの入力段階で法人番号を付与してデータを標準化し、かつデータ取込後にFORCASで名寄せするという2段階で企業情報の品質を向上させています。
（※余談ですが、法人名称変更／事業譲渡／法人統合／法人新設や、法人情報のマスタ情報の更新をどのタイミングでどう処理すべきかは考慮が必要そうだけど・・・と思っています。親子関係の取扱いもこれからの課題ですね。）
イチサンフォームによる法人番号付与
フォーム入力時にサジェストを表示させ、そこから選択することでデータを標準化するための超絶便利ツールがイチサンフォームです。これをMarketoフォームに連携させ、法人番号のフィールドを非表示項目として設定することで、フォームでの申込情報に法人番号を付与しています。
（出典：第2弾「イチサン」フォームα版無償公開！すべてのフォームで法人番号を当たり前に。（インボイス番号対応））
なお、利用環境によってはJavaScriptが動かなかったり、サジェストが出ても無視して入力することもできたりしてしまうため、入力率は高いとは言えないのにはご注意ください。とはいえそれでもデータの品質は向上するので、大変助かっています。
HubSpotでの同様の運用については、「ドメインではなく、法人番号を活用したHubSpotでの顧客管理の手法」が良くまとまっていたので参考までに。
定期的にクレンジングする
自動運用は上記の形にするとして、やはり一定のクレンジングは不可避です。1つ重要なのはリード→取引先／取引先責任者の移行時で、基本的にはここでISがコールしていると思うので、その情報とSalesforceでのサジェストをもとにレコードのマージやフィールドの更新を行います。
そのほか、重複が疑われるレコードがないかは、定期的にチェックしてマージするような運用にしておくとよいでしょう。
Salesforceデータを抽出して分析する
ここからはSFAデータを分析するにあたっての、秩序の保ち方についてお話しします。なお、MA／SFAにビルトインされた分析機能をどう使うかという観点もあるのですが、pNでは各種データを統合しながら使っているのもあり、DWHに吐き出しての分析が中心になっていることはご留意ください。
魔境化するMA／SFA
MA／SFAが魔境になっているというのは非常によく聞く話です。pNでもオブジェクトの設計は統制されており非常に綺麗になっていますが、フィールドの設計についてはそうも言えないところがあります。やはり一定の魔境になるのは不可避なのかもしれません。
その背景として、下記のようなことが考えられます。
- システムの設計思想を理解して、ときには運用の側を制限しつつシステムとの最適化を図っていくというのが重要でありつつ、1週目の人がこれをやりきるのは不可能に近い
- 業務システムである以上、業務部門が管理者を行うことも多く、その際にエンジニアほどIT知識が十分ではないことが多い
- 業務の変更に伴ってシステムの設計／運用が変わっていくため、秩序立った環境を維持し続けることがそもそも非常に難しい
- カスタマイズ性が非常に高いため、無理やりな運用を実現しようとしたときにそれができてしまう
この結果として、次のようなことが発生します。
- フィールドが無限にある
- 突然のfield3__c
- API名と論理名が対応しない
- 標準フィールドにhogeがあるのにhoge__cがある
- 論理名に「（利用しない）」とついている
- createdateなのにtimestamp（Salesforceの標準仕様）
- データ自体がカオスなので、データ加工もカオスになる
魔境化の予防策
以下が魔境化の予防策になります。
①不要に複雑にしない
再度の掲載ですが、「システムの設計思想を理解して、ときには運用の側を制限しつつシステムとの最適化を図っていく」ということで、本当にそれいる？というところから始めるのが出発点です。不要な複雑性の組み込みはやめましょう。
なおどれが不要なのかはどう判断するの？というご質問については、ノーコメントでお願いします。
②命名／型設定を適切に行う
API名、オブジェクト／フィールド名を適切に命名してください。API名はUI上見えないからと適当につけると、データ連携や分析に利用しようとしたときに担当者が号泣します。また、データ型や制約も適切につけておかないと、変な値が混入して統制が取れなくなるので、こちらも合わせて対応しましょう。
③使わなくなったオブジェクト／フィールドを削除する
Salesforceでは、フィールドをUI上から非表示にする機能があります。そうすると、DB的には無限のフィールドがあるものの、それが業務ユーザーには見えていないので見かけ上問題ないというようなことが起こります。とはいえ、こういった負債は少しずつ蓄積していって、気付いたら手に負えないような形になってくるもの。
本当に削除していいのかの確認が面倒な気持ちは大変よくわかりますが、使わなくなったオブジェクト／フィールドは強い意志を持って削除することで裏側の治安を守りましょう。
分析用のデータを整備する
ここまで秩序の保ち方について記載してきましたが、これらのことを徹底しようとしてもある程度の無秩序は残ってしまうかと思います。そこで、分析利用にあたってのポイントになりそうなことを下記にまとめておきます。
- 転送するオブジェクトは必要最小限のものに留め、ニーズが発生してから追加を行う
- 全部転送しようとすると数百オブジェクトあり、探すのが大変になるので・・・
- レイク層は全量を保持し、その後にクレンジングをかけたステージング層を入れる
- 不適切な命名を修正する
- 不要なフィールドを落とす
- 論理削除レコードを除外する
- 必要に応じて命名規則を変換する（キャメルケースCampaignMember→スネークケースcampaign_memberなど）
このあたりの前処理を個々人でやろうとすると時間がかかるのはもちろん、処理方法が属人化して数値が一致しないことになるので、統一管理する方が良さそうです。
BtoBビジネスにおけるMOps／SalesOpsとデータマネジメントの要点
ここまでの内容を踏まえてみると、分析基盤におけるデータマネジメントとは違う側面が見えてきます。
- 業務システムの設計思想を理解して、ときには運用の側を制限しつつシステムとの最適化を図っていく
- 業務ユーザーの業務インターフェースを考慮した上で、データの追加連携によりシステムの限界を補完しオペレーションを滑らかにする
- 業務の最適化を目的とした基盤整備でデータはある程度整うので、その上で分析目的に活用したいデータを追加し戦略設計につなげる
データ基盤それ自体の整備ももちろんですが、業務ユーザーが利用する業務システムのポテンシャルを最大限に引き出すように、システムの観点から整備していくというのが大事です。
さいごに
支援期間中にお手伝いいただいたpNのマーケ／セールスのみなさん、そして事例発表から勉強させていただいたMOps Study参加者のみなさん、その他記事など参考にさせていただいたみなさん、ありがとうございました＆これからもよろしくお願いします！
そして、このように全力でデータを使い込んでいる環境で、我こそはさらにデータをゴリゴリ使っていきたいぜという方、We are Hiring！ですので、ぜひご応募ください！