運用引継ぎ

1 運用引継ぎの概要

1.1 定義と目的

運用引継ぎとは、システム運用、サービス運用、保守運用などの業務を担う主体が交代する際に、運用を継続するための情報・判断材料・手順・権限・関連履歴・関係者情報を、次の担当へ整理して引き渡す一連の活動である。単なる資料の受け渡しにとどまらず、運用現場で実際に再現可能な形で知識を移し、判断のぶれを抑えることを重視する。

主な目的は、サービス品質の維持、事故やトラブルの再発防止、業務継続性の確保、引継ぎ期間中のリスク低減である。特に運用領域は「例外の処理」が品質を左右しやすいため、平常時だけでなく想定外への備えまで含めた引き継ぎが求められる。

1.2 対象範囲の考え方

対象範囲は、引き継ぐ業務の性質と運用体制を踏まえて決める。基本方針として、担当変更によって失われやすい情報（判断基準、対応履歴、暗黙知、停止条件、連絡網など）を優先し、さらに実務上の作業単位に分解して抜け漏れを管理する。

範囲決定では、運用のライフサイクル（監視、一次対応、エスカレーション、復旧、再発防止、定期作業）に沿って整理し、どの工程が誰の責任になるかを明確にする。加えて、運用手順が「通常手順」と「例外手順」に分かれている場合は、例外側の説明と根拠が引き継ぎの中心になる。

1.2.1 システム・サービス別の範囲設定

システムまたはサービスごとに、監視項目、対応手順、変更頻度、保守契約、復旧方法が異なるため、引き継ぎ対象も同一に扱わない。例えば、24時間稼働の基盤と、日中のみ利用される業務アプリでは、運用時間帯と影響度の評価が変わる。その結果、監視の粒度、一次対応の基準、停止許容の考え方も異なるため、範囲定義は個別化する。

また、外部連携がある場合には、相手先の障害時における観測情報、切り分けの起点、問い合わせの窓口が引き継ぎの要点となる。内部仕様の説明だけでは不十分になりやすく、連携前提の理解を含めた形で整理する。

1.2.2 体制・責任分界（RACI）整理

引き継ぎの成否は、責任分界の曖昧さにより損なわれることが多い。そこで、RACI（Responsible、Accountable、Consulted、Informed）のような枠組みを用いて、誰が実行し、誰が最終判断し、誰に相談し、誰へ通知するかを整理する。

運用の場面では「一次対応をするが、判断は別部署が行う」といった構造が発生しやすい。引き継ぎ時には、エスカレーションの条件と連絡経路、判断権限の切り替えタイミング、記録の持ち方をセットで定義する。これにより、担当者交代時でも同じ基準で行動できる状態をつくる。

1.3 成功指標（KPI）と評価観点

成功指標は、品質と安全性、引き継ぎの確実性を同時に測る設計が望ましい。具体的には、受入後のインシデント再発率、手順逸脱の回数、初動対応までの時間、問い合わせの一次解決率、監視アラートの取りこぼし率などが評価観点になり得る。

評価は「引き継ぎ完了時の理解度」だけでなく、「受入後の運用で期待した挙動が再現できているか」を確認する。さらに、ドキュメントの整備状況（版の一致、例外手順の網羅性、参照性）も成果として扱い、後工程で修正が集中しないようにする。

2 引継ぎ計画の立案

2.1 スケジュールと体制

引き継ぎ計画は、いつ何を完了させるかを時間軸と成果物に紐づけて作る。最終的な切替日だけを決めると、準備の遅延や知識の偏りが発生するため、複数のマイルストーン（現状整理、資料確定、研修実施、権限移管、並行稼働、受入判定）に分解する。

体制は、引き継ぎ元と引き継ぎ先の双方に加え、承認者や調整役を含めて構成する。特に権限移管や設定変更を伴う場合、承認者の意思決定がボトルネックになりやすいので、事前に決裁ルートと代替手段を定めておく。

2.1.1 役割分担（引継ぎ元・引継ぎ先・承認者）

引き継ぎ元は、業務知識の提供だけでなく、手順の根拠、過去の判断理由、失敗例の扱い方を説明する責務を持つ。引き継ぎ先は、受け取った情報を実作業へ落とし込むための質問や確認を行い、必要な追加資料の要求を整理して提出する。

承認者は、範囲・成果物・受入基準の妥当性を確認し、必要に応じて優先順位を調整する。受入後の品質責任と結びつくため、判断基準の整合を取る役割が重要になる。

