切り戻し手順があるのに事故る理由 — 「発動基準」の書き方

TL;DR

• 切り戻しの事故は「手順がない」からではなく「いつ発動するか決めてない」から起きる
• • 発動基準は 観測可能な条件 + タイムリミット の2軸で、作業前に固定する
• • ポイント・オブ・ノーリターンは切り戻し所要時間から逆算する

よくある光景

深夜のリリース作業。手順書には立派な切り戻し手順が書いてある。でも本番でトラブると——

「あと5分粘れば直りそうな気がする」
「切り戻すと明日また作業申請か…」
「これ、切り戻すほどのやつかな?」

と、人間は必ず粘ります。粘った結果、切り戻しにも間に合わなくなって朝を迎える。これが典型的な事故パターンです。

問題は判断力ではありません。判断を現場のプレッシャー下でやらせる設計が問題です。

発動基準の書き方

作業前に、以下の形式で「切り戻しを開始する条件」を固定します。

#	条件	判断者
1	手順5の期待結果が 15分以内 に得られない	作業者(即時発動可)
2	23:30(ポイント・オブ・ノーリターン)までに手順7が未完了	作業責任者
3	対象システムで作業と因果不明の重大アラートが発生	作業責任者

ポイントは3つ。

1. 観測可能な条件で書く

「問題が発生した場合」はNGです。観測できないので、解釈の余地=粘る余地が生まれます。「手順nの期待結果がn分以内に得られない」のように、誰が見てもYes/Noが割れない条件にします。

2. タイムリミットは逆算で決める

ポイント・オブ・ノーリターン = 作業枠の終了時刻 − (切り戻し所要時間 + 正常性確認 + バッファ)

例: 作業枠が24:00まで、切り戻し20分、確認15分、バッファ10分 → 23:15がリミット。これを手順書に書いておくと、23:15に「まだ粘るか」の議論自体が発生しません。

3. 判断者を決めておく

「即時発動できる条件」と「責任者判断の条件」を分けます。全部を責任者判断にすると、連絡がつかない5分間でリミットを越えます。

おまけ: 手順書自体の「型」

発動基準を含め、手順書に最低限必要な骨格はこれだけです。

1. 作業概要(目的・影響範囲・前提条件)
2. 1. 事前確認(チェックリスト)
3. 1. 作業手順(操作+期待結果のセット)
4. 1. 正常性確認(サービス/システム/監視の3視点)
5. 1. 切り戻し(発動基準+手順)

この型に沿って入力するだけで手順書ができるWebツールを作りました。無料で、データはブラウザの外に出ません(手順書は機密の塊なので、ここは徹底しました)。

👉 手順書メーカー: https://kazu-apps.github.io/tejun-maker/

Markdown/テキスト出力にも対応しているので、生成した手順書はそのまま社内Wikiやサクラエディタに貼れます。感想・改善要望お待ちしています。