2020年3月、Synergy!のメール配信に待望のABテスト機能を追加しました！ 今回、ABテスト機能の開発に携わった渋谷さんにプロジェクトのお話を聞きました。
渋谷 拓正（シブヤ タクマサ）料理／散歩／漫画が好きです。音楽もよく聞きます。
最近よくやる料理は、アジとかツバスとかを酢でしめて、軽く塩漬けにした玉ねぎとか人参とオリーブオイルで食べるやつです🐟
（男子ごはんでやってたスペイン料理的なやつ）
ABテスト？
― ABテストってどんな機能なんですか？
Synergy! のメール配信のひとつであるベーシックメール機能の拡張で、ターゲットの反応に応じて、より効果の高いメールを選んで送信できる機能です。
具体的には送信ターゲットの何割かに対して最大3パターンまでメールをランダムに送信し、その結果によって最も効果が高かったメールを残りのターゲットに対して送信する機能です。コンテンツを用意するだけで設定が複雑なABテストを自動で実施でき、効果の比較／検証が容易なので、マーケティング施策の PDCA を高速にまわすことができます。
サンプルから本配信まで自動で行うこともできますし、結果を見て自身でどのパターンを本配信にするかを決定する事もできます。
こだわったのは「速さ」
― 渋谷さんはフロントエンドの担当ですよね？
はい。
フロントエンドは「メール一覧／配信設定」「レポート機能」の２チームに別れて機能の実装をしましたが、僕は「メール一覧／配信設定」を担当していました。
ABテストはベーシックメールの拡張機能なので、基本的なコンポーネントはベーシックメールのものを再利用して開発しました。
― ABテスト機能、ここをみて！というところはありますか？
個人的にこだわった部分としては、「件名・差出人／本文」画面のパフォーマンスです。
この画面は、「パターンA／パターンB」タブと「件名・差出人／テキスト本文／HTML本文」タブがあり、非常に要素が多い画面になっています。
実装的にもリッチテキストエディタが多くあるため、いかに切替時に違和感を少なくし操作性を高めるかが重要だと感じました。 エディタのインスタンスの生成や、API 通信部分を工夫することにより、結果的に今まで描画に少し時間がかかっていた IE11 などのブラウザでもある程度パフォーマンスを保ってくれるようになりました。
追加開発の苦悩
― 苦心したところはどこですか？
今回の一番のポイントは既存部分のリファクタリングでした。
ベーシックメールの UI、社内では mail-ui と呼んでいるのですが、かなり長い間（5年くらい？）開発が続けられていて、その分技術的な負債も大量に抱えています。ABテストは ベーシックメールの拡張機能ですので、mail-ui を拡張しなければならなかったのですが、以下のような問題がありました。
- 1つのコンポーネントが非常に巨大になっていて、再利用が困難
- TypeScript での型の記述がほとんど any になっているため、型のメリットを享受することができず、JavaScript のみの状態と変わらない
- 自動テストがなく、変更時は毎回時間をかけて手動テストを実施していた
- 古い仕様の ES5 で記述されているため、記述が冗長になり読みづらい
- ベーシックメール機能だけでなくリターゲティングメール機能でも利用されているため、変更したときの影響範囲が広い
また、長く続いているプロジェクトはそれだけ多くの仕様を抱えていて、どうしてこういうコードになっているのかがわからない部分も多くありました。
そういった中で、ABテストは最大でメール3本分を同時に扱う機能であるため、管理すべき状態や発行すべき API リクエストが非常に増え、既存コードに乗せることがむずかしい状態になっていました。
そこでABテストの開発にとりかかるのと同時に、mail-ui の大規模なリファクタリングにも着手しました。
具体的には
- ABテストで開発に関する部分では積極的にリファクタリングを行う
- 既存の機能（ベーシックメール、リターゲティングメール）に影響が出ていないことを確認
- ABテストの開発に着手
のような形でプロジェクトを進めました。
幸い、チームリーダーが mail-ui に精通していたため、コードを読んでもわからない点はチームリーダーに確認しつつ、結合テストでABテスト以外の部分も網羅的におこない、リスクの低減に務めました。
― なるほど。丁寧なテストの甲斐もあり、リリースもスムーズに進んだんですね。
KAIZEN!!!
― 渋谷さんが所属するフロントエンドチームは常に積極的にプロセスを改善しているという印象があります。
そうですね、どのメンバもいろいろ提案するし、まず「やってみよう」となることは多いと思います。例えば、コードレビューです。今までは
- MR（マージリクエスト）時にレビューイがレビュアーを指定
- レビュアーがレビューし、問題なければレビュアーがマージ
という風に進めていました。ただ、どうしても特定の人にレビュアーが集中してしまうし、レビューしない人はコードを読む機会が限られてしまいます。そこで、チームの決められた人数からマージ OK の承認が出たらマージができる、という「approve制」に変えてみました。以下のような感じです。
- MR 時にレビューイがチームに対して MR の確認を依頼
- チームメンバの何人かが MR を確認する（誰が見ても OK）
- 2人以上から OK を貰えたら「レビューイ」がマージ
狙い通り、他の人・他のチームのコードを覗く機会が増えて、自分の作業範囲以外のプロダクト知識が増えたように思います。また指摘内容の幅が広がったと感じます。その反面、やっぱりなかなかレビュアーが集まらないときもあります... そんなときは地道に再度依頼を投げたりしてますね。「あと一人お願いします！」みたいな感じで。あと、レビューしやすいように Storybook ですぐに動きが確認できるようにしておくとか、どこを見てほしいとか MR に書くみたいなのは増えてきた気がします。
― 他にも今とりくんでいることはありますか？
今はシナリオ*1という機能を開発しています。新しいフレームワークを利用して開発していることもあり、できることがいっぱいでとても楽しいです。ただ、クラウドサービスは機能拡張し続けなくてはいけないので、今開発しているプログラムも既存のプログラムコードも、自動テストを整備する・リファクタリングする・フレームワークのバージョンをあげるなど、手を入れ続けないといけないなあと感じています。特に、ABテスト機能の開発では自動テストがなくてリファクタリングが大変だったので(笑)、チーム全体で「テスト、書いていこう」というムードが高まっていると思います。
― 次のシナリオも楽しみですね。ありがとうございました。
