Escalation Path

エスカレーションパスとは、スケジュールされたタスクの失敗が本当に人の介入を必要とするとき、通知を誰の手元に届けるか、どの経路で届けるか、そしてその人が一定時間以内に応答しなければ、自動的に次の担当者へ切り替えるかを明確に定義することを指す。これは fallback instruction（フォールバック指示）の中の「即座に停止し通知する」という選択肢が実際に実行される際の詳細を扱う。フォールバック指示は失敗を人に通知するかどうかを決め、エスカレーションパスは具体的にその通知をどう届けるか、誰に届けるか、応答がなければどうするかを決める。これは単に受信箱を一つ設定することとは違う。受信箱を一つだけ設定していると、その担当者がたまたま休暇中だったりメールを見落としたりすれば、通知はそこで止まり次の手立てがない。エスカレーションパスが求めるのは、時間制限とバックアップの担当者を備えた連鎖であり、責任が一人の人物のところで滞ってしまわないようにするものだ。

この仕組みが必要とされるのは、「誰かに通知すること」と「問題が実際に対処されること」が別のことであり、その間には見過ごされがちな前提がある。それは、その人が必ず通知を見て、必ずすぐに対応してくれるはずだという前提だ。実際には、通知を受け取った人が会議中だったり、休暇中だったり、大量の他の通知に埋もれて気づかなかったりすることがある。通知経路の終点が一つしかなければ、こうした事態が起きたとき、問題はそこで止まり、「この通知は実は対処されていない」ことに気づく仕組みが何もない。エスカレーションパスが存在する理由は、一人の人物がいつでも即座に応答できるとは限らないことを認め、時間制限と次の担当者を備えた連鎖を使って、「通知が送られたこと」と「問題を実際に誰かが対処していること」の間のギャップを埋めることにある。

実務では四つのことを定める。第一に、第一優先の受信者は誰か。通常はそのスケジュールタスクを直接担当し、対処法を最もよく知っている人物だ。第二に、どの経路で通知するか。本当に緊急の失敗に対しては、単純なメールでは十分に即時性がない場合があり、チャットやSMSなど、より即座に気づかれやすい経路と組み合わせるとよい。第三に、どれだけ待てば応答なしと判断するか。この時間はタスクの緊急度に応じて設定すべきであり、毎日データを更新する必要があるタスクなら1〜2時間応答がなければエスカレーションし、週に一度更新するタスクならより長い待機時間を設定できる。第四に、応答がないとき誰にエスカレーションするか。通常はその人の上司か、同じチーム内でそのタスクに詳しい第二の担当者であり、連鎖に次の手立てがあり、最初に応答しなかった人のところで止まらないようにする。この四点を明確にした後は、エスカレーションパス自体も定期的に見直す必要がある。チームメンバーの異動やタスクの緊急度の変化があれば、パスの設定を更新しなければならない。古くなったエスカレーションパスは、既に退職した人へ通知を送ってしまうことがある。

あなたにとって、エスカレーションパスが本当に変えるのは、問題が滞留する最長時間に上限が設けられ、「通知は送られたが誰も対処していない」状態が無期限に続かなくなる点だ。エスカレーションパスがない場合、スケジュールタスクが失敗し、通知がたまたま休暇中の人に届くと、その問題はその人が戻ってメッセージを確認するまで何日も止まったままになりかねない。エスカレーションパスがあれば、その待機には明確な期限が設けられ、期限が来れば自動的に次の担当者へ切り替わり、問題が一人の人物のところに無期限に滞留することはない。本当に注意すべきリスクは、エスカレーションパスは設定した後に忘れられやすい点だ。チームメンバーが退職したり異動したりした際にパスを同期して更新しなければ、連鎖のどこかに既に無効になった連絡先が残ってしまうことがある。この場合、エスカレーションパスは問題対処を速めるどころか、稼働しているように見えて実際には途切れているという見せかけを作り出してしまう。