この記事について
この記事は、「【CPaaS】SMS・メール機能の開発・運用でのやらかし談＆失敗エピソード募集 by ネクスウェイ Advent Calendar 2024」の23日目の記事です。
今では当たり前になったメールやSMSなどの通知は、誤送信や失敗などのやらかしによって、簡単にプロダクトのイメージダウンやユーザーの信頼低下を招く大きなリスクとなります。
例えば、新規登録時のSMSやメール認証が届かないことで、新規ユーザーが登録を諦めてしまい新規顧客を逃したり、変な文章をテストで送ってしまい炎上するなどなど...
なので、誤送信や失敗を防ぐために実施してきた対策について、この記事でまとめてみたいと思います。
また、他にも有効な対策があれば、ぜひコメントで教えていただけると嬉しいです！🙇
誤送信対策編
本番環境での送信権限をできるだけ絞る
基本的なことですが、ユーザーへ通知を送信できる権限をしっかりと絞り管理します。
本番環境のAPIを編集・更新できるユーザーや、本番環境で通知を送信する権限を持つユーザーを、できるだけリーダークラスや責任者に絞り込みます。開発者や一般的なマーケ担当などが本番環境で通知を送ることができないようにしたり、APIキーをローカルで触らないようにするなど、権限の制限を徹底します。
開発環境と本番環境をパット見で区別がつくデザインにする
誤って開発環境の通知を本番に送信してしまうリスクを減らすため、通知の送信画面を本番環境と開発環境で区別できるデザインにしていました。
具体的には、開発環境と本番環境でインターフェースの色合いやデザインを大きく異なるものにしていました。
例えば、開発環境ではヘッダーの色などを、本番のデザインとかけ離れたデザインにします。(Qiitaをブラウザ上で編集したイメージです。)
| 本番環境 | 開発環境 |
|---|---|
 |
 |
<Header background={isDev ? pink : green} />
テストの送信内容を誤送信しても問題ないものにする。
過去にSlideShareでバズっていましたが、「うんこ」など不適切な文言をテスト文言に使用するのは絶対にやめましょう。引用した記事と被りますが、人間は必ずミスをするので、失敗しても良い文章やデザインを使うようにします。卑猥な単語だけでなく、実在する企業名や、フルネームなどいろいろアンチパターンがありますが、テストだとしても、必ず適切なテスト文章を用意して使うようにしましょう。
実際に誤送信でニュースになっている事例
「ゲリラや特殊部隊による攻撃が発生しました」 Yahoo!系アプリで通知の誤配信、原因は調査中
「国道40号ばばばばばえおうぃおい～」 2021年の誤配信からみる教訓
「テスト」単体や、くだけた文章などもやめたほうが良いと個人的には思っています。
下記は「テスト」と送ってしまったことでニュース記事になっています。
プッシュ通知などであれば、普段送られている文言に寄せて「新作メニューを確認してみませんか？」など、送られてきても違和感がない文言を社内wikiなどに用意して、それを使うようにしたほうが良いと思います。
本番環境での通知送信時に1発で送れないようにする
送信ボタンを押した際に、「本番環境へ送信します。この文言で問題ないですか？」といったAlertを表示したり、送信する内容が多い場合は、確認画面を1ページ挟むように実装していました。
人間慣れてくると警告や確認画面すら見ずに送信してしまいますが、一応のチェックをかけていました。
今なら、長文のメール等の場合はChatGPTなどのAIで添削や確認などを挟んでも良いかもしれません。
送信監視編
送信後の確認機能
通知を送信した後、必ずその送信が正しく行われたかを確認できる環境を作っていました。
自分の場合は、プロジェクトのデータ可視化ツールを活用していました。
OSSのMetabaseなどを利用して、ダッシュボードに日々の送信の成功と失敗数や日時などをDBに保存しておき、ダッシュボード上で誰でも確認できるようにしていました。
しきい値を設定しておき、成功や失敗の数に大きな変動があった場合に、管理者のSlackにメンション通知が飛ぶようにしていました。1度これを設定していたおかげで、リリース後に新規登録メールが機能していなかったことに素早く気づくことができました。
CPaaS NOWではSMS・メール・認証コードの配信結果をWebhookで取得できるようなので、より手軽に管理者へアラートを飛ばす事ができそうです。
送信に使っている利用サービスの監視
自分たちの実装と送信だけでなく、通知の送信に使っているサービス自体も監視対象にしていました。
外部のAPIサービスを利用している場合、そのサービスが提供するステータスページやAPIを活用して、サービスの稼働状況を確認し、ステータスが変動した際に、Slackやメールで管理者に通知が飛ぶような仕組みを作っていました。
滅多にないのですが、障害が発生したり、メンテナンスによって止まることに前もって気づけて用意しておくと便利でした。通知領域に限らず、おすすめです。
今後の開発について
通知は身近な分、やらかしによってプロダクトの評価やユーザー体験を大きく左右する重要な要素です。
失敗を防ぐために、今回紹介した対策などを取り入れていくことで、やらかしが減るかと思います。
今後も新しい対策を取り入れながら、ユーザーの信頼を守り続けていきましょう。
最後まで読んでいただき、ありがとうございました。
もしこの記事が役立った、または他にも意見があれば、ぜひコメントでお知らせください！