ポストモーテム 入門 障害の振り返りボード|起きたことを時刻順に並べ、人を責めずに原因と再発防止のタスクまで決める

プロジェクト管理・開発

ポストモーテム 入門 障害の振り返りボード|起きたことを時刻順に並べ、人を責めずに原因と再発防止のタスクまで決める

ポストモーテム(障害の振り返り)を初めて行う開発・運用チーム向けの入門テンプレートで、障害や大きなミスが収まった翌日から1週間以内に、人を責めずに起きたことを時刻順に並べ、仕組みの原因と再発防止のタスクまで決められます。4枚の盤面で、1枚目で責めない約束を確かめ、障害の概要を書いて集める材料と持ってくる人を決め、2枚目で発生から収束の確認までを6段のタイムラインに並べて影響を数字で書き、3枚目でなぜなぜ分析(5 Whys)を使って仕組みの原因を掘り、対策を効果と手間で選び、4枚目で対策を担当と期限つきのタスクにして、共有する相手と日、次の振り返りで確かめることを決めます。タスクボードは「材料集め」「話し合い中」「対策の実行中」「効果を確認中」「完了」の5列で、4枚の盤面に合わせた親タスク4件と、それぞれ3件の子タスクが入っています。ポストモーテムの書き方に迷ったら、盤面の②〜④を概要、⑦を影響、⑫を根本原因、⑰を教訓、⑭を再発防止策として報告書に写せば形になります。人ではなく仕組みを見る「ブレームレス」の進め方を盤面の約束にしてあるので、初めてでも話し合いが責め合いになりにくく、限定公開チームのメンバーと一緒に書けます。

0 いいね 0 コピー 作者: WeProcess
ポストモーテム 障害対応 振り返り 再発防止 なぜなぜ分析
無料登録してこのテンプレートを使う

無料登録すると、マーケットプレイスからこのテンプレートをコピーして使えます

ホワイトボード プレビュー

プレビュー表示中 ポストモーテム 入門 障害の振り返りボード|起きたことを時刻順に並べ、人を責めずに原因と再発防止のタスクまで決める

ホワイトボード プレビュー

