【商品開発】設計検証で設計の正しさを確認:「評価結果が規格内だから問題なし」は危険「バラツキ持ってませんか?」

開発

設計し図面をアウトプットしたら、設計が正しいか、狙い通りの性能ができているか製品試作品を評価して「設計検証」します

検証が目的で、品質の保証はあくまで設計で行うことが重要です

仮に評価した結果合格であっても品質を保証したことにはなりません

結果対して「バラツキ」、「規格に対するの余裕度」を考えて判定することの重要性と考え方について話します

設計検証とは

試作品を作成し評価する段階です

その目的は

論理的な設計を行い、その設計の狙い通りの性能が確保できているか確認すること

あくまで、確認であることを正しく認識しましょう

「評価」は設計検証をするための手段ですのでお間違え無く

原則として、品質は設計で保証するべきであり、評価で保証するのはやむを得ない時の手段です

この記事では、その「設計検証の役割」について語ります

評価で品質を保証する危険性

よく、開発現場で「評価結果が合格なので問題なし」との設計者の発言をよく聞きます

これ、じつはメッチャ危険な考え方です

説明します

評価と言うのは、お客様の使用条件を想定した上で、評価条件を決めて性能確認行い、その結果で合否判定するものです

評価条件の多くは、過去の積み重ねの中で決めてきたものですが、評価が合格ならある程度品質を確保することはできます (全くの新規技術の場合は積み上げでなく、新たに評価基準を決めないといけません)

しかし、「絶対大丈夫」と呼べない場合が多々あります

評価により品質基準を満足しても、品質を保証できたといえない場合は多い

チョイと、説明が難しいのですが頑張ります

評価で「品質を保証できている」といない理由

〇評価結果は「バラツキ」をもっている

これが大きな理由の一つですね

評価には、環境のバラツキ・手順のバラツキ・測定者のバラツキ・サンプルのバラツキ、いろんなバラツキを持っています

多くのサンプル数で評価を行い、CPK(バラツキの指標)をしっかり確保できている場合ならそれほど問題になりませんが、耐久試験などそれほどの多くのサンプル数を評価できない場合も普通にあります

ですので、少ないサンプルをある条件下で計ったら、たまたま合格になっただけかも知れません

「そんなん言うたら、合否判定どうするねん」

って言われそうですが、

理想を言うなら「CPK求めてください」

ですが、そうもいかん場合も多いでしょう

そんな時の私の判断基準としては

「この商品のこの特性は、経験上これくらいバラつくから、この値なら大丈夫」

と言うことを過去の経験の積み上げから設定します

本来のお客様許容値に対してより厳しい規格の設定をするのが通常です

「お客様が性能値が100以上の性能なら満足してくれるけど、この性能10%はバラつくから評価基準は110以上と設定しとこう」

みたいな考え方が必要です

これをせず、100以上で合格のところ102の結果出て「OK」 ⇒製造で不良率増、さらには市場で大トラブル(バラツキで100以下の性能になる場合は十分にありますから)

よくある話です

〇余裕度(マージン)を把握していない=規格が全て正しいわけではない

これは、合理化などの時の仕様変更時によくありますね

合理化のための新しい部品を使ったとき、規格内=合格 と簡単に判断し、不良を多発する経験ありませんか?

「評価OK やったのになぁ~」

これは、今までは、たまたま良かっただけってやつです

100±5が規格だったとしましょう

今までの部品は、実は100±2の実力がありました。これで製品の品質を保証できていた

新採用の部品は98±2の実力 

これって、いままでより性能変化していますね

「でも、規格内だから合格」

しかし、市場で不良多発、普通にやっちゃいます

こんな場合、「規格がええ加減で、たまたま部品の性能が良かったから品質を維持できていただけ」っていう状況です

ですので、このような変更をするときは、「規格内だからOK」ではなく「性能差で判断」する必要有ですね

あくまで論理的設計が品質保証の原則

評価で品質を保証する危険性を述べましたが、イメージだけでもつかんでもらえるとうれしいです

品質は論理的設計で保証し、試作品等の「評価で」性能が設計の狙い通りかを確認するのが「設計検証」

ただ、皆さんの中には

「すべての機能に関し論理的設計してたら、とんでもない時間と人が必要になるがな」

と思われる方もいるかもしれません

確かにその通りで、品質を安定させるためには新規設計をできるだけ減らして新商品を作る、

つまり新機能以外は従来の技術、構造=従来標準をそのまま使うのが有効です

しかしながら、やはり

長年、標準としていた設計・構造をデザインや合理化のために変更しなければならないこと、よくあります

できることなら、「標準」なんだから変えたくない、品質を安定させるなら「変えるべきではない「と言いたいのですが、

