部下に特性要因図を書かせてみると頑張って作ってきてくれるのですが、残念なことに納得が行く仕上りの図を見ることはほとんどありません。同じ課題に対して何人かそれぞれ指示すると、みんな結構違うものが出来上がってくることもよくあります。
まず特性要因図になじみがない方はぜひ最初に「QCストーリーの要因分析」の「特性要因図とは」をご覧になってください。書き方も含めてまとめています。
特性要因図の目的は
特性要因図の目的は、結果として表れている品質特性に影響を与える要因を整理して把握することです。
確かに要因を思いつくままに議論しているようだと発散して収集が付かなくなってしまいますが、特性要因図のようなものを使って議論すると、例えば「ここと同じですね」と指摘したりして重複なく議論することが可能になります。
このように整理して把握するという点では、その目的を満たしているものと思います。
特性要因図の二つの問題
特性要因図の問題は大きく二つあると思います。一つが漏れを防ぐ手段がないことで、もう一つが要因として挙げていることの影響度が表現できないことです。
漏れが防げない
漏れを防ぐ手段がないことに関しては、どのような要因を並べるかはその時に集まった人の思いつきに依存しています。これでは漏れが生じて色々な特性要因図が毎回出てくるのは仕方のないことです。
要因の影響度が不明瞭
要因を色々と挙げる際には、あまり影響がないと思われることもとりあえず列挙してしまうと思います。問題はそれが同列になってしまうことです。大きな特性要因図を出されると何が重要要因なのかさっぱりわからなくなります。
要因の一本釣りが防げない
そもそも特性要因図を書くことは要因を広く把握することでしたが、最初に主観的に思っている要因を重要要因として、それに肉付けする形で特性要因図を仕上げていると思われるケースが良く見られます。
ソフトウェア開発中の不具合発生が増加していることに対して、ある人は実装スキルの低下を重要要因にあげ、ある人はコードレビューの質に重要要因をあげたりと、重要と選択した根拠が曖昧になります。
さらにそれを話し合いでどちらかにしようとしても、両者とも頭で決めつけているので妥協以外に解決策がなくなります。経験を持ったベテランが多いほどこういった状況に陥りやすいように感じます。
特性要因図の二つの問題がこのようなことを許していると言えると思います。
特性要因図にこだわらず「なぜなぜ」を繰り返すこと
ベテランがいない状態で、なぜなぜを繰り返させて作った特性要因図は見るのは大変ですが、面白いものができることがあります。問題解決の糸口も見えない状態では、効率が良いとは言えませんが作業を行うことによって糸口らしいものを見つけられることもあります。
しかし図を作ったから糸口が見つかったというより、なぜなぜを繰り返したから見つけられたのだと思います。図は整理できれば何でもよくてツールが整っているマインドマップがおすすめです。
結局重要要因の検証作業
特性要因図ではなんとなく要因を整理し把握した気分になって重要要因を決めてはみたものの、あくまでも主観に基づく仮説でしかありません。それを結局は検証作業を行って確かめる必要があります。
これは重要要因と思ったことが結局大した要因でなかったということになることもあるということです。これでは効率が悪いです。
要因分析の途中で検証をやること
検証は要因分析の最後にやるのではなくて、途中で、できればできるだけ早い段階でやることが効率を高めます。データの取れる切り口でMECEに層別して検証比較できるところを探すことです。
これは大抵の場合難しいことですが、意識しておくと要因を整理しているときに、うまい切り口というものは見つけることができるものです。
検証比較ができれば、要因として大きなところを絞り込むことができて、さらにその中で層別して絞り込んでいくことを繰り返すことで真の重要要因を探り当てることができます。
まとめ
特性要因図は要因を整理し把握することに関しては有用ですが二つの問題があります。そのために導かれる要因の信頼性はあまり高くありません。
要因を整理している途中で検証を挟むなど工夫することで信頼性を高めない限り、効果の薄い要因に対して対策を進め、無駄な時間を費やすことになりかねません。
QC七つ道具というように、特性要因図はあくまで道具であって、使う人の技術が肝心なのかもしれません。
コメント