① 振り返りの約束(ここから始める・最初に全員で読む) ② 何が起きたか ③ いつからいつまでか ④ きっかけ(分かっている範囲で) ⑤ 集める材料と持ってくる人(話し合いの前日までに) ⑥ 時刻順のタイムライン(⑤で集めた材料から並べる) ⑦ 影響の大きさ(事実と数字で書く) ⑧ まだわからないこと(決めつけずに分けておく) ⑨ うまくいったこと(⑥のタイムラインから) ⑩ うまくいかなかったこと(⑥から) ⑪ 運がよかったこと(⑥から) ⑬ 対策を選ぶ(⑫の原因に効く対策を置く) 効果が大きい × 手間がかかる 効果が大きい × 手間が少ない 効果が小さい × 手間がかかる 効果が小さい × 手間が少ない ⑭ 再発防止のタスク(⑬で選んだ対策から) ⑮ 振り返りを共有する相手 ⑯ 共有する日と伝え方 ⑰ 教訓(報告書にそのまま書く) ⑱ 次の振り返りで確かめること ポストモーテム 入門ボード(人を責... 使い方(全4枚): ① 責めない約... 決めたこと・対策 約束・担当 障害・うまくいかなかったこと 気づき・うまくいったこと 1/4 責めない場を整える Ctrl+F / ⌘F : 2/4... → 2/4 2/4 時刻順に並べる ↙ 3/4 人ではなく仕組みを見る「誰が間違えたか」ではなく「なぜ間違えやすかったか」を話す その時の判断には理由があった後から分かったことで責めない。例)その時見えていた情報で考える 事実と推測を分ける推測には「推測」と書き添える。例)推測: 設定の変更が原因かも 例)注文ページが開けなくなった 例)お客様が注文できなかった 見えた症状をそのまま書く 原因はまだ書かない(3枚目で掘る) 例)始まり 10月6日 14:05 例)終わり 10月6日 15:20 例)今は元どおりに動いている 時刻は記録で確かめて24時間表記で書く 例)14:00 に画面の更新を公開した 例)推測: 設定の値が古いままだった 分かっていないことは「不明」と書く 推測には「推測」と書き添える 集める材料 持ってくる人 いつまでに システムの記録 例)エラーの記録・アクセス数のグラフ 担当: ____ 例)振り返りの前日まで 連絡の履歴 例)チャットのやり取り・電話のメモ 担当: ____ 例)振り返りの前日まで お客様の声 例)問い合わせの件数と内容 担当: ____ 例)振り返りの前日まで 発生 14:05起きたこと例)注文ページが開けなくなった 検知 14:20誰が・何で気づいたか例)問い合わせを受けた窓口の人が気づいた 連絡 14:30誰に・どう伝えたか例)開発チームのチャットに知らせた 対応 14:40何をしたか例)14:00の更新を元に戻し始めた 復旧 15:20いつ元に戻ったか例)注文ページが開けるようになった 収束の確認 16:00どう確かめたか例)注文の数がふだんどおりに戻った 数字で書く 確かめた記録 確かさ 影響を受けた人 例)注文できなかった人 約120人 例)アクセスの記録 例)推測(数え方を確認中) 止まった時間 例)75分(14:05〜15:20) 例)エラーの記録 例)事実 問い合わせ 例)8件 例)問い合わせの一覧 例)事実 止まった仕事 例)発送の準備が1時間遅れた 例)倉庫からの連絡 例)事実 わからないこと例)14:05〜14:20 の間、なぜ通知が届かなかったか 調べる人と期限担当: ____ / 期限: __/__ 分かったら書き足す場所例)⑥のタイムラインと⑦の表に書き足す 3/4 仕組みの原因を掘る → 4/4 4/4 再発防止を割り振る 例)窓口の人がすぐ開発チームへ知らせた 例)元に戻す手順が手順書にあった 次も同じように動ける理由を書く 例)更新後に注文ページが開けなくなった 例)気づくまで15分かかった 人ではなく出来事を主語にする 例)お客様の少ない時間帯だった 例)詳しい人がたまたま席にいた 次は運に頼れないので対策の候補にする ⑫ なぜなぜ分析(5 Whys):... なぜ1 例)なぜ開けなくなった?→ 設定の値が古いままだった なぜ2 例)なぜ古いままだった?→ 公開前に試す場所で試さなかった なぜ3 例)なぜ試さなかった?→ 試す手順が手順書に無かった なぜ4 例)なぜ無かった?→ 手順書を直す担当が決まっていない なぜ5 例)なぜ決まっていない?→ 手順を変えても手順書を直す決まりが無い 根本原因 例)手順の変更と手順書の更新がつながっていない(仕組みの原因) 縦軸: 効果(上=大きい) / 横... 計画して進める。例)公開前に自動で確かめる仕組みを作る いちばん先にやる。例)手順書に「公開前に試す」を足す 今回は見送る。理由を書いて記録に残す ついでにやる。例)連絡先の一覧を最新にする 何を 誰が いつまで どう確かめるか 対策1 例)手順書に「公開前に試す」を足す 担当: ____ 例)1週間後 例)次の公開で手順どおりか見る 対策2 例)手順を変えたら手順書も直す決まりを作る 担当: ____ 例)2週間後 例)決まりをチームで読み合わせる 対策3 例)エラーが増えたら通知が届くようにする 担当: ____ 例)2週間後 例)試しにエラーを起こして通知を見る 対策4 例)公開前に自動で確かめる仕組みを作る 担当: ____ 例)1か月後 例)仕組みが止めた件数を数える 例)窓口のチーム 例)上司と関係する部署 例)同じ仕組みを使う他のチーム 例)10月10日の定例で10分 例)報告書をチャットで共有する 日付: __/__ / 担当: ____ 例)公開前に試す手順は手順書に書かないと抜ける 例)窓口からの連絡が早いと復旧も早い 人ではなく仕組みについての学びを書く 確かめる日例)1か月後の定例日付: __/__ 確かめる数字例)⑭の対策がいくつ終わったか例)同じ障害が起きていないか 確かめる人担当: ____結果はこのボードの⑭に書き足す → 2/4 時刻順に並べる ↙ 3/4 仕組みの原因を掘る → 4/4 再発防止を割り振る
100%

ドラッグで移動・ホイールで拡大縮小

タスクボードの内容

材料集め 16件

責めない場を整える
時刻順に並べる
仕組みの原因を掘る
再発防止を割り振る
責めない約束を読み合う
障害の概要を書く
集める材料と担当を決める
タイムラインを並べる
影響を数字で書く
わからないことを分ける
よかった点と課題を出す
なぜを5回重ねる
対策を効果と手間で選ぶ
対策をタスクにする
共有の相手と日を決める
次に確かめることを決める

話し合い中 0件

対策の実行中 0件

効果を確認中 0件

完了 0件

← テンプレート一覧へ戻る