障害対応でサービスを復旧し、利用者へ完了連絡を送り、インシデント記録を閉じる。ここまでは重要な仕事です。 しかし、翌週に似た障害が起き、同じ担当者が同じ手順で復旧しているなら、組織としての学習は十分に進んでいません。 復旧の速さだけを追う運用では、原因分析や恒久対策が「落ち着いたら取り組む仕事」になり、日常業務へ戻るほど後回しになりがちです。

PeopleCertの公式ITIL 4 Practitioner資料では、Incident Managementは中断後に通常のサービス運用を迅速に復元する役割、 Problem Managementはインシデントの実際または潜在的な原因を特定し、回避策と既知エラーを管理して、発生可能性と影響を下げる役割として説明されています。 目的が異なるため、インシデントの終了と問題の解決を同じ状態で扱うと、復旧は完了しても再発防止の仕事が見えなくなります。

Google CloudのWell-Architected Frameworkも、ポストモーテムを、影響、緩和・復旧措置、根本原因、再発防止のフォローアップを記録する仕組みと位置づけています。 重要なのは文書を作ることではなく、事実から学び、実行可能な改善を完了させることです。本記事では、ITIL 4を土台に、 復旧後の学習を日常のサービス運営へ組み込む5つのステップを整理します。

具体的な課題：復旧はできても、同じ障害が形を変えて戻ってくる

復旧中は利用者影響を止めることが最優先です。暫定回避、ロールバック、再起動、経路切替などによりサービスを戻せたなら、 Incident Managementとして価値があります。一方、その成功が「解決した」という感覚を強め、原因と改善の追跡を弱める場合があります。

  • 終了条件が混ざる：サービス復旧、原因特定、恒久対策の完了を一つの「クローズ」で表し、残作業が見えない。
  • 分析対象が重大障害だけ：単発では軽微でも、繰り返し発生して工数や利用者体験を損なう事象を拾えない。
  • 記録が時系列ではない：記憶や印象を中心に議論し、観測値、判断、操作、状態変化を分けて残していない。
  • 個人の注意へ収束する：「確認を徹底する」で終わり、判断を難しくした仕組み、情報、権限、設計を改善しない。
  • 対策に責任者と期限がない：良い提案は出ても、通常の変更・開発・予算管理へ接続されず、未完了のまま残る。
「早く戻す仕事」と「次を減らす仕事」を分けて見える化し、同じサービス価値へつなぐことが出発点です。

考え方：復旧レーンと学習レーンを一つの運用にする

復旧中に深い原因分析を求めると、利用者影響の解消が遅れることがあります。反対に、復旧後まで同じ緊急体制を続けると、 関係者が疲弊し、十分な事実整理ができません。そこで、状態と責任を二つのレーンに分けます。

  1. 復旧レーン：影響の把握、優先順位、連絡、回避策、サービス復元を管理する。終了条件は利用者が必要な水準でサービスを利用できること。
  2. 学習レーン：対象選定、事実整理、原因・寄与要因の分析、既知エラーと回避策の管理、改善実行を扱う。終了条件は合意したリスク低減が確認できること。

二つは別々の組織を意味しません。インシデント記録から問題候補を起票し、分析結果を既知エラー、ナレッジ、監視、変更、設計、教育へ戻す 「接続」が重要です。PeopleCertはITIL 4の実践を、プロセスだけでなく、責任、技術、知識、コミュニケーション、バリューストリームを含む多面的なものとして説明しています。

実践手順1：分析対象を事前基準で選ぶ

すべてのインシデントに同じ重さの分析を行う必要はありません。サービス停止時間だけでなく、利用者影響、データ影響、手動介入、 復旧時間、検知の遅れ、再発頻度、回避策の危険性、担当者負荷を組み合わせて、問題管理やポストモーテムへ送る基準を決めます。 Google Cloudも、利用者に見える停止・劣化、データ損失、ロールバックなどのオンコール介入、一定時間を超える復旧、監視で検知できなかった事象などを例示し、 事前に対象基準を定めることを推奨しています。

「重大度1だけ」のような単純な線引きでは、低い重大度の反復を見逃します。30日単位で、同一サービス、症状、構成要素、回避策を束ね、 個別には小さくても累積影響が大きい問題候補を拾います。対象外にした理由も記録すると、基準そのものを見直せます。

実践手順2：評価より先に、事実と判断を時系列で分ける

復旧直後の短い時間で、監視ログ、変更履歴、チャット、チケット、利用者報告、担当者の判断を一つのタイムラインへ集めます。 「何が起きたか」「その時点で何が見えていたか」「何を判断したか」「何を実行し、状態がどう変わったか」を分けて記録します。 後から得た知識を当時も知っていたかのように扱わないことが重要です。

