■「なぜなぜ分析」を行ったことがありますか？
「なぜなぜ分析」とは、問題の根本原因を探るために「なぜ？」を繰り返し問う手法です。
もともとは生産現場で利用されていた手法ですが、現在では問題の再発防止を目的として、さまざまな分野で広く活用されています。例えば、ソフトウェアバグの再発防止や、メール誤送信などの情報セキュリティ対策にも応用されています。
しかし、実際に「なぜなぜ分析」を行った経験がない人が、突然分析を行う必要に迫られることは珍しくありません。問題が起こって初めて実施される活動ですから、むしろ慣れている人のほうが少ないのではないかと思います。さらに、研修では生産現場の事例が多く、研修で学んだことがある人も実際に分析をすることになると、どうしたらよいか戸惑うことも少なくないでしょう。
特に経験が浅い人が実施した「なぜなぜ分析」は、見よう見まねで行われがちです。結果として、いくつかの共通の問題点が見受けられます。私がこれまでに見てきた事例を踏まえ、「なぜなぜ分析」をより効果的に行うためのコツを紹介します。
■ポイント①：「なぜなぜ分析」は上司が主体で実施する
問題を起こした本人に反省を促す意味で「なぜなぜ分析」を任せるケースはよくありますが、本人による分析結果は表面的な説明にとどまり、真因には至っていないことが多いです。そのため、本人以外が実施することが望ましいです。特に本人の上司が実施することが最も効果的です。
上司は管理責任を負う立場にありますし、問題発生に関連した背景や適切な手順についての知識があり、必要な情報へのアクセスや関係者へのヒアリングも実施しやすいためです。上司が「なぜなぜ分析」のトレーニングを受けていれば、なお良いでしょう。
しかし、本人にしか分からないことも多いため、ヒアリングを通じて共に分析を進めることが重要です。文書化は上司が行い、理解できない点は仮説を立て、質問を重ねて事実を確認します。可能な限り、現場や現物を確認することも重要です。これにより、客観的かつ論理的な検証が行え、本人も気づかなかった点が明らかになることがよくあります。これらが、上司が主体的に分析を行う利点です。
下の図はなぜなぜ分析の活動のフロー図です。この図を見るとわかりますが、「なぜなぜ分析」は分析して終わりではなく、対策を検討し、実施し、効果を確認するまで行わなければ意味がありません。その観点からも、上司が主体となって実施することが有効です。
ただし、ミスをした本人を責めるような対応は避けるべきです。重大なミスにより本人が落ち込んでいる可能性も考慮する必要があります。反省は大切ですが、ミスは誰にでも起こり得るものであり、本人に過度な責任を負わせるのは不適切です。ミスの真因を明らかにし、再発防止策を一緒に考える姿勢が重要です。
もし上司から「なぜなぜ分析」を依頼された場合、この投稿を見せて「一緒に分析をしていただけませんか」と提案すると良いでしょう。組織としては、分析の実施者を上司とするルールを定めておくのが望ましいです。
■ポイント②：分析前に事実を具体的に時系列で整理する
「なぜなぜ分析」を効果的に行うためには、問題が発生するまでの経緯を具体的に時系列で整理することが非常に重要です。分析のテンプレートに直接「なぜ？」の回答を記載してしまうのは、分析がうまくいかない典型的なケースです。分析を始める前に、関係者からの情報収集を通じて、問題が発生するまでの出来事を具体的に、事実に基づいてフロー図で記載します。確定できない情報は、仮説として区別し、後で事実確認を行います。
ソフトウェア開発での「なぜなぜ分析」では、問題の混入したポイントと、レビューやリリース確認などで防げたはずのポイントがあり、それぞれ混入系と流出系として明確化します。
この方法によって、問題がいつ、どのような経緯で混入(発生)したのか、また、どのように発覚(検出)したのかなどが明確になります。関連するプロセスやルールが存在する場合は、それらに対する対応状況も明らかにします。例えば、プロセスがレビューを要求している場合、流出系として、それは実施されたのか、何を確認したのかといったことを明確にします。
その混入ポイントと流出ポイントが「なぜなぜ分析」の１つ目の「なぜ?」の結果となります。
なお、確認した内容はフロー図にコメントのような形で記載していますが、実際のソースコードやレビュー議事録の該当箇所を画像で貼り付けることで、資料作成の手間を省きつつ、事実関係がより明確になります。
「なぜなぜ分析」のテンプレートを用意する際には、「問題発生までの経緯」を記載できるフリーフォーマットのシートを準備すると良いでしょう。
■ポイント③：分析の結果は逆からでも成立するかを確認する
「なぜなぜ分析」を行う際には、導き出された結果が論理的に成立しているかどうかを逆の視点からも確認することが重要です。例えば「メールを誤送信した → 急いでいたから」という結果は、逆の視点から見ると「急いでいる → メールを誤送信する」は必ずしも成り立ちません。このような論理的飛躍があると、分析が誤った方向に進むリスクがあります。適切な「なぜなぜ分析」では、「メールを誤送信した → アドレス帳に同姓の人があり、誤って選択した」といった具体的な原因が挙げられるべきで、これは逆から見ても論理的に成立します。
この逆順チェックは、離れた位置の場合でも確認することに注意してください。
なお、「なぜなぜ分析」のサンプルや例では、簡潔な記述になっていることが多いですが、それを真似て説明を省略すると、論理的に成立しないケースが見つけにくくなります。分析結果は、多少文書が長くなっても具体的な説明を行うべきです。また、複数の要因が関与している場合は、それぞれを独立した項目として分割して考察するようにします。
■ポイント④：対策はプロセス（仕組み）の改善になる
「なぜなぜ分析」は、一般的には「なぜ？」を5回繰り返すことで真因に辿り着くと言われていますが、これは5回に限定されたルールではありません。しかし、分析が3回程度で終わる場合、経験上、真因に至っていないことが多いです。そうした分析から導き出される対策は、「以後注意する」「ルールを守る」といった、一時的な個人への注意喚起に留まりがちで、根本的な再発防止には繋がりません。
なぜなぜ分析の結果は、組織的な再発防止に繋がるようなプロセスの改善を行うことを考えます。これには、作業手順の見直し、チェックリストの導入、教育プログラムの強化、ツールやシステムの利用など、仕組みの改善を伴う対策が含まれます。
下の表は根本原因とそれに対する対策の例です。「なぜなぜ分析」では個人のヒューマンエラーを分析し、対策すると考えがちですが、「なぜ」を繰り返して、その先の組織の問題までたどり着きましょう。
※組織/プロジェクトの項目は「CMMIⓇ for development V1.3 GP2.1～2.10」を参考にした。
ただし、プロセス改善においては、過度に厳格なルールを設けることが反対に作業の効率を損なったり、新たな問題を引き起こしたりするリスクもあります。そのため、実際に作業を行う人々が負担を感じず、かつ効果的にルールを守ることができるような改善策を見つけることが重要です。ツール化や自動化を進めることで、人的ミスを減少させることも有効な対策となります。
■ポイント⑤：本当に「なぜなぜ分析」が必要なのかを判断する
これは分析のポイントではないのですが、重要なことなので1つ付け加えました。
組織によっては「なぜなぜ分析」の適用条件が明確に定められている場合があります。これはプロセス的には望ましいことですが、場合によっては分析が形式的に、または過剰に行われることがあります。
例えば、システムテストが完了し、品質ゲートがパスした後に設計書の誤字が見つかった場合、ソースコードに影響がなければ、分析を行わないという選択は合理的です。このような場合、修正が漏れないように、課題として管理し、適切なタイミングで修正を行えば十分です。しかし、こういった軽微なケースにおいても「なぜなぜ分析」を要求されると、有効な再発防止策を見つけることは困難です。
問題の性質や影響の大きさ、発生頻度を考慮し、分析や対策にかかるコスト、時間、労力と、その結果が組織にとって価値をバランスよく評価し、分析の必要性を判断することが重要です。不必要な分析は、リソースの無駄遣いにつながるだけでなく、問題を隠蔽するような悪循環を生む可能性もあります。したがって、分析の必要性は、適用条件に一致するものから、個別に判断するべきです。
■「なぜなぜ分析」の参考図書のご紹介
「なぜなぜ分析」はもともと、トヨタ生産方式から生まれたものです。このため、生産現場向けの内容が多く、ソフトウェア開発の事例が書かれたものがあまりありません。私が参考になった本を2冊ご紹介します。
デンソーから学んだ本当の「なぜなぜ分析」, 倉田 義信, 日刊工業新聞社
www.amazon.co.jp/dp/4526077135
なぜなぜ分析の考え方を具体的な事例を通じて理解を深めることができます。ソフトウェアバグに関する章が含まれているため、ソフトウェア業界の方にも有用です。
クイズで学ぶ なぜなぜ分析超入門, 小倉 仁志, 日経BP
www.amazon.co.jp/dp/4822230465
クイズとありますが「こういう場合はどう考える?」という問いかけ式で記載された事例集です。読んで考えていくと、なぜなぜ分析の本質が身についていくと思います。