エスカレーション基準表のテンプレート

「この件、私が決めていいのでしょうか」。プログラムを進めていると、この質問が毎週のように出てきます。

そのたびに相談して決めていては、判断が止まります。かといって現場が勝手に決めると、あとで「聞いていない」ともめます。この板ばさみを解くのが、エスカレーション基準表です。

エスカレーションとは、問題を上の層に上げることです。基準表は、「どういうときに」「誰に」「いつまでに」上げるかを、あらかじめ決めておく表です。この記事では、プログラム向けの作り方を紹介します。

■ 背景・よくある課題

基準が決まっていないと、次のようなことが起きます。

とくに最後の項目が根深い問題です。基準表は、「上げるかどうか」を個人の勇気ではなくルールの問題に変えるための道具でもあります。基準にあてはまったから上げた、と言えれば、上げた人が責められる理由はなくなります。

■ 4つの層と、上げる時間

プログラムのエスカレーションは、ふつう4つの層で考えます。

大事なのは、右側の時間です。上げる基準だけを決めて、答える期限を決めない基準表をよく見かけますが、それでは機能しません。「3営業日以内に判断が出なければ、自動的に次の層へ上がる」というルールにして初めて、上げる側が安心して上げられます。

■ テンプレートの全体像

エスカレーション基準表は、次の8項目で作ります。1ページにおさまる分量にします。

作るときのコツは、2の「判定の指標」を数字にすることです。「重大な問題」「大きな遅れ」といった言葉で書くと、人によって解釈が変わり、結局は基準がないのと同じになります。

■ 記入例：サンフィールド運輸「物流DXプログラム」

物流会社サンフィールド運輸（年商96億円・拠点14か所・車両318台・荷主240社）が進める物流DXプログラムのエスカレーション基準表です。

回答期限は、L2が3営業日、L3が5営業日、L4が72時間です。それぞれの層で期限内に判断が出なければ、上げた人が何もしなくても自動的に次の層へ上がります。PMOがこの監視を担当します。

安全の行だけは特別扱いです。運行の安全にかかわることは、層を飛ばして直接L4へ上げてよいことにしています。時間との勝負になる区分は、このように例外を作っておきます。

実際に使われた例

1つめの例のように、「上げない」と判断したことも記録に残します。あとで問題が大きくなったとき、どこで判断したかをたどれるようにするためです。

■ 運用ルール

半年ごとの見直しは、忘れられがちですが必要です。プログラムが進むと、扱う金額の規模が変わります。立ち上げ期には100万円が大きな金額でも、終盤では日常的な変更になります。基準が実態に合わなくなると、上げる件数が急に増えたり減ったりします。これが見直しのサインです。

■ 活用シーン

• 新しいPMが入ったとき：この1枚を渡すだけで、裁量の範囲が伝わります。

• 判断に迷ったとき：区分と数字を見れば、相談すべきかどうかが自分で判断できます。

• 上げたのに動かないとき：回答期限を根拠に、次の層へ上げることができます。

• ベンダーとの会議で：どの規模の変更が誰の承認を要るのかを共有しておくと、見積りのやりとりが早くなります。

■ よくある失敗と直し方

■ 導入効果

相談件数が週18件から7件に減ったのに、判断は速くなっています。減ったのは「PMが自分で決めてよかった11件」です。基準表は、上げる仕組みであると同時に、上げなくてよいことを決める仕組みでもあります。

■ まとめ

• エスカレーション基準表は、「どういうときに」「誰に」「いつまでに」上げるかを先に決めておく1枚の表です。

• 層はL1（PM）・L2（PgM）・L3（運営委員会）・L4（経営）の4つ。層ごとに回答期限も決めます。

• 判定の指標は必ず数字にします。言葉だけの基準は、基準がないのと同じです。

• 期限内に判断が出なければ自動で次の層へ。上げた人が待ち続けなくてよい仕組みにします。

• 安全や法令など、階段を飛ばしてよい区分を例外として明記しておきます。

• 半年に1回、金額・日数が実態に合っているかを見直します。

次回は、プログラム全体に効く変更をどう審議するかを扱う「プログラム変更管理台帳」のテンプレートを紹介します。