一番気が重いと言われたポストモーテム委員会の改革

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Copyright coconala Inc. All Rights Reserved. 6 ココナラでの運用（ Before） ● 5年ほど前から週次で実施 ○ ポストモーテム委員会 ○ 障害報告チャンネルにあがってきた事象を対象 ○ エンジニアの各グループから委員を募って 30~60分のMTG ● 委員会のざっくりとした流れ ○ 事前に対象の障害に関わったエンジニアがドキュメントを記載 ○ 週次の委員会（MTG）に持ち込む ○ ドキュメントを中心に事象や対応について議論 ○ 議論の内容をもとに再発防止策を Fix

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Copyright coconala Inc. All Rights Reserved. 10 なにがそう感じさせたのか重いと感じさせてしまっていた要素 ● ドキュメントの精度 ○ 1稿作成に平均4時間程度 ○ 再発防止等をきちんと考えてくる必要があった ○ インシデントの時系列も細かく表化するようなフォーマットであった ● 雰囲気 ○ 再発防止まで記載したドキュメントのレビューが中心 ○ どうしても対象者の処置だったり、その対策の効果に対する議論に始終してしまい、糾弾するような空気になった ○ 有志で集まった委員も「自分はああなりたくない」として発言しづらい

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Copyright coconala Inc. All Rights Reserved. 12 ぼくの考えるポストモーテムと障害報告の違い項目ポストモーテム障害報告目的障害からの組織的な学び障害の影響度合いと再発防止のまとめ分析手法・範囲原因を中心として、技術以外にも運用・プロジェクトも含めた多角的な視点を求める根本原因となった点を中心とした技術的に細かい箇所 & 横展開ドキュメントフォーマットある程度の柔軟性があるほぼ固定

Slide 13

Slide 13 text

Copyright coconala Inc. All Rights Reserved. 13 ぼくの考えるポストモーテムと障害報告の違い項目ポストモーテム障害報告目的障害からの組織的な学び障害の影響度合いと再発防止のまとめ分析手法・範囲原因を中心として、技術以外にも運用・プロジェクトも含めた多角的な視点を求める根本原因となった点を中心とした技術的に細かい箇所 & 横展開ドキュメントフォーマットある程度の柔軟性があるほぼ固定ドキュメントのフォーマットも委員会の運用も障害報告向きになってしまっていた

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Copyright coconala Inc. All Rights Reserved. 16 雰囲気だけでも変えたい ● 来るまでの重さ ○ 精度の高いドキュメントを書くために時間がかかる ○ 通常開発をしながらその時間をなかなか捻出できない ● 来てからの重さ ○ とりあえず空気が重い ○ なに突っ込まれるかわからないネガティブポイントばかり捉えてしまうからよくない！ポジティブ要素もちゃんと一緒に振り返って「まなび」を広げたい

Slide 17

Slide 17 text

Copyright coconala Inc. All Rights Reserved. 17 雰囲気だけでも変えたい ● ドキュメントフォーマットを一新 ○ 言葉遣いを変更 ■ ex.) 再発防止→ アクションアイテム ○ 学びコーナーによかったことを2つ追加 ■ 事象に対する処置の仕方 ■ 事故になったけど〜のおかげで被害が広がらなかった ○ タイムライン表記をやめる ■ もともとSlackのチャンネルでやりとりしているので、そのリンクを転記するだけ

Slide 18

Slide 18 text

Copyright coconala Inc. All Rights Reserved. 18 雰囲気だけでも変えたい ● アクションアイテムは委員会でブレストする ○ 事前になにか考えてくる必要はない（もちろん思いつくのであれば OK） ○ 事象に詳しい人、そうでない人、俯瞰的に捉えている人で考えることは違う ○ 「これは仕方がないよね」も1つの結論とする ■ 相応の理由は必要であるけれど ● 過去に定めた再発防止策（アクションアイテム）も見直す ○ 無理やり生み出しただけで対応コスパが悪いものは引き下げ or 考え直し

Slide 19

Slide 19 text

Copyright coconala Inc. All Rights Reserved. 19 2つを変えて半年間の結果 ● 明らかにメンバーからの発言が増えた ○ 定量的な指標だが、1回につき1人 → 1回につき4~5人（全体は7~10人） ○ メンバーから「やりやすくなった」という声 ● なんでも技術で解決しようとしなくなった ○ 「技術的には可能ですが」→ プロジェクト/プロダクト運用の問題では？という視点も生まれるようになった ● なによりも委員会のときの空気感が圧倒的に軽くなった ○ 障害報告じゃないんだ、という感覚を持ってもらえている

Slide 20

Slide 20 text

Copyright coconala Inc. All Rights Reserved. 20 今後の課題 /展望 ● 技術ライン以外のステークホルダーとの戦い ○ 「技術的には可能ですが」→ プロジェクト/プロダクト運用の問題では？という視点も生まれるようになった ○ のはいいが、これをプロダクトラインに理解してもらい、施策として入れ込む必要がある ● AI利活用 ○ フォーマットとSlackスレッド / チャンネルを渡すことでいい感じのものはできる ○ 過去のポストモーテムを学習してもらい、類似性検索等もしたい

Slide 21

Slide 21 text