この記事はymzk(*1)が前職（2012年～2017年）でやっていた仕事についてまとめたものです。

営業担当者がBCCで取引先にメールを一斉送信するのを「メルマガ」と呼んでいた状態からスタートし、顧客情報の統合⇒メルマガツールの導入⇒Salesforceの導入⇒Pardotの導入　までを実務担当者（手を動かす人）として体験してきた、とても地味な記録です。
いずれかのフェーズにいる方、もしくは検討中の方の参考になれば幸いです。申し訳ないのですが、英語の勉強方法に関する情報はほぼありませんので、TOEIC800点取りたい方は他の人のnoteを読んでください。

入社時の状況と社内的立場の考察

学部卒の新卒で入社しました。当時の社員数は25人程度、いわゆるITベンチャーと呼ばれるくくりの会社です。（創業から10数年たっていたのでベンチャーと呼んでいいかは微妙かもしれない）

メインのプロダクトが3つあり、それぞれにプロダクトマネージャー・セールス・エンジニア・デザイナーが配置されているという縦割りの組織でした。
社員と顧客の距離が近く、少人数で物事が決まっていくのでスピード感があり、良いところもたくさんあるのですが、以下のような問題も生まれている状況でした。

(1)プロダクトに寄らないタスクが放置されがち
例えば、プロダクトサイトやプロダクトのSNSアカウントなどはそれなりに更新・運営されている一方、コーポレートサイトは「誰かが手が空いたら更新する」というルールに基づいた結果、荒野と化していました。

(2)顧客に対するコミュニケーションの一貫性が担保できない
それぞれのチームの営業担当者が個別にアポを取ったりメールしたり電話したりしているので、顧客側から見たときにコミュニケーションのムラが生じるという問題がありました。あるセールス担当者が取引先に電話したら、別のプロダクトのセールス担当がたまたま当日同じ話をメールしていたみたいな…

規模が小さいのでほかの社員の活動状況を確認すれば把握できるのですが、いちいちやっていられないので無駄やロスが出がちでした。
各プロダクトでメルマガやSNSなどの運用も独自にやっている状態で、「BCCに取引先入れて一斉配信」というアナログな方法でメルマガが運用されている場合もありました。もちろん、配信スケジュールとかはそこまでちゃんと共有されていないし、全社的な管理もされていませんでした。

で、プロダクト単位ではなく会社としてコミュニケーションをとりたい場面もあるので、そういう雑事を新卒一年目に拾わせようということになり、研修期間を終えたymzkに「マーケティング担当」というものものしい肩書が付与されました。
※この時点で本人はその状況を理解しておらず、上司の言われるままに手を動かすオペレーションマシンに過ぎません。今思い返すと、たぶんこういう問題意識だったんだろうなあという想像で書いています。違ったらすいません。

資料を送る…どこに？

最初の仕事は「販売代理店向けに営業キットを作成し、配布する」というものでした。
販売代理店とは個別に契約書を取り交わしており、締結日・企業名or屋号・住所・担当者名等を記録したExcelファイルがあったため作業自体は非常にスムーズでした。
送るまでは。

営業キットは販売代理店の営業担当者の手に渡らないと意味がありません。
しかし、契約締結者が必ずしも営業担当者というわけではありません。送付先の中には、企業間契約の管理者・事務作業担当者・異動者・退職者などが含まれていることがわかりました。
契約書をベースに配布リストを作るという作業自体が間違っていたということです。
自社のセールス担当者が連絡を取っており、我々の商品を売ってくれる/買ってくれる人のリストを作成する必要があります。その情報は各チームのセールス担当のPCの中や頭の中にあるということがわかりました。

顧客情報をサルベージする

ということで、「会社中の顧客情報を集めて一つのリストにまとめる」というのが次のミッションです。
販売代理店のリスト、請求書送付先の一覧、営業担当者のアドレス帳など、雑多な顧客情報を一つのDBにまとめるという作業です。
いわゆる「名寄せ」と呼ばれる作業を行いました。当時はymzkのExcel能力が低かったため、完全に根性で問題解決していました。
改めて思い返すと、めちゃくちゃ頭悪いです。

