問題をアクションに変える振り返りのために、大切にしている3つの質問
- どうしたら問題は発生しにくくなるか？
- どうしたら早く収束できるか？
- どうしたら影響を小さくできるか？
問題が発生したとき、私はよく上記3点について考えることで振り返るケースが多いと気づきました。
必要なデータが消えた、システムがダウンした、顧客との打ち合わせに遅刻した、など...
何らかの活動をしていると問題はつきものです。もちろん謝って誠意を見せるのも大切な事ですが、それは何も生産していません。発生した問題は、個人や組織の内包する何らかの弱みを具現化した物であり、成長に活かすためのアクションの宝庫です。反省が済んだら、宝探しに行くぐらいのノリで、振り返って再発防止策を検討し、どんどんノウハウを得て行っていいのではないかと思います。
なおシーンによって「インシデント」「不具合」「事故」など色々な名称で呼ばれると思いますが、以下本稿は一律で「問題」と呼びます。
反省しよう（2秒でいい）
──堀江貴文『多動力』より引用
問題が発生すると、何が悪いのか？
問題によって何が損失するかは、下記の掛け算で計算できます。
問題による損失の期待値 ＝ 発生確率 × 影響範囲 × 収束までの時間
この3つの因数について、最小化する方法を考えると、それが問題の損失を軽減するアクションにつながります。これは、必ずしも3点すべてについて回答を出す必要はありません。すべては掛け算なので、いずれかひとつの因数がゼロまたは限りなく小さい値になれば、他の因数の大小を問わず、損失はとても小さくなります。
なお、たとえば医療事故や旅客機事故のように生命に関わる問題など、ひとつのミスが取り返しのつかない重大な問題を引き起こす場合には、以下本稿の内容は適用できませんのでご了承ください。これは「影響範囲」が正の無限大に発散していて、他の因数をどれだけ小さくしても損失が一切小さくならない、と捉えることができます。
それでは、以下に挙げる3つの問いについて考えて、問題による損失をどうやったら小さくできるか考えましょう。
問1: どうしたら問題は発生しにくくなるか？
問題の発生確率を下げる質問です。これは、問題の原因をしっかり分析することによって、次のアクションを生み出すことができます。問題原因分析の手法は「なぜなぜ分析」「特性要因図」といった有名な物がありますし、そこまで体系だった手法を導入しなくてもちょっと考えれば思いつくケースも多いので、本稿では説明を省きます。
問題に対するよくある対策は「責任者によるダブルチェック」のようなものだと思います。何事も人間がやる以上絶対にミスが起きないという事はありえません。しかしダブルチェック導入によりミスの発生確率を大きく下げることができます。1人の人間がミスする確率が50％のオペレーションならば、ダブルチェックによってミスは25％になります。10％ならば1％にまで減ります。
このようにダブルチェックは簡単で効果的なアクションのひとつですが、決して完璧ではありません。例えば「目視でチェックしていたのを、システムによる自動チェックにする」といった方法で、チェックの抜け漏れやスピード・スケーラビリティが格段に上昇し、同一問題の発生確率が限りなくゼロに近づく場合があります。「チェックが必要なくらい複雑なオペレーションをしている点に問題がある」と考え、その原因を取り除く事も必要です。
実際の例を見てみます。下記のGitLab.comデータベース障害では「`rm`というデータ削除コマンドを、誤ったファイルに実行してしまった」事が直接的原因です。
これもオペレーション内容についてダブルチェックを行っていれば防止できた可能性があるかもしれません。しかし、GitLabのチームではどうしてこのようなミスが発生したかを分析した結果「`rm`コマンドで重要なファイルは削除できないよう、例えば安全な別のコマンドに差し替える(エイリアスを作成する)」といった策が挙げられています。
また、私の解釈ですが、こういった問題を起こす確率の高いヒト、まったく起こさないヒト、というのは、個人差の大きい側面もあると感じています。これはそのヒトの能力の高低と相関があるという話でも無く、先天的な性格でもあれば、生産性の高くアウトプット量の多いヒトや、難易度の高い課題・新しい課題に挑戦するヒトも、問題の発生確率は上昇します。問題を多く出しているヒトは大きく成長しているヒトでもある、という仮説もありえます。その場合、問題発生を抑制する施策が、そのヒトの強みを阻害する可能性もあります。問題発生による損失はよく語られますが、再発防止施策による損失が何かという観点も必要だと思います。
他の対策が可能ならば、この質問について考えるのをやめるのも一つの手です。
問2: どうしたら早く収束できるか？
この点を振り返るには、いつ問題が発生し、いつ検知し、どういう対応によっていつ収束したか、問題の経緯(Timeline)を分析することが必要です。
単に「どうしたら早く収束できるか？」と問いかけるだけだと、「対応するスピードが大切」という結論になってしまうかもしれません。しかし問題の検知から完全解決までにかかる時間は縮められない場合も結構あります。例えば寝坊した場合、タクシーを使って現地へ行く、以上に早く目的地に着く方法を考える事は難しいです。また不必要に急いだ結果、事故をして怪我をしたりしてしまうかもしれません。他の例で言うと、システムがダウンしてしまった場合ならば、システム再起動に結構な時間がかかるかもしれませんが、その時間を短縮するというのは困難を極めると思います。
そういう時もこの質問は、分析された問題の経緯に沿って「どうしたら問題の検知を早められるか？」のように深掘りする質問に変えると、別の答えが見つかることがあります。寝坊の例だったら、寝ている本人は寝坊を検知できないので、他のメンバーから電話をかけるといった感じでしょう。システムのダウンに気付かなかったのであれば監視の仕組みを導入するべきです。
また、チームの機能不全やコミュニケーションパスの過度な複雑化、心理的安全性の低下による報告の遅延などにより、普段だったらすぐに収束できるような問題に時間がかかってしまうケースも考えられます。そうなるとアクションとしては、十分な休息を取るとか、組織構造を改善するといった、かなり違った視点の施策が出てくると思います。
何に時間がかかっているか、どこならば縮められそうかを正しく見極めると、色々なアクションを見出して大きく成長できる可能性があると思います。
問3: どうしたら影響を小さくできるか？
この質問に対しては、問題による影響範囲を振り返る必要があります。影響というのは必ずしも直接金銭でいくらとか測れるものではないかもしれません。例えばデータ消失問題が発生したとき、「失ったデータを復元できるかどうか？」が、問題発生後に取り返しがつくかどうかに関わります。もちろん取り返しがつかない問題というのは影響が大きいと言えますし、逆に何らかの方法で後から取り返せる問題ならば、その影響はぐっと小さくなります。
もっと異なった事例を見てみます。Amazon.comでは、サーバ障害発生時に犬の画像が表示される事が話題になりました。これはWebサービスがダウンした時に顧客満足度の低下を少しでも食い止める、という意味では、省工数で汎用性の高い施策と言えると思います。
一方、同じAmazonでもECではなくクラウド事業のAmazon Web Servicesでは、ストレージサービス「Amazon S3」の障害発生時、サービスステータスを示すダッシュボードにも「Amazon S3」を使っていました。そのため障害中、顧客が障害ステータスも確認できないという問題が発生。影響範囲を広げてしまいました。障害発生時に必要とされるサービスやプロダクトには、対象となる障害点とは独立したシステムにして影響範囲を狭めておくことが求められます。
次のアクションを決める
問題の振り返りとして「どうしたら問題は発生しなくなるか？」という問いだけを投げかけているケースは多いと思います。決して悪いことではありませんが、それだけだと「ダブルチェックではなくトリプルチェックにする」「プロダクトリリースの回数を減らす」といった生産性を犠牲にする施策が、十分に代案検討されないまま挙がってしまったり、もっとひどい例だと「気をつける」「意識する」「ケジメをつけて見せしめにする」といった何の資産にもならない結論が出てしまう事もあるかもしれません。
ですが本稿で挙げた3点の質問を使うと、少なくともどれか1つの問いに対しては次につながるような効果的なアクションを生み出せる回答が出てくるときが多いと感じています。
また、問題を振り返った時に損失期待値が十分に低かった場合──その問題の発生確率が低く、影響範囲が小さく、収束までの時間が短かった場合──これは、その問題を発生させた個人または組織が、日頃から問題に対する振り返りやアクションをきちんと行ってきた結果が現れている可能性があります。ハインリッヒの法則とは異なる意見ですが...ひとつの軽微な問題の発現には、無数の問題が未然に阻止されている、と考える事も可能ではないかと思います。「今回の問題は、対応チームの網羅的な検証と迅速な報告により、損失を最小限に抑える事ができました。ありがとうございます」のように、問題への対策の試みを十分に賞賛・評価することも、問題を振り返る文化を形成する上で大切だと思います。
この記事が気に入ったらサポートをしてみませんか？