※この記事は、2022 Speee Advent Calendar、6日目の記事です。
昨日の記事はこちら↓

こんにちは。ヌリカエでグロースをしている九島です。

突然ですが、みなさんのチームで今年いくらの事業損失が起きましたか？
僕のチームの制作環境は、開発内容から複雑性が高く、リリース後に予期しない不備がでるという問題がありました。根本解決としてリファクタをしつつ短期的にも開発を進めるために、僕のチームで自動CVツールの導入/運用をはじめました。

今日はこの自動CVツールの話をします。
※エンジニアではないので、技術的な細かいことはわかりません。記事内でも、その点はご容赦ください。

はじめに

僕のチームでの主な活動の1つとして、ABテストによるLPO/EFOがあります。
ヌリカエでは問い合わせのほとんどがフォーム経由であるため（わずかに、電話での問い合わせ）、CVR改善(コンバージョン率改善)が事業数字に与える影響が大きいです。

そのため、かなりリソースを割いており、

週1の頻度でABテストを実施
異なるLP/エントリーフォームで、同期間に、複数の検証を実行
そのため、年間300以上の施策を実行

という、web業界でもわりとアグレッシブな回数、ABテストを実行しています。
（詳しくはこちらのMarTechLabさんのインタビュー記事をご覧ください。）

martechlab.gaprise.jp

一方で、LP/エントリーフォームでの障害が、事業損失に直結するという側面もあり、直近半年間でも数百万円の売上損失が起きてしまいました。

制作環境の複雑性が高い

ABテストを繰り返し行って事業を伸ばしてきたわけですが、そんなヌリカエの制作環境の特殊性は、「複雑性の高さ」です。

サービスドメイン、流入媒体、デバイス、訴求内容ごとにページが存在し、ざっと120本ほどURLがある
URLは、見た目も全く違うもの、項目の順序だけが違うもの、など様々
1つのURLでも、ユーザー選択によってルート分岐が存在する場合がある
ABテストによって、週1という高頻度のペースでソースコードを変更するURLもある
テストが失敗して削除するURL、テストが成功して反映するURLなどもまちまち

この仕様/コードの複雑性の高さは、事業の成長とともに加速していきます。さらに、次のような状況を考えると、この状況を放置することにより、損失金額の増加が想定されます。

事業規模の拡大
この半年は、経歴の長いメンバーのみで構成されたチームだが、今後はジュニアプランナー、経験の少ないエンジニアが増えていく

損失金額をへらすためには、影響範囲を小さくするようにコードを設計するのが一番です。しかし過去の負債も膨れ上がり、すぐに手を打つことができません。

「では、せめて障害に、すぐ気づくことはできないだろうか？」

そんな思いが、DatadogのSyntheticモニタリング導入の出発点です。

手動ですべてのURLを確認すると10時間

大体の障害は、リリースに起因して発生してしまいます。（外部環境の要因で障害が起きたことは、僕のチームでは今のところありません。）

そのため、次のようなフローにしていました。

実装完了時点で、Stg環境でCVできるかを手動で確認
リリース後、変更を加えたURLに対して、本番環境でCVできるかを手動で確認

しかし、障害が起きるときは、想定外のところで起こります。

変更してないはずのLP/エントリーフォームのルートで障害が発生（仕様/コードが複雑で、影響範囲が想定外）
変更してないはずのURLで障害が発生（仕様/コードが複雑で、影響範囲が想定外）
一部の環境でのみ障害が発生（ex.ブラウザ、OS）

となると、すべての環境でテストすればいいのですが、1つのURLでCVするのに、平均5分くらいかかります。
さらに、そもそもURLが120本もあるので、全部見ようとすると、10時間かかります。

自動CVツールの検討

そこで検討したのが、CVテストの自動化です。
特にヌリカエのように多数の選択肢を選んで最終的にページ遷移するようなものはテストが難しいのですが、そのようなブラウザ操作をテストできるサービスがいくつか見つかりました。

Datadog
mabl
Ghost Inspector
BrowserStack

主な論点はコストとカバレッジ（≒実行できるブラウザ）で、Datadogとmablの一騎打ちとなりましたが、下記のDatadogのメリデメを天秤にかけDatadogを採用しました。

