HOME > BLOG > やらかしたとき、再発防止策を求められたらどうする？
作成: 更新:

やらかしたとき、再発防止策を求められたらどうする？

LINE
この記事は最終更新日から1年以上が経過しています。この記事は最終更新日から21か月以上が経過しています。
このエントリーは約4分で読めます。
kpt再発防止策振り返り改善カイゼン

warとcronバッチを本番環境にデプロイしたところ、
実はリリース物が検証環境差異を含んでいて、検証環境を向いちゃってた！
というヤバめな事故があり、再発防止策を求められた際に行った内容。
KPTでいうと「Problem」を定義して「Try」を抽出する公式(個人的見解)

  • やらかした…顕在的リスク
  • 他の振り返り時に問題があらわになってきた…潜在的リスク

上記発生したとき、後述の手順で再発防止策を提案してきた。
※「問題あっての再発防止策検討」なので、問題なかったらYWTなどで振り返りして問題を浮き彫りにしてから

目的

  • 発生した問題を二度と発生させないこと
  • 問題発生のリスクを減らすこと

目的は「やらかし人が反省すること」ではなく「再発防止策をだすこと」

実際の作業

1.問題発生前後に行った作業を時系列で書き出す

  • とにかく書き出す、手を止めない
  • 事実だけを書き出す、事実以外(自分の感情、予想)は書かない
  • 必須事項は以下
    • 作業実施時のタイムスタンプ
    • 作業者
    • 作業内容
  • 固有名詞を用い具体的に書く(誰でもわかるように記載、読者を想定せず書く)
  • 例：2019/01/01 14:30 作業者Aが「/home/hogefuga/」配下に本番用(〇〇リポジトリ#12345)の「.bashrc」を配置した

2.問題発生の原因になった作業を複数ピックアップする

  • 原因は1つではない可能性が高いため、少しでも関係あるものはピックアップ

3.1つの原因作業に対し、複数の問題点を列挙する

4.1つの問題点に対し、原因分析していく

5.第三者に原因分析の結果を説明し意見を聞いてみる

  • 悩み始めた(=手が止まった)時がチェックポイント
  • 悩んでる状態はアウトプットないため

具体的なゴール

  • システム依存の再発防止策

※「スキルアップしよう」「注意しましょう」などの「人依存」の対策はダメ。
結局その人のスキルによるので、人により結果が変わってきてしまう
実施タイミングや実施者で結果が変わる対策は「再発防止策」ではない
「いつ」「誰が」やっても常にその問題が発生しない対策をたてる！

注意

1.問題発生前後に行った作業を時系列で書き出す

  • 一番時間かけること
  • ①細かく②たくさんの量を洗い出すこと

問題発生原因となる作業が間違っていたら原因が変わってくる
→解決策も変わってくる
→振り返りたい問題の解決につながらず、全く意味ない振り返りになるため

2.問題発生の原因になった作業を複数ピックアップする

  • 主観的に考えず、事実から客観的に問題発生の原因を洗い出すこと

個人の問題は「気をつける、勉強する」しかないので、、、
他作業者が問題を発生させないため、の対策はたてられないため
人依存になると、結局その人のスキル次第になってしまうので「二度と発生しない」とは言い切れない
特に以下が含まれてないかはチェックする

  • 個人の感情
  • 予測、仮説

4.1つの問題点に対し、原因分析していく

  • 原因分析の完了条件を意識すること

ゴールが「システム依存の再発防止策」なので
人依存の対策がでてる場合はまだ完了していない。
人依存の対策の判断基準とは
新人、新規参画者など技術・業務スキルが不足しているような
「信用できない人に任せられる作業」かどうか。
逆に言えば
「どんな人でも任せられる作業」
できることなら
「なにもしなくていい」
が最高の着地点。

###P.S. 問題分析の際、とてもいい方法がありました。
現在僕はこれしか使いません↓
https://note.com/mkt66gs/n/n2f61a0547284

5.第三者に原因分析の結果を説明し意見を聞いてみる

  • 個人のネガティブ感情が混ざってないかを観点にレビューしてもらうこと

自分のミスなんで、基本的にメンタルやられる
そのためどんなに意識して振り返っても、人間の自己防衛本能により無意識的にミスを隠している可能性がある
そのミスは他人に確認してもらえば案外すぐ見つかる
(主観ではみつけられない矛盾は割とある)

補足

見落とし、ケアレスミスなどの個人のスキル不足はほぼ確実に原因の一つ。
これらを減らすためには、
「〇〇のスキル不足」という個人レベルの問題に焦点をあてて上記フローを回してみると
取得するスキルが厳選される。再発防止に特化したスキルのみ抽出できるのでGood

所感

巷でいろんな振り返り手法やフレームワークが取り沙汰されるが
それらツールを「どの場面で」使うかがあまり落とし込めてなかった
今回再発防止策を求められてツールの使いどころや目的が実務ベースで実感できてとてもよかった
(本番障害起こしたので全く良くはないが。。。直接的な市場影響でなくてよかった。。。)
もともと他メンバーが進めてたdevopsも問題が顕在化したことで優先度が高くなっていて、
とても進んでる感じがしてよかった(よくないです、本当にすみませんでした、)

参考