障害・リスクマネジメント

ドキュメント

心構え

淡々と冷静な説明をこころがける

• 当然のことながら事実は脚色しない。無駄な修飾も要らない。客観的な事実を簡潔に述べる。
• 例： ❌「一生懸命頑張って対応したが…」 ❌「寝ないで対応したが…」 ❌「本当の原因は…」

できるだけ数字で説明する

• 具体的な数字をできるだけ用いた説明をする。
• 例：　❌「大勢のユーザーに影響が出た」 ❌「サービスに深刻な影響を及ぼした」　⭕️「MM月DD日01:30頃〜5:15頃の間にログインを試みた５,９６３人のユーザー」）
• 分からないところは「現在調査中」などとし、追って報告するなどの調整をしよう。

報告の内容でもっともプライオリティが高いのは影響範囲

• 原因と対策はその次だと思って構わない。
• 報告の時点で完全に分かっていなくても、分かっている範囲で影響範囲は述べること。
• 例： （まず報告しなければならない内容として） ❌「プログラムの実装で発生したバグによりログインエラーが発生した」 ⭕️「およそ３時間の間約1000人のユーザーがログインできない状態が発生していた」

• エンジニアの人が書くと職業柄どうしても原因に重きを置きがちな傾向にはなる。この報告で重要なのはビジネス上どのくらいインパクトを及ぼしたか（及ぼすか）という、報告を受けた人たちがそれを考えるための情報である。サービスのブランディングや信用、経済的損失（お金の問題）などに関わるからだ。

「です・ます」調や「だ・である」調でOK

• クライアントなどとの関係から「ございます」「いただいた」といった丁寧・謙譲語を書いてしまうかもだが、シンプルにですます調（です、でした）、またはだ・である調（した、であった）で問題ない。
• 原因説明や対策は「です・ます」調、概要や時系列など事実説明では「だ・である調」が良いかなと思っている。

体言止めは使わない

• 「〜へ一時報告。」「〜を計画、」と書いたりすることはないだろうか。なんとなく言わんとしていることはわかるが、した、のか、する、のか曖昧で読み手が判断に迷う場合がある。
• 時系列で経緯を説明する場合などで、体現止めにならないように注意しよう。

原因や改善対象は個人に帰するものではない

• 故意でやってない限りは、誰か一個人を原因とすることはない。
• チームで分担して開発している以上、誰か担当の人間の行為が事象のトリガーとなる場合があるが、だからと言ってその人を原因とすることはない。
• 背景、開発手法、運用方法などから、何が原因かどうやって解決していくかなどをポストモーテムなどを通してチームやプロジェクトなど考えていくことになる。

「意識」や「注意」では対策にならない

• 心持ちというよりプラクティスな内容であるが、改善策や再発防止策として「意識」や「気持ち」を変えるだけでは対策にならない。ヒューマンエラーの問題解決は人に依存しないところで解決すべし。
• フローを変える、環境を見直す、手順を見直す、（ツールなどで）機械的に解決する、といった対策をチームやプロジェクトで考えよう。
• 例：❌「同様の問題を起こさないよう開発者の意識を高める」 ❌「十分注意して作業する」 ⭕️「設計の段階でセキュリティのレビューを入れる」 ⭕️「一見して分かるように本番環境のUIの背景色を変える」 ⭕️「手順に作業監督者のダブルチェックと指差し確認を加える」 ⭕️「CIツールを導入してマージ前に自動的にテストをするようにする」
• ただし、教育や啓発といった目的で、意識や認識を高める施策活動を他の対策と併せて実施するのはアリ。

必ずレビューを経る

• SLAや補填・補償内容など、各契約に関わることもあるので、他の人（マネージャーなど）のレビューを経よう。

書く内容

必須

項目	どんな内容を書くか
（導入部分）	一言二言謝罪の言葉を述べ、これから事象内容について説明する導入文章を書こう。なおここは謝罪の部分であるので丁寧な口調を使う。
概要	事象の概要を書く。簡単な5W1H的説明を述べる。次項の影響範囲も含めて、サマリー表などを横に書き添えるのも良いアイディア。
発生日時	障害は発生した時間を書く。”YYYY年MM月DD日 hh:mm〜YYYY年MM月DD日 hh:mm”形式が良いだろう。時間は”hh:30頃”といった形でも良いが、SLAなどに関係する場合は正確に書く。
影響範囲	障害が発生していた場所や、影響を受けたユーザーの数、その条件などを書く。その時点でわかっている範囲でできるだけ具体的に説明する。数字が変化する可能性があればその旨も言及する。場合によってはユーザー数などは補填・補償に関係するので正確な数字が求められる。
経緯	事象の発生とその対処、完了までの一連の流れを時系列で説明する（完了していないのであれば現時点まで）。”MM/DD hh:mm 説明"　という書き方。表にしても良い。誰と誰がどうやりとりしたかといった自分たち以外のステークホルダー含めて、対応や連絡・報告のアクションの流れも記述する。
原因	直接的原因と間接的原因を書く。直接的原因とは問題事象の発生トリガーとなった原因である。例えばバグだったりオペミスだったり物理故障だったりである。間接的原因は、背景要因の説明であり、なぜそれを発生させたのかの分析の説明である。例えばテストが不十分だった、仕様や設計の考慮漏れだった、などといった理由である。原因がまだ調査中の段階で一旦出す場合は「調査中」とし、書ける情報を書いておく。
対応	原因を踏まえて、問題を解決する対応策などを説明する。（場合によっては報告書を出す段階ではすでに対応済みであるかもしれない。）当座の間でのワークアラウンドを「暫定対応」とし、根治的な改善改修を「恒久対応」とする、といった形で段階を分けて対応を計画し、説明する場合がある。開発のインパクトやスケジュールなどを勘案する必要があるためである。
再発防止策	前述の恒久対応の延長として説明することもある。同様の事象を再発させないために講じた対策を説明する。これはチームだったりプロジェクトだったり会社だったりで対応することになるので、必要に応じてPDCAサイクルに組み込んだり、ルール化・標準化したりと、開発・運用の品質向上として関係者全体で取り組むことになる。
その他	残タスクや検討事項、提案事項など、補足や備考など、付記しておきたいことを書く。

その他場合によって書くもの、添えるもの

項目	内容
設計系の図	構成図やネットワーク図、コンポーネント図など、問題が発生した箇所などを視覚的に把握するために添えたりする。✖︎印などをつけて分かりやすくする。
画面キャプチャ	実際に発生している事象を画像として記録し、どのようになっていたかの視覚的な説明資料としたりする。
ログ	実際に発生した時間やエラー内容など、証跡資料として添付したりする。エビデンスとなる場合がある。

参考

• 障害報告書を書こう！