なぜITインシデントが減らないのか?
掲載:2024年10月16日
執筆者:取締役副社長 兼 プリンシパルコンサルタント 勝俣 良介
コラム
「データベースを更新したが、反映させるべき元データがそもそも古く、間違った価格・情報を顧客に提示してしまった」「二重化どころか三重化してあるためハードディスク障害は決して起きないと思っていたが、ソフトのライセンス期限切れでまさかのシステム障害が発生してしまった」「ちょっとくらい手順を飛ばしてもこれくらいなら大丈夫だろうと思って設定を変更したら、誤ってユーザのデータを消してしまった」等々、直面するITインシデント件数がなかなか減らず、日々の業務で頭を悩ませていませんか?
こうしたITインシデントが一度発生すると、企業はその原因を特定し、対策を打って再発防止策を講じます。これがうまく回れば、ITインシデントは徐々にでも減っていくはずです。しかし、実態としては、「どうも減っている気がしない。いやそれどころか最近、増えてきている気さえする」。そんな声が聞こえてきます。
本コラムはこうした関係者の悩みや声に光を当てます。本稿をお読みいただくことで、以下のようなことを明らかにすることができます。
- なぜ、再発防止がそんなに重要なのか?
- なぜ、再発防止が機能しなくなるのか?
- どうしたらそうした状況を改善することができるのか?
なぜ、再発防止が重要なのか?
どうやったってインシデントをゼロにするなんて不可能。一定程度発生するのは仕方がないのに何をそんなに目くじらを立てて、再発防止を問題視するんだ? そんな声も聞こえてきそうです。
「インシデントが減っている気がしない」。この状態を放置しておくと本当にまずいのでしょうか。
では放置しておくと何が起こりうるのか? 1つには機会損失につながります。ちょっとした事前のコミュニケーションで防げたはずのインシデントであったならば、それを発生させてしまうのは残念なタイムロスです。それが軽微ではなく重大インシデントならなおさらです。例えば、システム障害が顧客向けのシステムで発生したならば、顧客の担当営業は状況把握や説明、謝罪に追われます。システム担当者は復旧のために夜中でも駆けずり回ります。上司も事態の把握や経営への説明、他の顧客で似たようなことが起こらないかの確認・検討など、てんやわんやです。こうしたタイムロスは本業のための時間を奪い、組織の競争力を徐々に削いでいきます。
2つにはレピュテーションへの影響です。人間はどうしても目の前で起きたインシデント1件で影響を評価しがちです。しかし、たとえ1つ1つのインシデントが許容できるレベルのものであったとしても、積み重なれば顧客から信用を徐々に失っていくことになります。企業はむしろ顧客の信用を積み上げていくべきなのに、そうしたつまらないインシデントの頻発で、顧客から信用を失っていくことは大きな損失です。
そして、徐々に顧客の信用を失っていくだけでなく、この状態の放置は将来の大事故を誘引する火種になります。皆さんはハインリッヒの法則をご存知ですか。1件の重大インシデントの裏には、29件の軽微なインシデントがあり、その裏には300件のヒヤリハットがあるという法則です。起きたインシデントがたとえヒヤリハットであっても、軽微なものであったとしても、それが積み重なればやがては重大事故につながるということです。言ってみれば、現状放置は重大事故発生の予兆を黙認しておくことに他なりません。
なぜ再発防止プロセスが機能しないのか?
再発防止プロセスが重要だというのはわかったし、だからこそ再発防止プロセスを導入しているわけなのに、どうしてインシデントが減らないのか。ここが大きな論点です。
本稿では3つの代表的要因をご紹介します。その3つとは「形式的な振り返り」「ガバナンス不全」「動機の弱さ」です。
「形式的な振り返り」とは、言うなれば「やっつけの振り返り」です。やっつけの振り返りは、原因の掘り下げをやっつけ仕事のように行った結果です。具体的には例えば「うっかりPCを電車に置き忘れて紛失したので、次回からは忘れないように気をつける」みたいなあまり意味のない振り返りをすることを言います。本来振り返りは「なぜ」という問いを5回またはそれに近い回数を繰り返して深く掘り下げることに意味があります。しかし、面倒くさがって2回程度で済ませてしまったり、偏った原因にばかり意識が向いてしまっていたりすると、その振り返りは学びにはつながりません。例えば、振り返り者本人が技術志向の強い人間だと、技術的な原因特定にばかり目が向きがちになりやすいです。例えばある企業でシステム障害が発生し、業務が停止したとします。技術者視点では「サーバーのメモリ不足」や「ネットワークのパケットロス」など、ハードウェアやソフトウェアの問題を最初に疑うことが多いです。実際には「過剰なシステムの改修スケジュール」が影響していたり、「運用チームの対応手順が標準化されていなかった」といった、運用プロセスや組織的な問題が本質的な原因となっている場合もあるのですが、そちらに目が向きにくいのです。
また、ヒューマンエラーの特性を理解しない掘り下げも「やっつけの振り返り」につながる原因です。そもそもヒューマンエラーは、「なぜ」を5回繰り返したところでその本質までたどり着くことが難しいものです。「なぜ、PCを置き忘れたのかといえば、電車の網棚にバッグを乗せたことを失念したから」「なぜ失念したかといえば他のことを考えていたから」「なぜ他のことを考えていたのかといえば顧客からの相談メールを読んでいてそちらに気を取られてしまったから」「なぜ気を取られてしまったのかといえば、顧客が急いでいるようだったから」となり、再発防止策は「電車移動中には他のことを考えないだな? ん? それでいいのか?」となります。ヒューマンエラーは表面的には「人的なミス」や「注意不足」といった個人の行動に起因するように見えますが、その根本原因は多岐に渡ります。環境要因や心理的要因、認知的要因など複雑に絡み合っている場合が多く、一方向の「なぜ」で突き止められる問題ではないことが一般的です。「電車移動中に他のことを考えない」の例えは極端だとしても組織はこうした落とし穴に陥りがちです。
「ガバナンス不全」とは「やっつけの振り返り」を当事者以外の人・組織が検知し是正するメスが入りづらいことを意味します。一般的には、再発防止策を検討するのはインシデントを起こした当事者や周囲の関係者です。その当事者による根本原因の掘り下げや再発防止策が妥当であるかどうかをレビューするのは上長であったり、3ラインモデルの二線である品質保証部だったりします。しかし、実態はといえば、二線も、スキル不足や意識不足、時間不足などから、形式的なチェックにとどまり、振り返りが妥当かどうかなどを見きれていないことが少なくありません。かくしてやっつけの振り返りはやっつけの掘り下げのまま片付けられてしまっているのです。
これらをも凌駕する代表的要因が「動機の弱さ」です。これはインシデント管理に関わる関係者が「重大なものの再発防止を考えるのはまだしも、なぜ軽微なものまで掬い上げて再発防止を考えるのか」という腹落ちしてない状態です。現場は「本業で忙しいのに、なぜちょっとしたインシデントまでもわざわざ原因を掘り下げていちいち記録を残すのか?」と感じています。マネジメントからすれば「そういうところをだらしなくするとやがて大きなインシデントにつながるのだから、やるのは当たり前だろ。言わなくてもわかるだろう?」という思いがあるでしょう。しかし、現場からすると「重大なインシデントが起きた時こそ、怒り心頭なマネジメントも、普段の軽微な再発防止プロセスの運用には評価どころか関心も示さない。こちらも人不足でそんな余裕ないのに、それでもやれってなんなの?」と思ってしまう。一生懸命、再発防止・未然防止活動をやっても褒められないけど、大きな事故が起きた時だけ怒られる。現場では不満が高まっています。
再発防止プロセス改善は、どうやればいいのか?
もし、皆さんの組織で起きているITインシデントが減らない原因が先に挙げた例のせいであるのなら、以下のポイントについて総点検をしてみるべきです。
- 「なぜを5回繰り返す」の実践方法やよくある落とし穴を回避する方法に関する研修や仕組みづくりができているか
- ヒューマンエラーの特性を踏まえた再発防止策検討プロセスの確立や研修実施ができているか
- 再発防止策の二線や上長による妥当性評価が十分に機能しているか
- インシデントの再発防止の取り組みに対して、強い動機づけができているか。経営の本気度は当事者にどこまで伝わっているのか
ただ前段であげた原因はあくまでも一部であり、考えうる要因は他にもたくさんあります。小手先のテクニックで改善できるのであれば、すでに解決できているはずです。それが解決されずに残っているということは、それなりの理由があるということです。インシデントが高止まりする状況の改善を図るための理想的なアプローチは、可能であれば次に示すステップを踏むことです。これらステップを経て、真因特定や改善策の検討、その実施に繋げていく必要があります。
- 1. 予備調査
- a. ステークホルダーヒアリング
- b. インシデント発生再発状況の確認
- c. 調査に基づく課題の仮説立て
- 2. 仮説立証のための本格的調査実施
- a. 関係者へのヒアリング
- b. データの収集・分析
- c. 仮説の修正及び追加調査
- 3. 課題及び解決策の選択肢の検討
- 4. マネジメントへの報告
- a. 中間報告の実施
- b. 最終報告の実施
上記はごく一般的なステップに見えるでしょうが、このステップを進めるにあたって最も大切なことは「課題の仮説立て」です。なぜなら、特に組織が大きくなってくると、再発防止プロセスは単一ではなく複数、しかも異なる形で存在することもあり、当たりをつけた調査をしないと、リソースがいくらあっても足りなくなるからです。調査対象として、これまでに起きたインシデントを記録している台帳を確認することがよくあります。しかし、その記録の信憑性については、疑ってかかる必要があります。ITインシデント一覧はしっかり記録されているように見えて、実態は記録に抜け漏れがあったり、書いてある内容が不正確であったり、そこで特定されている根本原因や再発防止策が適切でなかったりする場合もあるからです。もっと言えば、内容が不正確なのか適切なのかどうかを判断するに足る情報が記載されていない可能性もあります。そのような場合、そうしたデータを一生懸命分析・評価したところで本質的な課題に辿り着けない可能性があります。だからこそ「おそらくこういう課題があるだろう」と最初に当たりをつけることがとても重要なのです。
再発防止プロセスを改善するにあたってもう1つ、重要なポイントがあります。それは、再発防止プロセスに関わる課題解決策だけでなく、どうやってそれら課題解決策の導入効果を測るのかをあらかじめ考えておくことです。課題を解決するために、ついつい色々な施策を試してみたくなるのが人間の性です。「インシデント管理フォーマットの記載内容をもっと増やそう」「再発防止策のレビューをする二線向けのダブルチェックシートを用意しよう」「さらに追加でレビューの目が入るようにしよう」「研修を増やそう」等々、対策をどんどん増やしていきがちです。結果、管理のための管理が増えるだけになり、本業のための時間が奪われてはそれこそ本末転倒です。そうならないようにするためにも、やはり「やって意味があった」ということを目に見える形で示す必要があり、効果測定の仕組みも検討しましょう。そうでなければ、再発防止プロセスの運用に携わる関係者のモチベーション低下につながりますし、実際は役に立っていないのに新しいルールだけ追加されたなんてことになりかねません。
終わりに
私自身、様々な再発防止プロセス改善プロジェクトに携わってきましたが、いつも驚くのは、再発防止プロセスが機能しない「原因」が張る根の深さです。問題を掘り下げていくと、一見、当事者の力量に問題があるように見えて、実は組織間の信頼関係に問題があるなんてこともよくありました。ことITシステムが関わる世界では、組織体制が複雑になりがちで、委託や再委託は日常茶飯事です。そういう環境下では、コミュニケーションミスも起きやすく信頼関係の構築も難しくなりがちです。お互いのお互いに対する期待値や果たすべき責任のずれが出ることもままあります。
その意味では、前段でお伝えした「課題の仮説立て」は、一定の力量が求められます。それは単に論理的思考力があればできるというものではありませんし、努力さえすれば実現できるというものでもありません。再発防止プロセスが機能不全に陥る事例をどれだけ知っているか、その経験値が必要不可欠な要素になります。また、もし組織間の信頼関係に話が及ぶとしたら、利害を持つ人間がその部分の調査をしても本音が見えてこない場合もあります。
ゆえに、もし再発防止プロセスの改善プロジェクトを推進する場合は、どういうメンバー構成でプロジェクト体制を作るかも極めて重要なポイントになります。覚えておいてください。望ましい体制を作れない場合には、コンサルを活用するのも手です。
いずれにしても、慎重な取り組みが必要です。ぜひ本稿を参考に自組織の再発防止プロセスの改善をご検討くださいませ。