インシデント対応のスタンスと動き方 — 責めない、しかし当事者がリードする

システムを運用していれば、障害は避けられません。どれだけ丁寧にテストを書いても、どれだけレビューを重ねても、本番環境はいつか壊れます。分散システムが複雑になるほど、すべての故障を事前に想定し切ることは不可能に近づきます。だから、問われるのは「障害を起こすかどうか」ではなく「起きたときにどう動くか」です。

本記事は、インシデント対応におけるスタンスと動き方について、私が普段チームに伝えていることを整理したエッセイです。伝えたいことは 3 つに集約されます。インシデントを起こしてしまったこと自体は責めない。しかし、原因を作った当事者には、責任を持って対応をリードしてほしい。そして、リーダーという肩書きの有無にかかわらず、その場にいる誰もがリーダーシップを発揮して動いてほしい。この 3 点を、blameless postmortem や Just Culture、incident command といった確立された考え方を補助線に掘り下げます。

起こしたこと自体は責めない — blameless という前提

まず出発点として、インシデントを起こしてしまったこと自体を、個人の責任として責めることはしません。これは温情ではなく、障害から学び、同じ障害を繰り返さないための、合理的な運用上の選択です。

この考え方を体系化したのが、Google SRE の言う blameless postmortem です。Postmortem Culture: Learning from Failure では、blameless に書かれた postmortem は「インシデントに関わった全員が、そのとき手元にあった情報のもとで、善意で正しいことをしようとした」と仮定する、と述べられています。誤った操作をした人、危ういコードを書いた人を吊るし上げるのではなく、なぜそのとき、その判断が理にかなって見えたのかを問う。原因を人ではなく、システムやプロセスに探しにいく姿勢です。

安全工学の分野では、この考え方はさらに踏み込んで語られてきました。Sidney Dekker 氏は、human error（ヒューマンエラー）は障害の原因ではなく、その奥にあるシステム上の問題が表に出た症状にすぎない、と繰り返し説いています。人を取り替えても、同じ状況に置かれた別の人が同じ間違いを犯すなら、直すべきは人ではなくシステムのほうです。

なぜ責めないことが合理的なのか。理由はシンプルで、責める文化は情報を隠すからです。ミスをした人が吊るし上げられる環境では、次からみんなが自分の関与を小さく見せようとします。障害の第一報が遅れ、本当に何が起きたかが見えにくくなり、結果として復旧が遅れ、再発防止も甘くなります。逆に、正直に「私がここで設定を間違えました」と言える環境は、Amy Edmondson 氏の言う心理的安全性（psychological safety）が効いている状態であり、そこでは事実が早く集まり、対応も学びも速くなります。責めないことは、優しさである以前に、速さと再発防止のための投資です。

「責めない」は「無責任」ではない — 当事者が対応をリードする

ここで、大切な線引きがあります。「起こしたことを責めない」は「起こした人が何もしなくてよい」という意味では、まったくありません。責めないことと、責任を持って対応することは、両立します。むしろ両立させなければなりません。

この区別を鮮やかに示しているのが、Dekker 氏の Just Culture における、2 種類の accountability（責任）の対比です。一つは retributive accountability（応報的な責任）で、どのルールが破られ、誰にどんな罰を与えるべきかを問います。もう一つは restorative accountability（修復的な責任）で、誰が困っていて、何が必要で、どうすれば信頼と学びを取り戻せるかを問います。blameless が手放すのは前者の「罰としての責任」であって、後者の「前を向いて立て直す責任」ではありません。

そして、この修復的な責任を最も効果的に果たせるのは、多くの場合、原因を作った当事者です。その変更を入れた本人が、なぜその変更をしたのか、何を見落としていたのか、周辺に何が繋がっているのかを、いちばん深く知っています。だからこそ、当事者には逃げずに前に出て、対応をリードしてほしい。止血の指揮を執り、事実を出し、postmortem を自分の手で書き、再発防止のアクションを引き取る。これは罰ではなく、最も多くのコンテキストを持つ人が、そのコンテキストをチームのために使うという、ごく自然な役割分担です。

当事者が逃げずに前に出る姿は、チームにとって何よりの学びになります。「ミスをしても、正直に前に出て立て直せば、責められるどころか信頼される」という実例が一つ積み上がるたびに、責めない文化は言葉ではなく体験として定着していきます。逆に、当事者が身を隠し、周りが尻拭いをする構図が続けば、blameless はただの「言った者勝ち」に堕ちます。責めないという約束は、当事者が責任を持って動くという振る舞いと対になって、はじめて機能します。

肩書きではなく、手を挙げた人がリードする — 分散したリーダーシップ

3 つ目のスタンスは、リーダーシップについてです。インシデント対応におけるリーダーシップは、役職や肩書きに紐づくものではありません。その場に居合わせ、最初に気づき、最初に手を挙げた人が、その瞬間のリーダーです。

