SESで障害を起こしたら？報告の順番と障害報告書の書き方

本番の画面が開かない、と問い合わせが入った。しかも、原因は自分の担当ではない変更かもしれない。頭が真っ白になって、誰に何から伝えるか分からなくなる瞬間は、保守の現場なら誰にでも来ます。

私はSESエンジニアとして5年ほど、4社の現場を経験しました。3社目の保守改善では約1年半、障害調査・不具合修正を担当しています。IPA（情報処理推進機構）の障害管理の調査報告書も、重大な障害は原因の追究と再発防止策まで行うよう示しています。

今回は、SESで障害を起こしたときの報告の順番と障害報告書の書き方を、私の失敗を交えてお伝えします。

目次

1. SESで障害を起こしたら、最初の30分で何が起きたか
2. 3社目の保守で起きた障害の概要
3. 私が最初にやったこと
4. 自社と客先の二重の報告先｜どちらに先に連絡するか
5. 自社への連絡を忘れていた私に、営業から電話が来た
6. 先に客先へ、15分以内に自社へ同文を転送
7. 順番を決めるのは契約と社内規程
8. 第一報・続報・最終報の分け方｜障害報告の書き方の基本
9. 3つの報告の役割
10. 第一報に入れる4項目
11. 障害報告書の書き方｜項目と、自分の担当外が原因のときの言い方
12. 障害報告書に書く項目
13. 責任分界の書き方｜担当外が原因のとき
14. 再発防止策の書き方｜悪い例と良い例
15. 悪い例と良い例
16. 暫定対応と恒久対応を分ける
17. 障害のあとに気になること｜手当と、私が決めたルール
18. まとめ

SESで障害を起こしたら、最初の30分で何が起きたか

3社目の保守改善に入って5か月目、水曜の日中に定期リリースがありました。その翌日の木曜に起きた障害を例に、最初の動きを時系列で見ていきます。

3社目の保守で起きた障害の概要

障害の中身は、金融系Webサイトのマイページで、契約一覧が開かないというものでした。契約を3件以上持つ顧客だけが、エラー画面になります。

原因は、前日のリリースに入っていた別の依頼の変更です。契約一覧を取得する処理の修正で、私の担当ではありませんでした。検証環境のテストデータに、契約3件以上の顧客がおらず、テストで見つからないまま本番に出ていました。

エラーが出たアカウントはログ上で61件、問い合わせは11件でした。

私が最初にやったこと

調査の依頼は9時15分に、保守チームのリーダーから届きました。調べ始めてすぐ、本番ログにエラーが並んでいると分かり、9時25分に現場のリーダーへ口頭とチャットで第一報を入れました。

ここまでは、自分でも悪くない動きだったと思っています。問題は、そのあとです。自社への連絡を、完全に後回しにしました。

自社と客先の二重の報告先｜どちらに先に連絡するか

結論私は客先の現場のリーダーに先に連絡し、自社には同じ内容を時間を置かず転送する形に落ち着きました。ただし順番は契約と社内規程で決まるので、入場前に確認しておくのが前提です。

SESには報告先が2つあります。仕事の指示を出す客先と、雇用や契約を握る自社です。ここでは、私が実際にどう間違えたかと、そこから決めた運用を書きます。

自社への連絡を忘れていた私に、営業から電話が来た

障害の原因調査に集中していた12時40分、自社の営業から電話が入りました。

客先の上位の方が、現場を通さず自社の営業に状況を聞いたのです。営業は何も知らず、答えられない立場に置かれました。

自社の上長からは、客先に出した文面は同じものを自社にも入れてほしい、と言われました。私は障害の渦中で、自社は後で、と考えていました。報告が遅れたことで、自社が客先に対して無防備な状態を作ってしまっていました。

先に客先へ、15分以内に自社へ同文を転送

この件のあと、私は次の運用にしました。

1. 客先の現場のリーダーに第一報を入れる障害の指示系統は客先側にあります。初動の遅れを避けるため、ここを先にします。
2. 15分以内に、同じ文面を自社へ転送する自社の営業と上長に、チャットの文面をそのまま送ります。書き直す時間は使いません。
3. 続報も同じ二重の形で出す客先に出したら、自社にも出します。自社だけ情報が古い状態を作りません。

自社に先に相談する方法もありえます。ただ、現場のリーダーに初動が遅れると、客先の判断（利用部門への連絡や緊急枠の手配）が遅れます。私の現場では、客先への連絡を先にした判断が合っていました。

順番を決めるのは契約と社内規程

ここで強調しておきたいのは、私の運用が万能ではないことです。先にどちらへ連絡するかは、契約と自社の社内規程に従うのが原則だからです。

たとえば、自社への即時連絡が規程で義務づけられている会社もあるでしょう。重大障害は、客先より先に自社へ一報を求められる場合もあり得ます。

IPAの中小企業向けインシデント対応の手引き（セキュリティ分野向けです）も、発見者はまず社内の責任者へ報告し、責任者が経営者へ伝える流れを示しています。参考にするなら、報告先と順番が事前に決まっていることが大事、という点です（出典: IPA 中小企業向けインシデント対応の手引き）。

第一報・続報・最終報の分け方｜障害報告の書き方の基本

報告は1回で済ませず、3段階に分けます。ここでは、それぞれに何を書くかと、実際に私が書いた第一報の形を見ていきます。

3つの報告の役割

3つの報告は、書く内容も、求められる速さも違います。表のタイミングは、私の現場での目安です。

IPAの手引きも、第二報以降と最終報で、取引先へ対応状況と再発防止策を伝える流れを示しています。第一報では原因まで書かない、という点が一番のコツです。

第一報に入れる4項目

