多くのチームは「緊急」を不安の言い換えとして使っている
多くの小さなチームでは、「緊急」は仕事の種類を表す言葉ではありません。誰かがどれだけ焦っているかを表す言葉になっています。
依頼が遅れて届いた。顧客の声が強い。マネージャーが、重要な論点がまだ曖昧なことに不安を感じている。すると、その仕事は「緊急」と呼ばれ、全員がすぐ反応するべきだという空気が生まれます。
その場では責任ある対応に見えますが、運営としては悪い癖です。大事な仕事と、本当に待てない仕事の区別が消えるからです。そうなると chat が予定表の代わりになり、割り込みが初期設定になり、いつ集中してよいのかが誰にも分からなくなります。
「緊急」は重要度ではなく、待つと損害が出ることを指すべき
緊急は、重要と同じ意味ではありません。
重要な仕事は、今週の中でしっかり注意を向ける価値があるかもしれません。でも緊急な仕事とは、次の確認ポイントまで待つと即時の損害が出るので、通常の流れを中断すべき仕事のことです。
小さなチームで言えば、その損害はたいてい狭く、具体的です。
- 顧客向けの障害
- 今日中の売上に影響する問題
- 同日対応が必要な法務やセキュリティの問題
- 数日後ではなく、数時間以内に守る必要がある対外的な約束
それ以外の仕事は、たとえ重要でも、計画・意思決定・レビューの通常の仕組みに入れるべきです。そうしてはじめて、小さなチームは「速さ」ではなく「落ち着き」を最適化すべき理由 が思想ではなく運営になります。
ツールが速いほど、あいまいな緊急は高くつく
以前から、あいまいな緊急はムダを生んでいました。今はそれが、より速く、より騒がしくなっています。
chat ツールはエスカレーションを簡単にし、通知はどこまでも人を追いかけます。AI は、ぼんやりした懸念でも数秒で整った文面に変えられます。つまり、まだ未整理なだけの論点でも、いかにも深刻で、割り込みを許すべきもののように届きやすくなっています。
チームが「緊急」を文章で定義していなければ、初期設定は感情ベースの緊急になります。いちばん強い言い方をした人が、次の注意を奪うのです。だから Slackを管制塔のように使うのをやめる は重要です。chat は本当に緊急な経路を案内するものであって、何に全員が手を止めるかを決める場所ではありません。
10秒で判定できる緊急ルールを作る
1. 当てはまるケースを少数だけ先に書く
最初にやるべきなのは、ほとんどの仕事が明確に当てはまらないくらい、緊急の範囲を狭く定義することです。
具体例を 3 つから 5 つだけ書いてください。リストが長くなり始めた時点で、そのカテゴリはもう崩れ始めています。拾いたいのは「あらゆる気まずい状況」ではなく、「通常の流れでは遅すぎる、まれなケース」です。
2. 緊急連絡の経路を一本にする
緊急の連絡は、あらゆるチャネルから同時に飛んでくるべきではありません。
営業時間内の専用チャンネル、電話番号、当番連絡先など、経路をひとつ決めてください。そして最初の連絡には毎回、次の 3 点を入れます。
- 何が起きたのか
- 誰が対応オーナーなのか
- 次の更新をいつ出すのか
それだけで、緊急がチーム全体のパニックに変わりにくくなります。
3. それ以外の返答目安も決めておく
緊急ルールが崩れる大きな理由のひとつは、非緊急の仕事に返答目安が何もないことです。
普通の質問がいつ見てもらえるのか分からなければ、人はそれを無理やり緊急レーンへ押し込み続けます。非緊急の仕事にも置き場を作ってください。次の確認ポイントまで、当日中まで、あるいは週次リズムの中で扱う、といった形です。5人チームのためのシンプルな週次運営リズム が効くのは、仕事がいつ明確になるのかを先に示してくれるからです。
4. 該当例と非該当例の両方を文書に残す
「何が緊急か」だけでなく、「何が緊急ではないか」も見えるようにすると、定義は強くなります。
たとえば、次のようなものを非緊急の初期設定として書いておけます。
- 社内の承認依頼
- 通常のプロジェクトの遅れ
- 依頼が遅く届いただけの仕事
- 顧客への即時影響がない不具合修正や機能アイデア
実際にトラブルが起きたあとにこの一覧を見直してください。本当に緊急だったものがあれば例に加える。緊急と呼ばれたけれど本来そうではなかったものがあれば、それも残します。
緊急かどうかを決めるひとつのルール
次の確認ポイントまで待っても、顧客、売上、法務、セキュリティに即時の損害が出ないなら、それは緊急ではありません。
小さなチーム向けの最小限の緊急ポリシー
このくらいの短さで十分です。
緊急に当たるもの:
- 顧客向けの障害、または中核フローが止まる不具合
- 今日中の売上に影響する問題
- 同日対応が必要な法務・セキュリティ問題
原則として緊急ではないもの:
- 社内の承認依頼
- プロジェクトの進捗共有
- 遅れて届いた依頼
- 即時の対外影響がない通常の不具合や機能アイデア
緊急の経路:
- 指定したひとつのチャンネルか連絡手段だけを使う
- 影響、担当者、次の更新時刻を最初に書く
返答目安:
- 緊急: 営業時間内はすばやく受領を返す
- 非緊急: 次の確認ポイントか 1 営業日以内に返す
大事なのは完璧な文書を作ることではありません。普通の火曜日に、チームのふるまいが揃うことです。
緊急ルールが静かに壊れるとき
ひとつ目の失敗は、リーダーが選択肢を残したくて定義を広げすぎることです。それでは、言い回しが少し整うだけで、同じ割り込み文化が残ります。
次の失敗は、複数の緊急経路を並存させることです。Slack、メール、テキスト、DM のどれでもエスカレーションできるなら、そのチームにルールはありません。競合するアラームがいくつもあるだけです。
最後の失敗は、計画が遅れたことを緊急と呼ぶことです。早く決めていれば避けられた仕事は、やはり計画の問題です。その事実を隠し続けると、「緊急」は仕組みを直さないための言い訳になります。
緊急は「たまにしか起きないもの」であるべき
良い緊急定義は、小さなチームを遅くしません。むしろ、速く反応するべき場面を信頼できるものにします。
緊急が狭く、文書化され、一本の経路に流れるようになると、本当に必要なときだけすばやく動き、それ以外の時間は落ち着いて進めるようになります。