この考え方には、災害対応の現場で磨かれた明確な型があります。incident command system（ICS）と呼ばれる枠組みで、Google SRE も PagerDuty の incident response ガイドも、これをソフトウェア運用に持ち込んでいます。ここで中心になる incident commander（IC）という役割は、最も偉い人でも、最も技術力の高い人でもありません。対応全体を調整し、意思決定を前に進める人であり、その場で宣言すれば誰でも担えます。実際、多くの現場では「ページャーを取った人が、その障害の IC になる」という運用がなされています。

だから、メンバーであっても、上位者の到着を待つ必要はありません。障害に気づいたら、自分でチャンネルを立て、状況を宣言し、必要な人を呼び、役割を割り振ってよいのです。リーダーシップは許可を求めてから発揮するものではなく、手を挙げた瞬間に始まります。もちろん、より適切な人が IC を引き継ぐべき場面はありますが、その引き継ぎ自体も、最初に動いた人がいてはじめて起こります。空白の数分間に誰も動かないことのほうが、権限の越境よりもずっと危険です。

私がメンバーに期待しているのは、この「待たない」という動き方です。自分がリーダーでないから、自分が原因ではないから、と一歩引くのではなく、その場をよくするために自分にできることを見つけて動く。インシデントは、肩書きに関係なくリーダーシップが試される場であり、同時に、それを発揮するいちばんの機会でもあります。

動き方の型 — 止血・宣言・記録・引き継ぎ

スタンスを具体的な行動に落とすと、対応にはいくつかの型があります。慌てているときほど、型に沿って動けることが効いてきます。

止血を最優先する: Managing Incidents が説くように、まずやるべきは根本原因の解明ではなく、被害を止めることです。ロールバック、フラグでの無効化、切り離しなど、サービスを復旧させる手段を先に打つ。原因の調査は、出血を止めてから落ち着いてやればよいものです。
役割を宣言する: 一人で抱え込まず、IC（全体の調整）・comms（社内外への連絡）・scribe（記録係）といった役割を早めに切り出します。規模が小さければ兼務でよいですが、「今は自分が IC です」と口に出すだけで、指揮系統が明確になります。
オープンに情報を出す: 専用のチャンネルを立て、わかっていること・わからないこと・次の一手を、隠さず流し続けます。憶測と事実を分けて書くことも大切です。情報を出し惜しみすると、周りが状況を推測で埋めはじめ、混乱が増えます。
タイムラインを残す: いつ何が起き、いつ何をしたかを、その場で時系列に記録します。この記録が、後の postmortem の一次資料になり、記憶に頼った再構成よりもはるかに正確な振り返りを可能にします。
長期化するなら引き継ぐ: 対応が数時間に及ぶなら、疲れた頭で判断を続けるより、交代したほうが安全です。誰が単一障害点になっているかを意識し、権限とコンテキストを明示的に渡せる状態を保ちます。

これらは、当事者が一人で完璧にこなすべきものではありません。当事者が対応をリードしつつ、その場の全員がリーダーシップを発揮して型を埋めていく。先ほどの 3 つのスタンスは、この動き方の中で一つに繋がります。

振り返りを学びに変える — blameless postmortem

障害が収束したら、最後に残るのが振り返りです。ここでも、責めないことと当事者が責任を持つことが、両立します。

postmortem の目的は、犯人探しではなく、システムとプロセスを強くすることです。同じ障害が二度と起きないように、あるいは起きても被害が小さく済むように、恒久的な対策をアクションアイテムとして残します。ここで問うべきは「誰が間違えたか」ではなく「なぜその間違いが起こりやすい状態だったのか」「どうすればその状態自体をなくせるか」です。ガードレールが足りなかったのか、アラートが遅かったのか、手順が属人的だったのか。原因をシステムの側に探しにいくほど、再発防止は具体的になります。

そして、その postmortem を書く主体は、多くの場合、原因を作った当事者であってよいのです。自分の手で経緯を言語化し、システム側の課題として整理し、対策を引き取る。これは自己処罰ではなく、最も深いコンテキストを持つ人による、最も質の高い学びの生産です。書き上がった postmortem を広くチームに共有すれば、一つの障害が、関わっていない人まで含めた組織全体の学びに変わります。責めない文化のもとで当事者が前に出るからこそ、振り返りは正直で、深く、役に立つものになります。

まとめ

インシデント対応のスタンスと動き方を、3 つの軸で整理してきました。

起こしたこと自体は責めない: human error は原因ではなく症状。責める文化は情報を隠し、復旧と再発防止を遅らせる
当事者が責任を持って対応をリードする: 手放すのは罰としての責任であって、前を向いて立て直す責任ではない。最も深いコンテキストを持つ当事者が前に出る
肩書きではなくリーダーシップで動く: incident commander は役職ではなく役割。メンバーでも、手を挙げた瞬間からリードしてよい

インシデントは、起こさないに越したことはありません。しかし、いつか必ず起きるものである以上、そのときの動き方こそが、チームの実力と文化を映します。責めないこと、当事者が逃げないこと、肩書きに関係なく動くこと。この 3 つが噛み合ったチームは、障害のたびに少しずつ強くなっていきます。

以上、いくつものインシデントを間近で見てきた立場から、対応のスタンスと動き方について考えたことを、現場からお送りしました。