【Quipperブログ】マルケト戦記

はじめに

みなさんこんにちは、データエンジニアリングチームの戸井田( @toitech )です。

今回は、昨年の春からスタディサプリのユーザーへのメール配信で利用しているマーケティングオートメーションツール（以下 MAツール）「Marketo」の導入について書きたいと思います。

このプロジェクトで私は、スタディサプリのデータ分析基盤と Marketo のシステム連携を実装するエンジニアとしてアサインされました。
しかし、なぜか自分でも知らぬ間に役割がプロジェクトマネージャー的な立ち位置に変わっていきました。

そんな私が、どのようにこのプロジェクトを進めていったかを主にプロジェクトマネッジメントの観点で紹介したいと思います。

最初に断っておくと、自分の本職はデータエンジニアでマーケティングは専門ではないので本記事では Marketo の具体的な活用方法などについては触れず、導入して活用できるようにするまでどんな工夫をしたかについて書きたいと思います。

MAツールを導入前のメール配信方法と課題

まずはじめにMAツールを導入するまでのスタディサプリにおけるメール配信業務がどんなものだったか軽く紹介したいと思います。

学習コンテンツやキャンペーンの紹介などのメール配信を行う場合、以下のような流れになります。

プロダクトマネージャーが配信したいキャンペーンをマーケティンググループに依頼する
マーケティンググループが、配信内容、配信日、配信対象ユーザーを決める
マーケティンググループが、配信対象ユーザーの抽出をデータグループに依頼する
データグループが、データ分析基盤から対象ユーザーを抽出しマーケティンググループに提供する
マーケティンググループが、対象ユーザーリストと配信内容をメール配信ツールにセットして配信する

　　　　　　　　　　　　　　　　　従来のメール配信の運用フロー

これまで、この一連の流れのなかで、3と4の手順が煩雑であることが問題視されていました。

スタディサプリのデータ分析基盤は Treasure Data を利用しており、そこに日々溜まっている学習データなどのクライアントログやユーザーの学年や会員種別などの属性情報からユーザーセグメントを作成し、メール配信を行っていました。

このセグメントは案件ごとに違うため、都度 Treasure Data へ SQL を投げユーザー抽出を行う必要があり、案件によっては10個以上のテーブルを参照する必要があり数百行をこえる複雑なクエリを書かなければいけないケースもあります。
また、一つ一つの案件に SQL のコーダーとレビュアーをアサインされるため繁忙期は特に運用コストが高くなってしまっていました。

いっぽう、マーケティンググループとしても既存の配信ツールでは煩雑な作業が多々あり素早い PDCA が阻害され、本来集中するべきナーチャリングなどユーザーとより良い関係性を構築する施策に十分な時間が割けないといった問題もありました。

そのため、データグループ観点で「既存のメール配信の運用コスト削減」とマーケティンググループ観点で「ユーザーへのエンゲージメントを高める」といった2つの課題を解決するためにMAツール導入が検討されました。

まずスキーマ設計してから Marketo を導入

MAツールの選定は、2ヶ月ほど複数の企業様にヒヤリングしながら進めました。その中で弊社のやりたいことと一番マッチしたのが Marketo でした。

柔軟なキャンペーン配信、充実したレポート画面、導入運用コンサルのサポート、他のリクルートグループでの導入実績などが非常に魅力的に感じました。

契約を進める上で私がこだわったのは、実際の契約が始まる前にデータのスキーマ設計を行ったことです。

これは、「既存のメール配信の運用コスト削減」という観点で、業務を Marketo で代替できるかを判断するためです。

マルケト社のテクニカルコンサルタントの方にスタディサプリのサービスの特性やデータ構造を理解していただき、実際 Marketo 上にどのようにデータを持たせるべきかを徹底的に議論しました。

Marketo には、メールアドレスを管理するリードというテーブルがあり、そこにユーザーの属性などの情報を入れるカスタムフィールドというのものを自由に追加することができます。
このカスタムフィールドの値の組み合わせで、任意のセグメントをきりメールを送ることができます。

この設計を行うために、マルケト導入前のメール配信でのユーザー抽出で Treasure Data のどのテーブルを参照したかというのを洗い出しました。
この中で、頻繁に使われるテーブルのカラムをカスタムフィールドとして持つことにしました。
結果的に、カスタムフィールドは70個以上になりました。

そして、このくらいのデータをマルケト側に連携すれば、メール配信の案件全体の70%以上はマルケトから送れると予測できました。

残りの30%弱は、アドホックに発生するキャンペーンや SQL でしか対応できない複雑なユーザー抽出などがあるためで、Marketo で対応せず既存のやり方でメールを配信することにしました。
70% データ抽出業務が削減できるなら ROI の観点でも十分な効果が見込めると考えました。

最終的にマルケト社のテクニカルサポートのかたに、スキーマ設計をレビューいただき問題なく、こちらの要望が十分実現できると判断できたため契約を進めました。

契約後、スキーマ設計を通じて基本的な Marketo の特性を把握し様々なユースケースを想定していたので、データ分析基盤から Marketo へのデータ連携はスムーズにできました。

