続：ソフトウェア開発で「なぜなぜ分析」はアンチパターン

筆者は「なぜなぜ分析」を理解していない／誤解しているのではないか？

なぜなぜ分析にはメリットもあるが、筆者の理解、使い方の誤りがあるのではないかというようなご意見をいくつかいただいた。確かに、手法の確認が不十分だったかもしれない。

ただ一方で、指摘された「ただしい使い方」がどこまで共有されているのかについては疑問も感じている。今回の記事執筆にあたっては（この種の手法の辞書としてよく使っている）「アイデア大全*1」を確認しているが、基本的には『１つの出来事・現象について「それはなぜか？」と自問自答することを５回繰り返す』という手法しか紹介されていない。

他にはアクセスしやすい信頼できる情報源としてIPAの「情報処理システム高信頼化教訓集 ITサービス編 別冊Ⅱ：障害分析手法」というものもある。ただここでも手法の説明は大きく変わりはなく、これを理解してよい分析ができるのかという点には疑問が残る。

なぜなぜ分析は、発生した事象（問題：対策を必要とする事実）を起点として、その事象が発生した根本原因（それに対策すれば問題が再発しなくなる原因）に至るまで、「なぜ（それが発生したのか）」と問いながら原因を遡っていく分析手法である。
分析を実施するにあたってのポイントは以下の 2 点である。
① 問題事象を発生させた直接の原因（直接原因）を見つけ、さらに直接原因を引き起こした原因を見つけるという手順をくり返し、本質的な原因（根本原因）を見つけ出す。
② 分析は事実をもとに実施する。そのため、実施の際には、可能な限り障害事象の当事者（障害を引き起こした人等）の参加を促すことが望ましい。その際に注意すべきことは、あくまで、実施の目的は障害を発生させた「個人」を責めることではなく、原因を究明して「組織」としての再発防止策を検討することである、ということを参加者に徹底することである。

---

情報処理システム高信頼化教訓集 ITサービス編 別冊Ⅱ：障害分析手法　２．１．１ なぜなぜ分析による原因分析 より

• 情報処理システム高信頼化教訓集 ITサービス編 | アーカイブ | IPA 独立行政法人 情報処理推進機構

より専門的な書籍などで理解を深めると分析の誤りが回避できるのかもしれないが、では（製造業ではなく）ソフトウェア開発の現場でそこまで理解を深められることができるのか、という点については疑問を感じている*2。

もしおすすめ書籍などがあったら紹介していただきたい。

記事に書かれているダメな分析例が作為的すぎる

これは素直に手抜きだったと反省している。ただ、それでは他の例として上記でも引用したIPA資料にある例を引いてみると、印象が変わるのかという点については問題提起をしておきたい。

《IPAの資料にある事例》

• A社のオンラインサービスが丸一日間停止した。
• （なぜ？）お客様のサービス（復旧時間、障害中対応）に時間を要した（から）
• （なぜ？）負荷分散装置はD社と共用しており、再起動等の対処によるD社サービスへの影響が不明のため、A社の了解のもと対処を業務終了後まで先送りすることとした（から）
• （なぜ？）トラブル発生時等の情報共有のための利用者間の連絡体制は確立されていなかった（から、また）A社の論理区画を再起動した場合の共同利用している他企業D社のオンライン業務の影響を知らなかった（から）

• 対策
  • 共同利用者間の情報共有の強化を行う
  • （また）B社は、システムを停止／再起動させる場合についての条件や手順、責任等に関する取決めをSLAで定義し、共同利用各社と合意する

事例の前提となっているだろうインフラ構成の古さはあるが、それを差し引いてもこのような分析には わかりやすさを重視しすぎて、本来検討すべき事項の欠落を感じてしまう。IPAの例なので分析の妥当性はそれなりにあると思うが、どうだろうか。

なぜなぜ分析に代わる代替手段が記事に記載されていない

ご指摘の通りで記載していないが個人ブログであるということも踏まえてお許しいただきたい。ただ、自分の考えとしては、インシデントの分析にあたって特定の手法や方法論を標準的に使用すること、そのものが正しくないと考えてはいる。前回の記事でも書いたが「複雑系は、複雑な方法で故障する」ので、その事象を観察した上で適切な分析方法も都度検討すべきではないか、というのが自分の考えである。

引き続き、ご意見などがあればX（旧Twitter）か はてなブックマーク などでどうぞ。