2.2 必要成果物（ドキュメント）一覧

成果物は、現場で参照されることを前提に、体系立てて列挙する。例としては、運用手順書、例外手順、監視設計の説明、障害対応フロー、連絡網、変更履歴の要約、保守資材の所在一覧、権限一覧、運用ガイド（禁止事項・注意点）などが挙げられる。

ドキュメントは「存在すること」よりも「最新版であること」「参照しやすいこと」「現場が判断に使えること」が重要である。さらに、運用で利用するチケット運用ルールやナレッジ基盤の使い方など、運用活動の動線に関する記述も含める。

2.3 リスク洗い出しと対策

引き継ぎは情報量が増えるほど見落としが起きやすく、また切替前後は責任が過渡的になるため、リスク管理を計画に組み込む必要がある。リスクは発生可能性と影響度で整理し、抑止策（手順の明確化、教育、冗長確認）と検知策（監視、レビュー、ログ確認）に分けて設計する。

また、対策は「何かが起きたとき」だけでなく「起きる前に気づく」ための仕掛けも含める。過去に類似の問題があった場合は再発防止の観点から優先的に扱う。

2.3.1 引継ぎ期間中の停止・劣化リスク

引き継ぎ期間中には、誤った操作、設定の取り違え、手順の順序違いにより停止や性能劣化が生じるおそれがある。対策として、段階的な権限移管、変更操作の事前承認、テスト手順の実施、影響範囲の見える化（対象、時間、切戻し条件）などを整える。

停止・劣化を抑えるには、並行稼働の設計が有効である。引き継ぎ先が監視・判断に参加しつつ、実操作は段階的に移すことで、誤動作が本番へ直結する確率を下げる。

2.3.2 連絡・エスカレーション不備のリスク

連絡系の不備は、復旧遅延や誤った切り分けにつながりやすい。特に、窓口の変更、担当者の不在、連絡手段の優先順位の違いがあると、初動が遅れる。対策として、報告テンプレート、エスカレーション条件、連絡先と役割の対応表、応答時間の目安を事前に確定する。

さらに、実際の障害を模擬した訓練（想定問答、連絡演習）を実施し、会話の粒度が揃っているかを確認する。記録の残し方（チケットへの反映、ログの参照先）も合わせて整備する。

3 実務手順：情報の移管

3.1 現状把握（As-Is）の整理

現状把握では、引き継ぐ業務が現在どのように回っているかを、手順と判断の両面から写し取る。単なる作業の列挙に留めると、判断の根拠が抜け落ちやすい。したがって、各工程で「何を見て」「何を基準に」「次へどう進めるか」を整理する。

また、作業の頻度、運用時間帯、担当者が抱える判断負荷、よくあるトラブルの種類など、運用特性をあわせて把握することで、教育計画や監視の移管に反映できる。

3.1.1 運用手順と例外手順

運用は通常手順と例外手順に分かれる。通常手順は平常時の運用で参照する基準であり、例外手順は障害、想定外の挙動、保守都合などに対応するための分岐である。引き継ぎでは例外側の理解が特に重要で、どの条件で分岐し、誰の判断を必要とするかを明示する。

例外手順の説明には、過去の事例の要約が有効である。どの観測情報が決め手になったか、誤った判断に至った場合はどう修正したか、といった学習データを取り込むことで、次の担当が再現性高く行動できる。

3.1.2 過去の障害・インシデント履歴

履歴は、発生件数の羅列ではなく、パターン化して提示するのが望ましい。例えば、同種の障害が連続した要因、復旧までの典型的な手順、再発防止の効果（いまも有効か、別の副作用が出ていないか）を整理する。

加えて、インシデントの区分（重大度、影響範囲、顧客影響の扱い）と、記録の所在（チケット、報告書、監査ログ）を引き継ぎ先が辿れるようにする。これにより調査の時間が短縮され、対応の質が安定する。

3.2 手順書・ナレッジの作成と更新

引き継ぎでは、手順書や知識を「新規作成」だけでなく「更新・統一」する側面もある。現場に散在する情報を統合し、参照の導線を一本化することで、確認コストを減らす。更新では、用語の揺れ、手順の重複、版の混在などを解消する。

ナレッジ基盤は、検索性と粒度を意識する。長大な文章よりも、判断ポイントが分かる見出し、参照先のリンク、関連するチェック観点を備えることが有効である。

3.2.1 チェックリスト化と版管理