第一報の目的は、原因の説明ではなく、相手が判断を始められる最低限の材料を渡すことです。私は次の4項目に絞りました。

「分からない範囲」を書くことは、地味に重要です。原因の推測を書くと、外れたとき信頼を失います。分かっていることと分かっていないことを分けて書くだけで、報告の質は上がります。

実際に出した文面の要旨は、次のとおりです。

この日は11時30分に続報1、13時40分に原因特定を含む続報2、17時30分に復旧の続報3を出しました。続報の時刻を第一報で約束しておくと、相手から催促されずに済みます。

障害報告書の書き方｜項目と、自分の担当外が原因のときの言い方

ここからは最終報にあたる障害報告書の話です。何を書くかを項目で整理し、そのうえで責任分界と、担当外が原因のときの書き方に進みます。

障害報告書に書く項目

IPAの「障害管理の取組みに関する調査」報告書は、障害の発生状況を記録することを求め、復旧後も記録を怠らないよう示しています。同報告書の表2-2にある障害等報告書の例には、管理番号・システム名・発見日・発見者・対象・状況・通知先・応急措置・対処方針と承認権限者・対処実施者・対処区分・対処結果・原因・対処の詳細が並びます（出典: IPA 障害管理の取組みに関する調査）。

私の現場の様式は客先指定でしたが、中身はこの例とほぼ重なっていました。私が書いたもののうち、特に気を使った箇所を表にします。

書くのに約2時間かかり、そのほとんどは時系列の復元に使いました。チャットの履歴とログの時刻を突き合わせると、記憶より正確に書けます。

責任分界の書き方｜担当外が原因のとき

厄介だったのは、原因が私の担当ではない変更だったことです。調査したのは私なのに、原因を書けば誰かの変更を指摘する文面になります。

私が現場のリーダーに確認した言い方は、こうでした。

人ではなく、依頼番号と条件で書く。これが担当外のときの基本です。「事象の契機は、水曜リリースの依頼番号〇〇に含まれる契約一覧取得処理の変更。契約3件以上の顧客で、並び替え処理が例外を返す」のように、起きた事実と発生条件だけを書きました。

書いてはいけないのは、個人名と「ミス」という評価の言葉です。原因は個人ではなく、テストで見つからなかった仕組みの側にあります。報告書は誰かを裁く場ではなく、再発を防ぐための記録です。

担当者を責める書き方をすると、次から障害が隠される現場になりかねません。損害賠償の話が気になった方は、別の記事にまとめています。

関連記事SESでミスをしたら損害賠償？準委任の善管注意義務と個人が負う責任の範囲SESでミスをしたら損害賠償を請求されるのか。準委任の善管注意義務、会社からの求償、給与天引きの考え方を、検証環境の設定ミスで他…

再発防止策の書き方｜悪い例と良い例

最終報の山場は、再発防止策です。ここが「気をつけます」で終わる報告書は、読んだ側が次の判断に使えません。

悪い例と良い例

同じ障害について、悪い例と良い例を並べます。

悪い例

• 影響範囲の確認を徹底します
• 担当者に注意喚起を行いました
• 今後はテストを入念に行います

良い例

• テストデータに契約0・1・3件・上限件数の顧客を追加する（第4水曜のリリースまで）
• リリース申請書のテスト観点欄に「データ件数の境界」を追加する
• 本番データでの全画面横断確認の要否は、検討中（次回定例で決定）

良い例の特徴は3つあります。対象が具体的であること、期限があること、そして未確定は「検討中」と正直に書くことです。

IPAの手引きは、再発防止を技術・ルール・教育・体制・運用改善の観点で整理するよう示しています。私の良い例は、テストデータ（技術）と申請書の観点欄（ルール）の2つに分けた形です。

暫定対応と恒久対応を分ける

もう1つ、私が報告書で必ず分けるようにしている点があります。暫定対応と恒久対応を分け、恒久対応には期限を付けることです。

私の場合、暫定対応は緊急枠で反映した処理の修正と、同じ処理を使う他の画面2つの動作確認でした。恒久対応は、先ほどの2つです。第4水曜のリリース前に、テストデータの追加が終わっているかを、客先のリーダーに確認してもらいました。

障害のあとに気になること｜手当と、私が決めたルール

障害や深夜の呼び出しが続くと、手当や自分の負担も気になってきます。この記事では詳しく踏み込みませんが、入口だけ置いておきます。

夜間の呼び出しに手当は出るのか、正式な当番体制があるのか、という話は別の記事に書きました。

関連記事SESのオンコール・夜間呼び出しに手当は出る？待機手当・残業代・断れるかを整理SESの保守案件でオンコール待機や夜間・休日の呼び出しがあるとき、待機手当や残業代は出るのか。対応した時間の割増、待機時間が労働…

今回の障害では、損害賠償や責任追及の話は出ませんでした。ただ、迷ったときの私のルールは決まっています。報告は早く、事実だけを、客先と自社の両方に。この3つを守るだけで、大きく外れることはありませんでした。

まとめ

SESで障害を起こしたら、報告先は客先と自社の二重になります。私は客先の現場のリーダーに先に第一報を入れ、15分以内に自社へ同文を転送する形にしました。順番そのものは、契約と社内規程に従うのが原則です。

私が一番伝えたいのは、障害そのものより、報告の遅れと曖昧さが信頼を傷つけるということです。報告は早く、事実だけを、二重に出す。これが、私が失敗から持ち帰った型でした。

これから保守の現場に入る方は、障害時の連絡先と順番を、参画直後に一度聞いておいてください。すでに現場にいる方は、第一報の4項目を、メモアプリに雛形として置いておくだけでも、いざというときの動きが変わります。