設計システム:攻めの設計品質改善を前提とした場合

更新日

投稿日

 攻めの設計品質改善を前提とした設計システムとはどのようなものでしょうか。今回は、攻めの設計システムについて解説します。
 

1. 設計品質:想定外のトラブル発生

 
 想定外の市場トラブルはなぜ発生するのでしょうか。従来、日本の品質管理の考え方は、小さなカイゼンを繰り返すボトムアップ活動で優れた製品を生み出して顧客満足を得てきました。その製造工程のカイゼンと同様に、設計工程においても、問題が発生すると小カイゼンを繰り返し、不良を外に流出させないという流出防止の考え方が基本になっています。
   
 この品質管理の手法は、発生した不具合に対する原因追求・対策型であり、また、あらかじめ設定した社内基準を合格すれば良しとする検査型、認定型の手法であるため、工程で顕在化しない不具合は抽出することが困難となっています。
 

◆ 認定(Validation)から査定(assessment)へ

 
 そこで設計のやり方の発想を転換し、評価や検査での認定(Validation)ではなく査定(assessment)の考え方に切り替え、設計開発のスピードアップと市場での想定外のトラブルの未然防止を図って行くことが求められるようになってきました。
 
 査定(アセスメント)とは、実際の製品を対象とした評価結果、検査結果などの証拠に基づく合否判定を行うのではなく、製品を作る前の設計段階で、対象の実力や価値を見極め、影響を定量化しようとするもので、この事により漏れなく不具合を洗い出すことが可能となり設計開発のスピードアップと、市場における想定外の重大事故の発生を防ぐことが可能なります。
 
 市場の不具合を予測し、あらゆる条件を短期間で確認する効率的、効果的な手段を用いて未然防止を行う方法論を採用しなければなりませんが、そこには多くの誤解を生んでいるのも事実です。
 
 未然防止策とは、再発防止策と考え方が全く異なります。不具合事象から原因を追究して上流工程へフィードバックしていく方法は、次の新しい製品で似たような不具合を防ぐことは可能です。しかし全く経験のない未知の不具合は対応できません。
 
 未知の不具合を見つけ、対策するには、設計システム全体および設計者自身も原因追求型の「守り」の設計品質改善から未然防止型の「攻め」の設計品質改善の考え方へ発想の転換が求められています。
 

2. 攻めの設計システムとは

 
 攻めの設計システム査定(assessment)の考え方に基づく設計システムの例を下図に示します。
 
 技術マネジメント
 
 守りの設計システム比較すると、左側の「インプット」⇒「設計の管理」⇒「アウトプット」の設計プロセスは大きく変わりませんが、右側の設計技術は新たにアセスメントの考え方を基本とする固有技術、汎用技術を導入し、設計の上流工程で未然防止の対策を講じ、実機による評価テストによるフィードバックを極力なくすようにします。
 
 自動車産業向け品質マネジメントシステム規格であるIATF16949(ISO/TS16949)では、不具合発生前にリスクを削減、低減させるため、潜在的故障モードの想定妥当性確認などを実施し、市場クレームなどを減少させていく仕組みの構築を求めています。これは、自動車のみならず、あらゆる製品の設計に共通した課題であると考えられます。
 
 設計品質作り込みのための重要なポイントは以下の5項目であり低価格で、タイムリーに顧客の要求に応える付加価値の高い設計の製品をアウトプットすることにあります。
 
 ① 顧客...
 攻めの設計品質改善を前提とした設計システムとはどのようなものでしょうか。今回は、攻めの設計システムについて解説します。
 

1. 設計品質:想定外のトラブル発生

 
 想定外の市場トラブルはなぜ発生するのでしょうか。従来、日本の品質管理の考え方は、小さなカイゼンを繰り返すボトムアップ活動で優れた製品を生み出して顧客満足を得てきました。その製造工程のカイゼンと同様に、設計工程においても、問題が発生すると小カイゼンを繰り返し、不良を外に流出させないという流出防止の考え方が基本になっています。
   
 この品質管理の手法は、発生した不具合に対する原因追求・対策型であり、また、あらかじめ設定した社内基準を合格すれば良しとする検査型、認定型の手法であるため、工程で顕在化しない不具合は抽出することが困難となっています。
 

◆ 認定(Validation)から査定(assessment)へ

 
 そこで設計のやり方の発想を転換し、評価や検査での認定(Validation)ではなく査定(assessment)の考え方に切り替え、設計開発のスピードアップと市場での想定外のトラブルの未然防止を図って行くことが求められるようになってきました。
 
 査定(アセスメント)とは、実際の製品を対象とした評価結果、検査結果などの証拠に基づく合否判定を行うのではなく、製品を作る前の設計段階で、対象の実力や価値を見極め、影響を定量化しようとするもので、この事により漏れなく不具合を洗い出すことが可能となり設計開発のスピードアップと、市場における想定外の重大事故の発生を防ぐことが可能なります。
 
 市場の不具合を予測し、あらゆる条件を短期間で確認する効率的、効果的な手段を用いて未然防止を行う方法論を採用しなければなりませんが、そこには多くの誤解を生んでいるのも事実です。
 
 未然防止策とは、再発防止策と考え方が全く異なります。不具合事象から原因を追究して上流工程へフィードバックしていく方法は、次の新しい製品で似たような不具合を防ぐことは可能です。しかし全く経験のない未知の不具合は対応できません。
 
 未知の不具合を見つけ、対策するには、設計システム全体および設計者自身も原因追求型の「守り」の設計品質改善から未然防止型の「攻め」の設計品質改善の考え方へ発想の転換が求められています。
 