チェックリストは、作業の抜け漏れを防ぐための実務ツールである。引き継ぎでは「実施前」「実施中」「完了後」の観点に分け、確認事項を具体化する。例として、監視の事前確認、作業手順の順序、影響評価の記録、切戻し可否の確認などを含める。

版管理では、対象範囲（対象システム、対象期間、適用条件）と更新履歴を明確にし、参照すべき資料が一意になる状態を目指す。版の齟齬は判断ミスに直結するため、改訂のルールと周知方法を定める。

3.2.2 よくある問い合わせ（FAQ）の整備

FAQは、引き継ぎ直後の不安を減らし、問い合わせの再発を抑える目的で整備する。質問と回答は、原因→確認方法→対処手順→判断基準の順に組み立てると、現場で使いやすい。加えて、問い合わせが必要になる境界条件（自力対応の範囲、エスカレーションの要件）を明確にする。

FAQは固定物ではなく、運用で得た知見を反映して更新する。問い合わせの頻度や内容を分析し、手順書へ逆流（手順へ反映）する運用にすると、改善サイクルが回りやすい。

3.3 運用監視・チューニング情報の引継ぎ

監視の引き継ぎは、単にアラート名を渡すだけでは不十分である。何がトリガーで、なぜその閾値になっているのか、誤検知の傾向、ノイズの扱い、調整履歴を合わせて引き渡すことで、監視運用が再現できる。

また、チューニング情報には、性能指標と運用上の判断のつながりを含める。例えば、特定のメトリクスの変化がどの状態を意味し、どの対応へ進むかを説明することで、運用側の意思決定が安定する。

3.3.1 警報・監視基準

警報は、発火条件、重大度、一次対応の開始基準をセットで扱う。引き継ぎ先が「いつ」「どの対応を開始するか」を誤ると、重大度の誤判定や遅延が起きるため、基準の説明を明確にする。

さらに、監視の運用状態（メンテナンス中、誤アラート抑制中、閾値調整中など）を示す運用ルールも必要である。アラートの扱いは技術的な設定だけでなく、人の判断が入り込むため、手順書への反映が重要になる。

3.3.2 障害対応の判断基準

障害対応の判断基準は、切り分けの順序と、次のアクションへ進む条件を定義する。例えば、ログ確認、監視メトリクスの確認、外部要因の可能性評価など、観測の優先度を示すと対応の質が上がる。

判断基準には「やってはいけないこと」も含める。誤操作の危険性がある手順、復旧を急ぐことで悪化する可能性がある操作、外部連携へ依存する判断の注意点などを明示し、事故を予防する。

4 権限・ツール・環境の移管

4.1 アカウント・権限の移管

アカウントと権限の移管は、運用能力の付与とリスク低減を同時に満たす必要がある。引き継ぎ先に必要な範囲だけを付与し、不要なアクセスは付けない方針（最小権限）を採用することで、誤操作や不正利用の可能性を下げる。

また、権限の付与は「いつから」「どの操作が可能か」を明確にし、移管タイミングを計画に組み込む。切替前後で権限の衝突や欠落が起きると、運用の継続性に影響する。

4.1.1 ロール設計と最小権限

ロール設計では、操作の種類（参照、設定変更、復旧操作、承認が必要な変更）を整理し、それぞれに対応する権限を定義する。引き継ぎ先の役割（一次対応担当、エスカレーション担当、承認者）に合わせて権限を段階付与することで、過剰な権限を避ける。

最小権限の考え方では、将来の拡張性も考慮する。頻繁に権限申請が発生すると業務が停滞しやすいため、運用実態に合わせてロール粒度を見直す。

4.1.2 監査ログと証跡の扱い

監査ログと証跡は、調査や説明責任の基盤である。引き継ぎでは、ログの保存先、参照手順、閲覧権限、追跡に必要なキー（時刻、チケット番号、操作対象）を整理する。

また、引き継ぎ中は操作主体が混在しやすい。記録上の整合性を保つため、チケットと操作の関連付け、作業報告の粒度、ログ記録のルールを統一することで、後日の再調査が容易になる。

4.2 ツール・アクセス環境の確認

ツールとアクセス環境の移管では、「利用できること」だけでなく「同じ前提で使えること」を確認する。チケットシステム、監視画面、ログ閲覧、変更管理、ナレッジ検索など、運用の動線に関わるツールを洗い出し、アクセス確認を行う。

環境はネットワーク条件、端末要件、ブラウザ設定、証明書などの依存を含むため、事前に動作検証の観点を揃えると手戻りが減る。アクセス障害が起きた場合の代替手段も明示しておく。

