2015/11/23

信頼性試験は万全の方法か(4)

 さいごは「時間の壁」。信頼性試験のなかには、数千時間の試験時間が必要なものが多い。信頼性試験では使用段階の実時間(たとえば10年=87660時間)を「加速」という考え方を使って、数百~数千時間に短縮しているにも関わらずだ。

 そもそもなぜこんなに長い試験時間を必要とするのだろうか。「数の壁」のところでも述べたが、信頼性試験では寿命や故障(率)を対象にする。つまり品質を定量化するためには、寿命が来るまで、つまり故障するまでの試験が必要なのだ。ある購入電子部品では、従来は10,000時間以上の試験を実施していた。時間がかかっても合格すれば次のステップに進めて報われるが、試験の結果不合格になるとどうだろうか。もう一度部品の選定をやりなおしたり、設計を変更したりして、また長時間の試験を実施する必要がある。

 設計変更や修正を速く行って、短時間に品質を確保したい設計・開発の現場にとっては、このような時間のかかる試験を設計・開発段階で繰り返し実施することはできない。したがって、ここでも何か工夫をして、短い試験時間で品質をチェックする方法が必要となるわけだ。

 まとめると、開発・設計の初期段階で用いる品質チェックの方法として、信頼性試験に代わる、「使用段階の条件を模擬した複雑な条件で」「少ないサンプルで」「短時間で」実施できるような新しい品質のチェック方法が求められている、ということが理解できたかと思う。この方法論については、また別の記事で詳しくひも解いていきます。


株式会社ジェダイト(JADEITE:JApan Data Engineering InstituTE)

信頼性試験は万全の方法か(3)

 つづいて「数の壁」。信頼性試験ではたとえば、90%のサンプルが故障せずに生き残る年数を寿命としたり、逆に何時間と試験時間を設定して故障率を求める。それらが、あらかじめ設定した寿命や故障率の基準を満足しているかどうかを調べるのだ。

 信頼性工学は、非常に統計学と関係の深い学問で、そのなかの信頼性試験のやり方の設計や、信頼性の判定には統計を活用する。前記の「90%のサンプルが故障せずに」というためには、割合が求まるだけのサンプルの個数が必要だ。

 たとえば100個中90個ということだ。また「試験○時間後の故障率が0.1%以下」というような基準の場合は、故障率が求まるようなサンプルの個数が必要となる。100個では0.1%以下の判定はできない。詳しい話は省くが、仮に90%の正しさで(これを信頼度90%、あるいは危険率10%という)故障率0.1%以下を主張するためには、2300個のサンプルを試験する必要がある。ほとんどの製品では、設計・開発段階でこれだけのサンプルを準備することはできない。できたとしても試作や計測のコストや手間がかかりすぎて現実的ではない。

 統計に頼ることと、ある基準に合格したかどうかという判定方法(0・1判定)では、サンプル数という点で課題がある。したがって、設計・開発の初期段階というサンプル数があまり準備できない状態では、何か工夫をして少ないサンプル数で品質をチェックする方法が必要となる。


株式会社ジェダイト(JADEITE:JApan Data Engineering InstituTE)

信頼性試験は万全の方法か(2)

 まず「複雑さの壁」だ。信頼性試験というと、一般には使用段階の環境を模擬していると思われがちだが、そうではない。信頼性試験は、ほとんどが単一の要因に対する試験なのである。

 たとえば、高温放置試験、ヒートサイクル(温度の上げ下げ)試験、振動試験、…といったように、単一の要因について合格の基準値(例:80℃環境で1000時間放置したあと正常に動作すること)に対する合否を判断する。

 ところが、実際に製品を使用するときを考えてみよう。たとえば講演でレーザポインタを使っている。室内で使用していても、夏場と冬場では環境温度は異なる。また手のひらからの熱や塩分を含んだ水分などが伝わっている(高温、高湿、腐食性イオン)。ボタンを繰り返し押している(繰り返し応力、摩耗)。講演の調子があがってきて、ポインタを振り回しはじめた(加速度、振動)。誤って落としてしまうかもしれない(衝撃)。

 このような一見、室内のマイルドな環境での使用でも、「さまざまな種類のストレス要因が」「同時に」「繰り返し・継続的に」(これらをまとめて「複合的に」という)製品に、加わるので、製品の身になればたまったものではない。自動車だともっと厳しい環境だ。人工衛星の使用環境になると想像もできない(笑)。

 つまり製品の使用段階では、信頼性試験で行っているような単一の要因だけでの使い方というのはあり得ないのだ。信頼性試験の条件において、使用段階という非常に複雑な環境や使用条件が模擬できていないのである。

 信頼性試験で合格して、出荷前の検査も合格したはずのピカピカの製品が、期待に反して短い使用期間で故障したり性能が低下したりすることがある。信頼性試験の条件と使用段階の環境や使用条件が異なるわけなので、出荷前には思ってもいなかった(でもよく考えればあり得る)ような「複合的な」条件で、試験では見つからなかった不具合が発生するのだ。

 したがって、製品の使用段階での品質を確保するためには、使用段階の条件に合うような複雑な条件で製品の品質の「実力」を調べる必要があることがわかる。


