21時にベッドへ入っても、Slackのバッジがちらつく感覚が消えない。試しに通知をオフにしてみた翌朝も、未読の数字が気になって結局アプリを開いた。あなたが本当に消したかったのは通知ではなく、いつでも返信を求められているという感覚そのものだったはずだ。
flowchart TD
A[通知オフ] --> B[不安は残る]
B --> C[真因は返信回数]
C --> D[時間を宣言]
D --> E[例外だけ通す]
通知を切っても、既読の重さは消えない#
通知オフは一見、正しい対処に見える。バッジが消えれば、少なくとも視覚的な割り込みは止まる。
だが実際にやってみると、チェックする回数はむしろ増える。見えない間に何が来ているか分からない不安のほうが、通知が見えている不安より重いからだ。
通知疲れは個人のわがままではなく、多くの職場で共通して起きている現象だ。
不安の正体は通知の量ではなく、返信回数の予測不可能性#
通知を切っても、チームの中にある暗黙のルールは消えない。「Slackは見たらすぐ返す」という前提が共有されている限り、あなたはいつ呼び出されるか分からない状態に晒され続ける。
減らすべき変数は通知の可視性ではない。返信という行為が、1日に何回発生するかという回数そのものだ。回数が読めないから、通知を消しても神経は張ったままになる。
案件を掛け持つ疲弊の正体が往復の回数にあるのと同じ構造がここにもある。未読の発生源そのものを仕分ける話は別に書いた（AIが集中力を治すと言われても、Slack未読200件の動悸は消えない）。ここで扱うのは発生源の仕分けではなく、返信という行為の頻度を固定する運用そのものだ。
返す時間を1日2回、チームに宣言する#
打つ手は難しくない。返信する時間帯を1日2回決め、チームに先に知らせておくことだ。時間を決めるのはあなたであって、Slackのアルゴリズムでも部下の都合でもない。
Slackへの返信は 11:00 と 17:00 にまとめて行います。
それ以外の時間は既読が付かないことがありますが、
見落としではなく運用です。宣言した瞬間から、相手も「いつ返ってくるか」を予測できるようになる。予測できるということは、あなたが今すぐ反応しなくても、相手の不安も同時に下がるということだ。
この仕組みで本当に減るのは、あなたが払っていた無給の対応労働だ。返信の待ちぼうけが課長の無給時間に転嫁される構造から抜ける第一歩がここにある。
緊急の定義を1行に絞り、例外だけを通す#
時間を宣言しただけでは、例外が際限なく発生する。「これは緊急です」と言われるたびに枠が崩れるからだ。緊急の定義を先に1行で固定し、それ以外は問答無用で待たせる。
緊急の定義:顧客対応が今この瞬間に止まっている場合のみ。
それ以外は 11:00 / 17:00 の返信枠まで待ってください。
緊急時は電話で連絡してください。Slackでは気づけません。電話という別チャネルを例外の入口にするのは、Slackの中に例外を残さないためだ。同じアプリの中に「急ぎ」のタグを作ると、結局そこに判断が集中して枠は形骸化する。断る基準を圧力が来る前に決めておくのと同じ発想で、例外の通り道も事前に1本だけ用意しておく。
宣言を破られたときの逃げの一手#
宣言しても、最初の数日は破られる。緊急でもないのに即レスを求めてくる相手が必ず現れる。
そのときは反応せず、次の返信枠まで待ってから「緊急の定義に当てはまらなかったので、17:00にまとめてお返事します」とだけ返す。説明はこの一文で十分で、謝罪も言い訳も要らない。
相手が上司で、宣言そのものを認めないなら話は別だ。その場合は断るコストを先に設計で潰しておく話にあるとおり、個人の交渉に持ち込まず、チーム全体のルールとして上司に提示し直す。それでも崩れるなら、宣言を1日だけ諦めて様子を見てよい。崩したことを責める人間はいない。
まとめ：Slack疲れを消すのは通知設定ではなく、返信回数の固定だ#
通知をオフにしても、返信を期待される回数は減らない。時間帯の宣言と緊急の1行定義だけが、その回数を実際に固定する。
本記事は AI が下書きし、管理人が監修しています。
査定に載らない組織仕事を振られたその日に、そのまま出せる定型文が3通ある。
→ 期待値コントロール定型文集（抜粋版）続きはタイムラインに置いていく。