メルマガ配信ツールの導入

ある日大規模な社内体制の変更が行われました。これによりプロダクト単位の組織が解体され「営業部」「開発部」「マーケティング部」のように職務ベースのチーム編成となりました。

で、組織変更に伴い、プロダクト単位で自由気ままに送っていた既存顧客向けメールマガジンは「マーケティング部」のものとなりました。次のミッションは「メルマガを送る」です。
必要な情報をCSVファイルに落としてツールに食わせるという比較的シンプルなツールだったため、導入はスムーズでした。ymzkはこのメルマガ作成の業務の中でテーブルレイアウトを学びました。今となっては要らない技術です。
利用しているサービスや位置情報などで細かくセグメントを行うという施策でCVRをキープしていたものの、ユーザーのセグメンテーションを細かく行っていく中で配信の手間が増大し、ミスやトラブルが発生し、運用コストがどんどん上がっていくという悩ましい状況に陥っていました。

Salesforceを導入する

で、ある日社長がカンファレンスか何かから帰ってきて突然「Salesforceいれるぞ」と言い始め、唐突に導入プロジェクトが始まりました。
営業・広報・経理のすべてのデータを一つのプラットフォームに乗せるという改革です。ymzkはいままでメルマガを送っていた取引先の情報をSalesforceに載せ替えるという作業を担当しました。

いままで部署の業務の都合だけでDBを管理していたのですが、他の部署の業務遂行上MUSTな条件がいろいろ出てきて、みんなの業務に支障がない状態で載せ替えるという作業が発生しました。それなりに意思決定に時間がかかり面倒なんですが、おたがいがおたがいの業務のことを深く理解するよい機会になったのだと思います。

メルマガのセグメンテーションに使用していた情報もほぼそのままSalesforceに移すことができたため、メルマガ配信ツールの使用をやめてSalesforceが持っているメール配信機能でメルマガを配信することにしました。配信対象者の管理やセグメンテーションがとても簡単になり、感動したのをよく覚えています。ありがとうSalesforce。

配信通数の限界が見える

前述の通りSalesforceにはメールを配信する機能があるのですが、一日に配信できる通数には制限があります。
営業部が取引先や営業先に送るメールもSalesforceに一本化されている中、マーケティング部の送るメールマガジンが通数を大量に食うことが問題視されつつありました。遠からぬ未来、メールマガジンを配信したせいで当日はそれ以上顧客にメールが送れないという最悪な状況に陥る可能性が出てきます。
当座の対応として、スケジュールを細かく管理しながら配信通数の制限を回避するという運用で乗り切ることにしましたが、根本的な解決には至りませんでした。

Pardotを導入する

2014年の秋、Dreamforce（Salesforceが主催するカンファレンス）から戻ってきた社長が「Pardotすごい。Pardot使おう」と言い出しました。
Pardotって何？SalesforceのMA？MAとは？？？というレベル感でしたが、それを導入することによりSalesforceの顧客情報をもとにメール配信ができて、しかも通数制限がないということが分かった時点でこちらも導入する気満々になりました。(※通数制限はないですが、登録できるメールアドレス数に上限が設けられています。ニッチなBtoBならそこまで困らないですが、薄く広い系のプロダクトだと苦しいかもしれません)
その他にも魅力的な機能がたくさんありました。在職中にそれらの機能をきちんと使いこなせなかったのが残念です…

PardotとSalesforceを連携させるにあたって「ユーザー」の概念の粒度や顧客情報の持ち方が大きく異なるため、導入に際し運用ルールを根底から作り直す必要がありました。
Salesforceはマーケティングチームだけでなく社内の他のチームでもヘビーに使っていたため、多くのチームと議論しつつ進めていきました。これをきっかけに、マーケ⇒インサイドセールス⇒フィールドセールス⇒カスタマーサポート⇒バックオフィスとパスされていくコミュニケーションの流れや各工程の役割を他チームとも握り合うことができたのは良かったかもしれません。

