同じ障害を繰り返さない振り返りと改善の型
「この障害、前にも起きませんでしたか」——障害対応の場でこの一言が出たら要注意です。原因はだいたい特定できていて、応急処置もその都度きちんとやっている。それなのに、数ヶ月後に形を変えて同じトラブルが再発する。この相談は本当に多く、原因を聞いていくと「振り返りの場はあるが、記録も再発防止も実装されていない」という共通点に行き着きます。この記事では、なぜ振り返りが機能しないのか、そしてどうすれば「同じ障害を二度と起こさない」型を組織に定着させられるのかを整理します。
なぜ振り返りをしても同じ障害が再発するのか
障害対応後に何かしらの振り返りをしている会社は多いです。それでも再発が止まらないのは、次のような理由があります。
- 犯人探しになってしまい、本音の情報が出てこない: 「誰がデプロイしたか」「誰がレビューしたか」を追及する空気になると、担当者は自己防衛のために事実を薄めて話すようになります。結果、表面的な原因しか共有されません
- 記録がどこにも残らない: 口頭で「次からは気をつけよう」で終わり、議事録もチケットも残らない。半年後に同じ障害が起きたとき、前回何を話したかを誰も思い出せません
- 再発防止のアクションが「気をつける」止まりで実装されない: 「今後は確認を徹底する」という精神論で終わり、コードやシステムに反映される具体的な変更が起きない。担当者の注意力に依存する対策は、担当者が変わった瞬間に失効します
この3つは独立した問題ではなく、連鎖しています。犯人探しの空気があるから本音が出ず、本音が出ないから記録する価値のある結論に至らず、結論が浅いから実装可能な再発防止策が出てこない、という悪循環です。ここを断ち切るには、振り返りの「型」そのものを変える必要があります。
ポストモーテムの型: 非難しない・時系列・根本原因・アクション
障害対応の振り返りは、一般に「ポストモーテム」と呼ばれる形式に沿って行うと機能しやすくなります。骨子はシンプルです。
1. 非難しないという前提を最初に宣言する
会議の冒頭で「今日は誰の責任かを決める場ではなく、仕組みの問題を見つける場」と明言します。これは単なる建前ではなく、実務上の効果があります。人は責められると自己防衛的になり、都合の悪い事実を隠します。逆に「あなたを責めない」という前提があると、「実はあの時、警告ログを見ていたが緊急度が低いと判断してしまった」といった、再発防止に直結する本音の情報が出てきます。この前提が崩れると、以降のどのステップも機能しません。
2. 時系列を客観的に再構成する
誰が何を判断したかではなく、「何がいつ起きたか」を時刻付きで並べます。
- 障害の予兆(エラー率の上昇、レイテンシ悪化など)が最初に観測された時刻
- 誰かが気づいた時刻、アラートが鳴った時刻
- 対応を開始した時刻、応急処置が完了した時刻
- サービスが復旧した時刻
この時系列があるだけで、「検知まで45分かかっている」「アラートが鳴ってから対応開始まで20分の空白がある」といった、感覚では気づけないボトルネックが可視化されます。
3. 根本原因を「なぜ」で深掘りする
表面的な原因(「デプロイでバグが混入した」)で止めず、なぜそのバグが混入したか、なぜレビューで気づけなかったか、なぜテストで検知できなかったかと、複数回「なぜ」を掘り下げます。多くの場合、行き着く先は個人のミスではなく、レビュー体制・テストカバレッジ・監視体制といった仕組みの不備です。ここで個人名が結論に出てくる場合は、掘り下げ方が浅い兆候だと考えてよいでしょう。
4. 再発防止アクションを「実装可能な形」まで具体化する
「気をつける」「ダブルチェックする」で終わらせず、次のように具体的な実装物に落とし込みます。
- 該当パターンを検知するテストを追加する(担当者・期限を明記)
- 危険な操作(例: 本番DBの直接操作)にコード上の防御を入れる
- 監視ダッシュボードにこの指標のアラートを追加する
- デプロイ前チェックリストに項目を追加する
「誰が」「いつまでに」「何を実装するか」まで書けて初めてアクションと呼べます。ここが曖昧なポストモーテムは、記録として残っても実行されずに終わります。
記録を資産にする: 検索できる場所に、テンプレートで残す
振り返りの内容は、口頭やSlackの流れるメッセージではなく、後から検索できる場所に残す必要があります。おすすめは次のようなシンプルなテンプレートをNotionやドキュメントリポジトリに固定することです。
- 発生日時・検知までの時間・復旧までの時間
- 影響範囲(誰が・何人・どの機能に影響したか)
- 時系列
- 根本原因
- 再発防止アクションと担当・期限
- 類似障害への横展開の要否
このテンプレートが蓄積されていくと、「このエラー、前にも似たものが起きていないか」を過去の記録から検索できるようになります。記録が資産化されていないチームほど、同じ議論を毎回ゼロから始めることになり、対応時間も長くなりがちです。
文化として定着させるには
型を1回導入しただけでは定着しません。継続させるための工夫がいくつかあります。
- 障害の大小にかかわらず、一定基準以上は必ずポストモーテムを書くルールにする。「今回は軽微だから省略」を許すと、いつの間にか誰もやらなくなります
- 再発防止アクションの実行状況を追跡する。書いて終わりではなく、次のスプリントやチケットボードで進捗を管理し、放置されたアクションを可視化する
- 経営層・マネージャーが「振り返りは責任追及ではない」を体現する。誰かが正直に失敗を話したときに責めるような反応をすると、その場で文化は崩壊します。心理的安全性は宣言ではなく、実際の反応の積み重ねで作られます
こうした運用は、障害対応が落ち着いてから後回しにされがちですが、根本対応が実装されないまま放置される構造そのものは障害が多いWebサービスを改善する優先順位で扱った「応急処置と根本対応を分けて考える」話と表裏一体です。ポストモーテムは、根本対応を実装まで運ぶための仕組みだと捉えると位置づけが明確になります。
外注が入る場合の進め方
社内に振り返りの型がまだ整っていない状態で外部の開発チームが保守・改善に入る場合、私たちは次のような順番で進めます。
- 直近数ヶ月の障害履歴をヒアリングし、既に繰り返しているパターンがないか洗い出す。同じ症状が名前を変えて再発している箇所は、根本原因が未解決のまま放置されているサインです
- 簡易的なポストモーテムテンプレートを導入し、次に発生した障害から運用を開始する。いきなり完璧な仕組みを作るのではなく、まず1回動かして型に慣れてもらいます
- 既存の障害履歴のうち、影響度・頻度が高いものから根本原因を遡って調査し、再発防止のコード変更を実装する。振り返りの型を作るだけでなく、過去分の「未実装の再発防止策」も並行して消化していきます
- 監視・アラートの不足箇所を洗い出し、検知までの時間を短縮する。ポストモーテムの時系列を見ると、多くの場合「検知の遅さ」がボトルネックとして共通して現れます
外部チームが入る価値は、社内では出しにくい「なぜこの障害は毎回同じ原因なのか」という指摘を、利害関係のない立場から率直に出せる点にあります。犯人探しの空気が社内に根強い場合ほど、第三者が非難しない前提を持ち込むことが振り返りの立て直しに効きます。
まとめ
- 同じ障害が繰り返される根本原因は、犯人探しになって本音が出ない・記録が残らない・再発防止アクションが実装されない、という3点に集約される
- ポストモーテムは「非難しない前提→時系列の客観的再構成→根本原因の深掘り→実装可能な再発防止アクション」の型で運用し、テンプレート化して検索できる場所に残すことで資産になる
- 文化として定着させるには基準の明確化・アクションの進捗追跡・経営層の姿勢が必要で、社内で立ち上げにくい場合は非難しない立場を持ち込める外部チームの支援も有効
障害の再発に悩んでいる、あるいは振り返りの仕組みがまだ整っていないという段階でも、torcheees はご相談を受け付けています。「既存プロダクト改善 診断」で障害履歴と現状の運用体制を確認し、改善の優先順位と概算費用をご提示するほか、保守・運用のサービスとして継続的な改善支援も行っています。まずはお問い合わせフォームからご相談ください。