いつ知らせ、いつ黙るか──通知とサイレント

自動化されたシステムは、絶えず小さな判断をしている。いま起きたことを、利用者に知らせるべきか。それとも、黙っていてよいか。バックアップが完了した。ファイルが同期された。支払いが処理された。一つひとつについて、システムは「通知する」か「サイレントで済ませる」かを選んでいる。その選択の積み重ねが、使い心地そのものをかたちづくる。

「知らせる」が向く出来事

まず、知らせるべき出来事から考えたい。判断軸は単純だ。利用者の判断や行動を必要とするなら、知らせる。たとえば、決済に失敗してカードの再登録が要るとき。容量が上限に近づき、何かを削除する必要があるとき。あるいは、誰かが自分のアカウントに別の端末からアクセスしたとき。これらは、知らせなければ利用者が動けない、あるいは見過ごせば不利益が及ぶ出来事だ。沈黙が損失につながる場面では、通知は親切である。

緊急度に応じて、届け方も変わる。すぐ手を止めるべきものは割り込ませ、急がないものは静かに溜めて後で見せる。これは本サイトで論じた割り込みの設計と地続きの話だ。「知らせる／黙る」の二択の内側に、さらに「どれだけ強く知らせるか」の段階がある。

「黙る」が向く出来事

一方、黙ってよい出来事もある。利用者が必要なときに確認できれば足りるもの──たとえば、定期バックアップが無事に終わったこと、ファイルが正常に同期されたこと。これらは「うまくいって当然」の処理であり、成功するたびに報告されても、利用者には対応すべきことがない。むしろ、毎回の成功通知は害になりうる。

なぜ害になるのか。成功の知らせが続くと、人はやがて通知欄を見なくなる。「どうせまた、終わりましたの報告だろう」と。そうして通知が背景に溶けたころ、本当に手を止めるべき失敗の知らせが、同じ場所に紛れて届く。見慣れた成功通知の山に、ただ一件の異常が埋もれる。何でも知らせる設計は、皮肉にも、肝心なときに気づかれないシステムを育ててしまう。

沈黙には、裏づけが要る

ならば、成功はすべて黙ればよいのか。ここに落とし穴がある。黙るシステムは、順調なときも沈黙し、壊れたときも沈黙する。利用者から見れば、「うまくいっているから静か」なのか「止まっているのに気づいていないから静か」なのかが、区別できない。沈黙が二つの意味を持ってしまうのだ。

だから「黙る」設計には、条件がつく。普段は黙っていてよいが、異常のときには確実に、はっきりと声を上げる──その保証がなければ、沈黙はただの放置になる。システムの内部で何が起きているかを追える可観測性が効いてくるのは、まさにこの局面だ。内側で異常を検知できているからこそ、外側に向けて「普段は黙り、いざとなれば知らせる」を成立させられる。検知のない沈黙は、信頼ではなく、たまたまの無事に支えられているにすぎない。

知らせ方は、態度の表明である

通知とサイレントの線引きは、技術的な細部に見えて、実は提供する側の態度の表明だ。利用者の注意を尊重し、本当に必要なときだけ声をかけるのか。それとも、自分たちの存在を示したいがために、何でも報告するのか。後者は一見、丁寧で透明に見える。だが受け取る側からすれば、それは雑音であり、信頼を少しずつ削っていく。

よく設計されたシステムは、おしゃべりではない。順調な日々には静かに働き、利用者の判断が要る瞬間にだけ、はっきりと口を開く。いつ知らせ、いつ黙るか──この問いに一律の正解はない。出来事ごとに、利用者の利益という一点に照らして決めるほかない。だが少なくとも、「とりあえず全部知らせておく」は、配慮ではなく判断の放棄である。何を伝え、何を伏せるかを引き受けること。その引き受けの中にこそ、見えない設計の誠実さは宿る。

参考資料

1. Nielsen Norman Group によるアラート・通知設計のガイドライン — nngroup.com
2. Betsy Beyer ほか『SRE サイトリライアビリティエンジニアリング』オライリー・ジャパン（アラート設計と「意味のある通知」）