昨日、テクニカルサポートチームの不具合対策会議を手伝いました。会議では、客先での原因不明の製品不具合に対して、どのように調査し、どのように不具合の原因を掴むか、その方法について話し合いました。会議では複雑に絡み合ったいくつもの可能性のある原因とその影響をすべて捉えるため、パラメータ・ダイアグラム（Parameter Diagram）を使って議論を進めました。
消防士型の問題解決方法
良くあるトラブル対策は、専門家が集まって知恵を出し合いながら話し合い、最も可能性のありそうな結論をひとつだけ導き出し、それが正しいか（問題が解決するか）どうかを一つずつ検証するものです。もし問題が解決しなければ、新たに得た情報を基に再び話し合いを行い、次に可能性のありそうな解決策を選び、検証します。問題が解決するまで会議と検証を繰り返すので、所謂、消防士（Fire Fighter）型の問題解決方法と言われます。優秀な消防士がいる時は効果的な方法ですが、そうでなければ時間とコストがかかります。
特性要因図を使った問題解決方法
少し進むと、特性要因図（Fishbone Diagram, Ishkawa Diagram）を作ったり、または故障の木解析（Fault Tree Analysis）を行って、問題の原因を探ることがあります。これは予め、全ての原因を探り出そうとする試みです。特性要因図は、問題の原因を視覚的かつ網羅的に把握できるため、原因分析のためのツールとして良く使われます。
しかし特性要因図は、（１）一つの問題しか分析できなかったり（２）ひとつ原因が複数の問題に影響していることを分析できないため、複数ある問題に共通する根本原因を探ろうとするときは不便です。特性要因図を使っても問題を一つずつしか解決できないため、結局、消防士型の問題解決方法に戻ってしまいます。
パラメータ・ダイアグラム
テクニカルサポートチームが抱えていた製品の不具合は一つではありませんでした。しかし何か共通の根本原因が、いろいろ症状（不具合）になって表れているのではないかと想像できました。そのためその共通な根本原因を探るために、会議ではパラメータ・ダイアグラムを使ったのです
パラメータ・ダイアグラムは特性要因図と同じ機能を持っているだけではなく、複数の問題に対して使うことができます。そして複数の問題と複数の原因を関連付けることができます。
しかしパラメータ・ダイアグラムの最大の利点は、FMEAと相性が良いことです。パラメータ・ダイアグラムが完成すれば、それをFMEAに置き換えることができます。一旦パラメータダイアグラムをFMEAに置き換えてしまえば、今度は問題の危険度、原因の発生頻度、問題の検出力などを評価し、危険優先指数が計算できます。そうすればいくつもの対策案に優先順位をつけることができます。
