KAKEHASHI Tech Blog

カケハシのEngineer Teamによるブログです。

インシデントふりかえりの6つのポイントとふりかえりガイド

開発プロセス

インシデントのふりかえりをしたくても、そもそもやり方がわからない、ネットの記事が乱立していて適切かどうかわからない方は多いでしょう。このガイドでは、効果的なインシデントふりかえりにあたり、6つのポイントを記述しています。

ふりかえり6つのポイント

  • ふりかえり後に学びが増えている
  • 得られた知見を共有できている
  • ふりかえり後に仕組みが改善できている
  • 全体像が可視化できている
  • 良い問いが立てられている
  • レポートがストーリーとなっている

ふりかえり後に学びが増えている

以下のようなことがインシデントが発生して初めて分かることもあるでしょう。

  • サービスの動作
  • 影響範囲
  • 顧客の行動
  • 関係者が重視していることがら
  • 利用する道具やプロセス

インシデント対応中にわかったことをまとめたり、ふりかえりに必要な事実やエビデンス、データを調べながら学びましょう。最近の安全性工学の観点では、学習それ自体が重視されています

特に、一人ひとりが思い描くシステムの動作(メンタルモデル)と実際の動作との隔たりによって、コミュニケーションギャップや(全て終わった後に初めてわかる)判断の失敗が生まれます。この差分を継続的に埋める努力が必要です。

我々が普段扱うような複雑なシステム(complex system)では、考慮事項の組み合わせが膨大なうえ、環境が刻一刻と変化していきます。 あらゆるインシデントパターンや条件を想定し、全て準備しておくことは現実的ではありません。 だからこそ事象のあとの学びが重要になります。

得られた知見を共有できている

ふりかえりの結果得た知見を眠らせるのはもったいないですよね。組織全体でレポートを共有し、知見を広めましょう。組織の学習する文化を強化することもできます。インシデントで測定すべき真のKPIはこの部分が活発かどうかです。

ふりかえり後に仕組みが改善できている

何もしなければ似たようなインシデントで似たような影響が出てしまいます。インシデント対応中の高いプレッシャーで動悸が激しくなり、息が止まり、胃が痛くなる。こんな経験はもう一度したくないですよね。同じ轍を踏まないようフォローアップのアクションをまとめ、仕組みを改善していきましょう。

ここでの仕組みとは、対象システムだけを指すのではなく、オペレーションから教育、組織的課題まで幅広く指します。むしろ、良いふりかえりには幅広さが求められます。幅広さについては何度か触れます。

＊アクションアイテムを生み出すヒントは別稿にて記載します。

全体像が可視化できている

現物があると話し合いや理解がスムーズになります。

文字通り図を書いてください。それ自体が成果物となり役に立ちますし、現物があると話し合いがスムーズになります。(バウンダリーオブジェクト)

VSM(バリューストリームマッピング) は手軽なのでおすすめです。図を書かない取り組みは失敗が約束されるでしょう。

良い問いが立てられている

疑問に思うことから学びが始まります。よくある質問形式である「なぜ」はいくつかに分解することができます。

例

  • 目的(What purpose)
    • その目的は？
  • メカニズム(How)
    • どのように動いていたのか？
    • そのメカニズムは？
    • その作用機序は？
  • 背景、経緯
    • 経緯は？
    • どのように形成されたのか

＊分解について気になる方はティンバーゲンの4つのなぜを参照

WhatやHowを駆使して適切な問を立てましょう。イメージとしては、深堀りというより幅広い視点で分析すること。

レポートがストーリーとなっている

学びを活用する上ではまず人を惹きつけ、目を通してもらう必要があります。レポートを読んでもらわなければ効果は0です。無味乾燥な文章ではなく、構成を練り、強い印象を与えられるようにしましょう

ふりかえりのやり方: 情報を収集する

例えば、情報を探すには以下のような場所にあたりましょう。

  • 利用したドキュメント
  • Slackなどのチャットツール
  • 一次対応後の関係者全員へのアンケート

インシデント情報を収集しやすい仕組みになっているでしょうか？何事も準備が8割です。

ふりかえりのやり方: 事実を明らかにする

事実なくして考察はできません。

以下のようなことを明らかにしましょう

  • インシデント時のタイムライン
  • 明らかになったシステム内のフロー
  • (実際に行っている)業務フロー マニュアルには書いてない作業があるかもしれません
  • 利用したツールやドキュメント