4.2.1 チケットシステム・ナレッジ基盤

チケットシステムでは、作成ルール、優先度付け、担当割当、やり取りの記録形式、完了条件の扱いを引き継ぐ。特にインシデント対応では、初報のフォーマットや、追加情報の更新手順が品質に直結する。

ナレッジ基盤では、参照手段、編集権限、タグ付け規則、古い記事の扱いを整理する。検索で辿れる状態にすることで、引き継ぎ後の判断が安定する。

4.2.2 リモートアクセス・端末環境

リモートアクセスは、認証方式、接続手順、利用可能時間、二要素認証の有無などを確認する。端末環境では、必要ソフト、権限昇格の手順、設定ファイルの所在など、作業に直結する要件を整理する。

また、回線やVPNの不調時にどう代替するか（待機、連絡、別経路での確認）を決めておくと、障害時の迷いを減らせる。引き継ぎ期間中の検証で、実際に操作できる状態まで到達しているかを確認する。

4.3 設定情報・保守資材の取り扱い

設定情報と保守資材には、運用の継続性と安全性の両方が含まれる。設定は復旧や変更に直結するため、所在とアクセス権、更新手順、保管期間を明確にする。保守資材は、作業に必要な部品やスクリプト、手順に付随する添付ファイルなどを指し、破損や紛失の影響が大きい。

取り扱いは法令・契約・社内規程に従うことが前提であり、特に認証情報を含む場合は厳格な保護措置が必要になる。

4.3.1 秘密情報・認証情報の管理

秘密情報や認証情報は、共有によるリスクを最小化する設計が重要である。パスワード、鍵、トークン類は、保管場所、参照手順、ローテーション方針、棚卸し頻度を明記する。

引き継ぎでは「引き渡せる範囲」と「引き渡さない範囲」を分ける。鍵の共有を避け、個別認証へ移行する、もしくは安全な管理基盤を介してアクセスするなどの方法を採用し、証跡と監査性を確保する。

4.3.2 バックアップと復旧手段

バックアップと復旧手段は、万一の障害で運用が止まらないための土台である。バックアップの対象、取得頻度、保存期間、復旧手順、復旧時の検証方法を引き継ぐ必要がある。

復旧手段は手順書に加えて、実施履歴（最終復旧テスト日、成功/失敗の概要、復旧に必要な条件）も確認する。これにより、書面上の整備だけでは分からない実効性を評価できる。復旧を急ぐ局面での優先順位も併せて整理する。

5 研修・OJTと引継ぎの実行

5.1 研修（机上）と実地（OJT）の設計

研修は、引き継ぎ先が理解した内容を実務で再現できるように設計する。机上研修では運用体系や判断基準を扱い、実地研修（OJT）では監視対応、チケット運用、復旧手順の実行など、手を動かす工程へ進む。

設計のポイントは、対象者の経験差を吸収しつつ、同じ到達水準へ揃えることである。理解度の確認方法を計画に組み込み、知識の穴を早期に埋める。

5.1.1 引継ぎシナリオの作成

引き継ぎシナリオは、実際の運用に近い形で状況を提示し、判断と作業の流れを練習するための材料である。例えば「特定のアラートが発火した」「性能がじわじわ悪化した」「外部連携が遅延している可能性がある」など、段階的に難度を上げる。

シナリオには、開始情報、想定観測、期待する出力（チケットへの記載、エスカレーションの有無、操作の選択）を含める。評価の観点を事前に揃えることで、研修が主観になりにくくなる。

5.1.2 評価方法（理解度確認）

評価方法は筆記中心にせず、判断のプロセスを観察する形が有効である。手順の正誤だけでなく、根拠の提示、例外条件の認識、危険操作の回避などを評価項目にする。

理解度確認は単発ではなく、研修の節目ごとに実施する。早い段階で誤解が見つかれば修正コストが下がるため、短いサイクルの確認を推奨する。

5.2 合同運用・並行稼働

合同運用と並行稼働は、切替前に品質を担保するための実践的な手段である。引き継ぎ先が監視や判断に関与し、必要に応じて引き継ぎ元がフォローできる状態を作ることで、実運用の差異を吸収する。

並行稼働の設計では、どの範囲までを引き継ぎ先が担うか、いつ権限を移すかを段階的に示す。段階化は、リスクと学習効果のバランスを取りやすい。

5.2.1 体制切替の段階設計

