はじめに
iOSアプリ、Androidアプリのグロースには欠かせないプッシュ通知ですが、今月はプッシュ通知の誤配信が多いように感じます。
プッシュ通知誤配信そのものも「やってしまった」という精神的ダメージがありますが、配信データをちょっと工夫することで二次災害は防げるのではないかと思い記事を書くことにしました。
この記事で伝えたいこと
プッシュ通知の検証をする場合、検証環境（staging,test）であっても無難なものにしておきましょう。
プッシュ通知に限らず「テストデータはワンチャン漏れる」という意識で、本番環境で配信しても良い内容だとより良いです。
事例と考えられる対応策
1. 「テストです」
何が問題（二次災害）か
「テストです」という見慣れない文言を見ると、多くの人はついタップしてしまいます。
多くの人がついタップして、多くのユーザーを抱えているサービスほどアクセスが集中します。
その結果サーバーが繋がりにくくなりやすいです。
こうすると良さそう
本番環境で最悪流れてもよく、常日頃から促したい行動につながる通知が良さそうです。
例えば
d払いなら、「オトクなキャンペーンをアプリからチェック！」
PASMOなら、「チャージも定期券の購入も、アプリなら並ばず可能！」
のような通知だと二次災害が少なくなりそうです。
気をつけること
テストだからといって自分やチームメンバーの名前を入れてはいけません。
ネットニュースなどに晒されてしまうためです。
2. 「【政府発表】[配信テスト][dev]ゲリラや特殊部隊による攻撃が発生しました。（14時06分）」
何が問題（二次災害）か
-
一瞬、本当のことだと思ってしまう
信頼できるサービスからの通知であるほど、嘘でも一瞬信じてしまいやすいです。 -
通知内容が無駄に怖い
テストデータはワンチャン本番に出てしまうかもしれない・・
こうすると良さそう
-
ありえない内容だとすぐに分かるようにする
「ネコが世界を征服しました」
少し苦しいですが、ありえないと思えるほど二次災害が減りそうです。 -
訓練としての通知にする
「こちらは訓練用の通知です。」
見た人がパニックにならないという意味では有効そうです。
おわりに
DevOpsが一般的になってきたおかげで、開発者・テスターの冷や汗をかくような作業は減らしやすくなってきました。その一方で、まだプッシュ通知検証のようなヒヤヒヤしてしまう作業は残っています。
開発者、テスターも人間なので12月末までになんとか間に合わせようとして焦ってしまうこともあるかと思います。
ポストモーテムの考え方にあるようにミスを責めるのではなく、どうしたら（できるだけがんばらない方法で）再発を防げるのか、起こしてしまっても前よりマシな状況にできるかという仕組みづくりに力を入れていけると良いなと思いました。
こういった悲しい障害は少しでも軽減できればと思っているので、より良いアイデアがあればぜひ教えていただけると助かります。