しかし、Marketo 活用の道のりはここからが険しいものでした。

期中、やらないことを決める

Marketo の契約が3月に始まるとマルケト社の担当コンサルタントと週次でミーティングがセットされ、各種設定や機能のレクチャーを受けることができました。

コンサルタントのかたは、向こう半年の計画を WBS でまとめてくださり網羅的に Marketo の機能を活用できるように指導してくださいました。

これにより、MAツールはもちろんマーケティングに関する知識が決して豊富ではない私でも、ある程度 Marketo というツールの特性を理解することができました。

しかし、契約から最初の3ヶ月くらいは各種設定や基本機能のキャッチアップに時間を使いすぎ、メール配信は Marketo を使わない既存のフローで行われていました。

ちょうどこの頃、データグループ内で Marketo を活用しユーザー抽出の簡略化・安定化に対する期待が高まっていました。

さすがに、このペースの進捗ではまずいと思い、コンサルタントの方にいまデータグループが抱えている問題を今一度正直に打ち明け、抜本的に計画を修正しました。

MAツール導入の経緯で述べた通り弊社の要望としては、「既存のメール配信の運用コスト削減」と「ユーザーへのエンゲージメントを高める」というもので、この2つを実現するためのコンサルタントの方にはWork Breakdown Structure（以下 WBS）を用意してもらっていました。

しかし、前者に比べ後者はゴールが曖昧で、本当の意味で実現するにはじっくりと長期的に取り組まなければいけない課題です。

そこでコンサルタントとの協議の末、少なくとも向こう半年（期中）は敢えて導入の ROI が見えやすい「既存のメール配信の運用コスト削減」に集中するべきという方向に舵を切りることにしました。

「ユーザーへのエンゲージメントを高める」は、それ以降にやるということを社内の関係者にも納得してもらいました。

これを踏まえて WBS の中で、やらなくても良いものに斜線を引いて消していくことで、やらなければならないことがシンプルになりました。

具体的には、トリガーメール、ステップメール、カスタマージャーニーなどの機能は一旦使わない方向で進めました。
これは、Marketo の機能を使わなくても Treasure Data に溜まっているログと運用方法の工夫で代替できると判断したためです。

このように、迅速かつ柔軟に計画の変更に対応していただいたコンサルタントには非常に感謝しています。

またちょうどそのころ、前職で Marketo を使っていたというメンバーがマーケティンググループに入社したため、機能面の学習にかける時間を大幅に削減でき、案件をまわしていくことに集中できるようになりました。

目指せ、スマイルカーブ

今期に注力するテーマと体制が整ったところで、私はプロジェクトの起爆剤となる施策としてスマイルカーブというものを掲げました。

　　　　　　　　　　　　　　スマイルカーブ（Marketo 配信の目標消化スケジュール）

これは、横軸が日付で縦軸が全メール配信のうち Marketo で配信したものの比率になっており、今後の目標を示したグラフになっています。

このカーブは、はじめは立ち上がりは遅いが途中急激に上昇し最終的に70%くらいで収束するS字の軌道を描いています。

ちなみに、今回のマルケト導入プロジェクトには、データ抽出するメンバーを「笑顔」にするという目標があり「スマイル」というコードネームがつけられていました。
偶然(?)にも SMILE の「S」の軌道になっているのでスマイルカーブと命名しました。

さて、このカーブがこういう形になったのには要因は2つあります。

一つ目は、メールを定常的に配信できるようになるまでにメールサーバーのIPアドレスのウォームアップという作業が必要になるためです。
これは、Marketo に限らず特定のメールサーバーが送るメールが、ISP（インターネット接続業者）にスパムメールでない正当なメールだという信頼を得るために徐々にメールを送っていく作業で、最初の1ヶ月は日次の最大送信数を数千通ぐらいに抑える必要があると言われています。
このため、グラフの最初の1ヶ月くらいは低い消化率で推移しています。

もう一つの要因は、パレート図というものです。

　　　　　　　　　　　　　　　　　パレード図（Wikipediaより）

パレート図についての詳しい説明はここでは省きますが、図のような「発生頻度の高い順に並べた棒グラフとその累積比率の折れ線グラフ」をセットでそう呼びます。
今回のケースは、この「累積比率の折れ線グラフ」がスマイルカーブの右側になっています。

前述した通り、過去のデータ抽出業務で頻繁に使われていたデータ分析基盤のデータを Marketo のリードに連携させました。
つまり頻度の高い案件から順番にメールを配信していけば、急激に消化率があがり70%くらいまで一気に上げることができるという仮説がたてられました。

Marketo ではスマートリストと呼ばれる、GUI 上で配信セグメントの設定し保存しておける機能があります。
一度それを作ってしまえば何度も使いまわせ、類似案件であっても一部修正するだけで対応し続けることが可能です。
そのため、パレート図でいう「累積」が可能になるわけです。

ちょっと余談になりますが、このS字を描きつつ Marketo 化が進むであろうという仮説は自分の頭の中にあったんですが、このアイディアが日の目を見るキッカケになったのは、上長との何気ないやり取りの中でたまたま生まれました。

