ある日の昼下がり、ベンダーから「システムに障害が発生しました」という連絡が入る。画面の向こうのエンジニアは慌ただしく対応を始めますが、発注者であるあなたに求められるのは技術的な復旧作業ではありません。求められるのは「いま社内に何を伝えるか」「経営層にいつ報告するか」「ユーザーにアナウンスを出すか」といった、技術判断ではない意思決定です。
しかし非エンジニアの発注者にとって、本番障害ほど判断が難しい場面はありません。ベンダーに何を聞けばいいのか、どの段階で上司や経営層に伝えるべきか、ベンダーが「復旧しました」と言ってきたときに本当に終わったのかをどう確認するか——その判断軸を持っていないと、混乱の中で「何もできなかった」「後から責任を問われた」という事態に陥りがちです。
本記事では、システム本番障害が発生したとき、発注者として何をすべきかを時系列で整理します。発生直後の数分から復旧後の再発防止依頼まで、ベンダーへの具体的な質問テンプレート・社内エスカレーションの判断基準・業務影響度の評価フレームワークを、非エンジニアでも実行できる形でまとめました。
「技術的な対応はベンダーに任せる。発注者の役割は情報収集と意思決定に集中する」——この前提に立てば、混乱の中でも迷わず動ける手順が見えてきます。明日障害が発生しても落ち着いて動けるよう、自社の障害対応マニュアルのドラフトとして本記事をご活用ください。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
本番障害発生時、発注者がまず理解すべき「自分の役割」
「障害対応は技術者の仕事だから、自分はベンダーからの報告を待つだけでいい」——この理解は半分正解で、半分誤りです。確かに原因の特定や復旧作業はベンダー側の技術者が担います。しかし発注者にも明確な役割があり、その役割を果たさなければ復旧が遅れたり、社内・顧客対応で大きなトラブルに発展したりします。
発注者の役割を一言で表すなら「情報収集と意思決定」です。技術判断ではありません。
技術者の役割と発注者の役割は明確に分かれている
両者の役割は次のように整理できます。
担当 | 主な役割 |
|---|---|
ベンダー（技術者・運用者） | 原因の切り分け／暫定対応（応急処置）／恒久対応（根本対応）／復旧作業／技術的なログ収集・分析 |
発注者（あなた） | 業務影響度の判断／社内エスカレーション（誰にいつ報告するか）／ユーザー・顧客への告知判断／契約上の権利行使（SLAクレジット請求等）／追加コストを伴う対応の承認 |
ベンダーがどれだけ優秀でも、「業務停止が経営インパクトに至るか」「顧客への告知を出すべきか」「予算外の暫定対応を承認するか」を判断できるのは発注者だけです。
発注者が動かないと止まる意思決定
具体的に、発注者の判断がなければ前に進まない事項を整理します。これらは「自分が動かないと止まる」ことを意識しておくと、混乱時に役割を見失いません。
- ユーザー告知の文言承認: 障害が長引きそうな場合、ユーザーへの案内文を出すかどうか、どのような文言で出すかは発注者が承認しなければ発信できません
- 復旧優先度の決定: 「全機能完全復旧を待つ」のか「業務継続できる最低限の機能だけ先に復旧してほしい」のかは、業務を知る発注者にしか判断できません
- 追加コストを伴う暫定対応の承認: ベンダーが「臨時で追加のサーバーを立てれば早く復旧できるが追加費用が発生する」と提案してきたとき、その承認は発注者の役割です
- 代替業務手段の起動: システムが復旧するまで手作業で業務を回すか、別システムで代替するかの判断と指示も発注者が担います
「技術者の役割」と「発注者の役割」を明確に分けて意識することで、混乱の中でも自分が何をすべきかが見えてきます。次の章では、発生直後から復旧後までのタイムライン別に、発注者が取るべき具体的な動きを整理します。
障害発生から復旧後までのタイムライン別 対応フロー
本番障害が発生してから収束するまでの動きを、発注者目線で時間軸別に整理します。各フェーズで「自分がやること」「ベンダーに確認すること」「社内で動かすこと」の3つを分けて意識すると、漏れなく対応できます。
発生直後（最初の5〜15分）— 第一報を受けた時の動き
ベンダーから「障害発生」の第一報を受け取った瞬間、発注者がまずすべきは落ち着くことです。焦って「すぐ復旧して」「原因を教えて」と矢継ぎ早に問い詰めても、技術者の対応リソースを奪うだけで何も得られません。
この5〜15分でやるべきことは次の3点です。
- 記録を取り始める: 第一報を受けた時刻、ベンダー側の連絡担当者、伝えられた事象の概要をメモ帳・チャット・ノートに残し始めます。後の社内報告・SLA違反確認のすべての起点になります
- ベンダーに「現状把握中である旨」を確認する: 「いま何が起きているかを把握中なのか、原因まで分かっているのか」を確認します。原因まで判明していないなら「分かり次第連絡してほしい」と伝え、過度な確認は控えます
- 社内の関係者に第一報の連絡経路を起動する: 直属の上司には「障害発生の連絡を受けた。詳細は確認中」と一報を入れます。この段階では断片的な情報で構いません。「すぐ復旧指示を出さない」ことが重要です。発注者が「すぐ直して」と圧力をかけても、技術者が早く直せるわけではありません
最初の数分は「動かない判断」も大切です。情報が揃わないうちに上司や経営層に過剰に伝えると、誤った情報が独り歩きします。
30分以内 — 影響範囲の特定と社内一次報告
発生から30分以内には、業務への影響範囲をある程度把握し、社内の一次報告を完了させたい時間帯です。
このフェーズの動きは次の通りです。
- 業務影響範囲を自社側で特定する: ベンダーからの情報を待つだけでなく、自社業務の視点で「営業活動は止まっているか」「顧客対応は止まっているか」「データ入力・帳票出力は止まっているか」を確認します。現場の担当者からヒアリングします
- ベンダーから復旧見込み時間（ETA: Estimated Time of Arrival、復旧見込み時刻）を引き出す: 確定値でなくて構いません。「いまの時点で30分なのか、3時間なのか、半日なのか」のレンジを把握することが、社内判断の最重要インプットになります
- 直属の上司・関連部門責任者への一次報告: テンプレートに沿った形で簡潔に報告します。報告テンプレートは後述の「社内エスカレーションの判断基準（誰に・いつ・何を）」で詳述します
- ユーザー・顧客からの問い合わせ受付準備: 顧客対応窓口・コールセンターがある場合、「障害発生の認識あり・調査中」のスタンスを共有しておきます
この時間帯で重要なのは「事実」と「推測」を分けて伝えることです。「ベンダーから原因がDBらしいと聞いた」ではなく、「原因は調査中。ベンダーからの公式見解はまだ受領していない」と伝えるほうが安全です。
2時間以内 — 経営層判断とユーザー告知の検討
発生から2時間が経過しても復旧していない場合、経営層への報告とユーザー告知が現実的な検討事項になります。
このフェーズで判断すべきことは次の通りです。
- 経営層への報告タイミングの判断: 後述の「業務停止レベルの分類」に基づき、業務影響度が高い場合は経営層（役員・社長）への報告を実施します。「悪い情報ほど早く」が経営層への報告原則です
- ユーザー・顧客への告知判断: 障害がユーザーに直接見えるサービスの場合、SNS・サイト・メールでの障害告知を検討します。告知文には「障害発生の事実」「現在対応中であること」「次の連絡予定時刻」を含めるのが基本形です。ベンダーに公式コメントを求めるのではなく、発注者として自社の言葉で発信します
- 業務代替手段の検討開始: 復旧長期化に備え、手作業・別システム・別部署への業務振替など、システム停止中の代替手段の検討を始めます。実際の起動は次フェーズで判断しますが、選択肢を持っておくことが重要です
経営層への報告は「報告すべきか」を悩む時間がもったいない場面です。「報告すべきか迷ったら報告する」を原則にすると、後で「なぜすぐ報告しなかった」と問われるリスクを避けられます。
復旧時 — 「本当に終わったか」の確認
ベンダーから「復旧しました」と連絡を受けても、発注者として鵜呑みにしてはいけません。技術的に復旧していても、業務上の問題が残っていることがあります。
復旧時に発注者が確認すべきことは次の通りです。
- 業務上の動作確認を自社側で実施する: 障害が発生していた機能を、実際の業務シナリオで動かして確認します。営業担当が見積を作成できるか、顧客対応担当が顧客情報を引き出せるか、経理担当が伝票を起票できるか——技術的な復旧と業務的な復旧は別物です
- データロス・処理漏れの有無を確認する: 障害中に投入されたデータ・処理が正しく記録されているか、二重登録になっていないかを確認します。場合によってはベンダーに「障害中のデータ処理状況」のレポート提出を求めます
- ユーザー・関係者への復旧連絡: ユーザー告知を出していた場合は復旧完了の連絡を出します。社内の一次報告先・経営層にも復旧完了の連絡を入れます
「ベンダーが復旧したと言っているから大丈夫」と思い込まず、自社の業務目線で確認する習慣をつけることが、発注者としての信頼につながります。
翌営業日以降 — 振り返りと再発防止依頼
障害が一旦収束した後、翌営業日以降に発注者が動くべきことは「再発防止」と「契約上の対応」です。
- ポストモーテム（事後検証報告書）／RCA（Root Cause Analysis、根本原因分析）報告書の要求: ベンダーに対し、原因・タイムライン・暫定対応・恒久対応・再発防止策をまとめた報告書の提出を求めます。詳細は後述の「再発防止策の依頼方法（ポストモーテム・RCA報告書の要求）」で説明します
- 経営層・関係部門への確定報告: 障害発生時の一次報告に対し、確定情報をまとめた最終報告を実施します
- 契約上の対応の検討: SLA違反に該当する場合、サービスクレジット（割引・返金）の請求や、契約条件の見直し交渉を検討します
「障害は復旧したら終わり」ではなく、「次に同じことが起きないようにする」までが発注者の責任範囲です。
ベンダーへの連絡内容と効果的な伝え方
混乱の中でベンダーから必要な情報を引き出すためには、何を聞くかをあらかじめ整理しておくことが重要です。ここでは、第一報時にベンダーへ尋ねるべき質問テンプレートと、ベンダーに伝えるべき自社側の情報を具体的に整理します。
第一報でベンダーに必ず聞くべき5つの質問
第一報を受けたタイミングで、ベンダーに以下の5つを順に確認します。すべての回答が即時に得られなくても、「いつまでに回答できるか」を確認するだけで前進します。
- 何が起きているか（事象の概要）: 「技術用語ではなく、業務上どんな影響が出ているかで説明してほしい」と依頼するのがコツです。「DBが遅延」ではなく「ログインができない／検索結果が返ってこない」のレベルで把握します
- 影響範囲は: どの機能が使えないのか、全ユーザーが影響を受けているのか一部か、社内向け機能か顧客向け機能かを確認します
- 暫定復旧の見込み時間（ETA）は: 「いつごろ復旧見込みか、現時点での見立てを教えてほしい」と聞きます。確定値でなくレンジ（30分以内・数時間・半日以上）でも構いません
- 原因は判明しているか／判明していないか: 原因が分かっていれば共有してもらいます。分かっていない場合も「現時点で疑っている原因」を推測ベースで開示してもらいます。確定原因は後でいいので、現時点の仮説を聞きます
- 次の連絡はいつ来るか: 「次は何分後に連絡をもらえるか」を必ず決めます。「分かり次第連絡します」では発注者側の不安が募るだけです。「30分後にいまの状況を共有してください」と定期報告のリズムを作ります
この5つを聞けば、発注者として社内に伝えるべき情報の最低限が揃います。
ベンダーに伝えるべき自社側の情報
ベンダーから情報を引き出すだけでなく、発注者からベンダーに伝えるべき情報もあります。これを伝えないと、ベンダー側が復旧優先度の判断を誤ったり、不要な対応に工数を割いたりします。
- 業務への影響度: 「営業活動が停止している」「内部業務だけ止まっている」など、業務インパクトの大きさを伝えます。ベンダーは技術的な影響範囲しか見えないため、業務インパクトを知らせるのは発注者の役割です
- 顧客からの問い合わせ状況: 「顧客から問い合わせが続いている」のか「まだ顧客は気づいていない」のかは、告知判断の重要なインプットです
- 復旧優先度の希望: 「全機能完全復旧を待つ」のか「業務継続できる最低限の機能だけ先に復旧してほしい」のかを明示します。後者の場合、ベンダーは暫定対応を優先する判断ができます
コミュニケーションを混乱させないための運用ルール
障害対応中はベンダーとの連絡が頻繁になります。コミュニケーションが混乱すると情報の取りこぼし・二重対応が発生するため、以下のルールを徹底します。
- 連絡窓口を一本化する: 発注者側からは1人に集約します。複数の担当者がベンダーに個別連絡すると、ベンダー側が同じ情報を何度も説明する負荷が生まれます
- チャット・メール・電話の使い分け: 緊急度の高い指示・確認は電話、定期報告・記録はチャットまたはメール、と使い分けます
- 「定期報告」を要求する: 「30分ごとに状況を共有してください」と最初に決めます。情報が来ない時間が続くと社内の不安が増幅します
- 報告を受けたらタイムスタンプ付きで記録する: チャットで受けた情報も、別途タイムライン記録に時刻つきで転記します。後のRCA報告書照合・SLA違反確認に必須です
ベンダーは技術的な対応で手一杯です。発注者側がコミュニケーションを整理することで、ベンダーの対応リソースを最大化できます。
社内エスカレーションの判断基準（誰に・いつ・何を）
障害発生時、社内の誰にいつ何を伝えるかの判断は、発注者にとって最も悩ましい場面の一つです。報告が遅れれば「なぜすぐ報告しなかった」と問われ、過剰に報告すれば「些細なことで騒ぐな」と言われる——その狭間で適切な判断を下すための軸を整理します。
報告先の段階分け
社内の報告先は次の4段階に分けて考えます。各段階の判断基準も併せて整理します。
報告段階 | 報告先 | 判断基準 |
|---|---|---|
一次報告 | 直属の上司 | 障害発生を認識した時点ですぐ |
部門責任者報告 | 部門長・本部長クラス | 業務に影響が出ている／30分以上復旧見込みなし |
経営層報告 | 役員・社長 | 主要業務停止／2時間以上復旧見込みなし／顧客被害発生 |
取締役会・株主報告 | 取締役会・主要株主 | 経営インパクト大／対外公表に至る規模／IR対応必要 |
各段階の判断基準には「業務停止規模」「想定損失額」「顧客影響範囲」の3つが関係します。これらの判断軸は後述の「業務影響度の判断方法（業務停止レベル分類）」で詳述します。
報告タイミングの考え方
報告タイミングについては、「障害発生時点」で報告すべきものと「影響範囲が確定してから」報告すべきものの区別を持っておきます。
- 障害発生時点で報告するもの: 直属の上司への一次報告、コールセンター・顧客対応窓口への状況共有（顧客接点を持つ部門）
- 影響範囲が確定してから報告するもの: 経営層・取締役会への報告、ユーザー告知
ただし「影響範囲確定を待ちすぎない」ことが重要です。判明している情報だけで報告し、「現時点で判明している情報。続報を入れる」と明示すれば、後から「なぜすぐ報告しなかった」と問われるリスクを避けられます。
経営層は「悪い情報ほど早く」を求めることが多い、という前提を持っておきましょう。曖昧な情報でも、第一報を早く出すほうが信頼を損ねません。
報告内容のテンプレート（5W1H形式）
社内報告は次の5W1H形式のテンプレートに沿って記述すると、漏れなく簡潔に伝えられます。
【障害一次報告】
▼When（いつ）: ◯月◯日 ◯時◯分 障害発生
▼What（何が）: ◯◯システムの◯◯機能で障害発生
▼Where（どこで）: 本番環境／対象範囲は◯◯
▼Who（誰に影響）: 顧客◯◯件／社内◯◯部門
▼Why（なぜ）: 原因調査中／推測では◯◯（事実と推測を分けて記述）
▼How（どう対応中）: ベンダー◯◯が対応中／復旧見込みは◯時間／次の連絡は◯時
【経営判断が必要な事項】
- ユーザー告知の文言承認: 必要／不要
- 追加対応の承認: 必要／不要
【続報予定】: ◯時◯分
このテンプレートで重要なのは、「事実」と「推測」を明確に分けて書くことです。「ベンダーから原因はDBらしいと聞いた」のような不確定情報をそのまま伝えると、誤情報が経営判断に影響します。「原因は調査中。現時点での推測は◯◯」と明示してください。
また、最後の「経営判断が必要な事項」の欄を設けることで、報告を受けた経営層が即座に判断すべきことを把握できます。報告は「情報共有」ではなく「意思決定の要求」として組み立てると、報告先からの信頼が高まります。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
業務影響度の判断方法（業務停止レベル分類）
社内エスカレーションの判断軸となるのが「業務影響度」です。発注者が技術判断なしで影響度を評価できるよう、業務停止レベルを4段階に分類するフレームワークを使います。
業務停止レベルの4段階分類
業務停止のレベルは次のように分類します。
レベル | 業務停止の状態 | 具体例 |
|---|---|---|
Lv1 | 業務継続可能（一部機能のみ影響、迂回可能） | 一部のレポート機能が使えないが、基幹業務は問題なく動く |
Lv2 | 業務効率低下（手作業で代替可能） | 自動処理が止まっており手作業で対応中。時間はかかるが業務は回る |
Lv3 | 主要業務停止（売上・顧客対応に直接影響） | 受注システム・決済システムが停止し、売上が止まっている |
Lv4 | 全社業務停止／顧客被害発生（経営インパクト大） | 全システムが使えない／顧客データ流出の疑い／顧客対応がまったくできない |
このレベル分類は、社内報告の段階・ユーザー告知の要否・経営層関与の必要性を判断する基準になります。
影響度を見極めるための3つの問い
レベル判定に迷うときは、次の3つの問いを自問してみてください。
- いま売上が止まっているか？: 受注・決済・予約などの売上に直結する機能が止まっている場合はLv3以上です
- 顧客に直接的な不利益が出ているか？／出る可能性があるか？: 顧客が見える機能の停止、顧客データへのアクセス、顧客への通知遅延などはLv3以上の可能性が高くなります
- 復旧まで何時間以上かかると業務が回らなくなるか？: 「30分以内に復旧すれば問題ない」のか「半日止まると深刻」なのかで深刻度が変わります。長時間停止に耐えられない機能はLv3以上として扱います
この3つの問いに「Yes」が多いほど、レベルが上がります。技術的な判断ではなく、業務インパクトの観点で評価できる問いです。
レベル別の対応指針
各レベルでの対応指針は次の通りです。
レベル | 社内エスカレーション範囲 | ユーザー告知 | 経営層関与 |
|---|---|---|---|
Lv1 | 直属の上司への一次報告のみ | 不要 | 不要 |
Lv2 | 部門責任者まで報告／関連部門への状況共有 | 状況により判断（業務遅延の影響が大きい場合は実施） | 不要 |
Lv3 | 経営層（役員クラス）への報告必須／全関連部門への状況共有 | 実施（顧客向けに障害告知を発信） | 必須（意思決定への関与） |
Lv4 | 取締役会・株主への報告／法務・広報の関与 | 公式リリース・記者会見等を検討 | トップマネジメント直接関与 |
レベル判定は障害発生直後と途中で変わることがあります（「Lv2と思っていたが復旧が長引きLv3に格上げ」など）。タイムラインの節目で必ずレベルを再評価する習慣をつけましょう。
復旧確認のチェックポイント（「本当に終わった」と判断する基準）
ベンダーが「復旧しました」と連絡してきた瞬間、発注者として「本当に終わった」と判断できる材料を持っていますか。技術的な復旧と業務的な復旧が一致しないことは少なくありません。ここでは発注者として復旧を確認する具体的な手順を整理します。
業務動作確認の3観点
復旧時に発注者が確認すべきは、次の3つの観点です。
- 機能確認: 障害が発生していた機能が想定通り動くかを、業務シナリオで実機確認します。「ログイン→検索→詳細表示→処理実行」のように、ユーザーが実際にたどる動線で確認するのが理想です
- データ整合性確認: 障害中に投入された処理・データが正しく記録されているか、データロスや重複登録がないかを確認します。場合によってはベンダーに「障害中のトランザクション一覧」「処理件数の対比」を求めます
- 周辺機能の確認: 障害が発生した機能の前後で連携する処理（例: 受注→在庫引当→出荷指示）が問題なく動いているかを確認します。障害復旧後に「連携先の処理だけ動いていない」ことが発覚することがあります
これらの確認は、発注者単独ではなく現場担当者と協力して実施します。発注者が「動作確認のシナリオ」を整理し、現場担当者に実機操作を依頼するのが効率的です。
復旧後しばらく観察すべきこと
復旧直後の確認だけで安心せず、しばらく観察期間を設けます。
- 再発の有無: 同じ原因で再発しないかを数時間〜1日のモニタリング期間で観察します。「30分で復旧したが2時間後に同じ症状で再発」というケースは珍しくありません
- パフォーマンスが平常時に戻っているか: 応答速度・処理時間が平常時と同等に戻っているかをベンダーに確認します
- エラーログ・アラートが鎮静化しているか: ベンダー側の監視画面でエラーが収まっているかを確認してもらいます。「機能は動くがバックグラウンドでエラーが出続けている」状態は不完全復旧です
復旧確認は「点」ではなく「線」で見ることが重要です。
ベンダーに発行してもらう「復旧確認書」
復旧時には、ベンダーに次の内容をテキスト（メール・チャット等の証跡が残る形式）で残してもらいます。
- 障害発生時刻・復旧時刻
- 原因（暫定でも構わない）
- 暫定対応の内容
- 恒久対応の予定（または完了の旨）
- 影響範囲（処理件数・影響顧客数等、可能な範囲で）
この「復旧確認書」は、後の振り返り・契約上の証跡として活用できます。SLA違反の有無を判断する根拠にもなりますし、社内の最終報告にも使えます。「口頭で復旧したと聞いた」だけで終わらせず、必ず文書で残すよう依頼することが、発注者としての必須行動です。
再発防止策の依頼方法（ポストモーテム・RCA報告書の要求）
障害が収束した後、最も重要なのは「次に同じことが起きないようにする」ことです。発注者として、ベンダーに何を要求すべきか、そして提出された報告書をどう評価すべきかを整理します。
ベンダーに要求すべき報告書の内容
ベンダーに提出を求めるポストモーテム（事後検証報告書）／RCA報告書には、次の項目が含まれているべきです。
- タイムライン: 障害発生・検知・初動・暫定対応・復旧の各時刻の記録。誰が何を確認した結果、次のアクションを取ったかが時系列で見えること
- 直接原因と根本原因: 直接原因（直接的な引き金）と根本原因（プロセス・設計・運用の構造的問題）の両方を記述してもらいます。「5 Whys（なぜを5回繰り返す）」のような手法で深掘りされていることが望ましいです
- 暫定対応の内容: 何を実施したか、その効果はどうだったか
- 恒久対応の内容と完了予定: 恒久対応がまだ実施されていない場合、いつまでに実施するかの予定を含めてもらいます
- 再発防止策: プロセス改善、監視強化、自動化、ドキュメント更新、トレーニング実施など、具体的な再発防止策の一覧
報告書を要求する際は、上記の項目を箇条書きで明示して依頼するのがおすすめです。「ポストモーテムを出してください」だけだと、ベンダーごとに書く内容がばらつきます。
報告書受領のタイミング目安
報告書の受領タイミングは、次の2段階を目安にします。
- 暫定報告: 障害発生から24〜48時間以内に、現時点で判明している情報をまとめた暫定報告書を受領します
- 確定報告: 1〜2週間以内に、根本原因と恒久対応・再発防止策を含めた確定報告書を受領します
受領が遅延する場合は、催促のしかたに工夫が必要です。「いつまでに出せるか」を確認し、その期日にコミットしてもらいます。「なるべく早く」では遅延の言い訳になります。
報告書を評価する発注者目線の3つのポイント
ベンダーから報告書を受け取った後、発注者として評価すべきポイントは次の3つです。
- 根本原因が「人的ミス」で片付けられていないか: 「担当者の確認漏れ」「オペレーターの操作ミス」だけで根本原因を片付ける報告書は、再発防止策が「気をつける」「ダブルチェックする」のような曖昧な対策に終わりがちです。プロセス・仕組みの問題に踏み込んでいるかを確認します
- 再発防止策が具体的・検証可能か: 「監視を強化する」「教育を徹底する」のような抽象的な対策ではなく、「◯◯のアラートを追加し◯月までに本番運用する」「◯◯のチェックリストを作成し全担当者で運用する」のような、誰がいつまでに何をするかが明確で、後から実施を検証できる対策になっているかを確認します
- 同種障害の予防に有効か: 報告された再発防止策が、他の機能・他のシステムにも適用すべき教訓を含んでいないか、横展開の余地はないかを考えます。一つの障害から得られた教訓は、他の領域にも活かしたいものです
報告書は受け取って終わりではありません。再発防止策の実行状況を、1ヶ月後・3ヶ月後にフォローアップで確認することも、発注者の役割です。
保守契約・SLAを事前に確認しておく
ここまで「障害発生時の動き」を整理してきましたが、最も効果的な備えは「障害が起きる前」に契約・体制を整えておくことです。本セクションでは、平常時にチェックすべきポイントを箇条書きで整理します。
保守契約で確認すべきSLA条項
- 稼働率の定義と算出方法: 「99.5%」「99.9%」などの稼働率の数値だけでなく、計測対象期間・計測単位・除外事項（計画停止等）を確認します
- 障害対応の応答時間・復旧目標時間: 一次応答までの時間、復旧目標時間（RTO: Recovery Time Objective）が定められているか
- 障害ランク（重大度）の定義と対応優先度: 「重大」「中度」「軽微」の区分があるか。区分ごとに対応SLAが異なるか
- SLA違反時のサービスクレジット: 違反時の割引・返金の有無、計算方法、請求手順
障害対応体制の事前合意
- 緊急連絡先: 夜間・休日も含め、連絡が取れる窓口・電話番号を共有しているか
- エスカレーションフロー: ベンダー側の責任者（営業窓口だけでなく技術責任者）への到達経路が明確か
- 定期障害訓練: 年1〜2回程度、机上演習を含む障害対応訓練の機会を設けているか
自社側で事前に準備しておくこと
- 障害対応マニュアル: 本記事のフローを自社版にカスタマイズし、いつでも取り出せる場所に保管しておく
- 業務代替手順: システム停止時の手作業フロー（手書き伝票・スプレッドシート等）を整備しておく
- 関係者連絡網: 社内の報告先（一次・部門責任者・経営層）の連絡先一覧
- 顧客告知文のテンプレート: 緊急時に文言を一から考えなくて済むよう、告知文のひな形を準備しておく
平常時の準備に時間を投資しておくことが、いざというときの動きの質を決めます。
まとめ — 発注者の役割は「冷静な情報ハブ」になること
本記事では、本番障害発生時に発注者が取るべき対応フローを、時系列・ベンダーへの連絡・社内エスカレーション・業務影響度判断・復旧確認・再発防止・平常時の準備という観点で整理しました。要点を改めて確認します。
- 発注者の役割は技術判断ではなく「情報収集と意思決定」: 復旧作業はベンダーに任せ、業務影響度判断・社内エスカレーション・ユーザー告知判断に集中する
- タイムライン別の動きを事前にイメージしておく: 発生直後・30分以内・2時間以内・復旧時・翌営業日以降で、自分が何をするかを頭に入れておく
- ベンダーには「具体的な質問」で情報を引き出す: 第一報で確認すべき5つの質問、定期報告のリズム作りで、混乱の中でも必要な情報を確保する
- 社内エスカレーションは業務影響度で判断する: 業務停止レベルの4段階分類と3つの問いを使い、技術判断なしで報告先を決める
- 平常時の契約・準備が障害時の動きを決める: SLA条項の確認、対応体制の事前合意、自社の障害対応マニュアル整備が、混乱時の質を左右する
システム本番障害は、どれだけ備えても完全には避けられません。「障害は必ず起きる前提で備える」ことが、発注者として最も重要なスタンスです。
本記事を参考に、まずは自社の障害対応マニュアルのドラフト作成から始めてみてください。タイムライン別の動き、ベンダーへの質問テンプレート、社内報告のテンプレート、業務停止レベルの分類——これらを自社の業務に当てはめて整理しておくだけで、いざというときの動きが大きく変わります。明日障害が発生しても落ち着いて動けるよう、今日から準備を始めましょう。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