株式会社ジェダイト(JADEITE:JApan Data Engineering InstituTE)

信頼性試験は万全の方法か(1)

 製品や購入部品の品質が確保されているかどうかを確かめたり調べたりするために、製品開発の途中の段階で――製品なら開発終盤の試作段階で、購入部品ならそれを選定する段階で――信頼性試験を行っている。

 信頼性試験にはいろんな種類や目的があるが、ここでは寿命試験や耐久試験ともいうような、製品や部品の寿命や故障率を調べるような試験について考える。

 製品開発を行う際には、通常、製品企画段階で定められられた「設計すべき品質」において、製品出荷後の品質レベル(寿命○年、市場故障率○%)が示される。製品を設計、試作後にその品質レベルに適合(合格)しているかどうかを信頼性試験で調べる。合格すれば晴れて、「この“設計した品質”で問題ない」となり、量産・出荷に移行するわけだ。
 
 なお、注意してほしいのは、製品には製造のできばえの品質もありますので、信頼性試験に適合した設計であっても、製造のできばえが悪いと製品として不適合(不合格)になってしまいうので、正しい設計図面どおりの製品が作られているかどうかは、製造工程内や製品出荷前の「検査」で調べるのだ。

 信頼性設計は「設計した品質(設計のできばえの品質)」のチェック、製造工程での検査は「製造のできばえの品質」をチェックしていることを押えておこう。

 さてこのように、設計で品質が確保できているかどうかのチェックは従来信頼性試験をおこなってきたわけだが、これが最良の方法なのだろうか。以下に、信頼性試験における課題を3つの視点で示す。

(1)複雑さの壁(品質に関係)
(2)数の壁(コストに関係)
(3)時間の壁(納期に関係)

これらについて以降の記事で解説する。


株式会社ジェダイト(JADEITE:JApan Data Engineering InstituTE)

開発の後期になるほど高くつく対策コスト

 製品が出荷された後の使用段階での不具合やクレームの主要因は、お客様のほしい機能や、使用段階での使い方、環境条件を考えるべき設計・開発段階にある。設計・開発段階での検討もれや考え方の修正はどの段階で行えばよいのだろうか。

 ある調査では、設計・開発段階で不具合が発覚した場合の対策コストを1とすると、生産開始前でその10倍、製品出荷前で500倍、市場出荷後では実に10,000倍もの修正コストがかかることが示されている。この例では設計・開発段階に間違いと気づいた場合の修正コストは$20なっており、図面の訂正にかかる時間の人件費相当(下名推定)と計算されている。これが市場出荷後の不具合発覚となると、発生コストは$1,000,000すなわち1億円レベルと試算されている。

 つまり、設計・開発段階での見落としや間違いが市場出荷後まで見つからず、お客様の使用段階で発生してしまった場合、多くの場合製品全数への対応(交換、修理、保証など)になるため、膨大な対策費用が必要となるのだ。人命が係わるような製品や、社会システムなどでは、社会に与える損失の大きさを考えると、さらに対策コスト大きくなることは明白である。

 この分析からも分かるように、不具合の発覚が後になるほど対策コストは文字通り指数的に大きくなっていくので、品質への対応はできるだけ早い段階、できれば設計・開発の初期段階で行っておきたいわけだ。

 技術者は優秀なので、見落としや間違いが分かりさえすれば、すぐにその対策を考えて、設計変更する、方式を変えるなどの対策を打てることが多い。なので、大事なことはいかに設計・開発の初期段階で、品質を「見える化」するかではないかと考える。

 以降の記事では引き続き、見える化について考える。


株式会社ジェダイト(JADEITE:JApan Data Engineering InstituTE)

秋のワインメニュー(3)

はい。この時期お約束のボジョレー・ヌーボーですね。試飲したもののなかで、もっともフルーティなのを選びました。この瓶、ペットボトルです。すぐ飲むのでまあいいかと。

手前は、ポークのプラムソースがけで、甘いソースがフルーティなボジョレーに合います。

その奥の右は、砂肝のアヒージョ。キノコやジャガイモにもにんにくとアンチョビがしゅんでいて、うまいです。

