最強の障害報告書の書き方

最近障害報告の作成に定評があるので、ポイントを共有します。

障害報告の前に第一報

障害が発生した時点で、正式な書式の前に第一報として関係者に報告します。
これは、すぐに障害報告書が書けるとしても必要な手順です。
これによって「急いで知らせてくれた感」を出します。半日でも１時間でも、障害を検知した時点で即座に報告します。
この第一報を怠ると、「なぜ早く言わなかったのか」「隠すつもりだったのか」「連絡の体制はどうなっているか」など詰められます。
第一報を大事にしてください。

業務側の責任者と話してすぐに暫定対応

例えばバッチを再起動しないと業務が止まってしまうなどの場合は、業務側の責任者とすぐに話して再起動しますよね。障害の種類については割愛しますが、今すぐ対応すべきことがある、という場面です。
しかしこれを勝手にやってはいけません。必ず「業務側の責任者と話した」という履歴を残しましょう。
そうしないとやはり「勝手に本番環境を変更して誰が責任を取るんだ」という話になります。

障害を起こした本人を責めない

システムを運用していれば障害は一定の確率で起きます。
どんなサービスでも100％の稼働を保証しているものはなく、99.9％だとしても年に8時間くらいは停止します。
人間も一定の確率で間違います。
例えば5％の確率で失敗する人と10％の確率で失敗する人がいるとします。
Aさんは失敗率5％です。月に20件対応すると月に1件の障害を起こします。
Bさんは失敗率10％です。月に5件対応すると2か月に1件の障害を起こします。
では、Aさんの方が障害を多く起すということで責められるべきなのでしょうか。
多く仕事をする人はその分多く失敗をするものです。
失敗した人を責めても上司と部下の信頼関係を失って、原因の隠ぺいや次の障害の隠ぺいに繋がるだけです。
障害に対しては、本人を責めることなく淡々と処理するべきです。

犯人捜しは・・・する！

障害を起こした人を責めないのと、犯人捜しをしないのはイコールではありません。
犯人捜し、つまり正しい原因の分析をしないと、次に同じ過ちを起こさないための対応策が思い浮かびません。
例えば、「入っているデータが誤っている」という話だったとき、

• 誰が登録したのか
• 入力する値を間違えたのか
• 貰った資料がそもそも間違っていたのか
• なぜ誤ったまま最後の処理まで行ってしまったのか
• 確認するべき人は誰だったのか

などの原因を突き止めなければなりません。
これを曖昧にして「入力した自分が全部悪いです」となってしまうと、組織としての改善がありません。人間は一定の確率で間違いますので、「間違わないように気を付ける」というのは何ら改善策になっていません。
なので、「間違いを引き起こさせたのはなんだったのか」「この仕事を別の人に引き継いだとして、その人が間違えないようにするにはどうすればよいか」などの視点を持って原因を探します。
つまり犯人捜しは、怒るためではなく、次に起こさないためにします。

いざ障害報告を書く

テンプレはなんでもいいですが、基本的には以下のような項目があります。

• 概要
• 経緯
• 原因
• 暫定対応
  • すでにやっていることが多いので、「原因と暫定対応」として流れで書くことが多い
• 恒久対応（今後の対応）

原因と恒久対策は対応させるように書いてください。

他責視点の報告書

障害報告なんだから自責で書くのが当たり前です。
ベースはそれでよいですが、自責の改善点を書いた後に、もう一度障害報告書を見直します。
ここで、業務側にも改めてほしいことがあるはずです。
いくつか例を挙げてみます。皆さんがいつも不満に思っていることです。

• 仕様書にないことを言われて対応した。その部分の条件が足りずに出力内容が違った。
• チェックしてほしいと言ったのにチェックしてくれなかった。
• 担当者が何度も変わって業務側の責任者がいない状態で判断が遅れた。
• いつも資料がおかしいから適宜読み替えて設定していた。それが違ったらしく、どこにも正解がない。

これらの不満を思い出して下さい。

障害報告はどこに行く

障害報告は誰に出すものなのでしょうか。
それを意識する必要があります。
例えば、エンドユーザー、ユーザー企業、開発会社（自社）、開発会社のメンバーの自分、という関係性の場合、開発会社のメンバーは自社の上司に障害報告を提出する意識かもしれませんが、実際には　「ユーザー企業の偉い人が見てエンドユーザーに説明する資料にする」　のです。
だから、開発会社が全部悪いですという話より、再発防止の策を考えてほしいのです。
そのためなら、自社の体制に切り込まれても、まともな部門長なら起こりません。なぜなら、エンドユーザーに利益のあることをするべきだと思っているからです。

他責を自責っぽく書く

ここが今回最大の山場です。
先ほどの他責視点（不満）を例に自責っぽく書くということを見ていきましょう。

仕様書にないことを言われて対応した。その部分の条件が足りずに出力内容が違った。

• 原因：修正内容を仕様書に反映せず、口頭で指示を受けて修正してしまい条件が不足していた。
• 対応策：修正内容を仕様書に反映し、内容の承認をいただいてから修正を行う。
• ※言いたいこと　承認ないと修正しないから！承認なしでやれっていったらそっちのせいだから！承認したのに違ってたら承認した人も悪いよね。
• ※姿勢　口頭で指示を受けるなんて正規の手順を踏まずに修正してしまい申し訳ありません

チェックしてほしいと言ったのにチェックしてくれなかった。

• 原因：依頼側に確認手段がなく、入力内容の正誤を確認できない状態だった。
• 対応策：確認資料（確認ツール）を作成し、入力内容を確認していただき、承認をいただく。
• ※言いたいこと　確認できる状態で確認しなくて間違ってたら依頼側が悪いよ！次はないからな！
• ※姿勢　確認手段を用意できておらずご不便をおかけして申し訳ありません

くれぐれも、報告に際して姿勢の部分を頭に叩き込んで挑んでください。

良く言えば視座が高くて周りを巻き込む力があるってこと

私はプロジェクト全体を良くしたいんです、という姿勢を失わないようにしてください。
障害を起こすというのは結局ユーザーに迷惑をかけているわけですし当然です。
障害が大きければ大きいほど問題の構造も根深く、大きくプロジェクトの体制が変わるきっかけにもなります。大きな予算を割り当てられ、大きく改善することもあります。
これは相手の担当者の人間性をどれだけ把握できているかにもよりますが、問題に切り込む勇気をもって障害報告を書いてください。

※シンプルにやらかした場合は普通に大人しく自責で障害報告を書きましょう。