運用アラートの設計｜鳴らしすぎると、誰も見なくなる

最初はチャットに書くだけだった

このお知らせ欄の記事は、毎朝AIが自分で書いて自分で本番に反映している。
以前はここまで自動化されていなかった。
人が承認してから公開する仕組みだった。
承認ゲートを外したのは今年の夏、記事を止めずに毎日回すためだった。
承認をやめた代わりに、毎回の作業結果はチャットの画面に長いレポートとして残すようにした。
掲載した記事のタイトルと本番URL、検証の結果、Zennの下書きの本数まで、その日にやったことを全部そこに書き出す。
だが正直に言うと、そのレポートを自分から毎朝開いて読むかというと、そうでもなかった。
忙しい日が続けば、数日分のレポートがチャットの中に埋もれていく。
そのときにひとつ心配事が残った。
何かあったとき、誰にも気づかれないまま放置されるのではないかということだった。

通知を増やしたくなる瞬間

最初に思いついたのは、動いたらすべて通知することだった。
記事を公開したら通知、Zennの下書きを作ったら通知、SQLを本番に流したら通知。
念のため全部知らせておけば安心だと思っていた。
実際にやってみると、毎日同じような文面のプッシュ通知が届くようになった。
数日もすると、内容を読まずにスワイプして消すようになっていた自分に気づいた。
なかには「本日も記事を1本公開しました」というだけの通知も混じっていて、それを開く手間の方が読む価値より大きくなっていた。
通知は増やすほど安心になるわけではなく、増やすほど読まれなくなる。
これは運用を始める前には分からなかったことだった。

絞った基準は2つだけ

そこで通知を送る条件を2つだけに絞った。
ひとつは、本番反映が失敗したとき。
記事の検証やSQLの投入でつまずくと、その日の記事が公開されないまま穴が空いてしまう。
これは黙っていると翌日以降も気づかれない種類の問題なので、必ず知らせる。
このとき送る通知には「何が失敗したか」と「原稿はpendingフォルダに残してある」という2点を必ず書くようにしている。
通知だけ見て、まず何をすればいいかが分かる文面にしておかないと、結局レポート全文を読みに行く手間が発生してしまうからだ。
もうひとつは、Zennへの転載用原稿が溜まったとき。
Zenn側には自社サイトのような監視の仕組みがなく、投稿を忘れると何本でも積み上がってしまう。
この2つ以外は、レポートには書くが通知は送らない、と決めた。

3本・3日という数字で線を引いた理由

Zennの通知は「未投稿が3本以上、または最も古いものが3日以上前」という条件にした。
最初は1本でも溜まったら知らせようかと思ったが、それでは結局さっきの失敗を繰り返すことになる。
Zennは前回投稿から24時間空けないと次を投稿できない制約があるので、1日1本のペースでしか消化できない。
その消化ペースを踏まえると、1本や2本の滞留は正常運転の範囲内で、慌てて知らせる必要がない。
実際に過去、通知の仕組みがなかった期間に4本が投稿されないまま放置されたことがあった。
その反省から、放置すると本当に損をする水準はどこかを先に数字で決めておくことにした。
感覚で「多いから知らせよう」とすると、結局また毎日通知することに逆戻りしてしまう。
24時間に1本という制約は、実際に運用してみて初めて実感した数字でもある。
最初にこの仕組みを作ったときは、原稿さえ用意すればすぐ公開できるものだと思い込んでいた。

通知しない日のほうが多い設計にした

今のこの仕組みは、平常運転の日は何も送らない。
記事は公開されているし、Zennの下書きも許容範囲に収まっているからだ。
何も届かないことが「正常に動いている合図」になるように作った。
これは裏を返せば、何か届いた日は必ず見てほしいというメッセージでもある。
毎回同じ強さで鳴らす仕組みは、結局どの音も同じ重さに聞こえてしまう。

サイトの通知機能も同じ考え方で作っている

この設計は、コンテナのWEBプッシュ通知機能を作ったときの考え方と近い。
何でも通知すればいいわけではなく、訪問者にとって本当に価値がある更新だけを届けるための機能として用意している。
自分たちの運用でも、製品として提供している機能でも、通知の値打ちは「頻度を絞ること」で決まるのだと思う。

詳しい機能の使い方はWEBプッシュ通知のページにまとめている。