原因分析「なぜなぜ問答」の勘所

株式会社 プロセスネットワーク
代表取締役　金子　龍三

1. はじめに

　適確な原因分析技術を修得していると、改善が進み技術力・マネジメント力が向上し、次のプロジェクトから未然防止ができるようになります。
原因分析の方法のひとつが「なぜなぜ問答」ですが、「なぜ」を単純に5回繰り返しても分析は成功しません。分析結果が縦の棒状になるようでは原因を見逃している可能性があり、多くの場合失敗です。分析結果はツリー状になることがしばしばあります。

2. なぜなぜ問答の勘所

　「なぜなぜ問答」は管理者や品質保証スタッフが分析するのではなく、当事者が自問自答し、その後管理者や品質保証スタッフがレビューし、分析方法を指導することが勘所です。管理者や品質保証スタッフが分析すると過去の経験から誘導しやすく、誘導すれば再発しやすくなります。
当事者が原因分析する際には次の事項について注意する必要があります：

• 現物をみて分析する
• 複合文は単文にわけ、単文ごとに分析する
• 事実か推論か参考意見かを区別する
• 検証不可能な回答（形容詞・形容動詞）は詳細を具体的にする
  例：忙しい、時間がない、人がいないなど
• どのように行ったかを分析する（Whyではなく、What、How、Whenが先）
• 論旨を確認し検証するために図解（系統図が推奨）する

原因分析を管理者や品質保証スタッフが分析する場合には：

• 質問ではなく聞き出し相手に思い出させ・気付かせる（精神分析相談型カウンセリングの技術）
• 相手の思考を妨げない（討論や説得ではない・次々と言わない・間を置く・回答を待つ）
• 相手の思考を活発にするためにあいづちを打つ
• 相手が真実を言っているか相手を観察しながら行う

3. 原因分析「なぜなぜ問答」レビューの勘所

　レビューする際にも、同様な事項を確認しながら行います。

• 分析の論旨を図解する、あるいは図解資料を基にレビューする。A4用紙程度の「なぜなぜ問答」テンプレートに記載されているようでは原因のもれの可能性があります。
• 図に記載された原因で、形容詞･形容動詞などあいまいな回答はすべて吟味します。

　 例：忙しい　何を行っていて余裕がないか、担当している業務を列挙する。

• 図に記載された原因が事実か推論か吟味します。

　 例：標準が無い　標準があるが；無視した、理解できなかった（教育に原因がある）、必要性がわからなかった（指導に原因がある）、標準を守らなくても誰にも指導されない（マネジメントに原因がある）などの可能性があります。

• 分析論旨に飛躍がないか吟味します。

　 例：例外条件がもれた　設計時に気がつかなかったか、仕様書に記載があったか無かったのかを分析しているか。

• 分析もれ／不足を吟味します。

　 例：最終検査でもれたと分析し原因分析は終了した。要求仕様書に記載されていない事項であり、要件開発工程も分析するべきだった。作りこみ工程の分析がもれた。またプロジェクト品質マネジメント計画も立案されていない（マネジメントプロセスの分析がもれた）。

• 分析の誤りがないかどうか検証します。

　分析の誤りで多いのが、実際には実行できないことを実行していないから問題が発生したと断定するケースです。次のプロジェクトなどで実行できるかどうかを検証する必要があります。
例：検査でバグが発見され、レビューもれと指摘され、チェックリストの不備が原因だと報告された。次回のプロジェクトでそのチェックリストを正確に適用できるかどうか検証したところ、開発期間と対象物の量、チェックリストの量からすると実行できないことがわかった。設計課題、最終成果物の質に与える影響（FTA,FMEA、その結果から規定したプロジェクト品質マネジメント計画）、担当技術者の能力、その工程での品質保証記録から「ぎりぎりの意思決定」を行い、レビュー範囲を規定することがもれていた。
例：検査もれと指摘された。しかし、テスト技術の観点からすると完璧な検証は膨大な期間と工数がかかり実行不可能である。検証しようとすると費用も大幅に増え、今回のプロジェクトの開発期間からすると納期を延ばす以外にない。開発期間と費用がかわるとこの商品の市場性はなく、商品開発は停止に追い込まれる。納期と費用との関係でどこまで品質保証するかはプロジェクト責任者決定事項であり、プロジェクト立ち上げ時のプロジェクト憲章にて前提条件および制約条件として明記すべきであった（プロジェクト憲章発行もれ・・・プロジェクト責任者の責任放棄）、またどのように品質保証するかはプロジェクト計画策定時にプロジェクト品質マネジメント計画を策定し、明記しプロジェクト責任者出席のレビューで決定するべきであった（プロジェクト品質マネジメント計画策定および審議もれ）。これらのことからすると、品質保証部門関係者およびプロジェクト責任者に対するプロジェクトマネジメント教育が欠落している可能性が高い。

• プロジェクト関係者がその要因が解消されたら、同じことは起きないと確信を持てるか。分析者や管理者が「真の原因がわかった」と納得することではありません。

4. おわりに

　それぞれが原因分析の結果を保存し、後日見直すと原因分析力の向上のきっかけになります。
分析結果を集めてみると「知らなかった型」「守らなかった型」「できなかった型」「意図的に省略した型（弁解型を含む）」「ヒューマンエラー型」などの類型があることがわかります。類型別に分析方法を訓練することを推奨します。
原因が判明したら、関連の専門領域を調べ知識体系や同様な要因類型（一般化）を調査し（一を聞いて十を知る）、系統図に追加することも原因分析では重要です。
「なぜなぜ問答」による分析は広い範囲に適用できますが、分析も、分析結果のレビューも難しい技術です。より簡単に修得できる技術として、ISO-9000に基づく原因分析技術「プロセスネットワーク分析」法があり、11月号に掲載する予定です。「なぜなぜ問答」だけではなく、「プロセスネットワーク分析」法の適用もお勧めします。