個人開発の運用を始めると、エラー、利用状況、支払い、問い合わせなど、見たい情報が次々に増える。心配だからと通知を足していくと、スマートフォンやメールが鳴るだけで、どれから動けばよいか分からなくなる。通知を作る前に、受け取った後の行動まで決めておくと運用しやすい。
通知したい出来事を書き出す
まず、今気になっている出来事を列挙する。サーバーの停止、処理の失敗、問い合わせの到着など、意味の違うものを一行ずつ分ける。「何か問題が起きたら」のように広くまとめると、通知の条件も曖昧になる。
誰がいつ見るかを決める
個人開発でも、通知を受け取る自分が常に対応できるわけではない。仕事中、睡眠中、移動中に届いた場合を考え、すぐ見るものと翌朝でよいものを分ける。即時対応できない情報を夜中に鳴らしても、疲れるだけになりやすい。
最初の一手を一行にする
通知ごとに、受け取った直後にすることを一つ書く。「管理画面の状態を見る」「直近の処理記録を開く」のように、迷わず始められる粒度にする。行動が思いつかない通知は、送る目的がまだ固まっていない可能性がある。
緊急度を通知先で分ける
すべてを同じメール箱へ送ると、重要な知らせが日常の情報に埋もれる。すぐ確認するもの、後でまとめて読むもの、記録だけ残せばよいものに分ける。音を鳴らす条件も、最も急ぐ種類に絞る。
同じ出来事を束ねる
短時間に同じ失敗が続くと、一件ずつ通知が届いて画面が埋まる。最初の一件を知らせ、その後は一定のまとまりで件数を伝える形を考える。復旧したときの知らせを別に用意すると、止まったままかどうかを判断しやすい。
通知文に判断材料を入れる
「失敗しました」だけでは、確認のために複数の画面を開くことになる。発生時刻、対象の処理、確認先を短く含める。一方で、利用者の個人情報や秘密の値を通知本文へ載せない。転送されても困らない範囲にとどめる。
月に一度、不要な通知を消す
受け取っても毎回読み飛ばす通知は、条件を変えるか停止する。逆に、問題に気づいたのに知らせがなかった出来事は追加候補として記録する。通知の数ではなく、受信後に迷わず動けたかを見直しの基準にする。
通知は不安を減らすための道具だが、行動と結び付かなければ新しい作業を増やす。小さなサービスの運用や開発記録は、Burning Tribeにもまとめている。