メリット
- 月次契約（mablは年次契約）
- コスト面（mablよりよかった）
デメリット
- safariで検証できない（mablは可能）

導入にあたって工夫したこと

コストの削減

Datadogは、テスト数で金額が決まります。（料金 | Datadog）
つまり、コストは次の計算式です。

（コスト≒）月間のテスト数 = URLの数 × テストするブラウザ数 × 1URLでテストするルート数 × 月間でのテスト実行回数

特に、「月間でのテスト実行回数」について、

1日1回、本番環境のURLすべてで実行
Stg環境にアップしたときに、Stg環境のURLすべてで実行
本番環境にアップしたときに、本番環境のURLすべてで実行

のすべてで実施するのが理想ですが、コストカットが必要でした。そこで120本あるURLを、コードの更新頻度・損失が起きたときの事業への影響度で分類し、テスト頻度を見直しました。予算とのバランスをとることで、最終的には次のようにすることにしました。

すべてのURL
- 1日1回、本番環境のURLすべてで実行
- 本番環境にアップしたときに、本番環境のURLすべてで実行
事業損失が大きいURL
- Stg環境にアップしたときに、Stg環境の対象で実行

運用の自動化

重要度が高いが緊急度の低いタスクをやり続けることは、意義を理解して、それを感じ続けてもらう必要があり、関係者みな苦労します。そこで、一連のフローをできるだけ自動化し運用のしんどみをできるだけ削減する工夫が必要だと考えていました。

今回は運用にあたって、

1日1回のテストを、本番環境のURLすべてで、テストを実行
本番環境にアップしたときに、本番環境のURLすべてで、テストを実行
これらのテスト結果（テストに失敗した場合は、その詳細）を、特定のSlackチャンネルに通知

の3つが、自動で行われるようにしました。

また細かい話ですが、テスト結果の通知が来るSlackチャンネルを、jsなど他のalertチャンネルと分けて作りました。通知一つひとつに対して判断する必要がなく、「このチャンネルに通知がきたら、やばい！」とすぐに判断できるようにするためです。

導入してみてどうだったのか

導入して3ヶ月になりますが、本番環境でCV損失は発生していません！！

Stg環境で、2度損失を防いだ

損失がないのは、ラッキーだったり、簡単な実装が多いわけではありません。実は、Stg環境でのテスト実行で、2度ほどCVに失敗しています。3ヶ月で2回の事業損失を防ぐことに、しっかり貢献していると言えそうです。

組織の事業損失への感度上昇

もう一つ損失が起こっていない理由として、Datadogが「事業損失に対してチームが当事者意識を持てる仕組み」として、非常に機能している感覚があります。Slackで通知がくることで、「Datadogが失敗したら、損失しているかも」とフラグが立ちやすくなっています。（これまでは障害発生かも？のフラグがなかったため、障害が起きた1ヶ月間は敏感になり、しばらく安心すると危機意識が薄れてしまうサイクルを繰り返していました。）

このような、「重要度が高いが緊急度に波がある」Issueに対して、人に依存せずに対応できる仕組みが作れたことは、非常に価値があると思います。

時間的な運用コストも高くない

ちなみに、運用の時間的なコストですが、「導入は大変だけど、運用はそこまで！」という感じです。

URLを新しく作るたびに、10分
ABテストなどで、既存のテスト設定を変える作業として、5分（テスト実行完了までは30分）

さいごに

DatadogのSyntheticモニタリング、導入してよかったです。

ちゃんと効果を発揮して、未然に障害を防いでくれているというのもありますが、一番は、エンジニアの心理的負担の軽減かなと思います。DatadogのSyntheticモニタリングがあるおかげで、無駄な心配をせずに開発に注力できるようになり、出力が上がっています。

他部署でも導入を検討しているとのことだったので、DX全体を加速させる良い取り組みになったのかな？と思います。

とはいえ制作環境としてはまだ多くの課題を抱えており、根本解決としてのリファクタリングを含めて、それらの解決に引き続き取り組んでいきます！！

いつもの

Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！
こちらのFormよりカジュアル面談も気軽にお申し込みいただけます！

Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！