この記事はNTTコムウェア Advent Calendar 2024の18日目の記事です。
はじめに
こんにちは、NTTコムウェアの高木と申します。
普段は社内向けにゼロトラストな環境を提供する為の、ネットワーク周りの業務に従事しています。最近は業務に没頭していてアウトプットができていなかったので、Advent Calendarで何か記事を投稿しようとした次第です。
何を書こうか考えていたところ、担当内で過去の作業ミスを事例にどうすれば作業品質があがるかディスカッションする場が設けられました。その中で再発防止策を考えることになりました。しかしながら、作業担当者自身が「確認を徹底する」「報連相を徹底する」「手順書にないコマンドを実行しない」といった、大事な心掛けではあるものの、作業担当者が頑張るだけの精神論・根性論のような対策が多くあげられました。精神論・根性論では、しばらくすると意識が薄れたり人の異動でリセットされ、ミスが再発してしまうので、再発防止策としては不適切です。
何故再発してしまうようなものを再発防止策として考えてしまうのでしょうか。どのようにすれば適切な再発防止策をたてられるのでしょうか。
本記事では、私が普段実践している、適切な再発防止策をたてるために根本原因を分析する手法（考え方）について紹介していきたいと思います。
なぜなぜ分析
誤った再発防止策になってしまうのは、直接的に問題を引き起こした個所のみに着目し、根本原因まで至らない対策になってしまうからです。
「間違ったコマンドを実行して、データが消えた」という事象が発生したとしましょう。直接的に問題を引き起こした「間違ったコマンドを実行した」ことを原因とし、その対策として「間違えないように確認を徹底する」としてしまうと、人の頑張りに期待するだけの精神論・根性論になってしまいます。そもそも間違えなければ問題は発生しないので、間違えた根本原因を見つけ出し、そこに対して再発防止策を考えるのが正解です。
この根本原因を見つけ出す為の分析手法として、なぜなぜ分析というものがあります。考え方としては難しくなく、何故そうなったかを繰り返すことで、問題が再発しなくなる根本原因まで遡るというものです。「間違ったコマンドを実行して、データが消えてた」を例に、なぜなぜ分析をおこなうと以下のようになります。
- データが消えた
↓ Q1：なぜ消えたのか - コマンドを間違えたから
↓ Q2：何故間違えたのか - パラメーターシートの違うところをみていたから
↓ Q3：何故手順書でなくパラメーターシートをみるのか - コマンドオプションはパラメーターシートの値を参照・入力するようになっていたから
↓ Q4：何故手順書にオプション含めてコマンドをすべて書かないのか - 同じコマンドをオプションを変えながら実行するが、同じようなものを何度も書くのが面倒だったから
なぜなぜ分析の結果、根本原因は面倒でコマンドをパラメータ含めて書かなかったことで、取り違いやすい状態であることがわかりました。あとは、この根本原因に対して対策を練っていけばよいので、「面倒でも手順書にコマンドを全部書く」「Excelの機能でコマンドを自動生成してすべてのコマンドを手順書に書く」といった対策になります。
なお、対策は複数考えられたり、何故を繰り返す際に分岐が発生して複数の原因・対策が導き出されることもあるので、何を対策とするかは実現性（費用・難易度・期間等）や効果を踏まえて取捨選択していくことになります。
上の例でもQ3の所で「何故違うところを見たのか」という問いで分岐が発生し、わかりにくいパラメーターシートが原因となるかもしれません。そうすると、パラメーターシートをわかりやすくするのと、手順書にコマンドを全部書くのと、どちらがより良いのか判断して選択することになります。
なぜなぜ分析の考えは難しくないですが、実際にやってみると原因の深掘りができないことがあります。いくつかコツがありますので、こちらを参考に実践してみてください。
- 一般的に何故を５回繰り返すと言われていますが、あくまで目安であって必ずしも５回でなくて良いです。ただし、根本原因に至るまでは何故を繰り返しましょう。
- 根本原因まで至るために、頭を柔らかくして当たり前のことも何故と問いましょう。
- 安易に人のせいにせず、仕組みや組織に問題がないか問い続けましょう。
- 行った／考えたことは正確に書きましょう。行った／考えたことは事実として受け止め、そのことで人を責めるのはやめましょう。
RCA（Root Cause Analysis：根本原因の分析）
なぜなぜ分析は優秀ではあるのですが、発生した問題からすぐに分析が始まるので、狭い範囲までしか分析が進まないことがあります。範囲を広げて、よりシステムやプロセスに焦点があたる分析手法として、RCAというものがあります。RCAでは最初に問題発生より前に行っていたことも時系列で並べた出来事流れ図を作成します。出来事流れ図に記載した前のこともなぜなぜ分析を行い、最後に事象や問題の因果関係を考え根本原因を確定することで、システムやプロセスを起因とする根本原因まで見つけ出すものになります。
なぜなぜ分析でおこなった、「間違ったコマンドを実行して、データが消えてしまった」をRCAで分析してみましょう。最初に出来事流れ図をつくり、それぞれの事象でなぜなぜ分析を行います。
- 作業者が間違ったコマンドを実行
⇒何故実行したのか⇒確認者もOKとしたから問題ないと考えたから⇒・・・ - 確認者が入力されたコマンドが正しいか確認
⇒何故誤りを見つけられなかったのか⇒見落としていたから⇒何故見落としたのか⇒手順書の理解が不十分 - 作業者が手順書とパラメータシートを見て、コマンド入力
⇒何故誤った値を見ていることに気付かなかったのか・・・ - 作業者が手順書とパラメーターシートを開く
⇒何故確認者は開かないのか⇒同じ画面を見ながら作業しているから⇒・・・
・・・ - 作業者、有識者で手順書のレビューを実施
⇒何故確認者がいないのか⇒スケジュールが合わなかった⇒・・・⇒確認者の手順書への理解が不十分
・・・
これを見てどう思いましたか。なぜなぜ分析にくらべ、格段に分析するところが増え、複雑になったと感じるでしょう。その通りだと思います。上の例ではかなり省略していますが、事象や何故は更に分岐して、考えられる原因が様々な観点であげられ、複数の事象の原因が同じだったり、関係性があったり、何故を繰り返したが問題がなかったりと、かなり複雑になっていきます。複雑すぎると分析がいつまでも終わらないので、出来事流れ図で何処まで過去にさかのぼるか、どの程度の粒度で書くかの匙加減がポイントになります。問題発生の直前は細かく、ある程度過去はポイントとなるところにするのが良いかと思いますが、この辺の匙加減が難しいところです。
なぜなぜ分析の次は、因果関係を考え、根本原因の確定に移ります。因果関係を考えると、確認者が誤りを見つけられなかったのは手順書の理解不足であり、手順書へのレビューに確認者が参加していないことで手順書への理解が不十分になっていたことがわかります。よって、手順書レビューに必ず確認者が参加することを作業する為の条件とするプロセスを追加することで、作業品質が向上し再発防止策へとつながることになります。
RCAではこのような流れで根本原因を確定し、再発防止策を立てていきますが、様々な事象・観点から原因・対策を導き出すことになるので、どの対策から始めるかは実現性（費用・難易度・期間等）や効果を踏まえて取捨選択していくことになります。
最後に
なぜなぜ分析やRCAを行う上での考え方は難しくないので、まずはやってみるのが良いかと思います。
図を書くのが面倒かもしれませんが、頭の中で考えるだけでなく、図示することで頭の整理ができたり、別の観点での気付きがうまれてくることがあるので、見た目にこだわらず、多少は手抜きでも良いので、図を書いてみてください。
本記事が皆様の安定したシステム運用につながる一助となれば幸いです。
記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。
参考文献
IPA 重要インフラ分野のシステム障害への対策
https://www.ipa.go.jp/archive/digital/iot-en-ci/system/system.html .
IPA 情報処理システム高信頼化教訓集（ITサービス編） 別冊2：障害分析手法
https://www.ipa.go.jp/archive/files/000071988.pdf