事実の欠落も発見です。たとえば、利用者影響を示す指標がない、構成変更の履歴がつながらない、操作理由が残らないなら、 原因分析以前に観測可能性や記録設計へ改善余地があります。報告書を長くするより、影響、検知、対応、復旧、判断根拠を関係者が追える粒度を優先します。

実践手順3：「誰が」ではなく、再発を許した条件を分析する

原因を一つの部品や操作へ絞ると、説明は簡単になります。しかし実際の障害では、設計、監視、変更、手順、権限、教育、 サプライヤー、容量、目標設定など複数の条件が重なります。直接の技術原因に加え、影響を拡大した条件、検知を遅らせた条件、 復旧を難しくした条件、同種事象を見逃していた条件を整理します。

Googleの公式SRE資料は、非難のないポストモーテムを、個人ではなくプロセス、ツール、技術へ焦点を当てる学習機会として説明しています。 これは責任を曖昧にすることではありません。意思決定時に利用できた情報と制約を明らかにし、同じ状況でも安全な判断がしやすい仕組みに変えるための姿勢です。

実践手順4：回避策・既知エラー・恒久対策を別々に管理する

原因が完全に解消できない場合でも、既知の症状、影響範囲、判定方法、安全な回避策、実施権限、連絡先を既知エラーとして管理すれば、 次回の影響を抑えられます。ただし、回避策があることとリスクが受容されたことは同じではありません。再起動や手動補正のような回避策は、 作業ミス、データ不整合、担当者依存といった新しいリスクも持ちます。

恒久対策は、発生可能性を下げる、影響を小さくする、検知を早める、復旧を容易にする、判断を支援する、のどれを狙うか明記します。 費用や複雑性を増やす対策は、再発可能性と事業影響に見合うかを評価します。Google Cloudも、再発の可能性が低い問題に過剰な複雑性を加えると、 かえって不安定さが増す可能性を指摘しています。

実践手順5：改善項目を通常の仕事へ戻し、効果まで確認する

改善項目には、責任者、期限、優先順位、完了条件、対象サービス、期待するリスク低減を持たせます。コード修正だけでなく、監視、 テスト、復旧手順、権限、構成管理、サプライヤー合意、ナレッジ、訓練などを、既存の変更・開発・運用バックログへ接続します。 大きな再設計だけを待たず、短期間でできる検知改善や回避策の安全化も並行して進めます。

実装後は「チケットを閉じた」だけで終えず、同種インシデントの頻度、累積影響、検知時間、復旧時間、回避策の使用回数、 未完了改善の経過日数などを確認します。再発がゼロになる保証はありませんが、影響や対応負荷が狙いどおり下がったかを見れば、 対策の有効性と次の優先順位を判断できます。学びを他サービスへ共有するところまでを運用に含めます。

注意点：原因分析を儀式や監査対応にしない

  • 復旧会議をそのまま反省会にしない：緊急対応者の休息と事実収集の時間を確保し、目的と参加者を切り替える。
  • 「根本原因」という一語へ固執しない：複数の原因・寄与要因と、検知・影響・復旧の条件を扱う。
  • 対策数を成果にしない：大量の小項目ではなく、事業影響と再発可能性に対して有効な項目を選ぶ。
  • 非難のない姿勢を免責にしない：個人攻撃を避けつつ、役割、判断、統制、設計の改善責任は明確にする。
  • 機密情報を無制限に共有しない：学習へ必要な範囲と、個人情報、顧客情報、脆弱性情報、契約上の制約を整理する。

まとめ：復旧を終点ではなく、学習の入口にする

Incident Managementの速い復旧と、Problem Managementの再発可能性・影響の低減は、競合する活動ではありません。 終了条件を分け、問題候補を選び、事実を整理し、非難ではなく条件を分析し、回避策・既知エラー・恒久対策を管理して、 改善効果まで確認することで、一つのサービス価値へつながります。

最初から大規模な制度を作る必要はありません。まず一つの繰り返しインシデントを選び、復旧記録から問題候補を起票し、 30分の事実整理と少数の改善項目を、通常のバックログで追跡するところから始められます。大切なのは、完璧な報告書ではなく、 次の利用者影響を具体的に減らす学習が続くことです。

参考資料

本記事は公式・公的資料をもとに、一般的なITサービスマネジメントと信頼性改善の考え方を整理したものです。 個別組織の契約、法令適合性、労務、個人情報、セキュリティその他の法律上・専門上の助言を行うものではありません。 公式資料は2026年8月18日時点で確認しています。実際の運用では、自社のサービス、利用者影響、契約、組織体制、適用される法令・規格、 リスク許容度を踏まえ、必要に応じて関係部門や専門家へ確認してください。

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る