メールシステムの運用に手間をとられないメリット
構造計画研究所 中井:SendGridにしてよかった点はありますか?
ピースオブケイク今:うちはエンジニアが少ないので、メールの運用に負荷をとられたくない。その点、SendGridはAPI経由で送れば、あとは自動なので助かっています。
クラウドワークス大場:APIだけではなく、SMTPが使えるというのが大きかった。もともと使っているpostfixからリレーするだけで、少しずつSendGridに移行できる。あとフルマネージドであるところがいいですね。単純に送ることはほかのサービスでもできるけど、送って状況をWebから簡単にモニタリングできます。ワールドワイドで使われていて、メールの問題を解決した会社というイメージ通りでした。
コーチ・ユナイテッド富田:僕もだいたい同じですが、SMTPのログをまめに見るという仕事がなくなりました。うちの場合、問題は再送のタイミング。メールサーバーの設定を変えて、送り直すとかけっこう怖いじゃないですか。以前は、人手で再送のタイミングをチェックしていたのですが、SendGridに切り替えてからは成功が増えたので、すごく助かってます。
ピースオブケイク今:Event Webhookがあるじゃないですか。それ見ながら、「あっ、deferredしてる」とか、「あっ、再送した」とか、感動しています。
クラウドワークス大場:メールの運用って細かいところまでケアしないとうまく回らないんですが、SendGridはそれができる。たとえば、受信者がGmail上などで迷惑メールボタンを押されてしまったモノとか、SendGrid側でカウントしてくれます。そういうアドレスは次回以降送らないようにしようという作り込みができます。運用はプロに任せ、あとは自社のサービス開発に専念できます。
構造計画研究所 中井:メールってエンドユーザーとつながる手段として絶対必要なんですけど、やりたくはないんですよね。たとえば転職して任された仕事がメール運用だとテンション下がると思うんです(笑)。なので、そこらへんはプロにお任せいただいて、自身はコアの開発に専念いただけます。
ピースオブケイク今:あとは構造計画研究所さんのブログの充実ぶりがすごいです。
構造計画研究所 中井:ありがとうございます。週に2本を守っていて、今200本くらいになってます。
dots.杉山:うちもエンジニア自体が少ないし、メールに精通しているエンジニアは大手に穫られちゃうんで(笑)。ノウハウをそれほど知らなくても、運用ができるのは素晴らしいと思います。
構造計画研究所 中井:今回はメールを安全に大量送信するのにそのノウハウを知っている人って少ないよねというのもテーマですが、逆に言えば知らなくても運用できるサービスもあるんです。だからメールもクラウドも含め、ロストテクノロジーなんですよね。
経営者はなぜ届かなくてもリスト数にこだわるのか?
構造計画研究所 中井:次に運用の苦労という話に移るのですが、みなさん送信できないメールアドレスってどうしてます?
コーチ・ユナイテッド富田:うちはロックかけて送らないようにしています。
構造計画研究所 中井:できれば一度届かなかったアドレスのユーザーがログインした時に、アドレスを確認するためのアラートを挙げるくらいがいいです。クラウドワークスさんもリコンファーメーションキャンペーンを行なって、ユーザーに送っていいかをチェックしてもらっていましたね。長い間使用されていないアドレスを抜くと、スパムトラップのアドレスも排除できます。
クラウドワークス大場:そうですね。クリーンなリストにのみ送れる仕組みを作って、数回送って、ユーザーを復活させていくしかないです。
構造計画研究所 中井:でも、こちらが引くくらい汚れたリストを持っているユーザーもいるので、今後問題になってくるとは思います。すごい配信数ということで、意気揚々とお客様のところに乗り込んで、運用を始めてみたら、バウンスレートが高くて、数十万人のリストが半分くらいになったということもあります。日本ではメルマガのKPIをリスト数×送信回数で見るので、読まれなくても大量に送る傾向がある。
クラウドワークス大場:本質的には読まれないメールは送っても効果がないので、減らしても影響はないはず。でも、背景を理解しないで数字しか見てない状況では何度説明しても、送信件数を減らすことに抵抗がでてしまい、結局送信件数を増やそうという議論になる(笑)。
構造計画研究所 中井:みなさん、なんで数に固執するんでしょうね。バウンスしたアドレスすら消したくないという方もいます。
コーチ・ユナイテッド富田:でもSendGridならクリック数とれますよね。
クラウドワークス大場:まだまだテキストメールも多いので、クリック数だけに頼れない状況があります。
構造計画研究所 中井:ちなみに、みなさんはHTMLですか、テキストですか?
クラウドワークス大場:うちはHTMLとテキストの併用です。
ピースオブケイク今:うちはHTMLパートのみです。
構造計画研究所 中井:なるほど。お作法的にはHTMLとテキスト両方にしたほうがいいです。スパムメール扱いを受ける可能性があります。どんなメールでもセットで送るのがよいです。
コーチ・ユナイテッド富田:うちは去年モバイル前提でHTML組みをしました。内容的にはレッスンのリマインダーなので、ロゴ、文字、リンクのボタンくらいシンプルにしました。
dots.杉山:うちも昔はモバイルだと見切れてたりしたので、きちんと作り直しました。
コーチ・ユナイテッド富田:でも、ケータイのデコメールにも対応しなければならないので、ログイン履歴からHTMLメールを送っていいかある程度判別してます。HTMLメールで送っていい人にはマルチパートで、それ以外はテキストで送っています。
構造計画研究所 中井:デコメールってキャリアによってフォーマット違うじゃないですか。それって作り込みました?
コーチ・ユナイテッド富田:しばらくメールばかりという時期があったので、そこは作り込みましたね。
構造計画研究所 中井:ケータイという話だと、特定のアドレスに送るために、届くまで送信元IPアドレスを変えて送り続けるといった方法がよく取られています。でも、それは「Snowshoeスパム」という行為ですよと指摘したら、相手に切れられたことがありました(笑)。キャリアによって、バウンスを返す、返さないも違うし、ユーザー自身が設定できるところもあるので、面倒です。