その奥左は、生のカリフラワーのサラダ。しゃきしゃきで癖もないので大量に食べられ、ビタミンも豊富です。

風邪やインフルが流行りだしていますので、しっかり食べて体も冷やさないようにしましょう。



秋のワインメニュー(2)

こちらはカモの新メニュー。コンソメで煮た大根にたっぷりのカモローストのせ。味は意外に、大根おろしとねぎとポン酢で和風です。
うしろは既成の加にクリームパスタと、娘の大好きな生春巻き。
カモにはやはり赤が合う。クーボ・セレクシオン2011というスパニッシュワイン。


秋のワインメニュー(1)

北海道は美瑛産のでっかいユリ根を使って、ほくほくのグラタンを。
また、カモが夫婦とも大好きなので(しかもグラム300円台と結構リーズナブルなので)ローストにして再登場。右下はタコとセロリ、じゃがいもの定番マリネサラダ。
赤ワインはソテロ・デ・ブーリャス2009というスパニッシュワイン。セットものの1本。




2015/11/15

京都品質工学研究会で講演ほか

11/13(金)は、京都品質工学研究会にご招待いただき、2時間半の講演をさせていただきました。

前半は品質工学(とくに機能性評価)を開発設計の上流で取り入れて、製品使用段階での品質を早期・短時間に見える化する取り組みをお話ししました。後半は、ノイズ因子や設計リスクのシステマチックな抽出方法である、XCN(クロスチェック付きなぜなぜ分析)の概要をご紹介しました。

非常に活発にご質問いただき、大変関心が高かったという印象です。

とくに、「いままで聞いた品質工学の話のなかで、一番役に立った」とのご感想もいただき、品質工学活用のすそ野が少しでも広がったことが収穫でした。品質工学で設計や開発のコンサルをやっているものとしては、冥利に尽きますね。

その後は、G社のIさんと飲みに行き、京都の夜を満喫しました。

先週は月、火曜も関西の某大手電気機器メーカにて2日間の、品質工学実践講座の社内研修を実施させていただき、こちらも良い経験になりました。参加者全員の方が、職場に帰られてからの「次のアクション」を明確にされて修了したことが、なによりでした。


株式会社ジェダイト(JADEITE:JApan Data Engineering InstituTE)

2015/11/03

【今日の言葉130】

そもそも誰もが同意し、反論の価値がないような主張をしたところで、自分の存在意義をだせないのではないか。
((株)プレミアム・インベストメント&パートナーズ代表 午堂登紀雄氏)

さらに、「読者に論争を巻き起こし、考え、行動してもらうきっかけを」作るべきとしている。

来年はそのような、きっかけを発信できるかもしれません。


2015/11/01

現場や実務者の立場を徹底した、品質工学のようなもの

忙しさにかまけていたわけではないが、10月のブログ更新はゼロであった。
会社の業務(含むあちこちに出張)以外にも講演や執筆、休日はアウトドアにとあわただしく、充実して過ごせているのではあるが・・・

さて、以下は最近品質工学について考えていることである。つまりトップランナーを対象にするのではなく、以下にマスを底上げするのかという現実的な議論である。

パレートの法則によれば、本やセミナーや社内教育などで品質工学に出会った人の中で、それを理解して「いいね」とアンテナが立つ人が2割とする。その中の2割が実際に行動を起こす。その中のさらに2割が品質工学でなんらかの成果をもたらすと考えると、成功するのは品質工学に何らかの形で触れた人の0.8%という狭き門である。残り99.2%の人には品質工学は不要な考え方なのだろうか。一部の高度な技術力、有能な技術者(研究者)、リソースが潤沢にある開発組織だけのものなのだろうか。

品質工学は故田口玄一氏が半世紀を費やしてほぼ独力で創造した、技術論・方法論の結晶である。これを一部の技術者、組織だけのものとするのは余りにもったいない。より多くの方が、より広い範囲で品質工学を設計・開発の現場では使い、成果を出せないものだろうか。社内の指導・推進者やコンサルタントはここをよく考えたい。

そこでいわゆる学会的な理想論・原則論の立場だけではなく、現場や実務者の立場を徹底した考え方が提供できなかと思い、これまでもその立ち位置で研究や講演・セミナーを提供してきたつもりである。つまり、実際に実行に移し、成果を出すための実務者のためのアウトプットである。それゆえ意図的に「タグチイズム」から逸脱せざるをえない場面もある。下名の思いは歩留り2割の部分を少なくとも8割にすることにある。

来年のQESのころまでには1つの解をまとめたいと考えている。


株式会社ジェダイト(JADEITE:JApan Data Engineering InstituTE)