体制切替は、監視のみ→一次対応→復旧操作→責任の全面移行といった段階で進めることが多い。各段階で到達条件（対応時間、手順遵守率、判断の妥当性）を設定し、基準を満たした場合に次へ進む。

また、切替期間における責任の所在をRACIで明確化する。双方が動く局面でも、最終判断を誰が行うかが曖昧だと、現場が迷って時間を浪費する。

5.2.2 エスカレーション動線の運用確認

エスカレーション動線は、連絡手順が紙の上だけで完結していては意味がないため、実運用で確認する。エスカレーション条件に該当したときの連絡の速さ、必要情報の粒度、引き継ぎ元からのフィードバックの反映までを観測する。

動線の確認では、単に連絡が届いたかではなく、「判断に必要な情報が揃っていたか」が重要である。報告テンプレートの項目不足や、時系列の欠落があると、後で手戻りが発生する。

5.3 連絡ルールと窓口の統一

連絡ルールは、障害時に混乱を生まないための共通言語である。報告の順序、含めるべき情報、連絡手段の優先順位、応答までの目安を統一することで、判断の速度と正確性が向上する。

窓口の統一では、誰に連絡するかだけでなく、連絡した後に何を待つのか（判断、承認、技術支援など）を明確にする。曖昧な待ち時間は現場のストレスと遅延要因になる。

5.3.1 報告テンプレートの整備

報告テンプレートは、インシデントの初報で必要な情報を規格化する。典型的には、発生時刻、影響範囲、観測情報、試した対処、次に行う判断候補、依頼したい支援内容などを含める。

テンプレートは引き継ぎ中に実際のやり取りへ適用し、記入漏れや情報過不足を点検する。改善により、引き継ぎ後の問い合わせ品質も安定しやすくなる。

5.3.2 障害時の初動基準

障害時の初動基準は、最初の数分で何を確認し、いつエスカレーションするかを規定する。初動では、誤った復旧操作を避けるための安全確認を含めることが望ましい。

基準は、重大度ごとの対応粒度に応じて定義する。軽微なアラートと顧客影響がある事象を同じ基準で扱うと、過剰対応または遅延のどちらかが起きるため、分類と基準をセットで運用する。

6 完了判定とアフターフォロー

6.1 完了条件（受入基準）

完了条件は、受入の合否を判断するための具体的な基準である。資料の整備だけでなく、実作業の再現性、判断基準の理解、連絡ルールの遵守、監視運用の正確さといった観点を組み合わせる。

受入基準は、引き継ぎ範囲に応じて調整する。すべての項目を同じ重みで評価すると、重要度の低い欠落が停止要因になったり、逆に重大な不足が見逃されたりするため、優先度を付ける。

6.1.1 資料整備の確認観点

資料整備の確認では、版の一致、所在の明確さ、参照の導線、例外手順の網羅性を点検する。手順書と監視基準、連絡網が矛盾していないかも確認対象にする。

また、資料が「作ったまま」になっていないかを見極めるため、現場で実際に参照して作業できるか（レビュー観点）を確認する。読み物としての完成度より、実務利用の可否が重要である。

6.1.2 実作業テストの合格条件

実作業テストは、対象範囲の手順を模擬環境や管理された条件で実施し、合否を決める。合格条件には、時間目標、手順順守、記録の残し方、切戻しの可否確認などを含める。

さらに、誤差を許容する範囲を明確化する。例えば、応答時間の上振れは改善対象になるが、手順逸脱がある場合は重大不足として扱うなど、評価の基準線を揃える。

6.2 受入後の定着支援

受入後は、運用が実際に安定するまで支援を継続する。定着支援では、問い合わせ対応だけでなく、運用上の判断が資料に沿っているか、改善点が現場に反映されているかを確認する。

支援期間は一律でなく、難易度や変更頻度により設定する。重要なのは、問題が起きたときに適切な助言が得られる状態を確保しつつ、徐々に依存を減らすことである。

6.2.1 フォローアップ面談

フォローアップ面談では、引き継ぎ後の運用で出た疑問や迷いを整理し、再教育の必要性を判断する。単なる進捗報告ではなく、判断に関するフィードバックを中心に据えると効果が高い。

面談では、問い合わせの傾向や手順の利用状況を見て、資料更新やFAQへの反映を決める材料を集める。これにより、支援が次の改善へつながる。

6.2.2 問い合わせ対応の期間設定