驚いたところに焦点を絞る

前述したとおり、思い込みと実際の動きに隔たりがある部分が失敗のもととなります。 見つける方法は単純です。驚いた部分に集中すればOK。ギャップがあると人間は驚き、つまり感情が動きます。

VSM(バリューストリームマッピング) は手軽なのでおすすめ

あまり覚えることがなく、枠と線だけ書けば全体像が見えてくるのでおすすめです。 日本CTO協会が提供しているDX CriteriaでもVSMが一つの項目となっています。

工程ベースで分析してみよう

全体像を掴めと言われても、慣れていない人には難しいでしょう。まずは、自工程、次に自工程の前工程と後工程、そしてその前後の工程....と伸ばしていくと調査しやすいです。ひとまず仕事を依頼してくる人と、自分が依頼する人に対して、話を聞きに行きましょう。

調査官を設置するのもOK

調査官を設置する方法もあります。より情報を引き出すために1on1インタビューをする方式です。運輸系の業界の方式に近く、こちらのほうが話しやすいという声もあります。 GitHub社の事例

5 Whys(なぜなぜ分析)は効果が薄い

いわゆるなぜなぜ分析は単純なものには効果的ですが、

など複雑な事象には効果が限定的です。実例として、5 Whysのサンプルを書籍やネットでいくつか探してみましょう。あまり役に立たないと実感できるはずです。

良い問立ての例

Debriefing Facilitation Prompts https://www.kitchensoap.com/2014/11/14/the-infinite-hows-or-the-dangers-of-the-five-whys/

他の方法もある

古典的ですが、SHELLモデルにて関連する要素ごとに分解するのも定番です。

  • S Software(ソフトウェア) 手順書やマニュアル、規則など。直接操作やモニタリングするわけではないもの
  • H Hardware(ハードウェア) 機器や機材、設備、施設の構造など 。実際に操作やモニタリングするもの
  • E Environment(環境) 温度や湿度、照度など 自宅状況なども
  • L Liveware(人間) 本人や関係者すべて

Lを中心として、L-S / L-H / L-E / L-Lの4種類の関連性について検討します。

ふりかえりのやり方: まとめる

まとめは2パターンあります。1つ目は調査事項を詳細にまとめたもの。2つ目は、読んでもらうことに特化したストーリーです。

ストーリーの書き方:人を中心にする

システムではなく人、人、人です。感情の動き、人間関係、欲求。人は人に興味があるということ。また、システムの詳細はチームや時代ごとにほぼ違うため他者にとって参考にならないこともありえますが、組織系の課題は共通しています。

ストーリーの書き方:3幕構成

  1. 状況設定
  2. 葛藤
    • 葛藤がなかったらおそらくその障害は発生することはないでしょう
    • トレードオフ、悩み...
    • 葛藤に時間がかかっていたり、誤った選択をすれば、障害が拡大するわけです
      • ふりかえりの視点でも重要
  3. 解決

詳細は書籍やwikipediaを参照

情報を削ぎ落とす

ついついなんでも詳細に書きたくなりますが、無関係な内容は邪魔になるだけです。どんどん捨てましょう。

ふりかえりのやり方: 公開する

再発防止策とは別に公開しましょう。

読み返されないレポートは無意味であり、購読状況が最重要KPIです。ストーリーが必須としたのは、読み応えのあるレポートを記載するためです。

全体会議相当の場所で発表しましょう。なお、ドキュメントシステムによっては読まれた量が測定できます。できるだけ測定しましょう。

良い分析のためにさらに知っておくべきこと

与えられた制約下では、みな常にベストを尽くしている

後から見たら誤った決定や行動でも、悪意を持っていたわけではなく、その当時はそれがベストでした。

当時の制約を明らかにし、環境を最適化していきましょう。

個人の責任に帰結させない

ある問題のある個人を取り除けば改善するというモデルです。さすがに今の時代にこういう分析をする人は減りましたね。

さらに最悪なのは心に帰結させることです。コントロール可否の問題もありますが、それ以前に無意味です。