2. 攻めの設計システムとは

 
 攻めの設計システム査定(assessment)の考え方に基づく設計システムの例を下図に示します。
 
 技術マネジメント
 
 守りの設計システム比較すると、左側の「インプット」⇒「設計の管理」⇒「アウトプット」の設計プロセスは大きく変わりませんが、右側の設計技術は新たにアセスメントの考え方を基本とする固有技術、汎用技術を導入し、設計の上流工程で未然防止の対策を講じ、実機による評価テストによるフィードバックを極力なくすようにします。
 
 自動車産業向け品質マネジメントシステム規格であるIATF16949(ISO/TS16949)では、不具合発生前にリスクを削減、低減させるため、潜在的故障モードの想定妥当性確認などを実施し、市場クレームなどを減少させていく仕組みの構築を求めています。これは、自動車のみならず、あらゆる製品の設計に共通した課題であると考えられます。
 
 設計品質作り込みのための重要なポイントは以下の5項目であり低価格で、タイムリーに顧客の要求に応える付加価値の高い設計の製品をアウトプットすることにあります。
 
 ① 顧客の要求事項を確実に設計にインプットさせる
 ② 市場あるいは顧客の暗黙の要求事項、法的な制約を確実に設計にインプットさせる
 ③ 顧客のあらゆる使用環境を考慮した製品をアウトプットする
 ④ 顧客のあらゆる使用方法を考慮した設計の製品をアウトプットする
 ⑤ 部品ばらつき、製造ばらつきを考慮し、製造しやすい設計結果をアウトプットする
 
 市場トラブル未然防止のためには、従来から採用されている原因究明・対策型認定(validation)に基づく設計システムそのものを根本から見直し、査定(assessment)の考え方に基づく設計システムを構築していくことが求められています。

   続きを読むには・・・


この記事の著者

濱田 金男

製造業に従事して50年、新製品開発設計から製造技術、品質管理、海外生産まで、あらゆる業務に従事した経験を基に、現場目線で業務改革・経営改革・意識改革支援に取り組んでいます。

製造業に従事して50年、新製品開発設計から製造技術、品質管理、海外生産まで、あらゆる業務に従事した経験を基に、現場目線で業務改革・経営改革・意識改革支援に...


「技術マネジメント総合」の他のキーワード解説記事

もっと見る
類似-2 普通の組織をイノベーティブにする処方箋 (その101)

   現在、KETICモデルの中の「知識・経験を関係性で整理する」について解説していますが今回は、前回に引き続き「類似」について考えてみた...

   現在、KETICモデルの中の「知識・経験を関係性で整理する」について解説していますが今回は、前回に引き続き「類似」について考えてみた...


新しい挑戦はハードルを下げる 新規事業・新商品を生み出す技術戦略(その68)

1、モチベーションを失うケース  先日、開発リーダーをされている方からこんな相談を受けました。「自由な発想で新規事業の開発をしてくれ!というオーダー...

1、モチベーションを失うケース  先日、開発リーダーをされている方からこんな相談を受けました。「自由な発想で新規事業の開発をしてくれ!というオーダー...


普通の組織をイノベーティブにする処方箋 (その171) 動物を深く知る

  【目次】   【この連載の前回:普通の組織をイノベーティブにする処方箋 (その170)へのリンク】 これまでアナロ...

  【目次】   【この連載の前回:普通の組織をイノベーティブにする処方箋 (その170)へのリンク】 これまでアナロ...


「技術マネジメント総合」の活用事例

もっと見る
ソフトウェア開発スケジュールと結合テスト プロジェクト管理の仕組み (その7)

 前回のその6:進捗管理可能なソフト開発計画に続いて解説します。    ソフトウェア開発スケジュールでは次のような問題を抱えています。 &...

 前回のその6:進捗管理可能なソフト開発計画に続いて解説します。    ソフトウェア開発スケジュールでは次のような問題を抱えています。 &...


製品開発部へのカンバン導入記(その3)

        前回からの続きです。前回ではまず製品開発工程の価値(物と情報)の流れ図を作り、工程上の問題点...

        前回からの続きです。前回ではまず製品開発工程の価値(物と情報)の流れ図を作り、工程上の問題点...


設計部門とリスク管理(その3)

【設計部門とリスク管理 連載目次】 1. リスク管理とは目標達成までのシナリオ作成 2. コンティンジェンシープランの注意事項 3. リスク管理...

【設計部門とリスク管理 連載目次】 1. リスク管理とは目標達成までのシナリオ作成 2. コンティンジェンシープランの注意事項 3. リスク管理...