地味にしんどかったのは言語の壁です。当時のPardotは英語オンリー、そして、マーケには英語が得意な人間がいませんでした。
国内企業が提供している導入支援サービスを使っていたため、基本操作については日本語の資料が手に入ったのですが、細かい仕様の確認などは慣れない英語をググりながらヘルプページをどうにかして解読する必要がありました（それでも分からないことがあり、自社で検証してもわからず、導入支援サービス経由でPardot本体に問い合わせてもらう場合も。）
活用事例・成功事例なども日本語で読めるものがほとんど存在せず、必然的に英語コンテンツを解読することになります。

ポジティブな点として、500点台だったTOEICの点数が半年で750点まで伸び、その1年後には800点を突破しました。「必要に迫られる」というのは最強の学習法です。

属性ベースから行動ベースのコミュニケーションへ

Pardot（に限らずMAという思想そのもの）の面白いところは「ユーザーの行動をトリガーにして次のアクションを取れる」という点です。

行動ベースのメール施策によって、今までのメルマガ施策では見たことがないCTR・CVRが叩き出されていきました。ダッシュボードでCVR30%という数字を見て、強烈な後悔の念がわいてきたのを覚えています。機会損失がないように最大限リーチを取ろう、1ミリでも反応してくれる可能性のある人ならメルマガ送ろうという今までの（安易な）メール施策。嫌がられることを前提に、件名やCTAのA/Bテストを繰り返して手に入れた数％のCTRやCVR。そんなものに時間と情熱を傾けていた自分ってなんだったんだ、と膝から崩れ落ちる思いでした。

欲しい時に欲しいものをわたせば、もらってくれる人は多い。そんな当たり前のことがわかるまで遠回りしてしまったなという感じです。

と、MAのことをだいぶ持ち上げたくせになんですが、あまり深く考えずに設定したせいで激しく事故ったりトラブったりしてガチ凹みすることもかなりありました。複雑性が増すごとに予期せぬトラブルが発生する可能性が増える一方、遂行能力そのものもめちゃめちゃ上がり、人の手が動いていないところでとんでもない事が自動的に起こります。テクノロジーって恐ろしいですね。

ところで、この辺の業務と並行して自社サービスに関する企業出版施策に携わりました。早い話が本屋に流通する本を作って流通させるという施策です。正直、企業出版って「自分で自分を持ち上げる本書いて誰が騙されるんだよ」というつっこみが先行しがちかと思います。実際「本の売り上げで儲ける」という狙いだと厳しいと思うのですが、新規顧客獲得のためのツールとしてはかなり優秀で、じゃっかんビビりました。

コンバージョンジャンキーと化し、転職

MAを運用するなかで、だんだんとコンバージョン中毒が悪化しはじめました。
BtoBビジネスは成約までにさまざまなプロセスと意思が介在し、成約までにかかる時間が長く、自分の施策が貢献している実感を持ちづらい傾向にあります。しかし、MAを通じて見込み顧客が思ったとおりに動き狙った通りにコンバージョンするさまを目の当たりにし「自分の施策がちゃんとハマる」様子が可視化される中で、コンバージョンの獲得が楽しくてしかたなくなってきました。

その折にあるゲーム系スマートフォンアプリのプランナーの話を聞く機会があり、日単位・時間単位で施策の効果測定が行われる現場があることを知りました。施策開始の数時間で効果検証をして次の施策を打つ、そのスピード感に魅了されてしまいました。

一分一時間で反応がもらえる、もっとスピーディーにコンバージョンが手に入る、という欲に負け、いつのまにかCtoC系Webサービスのディレクター職に転職していました。
ちなみに転職先の雇用条件の一つとしてTOEIC700点以上の獲得が必須でした（エンジニアに英語話者が多いため）
人生何がどう転ぶかわからないな、というのが率直な感想です。

転職後の業務についてはかける範囲でかくかもしれません、かけないかもしれません、割とコンプラ厳しいので…

この記事はBtoB実務系記事のハブとして運用していく予定です。

*1 この記事の筆者を指す固有名詞です。