「指示に従わないのは、やる気がないから」という説明について、ちょっと考えてみましょう。 「何故やる気がないと思ったのか？」と考えた時、「指示に従っていないから」という答えが出てくると思います。 つまり、「やる気がない」という言葉は、「指示に従っていない様子」を見て、出てくる言葉になります。 　　指示に従わない犬　→　この犬はやる気がない ぱっと見、納得出来る感じがします。 しかし、これで納得してはいけないんですね。 ↑にも書いたように、この説明は何も説明していません。 この場合、「指示に従っていない様子を見て、やる気がないと判断する」わけですから、言ってみれば「指示に従っていない様子」を「やる気がない」という別の言葉で表現しているに過ぎません。 https://ameblo.jp/dogluck-1678/entry-10361917313.html

行動分析学から見るとトートロジーであり、言語ラベルを貼っているだけで何の分析にもなっていません。

ヒューマンエラーという単語も同様です。眺めてヒューマンエラーという単語を割り振るだけでは分析ではありません。

ハイプレッシャー下において人は正常ではなくなる

文字通りの意味で災害と同じであり、同様の傾向を示します。

  • fight or flight反応。HRTがなくなったり動きが遅くなったり
  • 慣れ親しんだものを使う
    • 逆に言うと、ここで使った道具は、ある人が慣れ親しんでいるものである
    • 道具だけではなく、コミュニケーションする人や方法も

image 心理的応急処置 （サイコロジカル・ファーストエイド：PFA）フィールド・ガイド 日本語版

深呼吸をする、休息を取る、食事をするといったことを大切にしましょう

根本原因は存在しない

インシデントにはなにか一つの根本原因があると信じている人を時折見かけます。 では、例えばAppleが成功した一つの根本原因を挙げることはできるでしょうか？

複雑なシステムでは多数の要因(contribution factor)が絡まり合って障害が発生します。

ほかには、そもそも原因を求めることを避けるという立場もあります。解決志向アプローチなら、望ましい未来に焦点を当てるでしょう。家族療法なら、直接の原因がわからなくても悪循環を修正できれば解決できるという考えになるでしょう。

関係者全員が要因になりえる

自分ではない誰かが起因の障害でも、暗黙のプレッシャーやコミュニケーションミス/不足が遠因となっていることはよくあります。

ここでの関係者とは全部門を含みます。組織要因と見てもよいですが、組織という物理的には存在しないものよりは一人ひとりバイネームで考えたほうが具体的になります。

エンジニアリングのような、意思決定チェーンの後方、事象発生に近い部分に注目されがちですが、より深く広く考えるなら、前方について同程度の労力をかけて見てみましょう。

完璧な仕組みになればなるほど、被害が大きくなる

完璧になればなるほど、信頼を深め依存するようになり、中身を理解しなくなり、結果としてなにか起きたときは大惨事になります。より認識を深めたい方はIronies of Automationを参照

インシデントは連続で発生しても不思議ではない

ポアソン過程を用いて計算してみましょう。インシデント発生が指数分布(exponential distribution)に従い、年間4回発生すると仮定します。

ある日障害が発生し...また

  • 1ヶ月後に起きる確率 -> 28.3%
  • 2週間後に起きる確率 -> 14.3%
  • 1週間後に起きる確率 -> 7.4%
  • 次の日に起きる確率 -> 1%

結構発生しますね...

＊端数と日付処理は雑

被害結果と要因を分離する

薬の取り違えを考えてみましょう。実は誰も飲んでいなければ被害はなく、弱めの薬で被害がほとんどないこともあれば、死亡事故になることもあります。

同じできごとでも結果は偶然に左右されます。大規模インシデントになってから慌てるのではなく、一歩手前なものにも目を向ける習慣があるとよいでしょう。

ICSを学ぶと対応がスムーズに

広域災害から企業危機やIT障害まで、インシデント対応の世界標準はインシデントコマンドシステム(ICS)です。権限の移譲、コミュニケーションパスのコントロール、インシデントコマンダー(IC)への判断権限集中が特徴です。日本語でも最近文献や情報が増えてきたようです。

一方でICSの限界も議題に上がります。

Q&A

ポストモーテムと聞いたのですか

意図的に使っていません。ポストモーテム(postmortem) は文字通り「死後」であり検死を指します。IT業界は未成熟だったこともあり、過去の経緯から適切ではない用語選択をよく見かけます。インシデントプロセスは社会的、組織的要素を含み(Sociotechnical)、用語への敏感さも成熟度の物差しです。

文責：高木