第11章 QFD、FMEA、品質工学は「答え」ではなく武器である
― 手法に使われる技術者から、手法を使いこなすDQL（設計品質リーダー）へ
手法を知っていることと、問題を解けることは同じではない
製造業には、非常に多くの優れた方法論がある。
QFD、FMEA、実験計画法、統計解析、品質工学、信頼性工学、シミュレーションなど、製品企画から設計、評価、量産準備まで、さまざまな局面で利用できる。
企業では、こうした方法論を教育するために研修も行われる。
QFDの作り方を学ぶ。
FMEAの書き方を学ぶ。
実験計画法でデータを解析する。
品質工学の考え方を学ぶ。
これらはもちろん重要である。
しかし、ここで一つ気をつけなければならない。
手法を知っていることと、良い製品を生み出せることは同じではない。
さらに言えば、良い製品をつくれることと、儲かる事業をつくれることも同じではない。
どれほど立派なQFDを作っても、そもそも選んだ顧客課題が小さければ大きな事業にはならない。
どれほど詳細なFMEAを作っても、顧客が必要としない製品なら売れない。
高度な統計解析を行っても、検証している仮説そのものが間違っていれば意味がない。
方法論は、正しい方向へ進むことを保証してくれるものではないのである。
地図があっても、目的地を間違えれば意味がない
方法論は、地図やナビゲーションに似ている。
優れた地図があれば、目的地まで効率よく進むことができる。
しかし、「どこへ行くべきか」は地図が決めてくれない。
たとえば東京から大阪へ行きたい人が、非常に精密な北海道の道路地図を持っていても役には立たない。
製品開発も同じである。
QFDは顧客要求と技術特性の関係を整理するのに有効である。
FMEAはリスクを構造化するのに有効である。
実験計画法は効率よく技術仮説を確認するのに有効である。
しかし、「この顧客課題を解決する価値があるのか」という問いは、それ以前に考えなければならない。
DQL（設計品質リーダー）に必要なのは、手法を正しく使う能力だけではない。
今どこにいて、どこへ行きたいのかを考え、そのためにどの道具が必要かを選ぶ能力である。
QFDは「表を埋める道具」ではなく、顧客価値を技術へ翻訳する道具である
QFDは、DQLにとって非常に有効な道具の一つである。
ただし、品質表を完成させることが目的になってはいけない。
本来の価値は、顧客の言葉を技術者が扱える形へ変換することにある。
たとえば顧客から、
「保守が楽な装置がほしい」
という要求が出たとする。
このままでは、設計者は何をすればよいか分からない。
そこで、「保守が楽」とは何かを掘り下げる。
交換時間が短いことなのか。
工具が不要なことなのか。
点検回数が少ないことなのか。
故障箇所を簡単に特定できることなのか。
こうして顧客要求を具体的な技術特性へ展開していく。
この過程で重要なのは、表のマス目を埋めることではない。
顧客が本当に価値を感じているものを、設計判断へ変換することである。
もしQFDを使っても、顧客の本当の損失を理解していなければ、精密な表の中で間違った要求を展開しているだけになる。
簡単な事例――「高精度」という要求をそのまま信じない
ある計測機器メーカーが、顧客から「もっと高精度なセンサーがほしい」と言われたとする。
設計チームは、測定精度を±1％から±0.5％へ上げることを開発目標にした。
しかし、DQLが顧客現場を詳しく確認すると、本当の困りごとは別にあった。
測定値が一定範囲を超えたとき、設備を止めるべきかどうかの判断に時間がかかっていたのである。
顧客が欲しかったのは、単純な測定精度の向上ではなく、異常判定の確実性だった。
この場合、QFDを使うなら、「高精度」という言葉をそのまま技術特性へ置くのではなく、「異常判断の誤りを減らす」という顧客価値まで掘り下げる必要がある。
その結果、測定精度よりもノイズ耐性や判定ロジックの改善のほうが重要だと分かるかもしれない。
手法の価値は、こうした思考を支援するところにある。
FMEAは「心配事を全部書く表」ではない
FMEAも、製造業では広く使われている。
しかし運用を誤ると、膨大な表を作ることが目的になりやすい。
考えられる故障モードをできるだけ多く列挙する。
原因を書く。
影響を書く。
対策を書く。
行数は増える。
会議時間も増える。
しかし、本当に重要なリスクが見えなくなってしまうことがある。
DQLにとってFMEAの目的は、
「事業や顧客価値を壊す可能性が高いリスクは何か」を明確にして、行った信頼性設計で十分かチェックすること
である。
すべてのリスクを同じように扱う必要はない。
重大事故につながるもの。
顧客の大きな停止損失につながるもの。
市場投入後に回収が難しいもの。
こうしたリスクを見て、必要な対策を設計で講じる。
逆に、ほとんど起こりえず、影響が小さく、簡単に修正できる問題へ大量の時間を使うのは、必ずしも合理的ではない。
リスクを減らすことと、リスクを全部なくすことは違う
FMEAなどのリスク管理手法を使うと、「できるだけリスクを減らそう」という方向に意識が向く。
もちろん安全や法規に関わるリスクは、十分に管理しなければならない。
しかし研究開発全体で考えると、すべての不確実性をゼロにしてから進むことはできない。
たとえば、新しいソフトウェア機能を開発しているとする。
将来の顧客使用条件をすべて想定し、すべての故障モードを完全に潰してから市場へ出そうとすれば、競合に先を越されるかもしれない。
一方で、重大なセキュリティリスクや安全リスクを残したまま出すことはできない。
つまり必要なのは、リスクゼロではなく、
「どのリスクは許容でき、どのリスクは絶対に潰すべきか」を判断することである。
ここでも、手法より判断が重要になる。
※御社のプロダクト（製品・サービス）分野で同様の話が聞きたい！という場合は、どうぞご相談ください。
[無断転載禁止]
DQL（設計品質リーダー）育成コースの詳細なご案内は下記よりダウンロードできます。
ダウンロード
0 件のコメント:
コメントを投稿