こんにちは、ホーリーです。
さっそくですがIT業界でもとっても有名な、なぜなぜ分析について話していきます。
と言ってもなぜなぜ分析を説明されている記事は世の中にたくさんありますので、今回は実際にやってみて上手くいかなかった点や、それをどう対応していったのかを紹介したいと思います。
本記事は製品不具合に対してなぜなぜ分析を採用した際の内容となっております。
- なぜなぜ分析とは
- 回答者の精神的負担を可能な限り減らす
- 回答に対しての質問（なぜ？）を上手く投げかけられない
- 対策をしたい内容につながるような真因（偽）に意図せず進んでしまう
- 取り扱う内容が昔すぎて思い出せない、担当者がもういない
- （対策について）人依存の対策になってしまいがち
- 真因および再発防止策は明らかになったが、それらの対策が浸透しない
- チェック、監視プロセスがどんどん増えていく
- まとめ
なぜなぜ分析とは
話さないと言いつついきなり手のひら返しですが、何も説明しないのも良くないのでざっくりとだけ触れていきます。
なぜなぜ分析という名前の通り、起きた事象に対してなぜ（起きたか？）の質問と回答を繰り返して真因を突き止めていく手法になります。
それでは改めて紹介をしていきます。
回答者の精神的負担を可能な限り減らす
こちらは当初から注意して意識するようにしていましたが、健全な進行をする上でかなり重要な意識づけかと思いますのであえて一番に記載しておきます。
進行の特性上、（その意図はなくとも）回答者を詰めていくような流れになりがちです。
対策した内容
心理的安全性。すなわち回答者が事実を包み隠さず答えられるような場となるよう参加者全員で心掛けることを最初に認識合わせしています。
事象を根本から解決するために真因を目指して質問を繰り返しているので、そのための回答はどんな内容であっても当時の事実として受け入れる、許容することを約束します。
極端な例ですが『気が散っていた、寝ぼけていた』といった回答であっても事実であれば歓迎しますし、そこに対して回答者を攻撃するようなことはない旨を周知していました。
回答に対しての質問（なぜ？）を上手く投げかけられない
参考となるなぜなぜ分析に関する資料を閲覧しても、回答に対してなぜ？と繋げるようにと書かれていることが多いですが、いざやってみても上手くいかない...。
実際どのようなやり取りをしていたかを振り返ってみたところ、例えば以下のような状況がありました。
- ○○の状況だったので△△をしてしまった結果、□□となってしまったから。
端的ではなく回答の粒度が大きくなってしまっていたなと感じます。
次は○△□の何に対して質問をすべきか、全てひっくるめて質問すべきか。この辺りを上手くさばくことが出来ず停滞したり質問と回答がループしてしまいました。
対策した内容
このような回答が出た時には、次の質問に入る前に皆で認識合わせをしながら内容の分解をするようにしています。
多くの場合には『□□となってしまったから』を補強するための情報であるパターンが多いので、いったん回答としてはこの部分のみとして抽出してしまいます。
次に残りの『○○の状況だったので△△をしてしまった結果』の部分を見ていくわけですが、抽出した回答に対する次の質問に繋がる内容であることが多いです。
そうでない場合は派生ルートとして外出しして、そちらも個別になぜなぜ分析を進めていくかどうか判断をしています。
対策をしたい内容につながるような真因（偽）に意図せず進んでしまう
なぜなぜ分析で取り扱う事象について、タイミングによっては不具合対応が先に進行して対策が既に完了している場合もあります。
そんな状況下でなぜなぜ分析を開催すると不具合修正内容が既に頭に入っているため、そこにどうしても意識が引きずられてしまって、意図せずそこへ繋がるような質問＆回答になってしまうことがありました。
対策した内容
意識しすぎてもなぜなぜ分析を上手く進められないので、いったんはあまり気にせずに進めていきます。
真因までたどった段階で他に気になる点がないか、回答に対して別の質問を投げかけられる部分は無いかといった形で全体を一度見渡すようにしています。
再発防止策についても、同様の真因となる類似事象をシミュレートしてみて防止できる内容になっているか確認をしています。
取り扱う内容が昔すぎて思い出せない、担当者がもういない
過去のバージョンで発生していた不具合を対象とした場合は、既に担当者がいなくなってしまっていた、または在籍していても相当昔の内容のためもう覚えていないといったことが起きました。
長年続いているサービスですとこういうこともよくあるかと思います。
対策した内容
当時の状況を正確に把握するに越したことはないのですが思い出せないものは仕方ないので、今現在のメンバーや体制で該当プロジェクトを再度取り組んだとしたらどうなるかといった視点で振り返りを行っています。
最終的な目的は今後同じ事象を起こさないようにすることのため、『今』どうなのか現状の体制でも起きるなら何が不足しているかという軸で再発防止策を考えるようにしています。
（対策について）人依存の対策になってしまいがち
始めた当初はいろいろ再発防止策を考えてやっていましたが、末端の所で人の判断に依存してしまう形が存在していました。
- レビュー時にしっかり確認する
- 忘れずチェックする
そのためせっかく対策した内容も、それ自体の実施を忘れてしまった。といったことが起きてしまいます。
対策した内容
人に依存する対策は極力排除して、人が忘れたとしても気づける対策・仕掛けとなるよう色々と体制を整えるようにしていきました。
- レビュー時にしっかり確認する
- 忘れずチェックする
- チェック結果の成果物が全て合格するまで次のステップに進めなくする。
どうしても人の判断に依存してしまう対策にせざる場合は、人的ミスの検知・リカバリー手段もセットで組み込むようにして少しでも人依存が減らせるよう考えるようにしています。
真因および再発防止策は明らかになったが、それらの対策が浸透しない
始めたての頃はなぜなぜ分析を実施することに意識が集中してしまい、決まった再発防止策を推進することがあまりできていませんでした。
当初の対策は別枠で話しましたが人依存の対策内容が多かったこともあり、全体周知をしてお終いとなってしまうこともありました。
対策の周知だけだとどうしても流し見で終わってしまう所もあり、どうインプットさせるかも課題でした。
対策した内容
なぜなぜ分析の実施ペースを下げたくなかったので再発防止策を管理運用するタスクを明確に分離化して、周知および運用へ浸透が行われるまで活動しきるチームを用意しました。
どういう背景からこの再発防止策が生まれたかも把握できるようなコンテンツにしたりして、ただチェックするだけでなく各人が自身で考えたり気づけたりする土台となるよう意識しています。
チェック、監視プロセスがどんどん増えていく
多くのなぜなぜ分析をこなしていくと、再発防止策も比例して増えていきました。
最初の頃は特に問題はなかったのですが時間の経過とともにチェック内容やプロセスが多くなってきて、それの実施自体が負荷になるようになってきました。
メンバーの入れ替わりもあるため、過去の不具合や再発防止策を知らない人員もいる中で単純にチェック内容を減らすわけにもいかない状況でした。
対策した内容
これに対しては現在進行形で改善方法を検討、実施中となっています。
プロジェクト内容に応じてチェック内容をフィルターして、相関性/関係性のないチェックリストの間引きを行えるようにしています。
類似したチェック内容は統合して、実際に不具合が起きた事例として取りまとめるといった形でのスリム化を行っています。
メンバーの熟練度に応じて、初見者向けの内容はフィルターできるようにするなどといった対策も検討中です。
まとめ
いかがでしたでしょうか。
現実と同様に中々理想通りに進まないですが、なぜなぜ分析はあくまで手段であって目的ではありません。
基本通りの進め方で上手くいかなくてそこでやめてしまうよりは、自分達の仕事の進め方とマッチするように内容をブラッシュアップするのもいいかと思います。
※真因を見つけて根本から対策するという本質がぶれないようにだけ注意です！
ecbeingでは新進気鋭なエンジニアを募集しております！
careers.ecbeing.tech