ちょうど「やらないことを決めた」6月中旬ぐらいの時期で、Marketo化の進捗が芳しくなかったため、それを見かねた上長が私を呼び出し

上長　「Marketoの件、いつになったらメール送れるの？」

私　　「今はウォームアップ中なのであまり送れてないですが、それが終われば一気に送れるようになります！シグモイド曲線（S字カーブ）っぽくなるんで、大丈夫です！」

上長　「じゃ、最終的にどのくらいの時期で70%くらいになるの？」

私　　「...9月1日には70%までいけます！」

と啖呵を切ったのが、はじまりだったりします。

その後、データグループの定例でこのカーブを公表し、私の席のモニターの上にスマイルカーブが書かれたボードを立てたりと社内マスプロモ（？）を行いメンバーを鼓舞していきました。

自分の中で、しかるべき手順で進めればS字カーブで進捗するという自信はあったんですが、どのくらいの勾配のS字カーブになるかは未知数でした。

何気ない会話の中で9月1日と発言したことで、明確に締め切りが決まってしまいここから2ヶ月間はやきもきすることになりました。

まさに背水の陣の覚悟で進めることになりました。

昼会という名のデイリースクラム

このような経緯から明確な目標が設定されてしまいました。
では実際に、どのように案件を進めていくか。
一つの工夫として、メンバーとデイリースクラムを行いました。

この当時、Marketo導入の過渡期ということもあり、マーケティンググループとデータグループのメンバー間で、案件ごとにマルケトで配信するか従来のメール配信するかというコンセンサスがなく、Github のイシュー上でも認識のズレが何回か起こっていました。

特にユーザーの会員種別の定義などは、かなり複雑だったためイシュー上でのやりとりでは限界があり対面でコミュニケーションする必要が出てきました。

そこで、問題を早く検知するためにスクラム開発の考え方を取り入れ、デイリースクラムを行うことにしました。

しかし、スマイルプロジェクトのメンバーは僕以外エンジニアではなかったので、スクラムみたいなことを言ってもピンとこないかなと思ったので「昼会」という名前にしてみました。

なぜ朝会でなく昼会だったかというと、単純にみんなが集まりやすい時間がそこしかなかったためです。

マーケティンググループとデータグループのメンバー4人で毎日15分くらいメンバーが集まって、今着手してることや困ってることなどを共有するという簡易的なものにしました。

典型的なスクラムとちょっと違うところは、みんな座って一つのモニターで Marketo の画面を見ながら話したことです。
Marketo のカレンダー機能や Github のイシューをカンバンで見ながら、自分たちがスマイルカーブを実現するために、今何をすべきかというスケジュール感を共有できました。

また、Marketo の用語や操作方法に詳しくないメンバーもいたので、実際の画面を見ながら議論をすることでイメージが共有できて認識のズレも解消されました。

スマイルカーブを発表してからの最初の3週間くらいは毎日やって、次の2週間くらいは週2になって、それ以降は相談したいことがあれば集まろうって感じになりました。

これにより、プロジェクトが軌道に乗り昼会を定期的にやらなくなった後も、当事者間でわからないことは直接聞きに行ったりして解決するようになり非常に良い雰囲気でプロジェクトを進めることができました。

今回のような短期集中のプロジェクトの場合、コミュニケーションの頻度が重要になってくるということを肌で感じることができ、私としても大変勉強になりました。

他社事例の調査と運用の型化

スマイルカーブの推進と同時に運用体制の強化にもつとめました。

メール配信はオペミスなどによる誤配信が起こると、ユーザーの信頼を裏切ることになりかねません。
そのため、属人化しない持続可能で安定性の高い体制を整えなければなりません。

そこでまず、他社がどのような体制で Marketo を運用しているかの情報収集をしました。

Marketo を導入しているサービスを実際に登録してみてどんなメールを送っているか確認したり、コンサルタントの方に他社の事例を伺ったり、場合によってはMarketo導入企業の担当者のかたに実際お話を伺ったりもしました。

文面やクリエイティブの制作体制、配信設定を行う運用面での工夫などの情報を集めることができました。

これを踏まえて

配信ミスを防ぐチェック体制
属人化せずチームで安定的に運用できる体制
データ基盤の障害によりマルケトのデータ連携が遅れた場合のリカバリー対応のとりきめ

などの構想を膨らませていきました。

また、Marketo を使わずに従来の方法でメールを送る場合に担当者間の認識の齟齬をなくすために

Github イシューテンプレートの作成
データチームへのユーザー抽出依頼は5営業日前までに済ませる

などのルールも作りました。

イシューのテンプレートを用意することで、誰が依頼してもだいたい同じようなフォーマットになるようにしました。
また、ユーザー抽出依頼が突発的に発生すると現場が混乱するので、5営業日前に依頼することを基本ルールとし、止むを得ず必要な場合はデータグループのマネージャーの承認をもらうというフローを作りました。
これにより、計画的にキャンペーンをうつ土壌が整いました。

このように、特定のプレイヤーに頼るのではなくチームで運用できるように業務を型化を目指しました。