BLOGサブスレッドの日常

2020.07.17

インシデントカンファレンスをやってみた

tama

はろー。tama です。
たまみチャンネル、はじまるよ〜。

はじめに

一昨年の合同勉強会2018で「看護の世界 ITのセカイ」という発表をさせてもらいました。

その中で「インシデントレポート」について紹介しました。

インシデントレポートとは

  • 重大な事故・災害(アクシデント)、軽微な事故・災害(インシデント)、ヒヤリ・ハット(事故には至らなかったもののヒヤリとした、ハッとした事例)は統計上 1:29:300 となる(ハインリッヒの法則)
  • インシデントレベルのものを共有し、原因究明・再発防止をすることでより重大なアクシデントや同種のインシデントを防ぐ
  • そのためにインシデントレポートと呼ばれる報告文書を作り、カンファレンス(会議)で共有・議論する

というものです。
医療・看護系では当たり前にインシデントの共有(インシデントカンファレンス)が行われています。
「月1つはインシデントレポートを書きましょう」と推奨している病棟もあると聞きます。

インシデントレポートには、

  • When いつ
  • Where どこで
  • Who 誰が
  • Whom 誰に
  • Why なぜ
  • What 何を
  • How どうしたか

などの事実を正確に記載します。
インシデントカンファレンスはインシデントレポートを参考に事例の共有と原因究明、そして再発防止策を議論する会議です。決して犯人探しや反省をする場ではありません。
したがってインシデントレポートは 反省文ではありません。「どう思ったか」という情報はいらず、客観的な事実だけを書くようにします。
また、反省文ではないので、必ずしもインシデントを起こした本人が書く必要はありません。そのインシデントそのものや周辺事情に詳しい人が書くべきです。(そのため一番詳しい当事者が書くというケースも多くなります)

インシデントカンファレンスをやってみた

弊社では昨年1月から「ちょっとこれはマズいんじゃないの」ということがあった際にインシデントレポートを作り、インシデントカンファレンスをするようにしています。
例えば「確認不足で本番環境でエラーが出た」「改修リリースで要件の対応漏れがあった」などです。「本番データを誤って削除した」というそれはもうアクシデントなのでは、、というものもあります。
1年半の運用で 37件のインシデントに対してインシデントレポートを作り、20回くらいインシデントカンファレンスをしてきました。インシデントレポートが2件溜まったら1時間くらいかけて2件のカンファレンス(1件30分くらい)をすることにしています。

何かインシデントが発生すると「これはインシデントレポートを作ります」と名乗りをあげてくれることもあれば、誰からともなく「これは作ったほうがいいね」という話になることもあり、誰かがインシデントレポート作成というタスクを持ってくれます。そのインシデントに一番深く携わっていた人であったり、一緒に作業していた人だったりが、他の人からも状況をヒアリングしながらレポートを作ります。
よほどでなければ大至急ではなく業務優先で、場合によっては1〜2週間以上後にインシデントレポートが完成することもあります。(あまり遅くなってしまうと記憶が薄れるので早く記録したほうがよいのですが)

弊社のインシデントレポートは典型的にはこういった項目が埋められています。

  • プロジェクト(どのプロジェクトで発生したか)
  • 事象(何がどうなったか簡潔に)
  • 問題発覚(発生)日時
  • 経緯(時系列で誰が何をしてどうなったか、何が起こったか)
  • 原因(直接原因、間接原因、多少なりと影響したことを列挙)
    • 単に「確認をしなかったから」ではなく「なぜ確認をしなかったか」まで言及する
  • よかった点(トラブルの中でも何かよかったところはあるはず。〇〇があったので復旧が早かった、〇〇はできていたなど)
  • 再発防止策(報告者が思いつくものを議論のたたき台として)

このインシデントレポートを参照しながらインシデントカンファレンスを行います。
なるべくインシデントレポートを書いた人(報告者)以外がレビューして、レビューした人がカンファレンスでの発表者になるようにしています。レビューによって内容がひとりよがりになっていないか、当該業務に詳しくない人にも伝わる内容になっているか(特定のプロジェクトの特定の事象であってもなるべく一般化して他のプロジェクトでも参考になるような書き方になっているか)のチェックができます。
発表後、不明点の質疑応答と再発防止策の議論をしていきます。

質疑応答ではインシデントレポートに書き表しきれていない情報が確認されます。
「その観点のチェックシートはなかったの?」「これまではどうして大丈夫だったの?」など第三者ならではの視点が出てきます。
これが再発防止策のヒントになることも多々あります。

再発防止策の議論は原因を深化させることと密接に関係しています。
「確認をしなかったから」の背景には「確認しづらい構成」などが潜んでいることもあり、確認しやすくするための開発環境の構築やノウハウにまで話が及ぶこともあります。
漏れを防ぐためにチェックシートを作って手間を増やすばかりが再発防止策ではなく、開発者本人しか確認していないのであれば必ずほかの人にも確認してもらって と言ってもらうという対策もあります。

議論の際、弊社では誰も人を責めません。インシデントを共有することの意義や進め方が浸透しているのだなと感じます。
ある意味我々は 人間を信用していない とも言えます。「気をつける」だけでは再発防止策にならないことをみんなわかっていて、仕組みでなんとかしようとします。インシデントを防ぐ仕組みがなかったからこのインシデントは発生したのだ、人間なんかアテにしてはいけない、と考えているわけです。
(とは言えやむをえず人間の感覚(違和感の知覚)に頼っている場合もあります。例えば本番環境と他の環境(開発環境やローカル等)とを区別するためシェルのプロンプトの色を変える、などです)
議論に参加したほうが、ただ聞いているだけより、そのインシデントについて深く考え再発防止策を検討することになるので印象に残ります。なるべく全員が発言するようにファシリテートしますが、最近は皆が当事者意識を持ってくれていて放っておいても全員参加してくれます。
弊社ではインシデントレポートも各種MTGのアジェンダも議事録も Googleドキュメントを共有して全員が同時編集しながら見ているので、一連の議論の議事録もインシデントレポートに書き加えていきます。
こうして最終的に なるべく人に依存しない再発防止策 ができあがります。
再発防止策は必要に応じてインシデントでご迷惑をおかけしたお取引先に共有することもあります。

まとめ

10人前後という人数が、皆で共有して議論するインシデントカンファレンスにちょうどいいのかもしれませんが、
それにしても上手く回っているなとカンファレンスするたびに嬉しくなるので、つい自慢したくて筆をキーボードをとりました。

長くなってしまいました。。
このネタ、いいこと言ってるっぽい雰囲気のスライドを作れそうなので、機会があればどこかの勉強会でお話したいと思います :)

それではみなさまよい在宅ワークを!
(そういえばインシデントカンファレンスももちろんリモートでやってます。Wherebyです)

この記事を書いた人

tama