これ言ってると進化・革新ができません

やっぱりチャレンジ必要です

この時、重要なのは変化点/変更点管理です

変化点/変更を発生させる場合、その変化により発生するかもしれないリスクを全力で予測し、その対策を設計でおこないます

「このリスク対策は」

と聞いて

「評価OKでした」

って回答したら、即退場です

ありがちですの、皆さん注意しましょう~~

論理的設計の裏付けをベースに品質を保証することを最優先してください

【新商品開発にかかわる人たちへ】品質を確保するために設計者がするべきこと
品質を新商品開発段階で如何に保証するかで悩んでいる設計者は多いと思います。この記事では新商品開発段階で品質を保証するために設計者がするべき5つのポイントを述べたいと思います

設計検証の結果を受け

設計検証をするための評価結果を受け、設計者は結果を考察します

結果をバラツキを意識しながら考察し、問題が無ければ次ステップへ移行

もし問題があれば設計変更、もしくはバラツキを抑える生産技術開発が必要になります

対策について、設計・製造十分話し合いましょう(製造には調達含みます)

ここで、結果の考察の仕方の一つの考え方を示します

下のグラフを見てください

バラツキを正規分布で示しています

例1はバラツキは小さいが、平均値が下限値に近いためNGになった例

例2は平均値は規格の中心地に近いが、バラツキが大きいためNGになった例

このように、分布を取れるくらいサンプル数があればいいのですが、なかなかそうはいきません

しかし、NGの原因がどっちであるによって、対策がかわります

ですので、平均値か?  バラツキか? NGはどちらによって起きているのか見極める能力が必要です

例2のようにバラツキが原因にもかかわらず、平均値を上げる対策をすると、上限の規格を超える可能性があります

逆に、平均値が低いのにバラツキを抑える対策をすると、技術的に難しくなり、余計なコストをかける可能性があります

えてして、設計者はバラツキではなく平均値で対応しがちですけどね

●平均値を変えて対応する考え方

平均値が低い場合は、性能が不足していることになります

下図は「入力=INPUT」と「性能=OUTPUT」の関係を示したグラフです

何らかの性能を持っているもの(機械をイメージするとわかりやすです)はインプットに対してどれだけアウトプットとするかで性能が決まります

下図はわかりやすくするために一次直線で表しています(こんな簡単なシステムはなかなかいですけど)

設計検証の結果、平均値が低いために起こるNG~性能不足は〇で囲んだ部分にあたります

これを保証すべき性能を満足するためには、大きく3つ方法があります

 1.効率を上げる

 2.入力を上げる

 3.設計パラメーターを変える

1.効率を上げて性能を上げる方法がベストですが、設計検証後では技術的難易度が上がるので少々骨が折れます

開発初期段階で見極めたいですね

2.入力を上げて出力の性能を上げる方法は効率を上げるよりは難易度下がりますが、これは各機能要素に負荷がかかりますので、耐久性等に問題が発生しやすいので注意しましょう

3.設計のパラメータを変更(チューニング)して最適化にむけ調整する方法です

下図の場合、入力値を超えたところの性能を落とす代わりに、入力規格値での性能を上がるように調整した事例です

以上、性能向上を考える場合の基本的な概念として理解してください

●平均値は規格の中心地に近いが、バラツキが大きいためNGになった場合

バラツキ改善は製造と連携して進めますが、ツイツイ設計者は平均値を変えることを優先します

しかしながら、バラツキは工程の慢性不良につながります

量産始めてから、バラツキを抑さえるのは非常にロスを生みます

設計段階でいかに抑えるか考えましょう

特に設計者に気を付けてほしいのは、 部品の性能バラツキです

寸法や性能の公差をいい加減に決めてしまうと、商品として許容できないバラツキになってします

ただ、必要以上に公差を厳しくするとコストが上がります

ここが設計者のスキルになります

必要ならば、生産技術も交えて対策を事前に検討しましょう

工程品質を改善するために「慢性不良」と「突発不良」では異なるアプローチが必要
「工程不良が減らない」と悩んでいる工場責任者の方は多いのではないでしょうか そのアプローチはいろんな考え方がありますが、今回は「慢性不良」「突発不良」に分けた改善活動について考えてみます

まとめ

「設計検証」に関する私が感じていることを書いてきました

要は「評価OKだから問題なし」

これ、絶対ダメ 忘れないでください

設計の意図通りモノができているか

バラツキ含めて問題ないのか

しっかり考察して、次ステップに進みましょう

もし、設計検証でNGになった場合、原因がバラツキによるものか、性能が不十分か見極めて対策を考えてください

コメント

タイトルとURLをコピーしました