問い合わせ対応の期間は、支援側の負荷と引き継ぎ先の自立度を踏まえて定める。初期は頻度が高くなりやすいため、一次回答までの目安、回答が難しい場合の切り分け基準を整備する。

期間が終わる段階では、問い合わせが自己解決へ移行しているかを確認する。必要に応じてナレッジや手順の改善を先に実施し、依存が残り続けないようにする。

6.3 改善サイクル（振り返り）

改善サイクルは、引き継ぎを単発で終わらせず、次回の質を高めるための仕組みである。振り返りでは、成功要因と課題を分けて記録し、次の計画へ反映する。

再発防止は、個人の反省に寄せるよりも、手順・教育・ツール・連絡ルールのどこに原因があるかを分類し、構造的に対策を打つことが重要になる。

6.3.1 失敗要因の分類と再発防止

失敗要因は、情報不足、手順の不明確さ、教育不足、権限・ツールの不整合、連絡ルールの欠落などに分類する。原因の分類により、対策の種類が自動的に決まってくるため、再発防止の方向性がぶれにくくなる。

再発防止では、変更管理により手順や資料へ反映し、さらに運用で確認する。改善が完了したかを追跡しないと「直したつもり」になりやすいため、検証と記録をセットにする。

6.3.2 次回引継ぎへの反映方法

次回への反映方法は、改善点をバックログ化し、次の引き継ぎ計画へ具体的に落とし込む形で運用する。例えば、テンプレートの項目追加、評価基準の調整、シナリオの見直し、権限移管の順序変更などを、優先度と期限付きで整理する。

反映の追跡では、実施状況と効果を確認する。効果が薄い場合は、原因分類を再評価し、別の対策へ更新することで、改善活動の精度を高める。

7 付録：運用引継ぎで役立つテンプレート例

7.1 引継ぎ計画書ひな形

• 目的と対象範囲（システム/サービス、期間、適用範囲）
• 体制（引き継ぎ元、引き継ぎ先、承認者、窓口）
• 成果物一覧（手順書、監視基準、連絡網、FAQ、履歴要約など）
• スケジュール（マイルストーン、権限移管、並行稼働、受入日）
• リスクと対策（停止・劣化、連絡不備、権限逸脱など）
• 受入基準（資料、実作業テスト、評価観点）
• 連絡ルール（報告テンプレ、エスカレーション条件）
• 変更履歴（計画変更の記録方法）

7.2 チェックリスト（完了判定）ひな形

• 資料
• 手順書が最新版である
• 例外手順が分岐条件付きで記載されている
• 連絡網と窓口情報が更新されている
• 監視基準と警報の扱いが一致している
• 権限
• 必要ロールが付与されている（最小権限に基づく）
• 監査ログの参照手順が確認済み
• ツール
• チケット運用の手順が再現できる
• ナレッジ検索と参照ルールが確立している
• リモートアクセス/端末要件を満たす
• 実作業テスト
• 模擬対応で手順逸脱がない
• 記録（チケット/ログ）が規定通り
• 切戻し手順の理解が確認できている
• 受入判定
• KPI/評価観点に基づき合否を決定する
• 次段階のフォロー計画が合意されている

7.3 報告・連絡のテンプレート例

• 件名：インシデント種別／影響範囲（簡潔）
• 発生日時：YYYY-MM-DD HH:MM（タイムゾーン）
• 現象概要：何が起きているか（観測ベース）
• 影響：サービス影響、対象利用者、継続時間
• 根拠：監視アラート名、ログ抜粋、メトリクス値
• 試した対応：実施した手順と時刻
• 現時点の判断：継続、縮退、エスカレーション要否
• 次アクション：今後の確認や実施予定
• 依頼先：追加支援が必要な窓口
• 参照情報：チケット番号、関連資料リンク

7.4 障害対応手順のひな形

1. 初動確認

• 影響範囲と重大度の暫定評価
• 監視とログの整合確認

1. 切り分け

• 性能/稼働/外部要因の切り分け観点に沿って確認
• 例外手順の分岐条件を確認

1. 対処の選択

• 通常手順で可能な対応か、承認が必要かを判定
• 変更操作の実施可否と切戻し条件を整理

1. 復旧

• 手順に従って復旧操作を実施
• テスト観点で復旧状態を確認

1. 再発防止

• 原因仮説と残課題を記録
• 対策の反映先（手順書/FAQ/監視基準/チケット運用）を決定

1. 連絡と締め

• 関係者へ状況更新
• 完了条件に基づき終了判定を行う