icon-sns-youtube icon-sns-facebook icon-sns-twitter icon-sns-instagram icon-sns-line icon-sns-tiktok icon-sns-etc
SEARCH

機械設計 連載「B to B向け機械設計のポイント」

2026.05.25

第8回 QCD(品質/コスト/納期)の設計検証のポイント

  • facebook
  • twitter
  • LINE

技術力向上カウンセリングオフィス 布施 裕児

ふせ ゆうじ:代表 1989 年4 月、旭硝子(現・AGC)入社、パソコン用ハードディスク向けガラス基板の加工技術開発、営業などに従事した後、液晶用のガラスを扱う事業部に異動となり、液晶用ガラスの梱包容器/梱包材料の設計開発を17 年以上担当。途中、1 年半ほど知財部兼務となり、特許戦略構築、出願推進活動も経験。2023 年4 月、同社を早期退職。現在は中小企業の技術支援や組織改革支援、セミナー講師として活動中。(一社)製造業総合支援 副代表。資格:上級心理カウンセラー[(一社)日本能力開発推進協会]。

はじめに 

 図1にQCD(品質/コスト/納期)の設計検証のイメージ図を示す。今まで紹介したように、顧客の要求事項を正しく把握し、基本設計/基礎開発の段階からQCDのおのおのの目標値をしっかり立ててレビューしていくことが大切である。今回は、その仕上げである図1 の「5. 量産検証」、つまり、試作活動を通して専門の部署によりQCDの検証を進めていくうえで大切なことを紹介していく。
図1 QCD(品質/コスト/納期)の設計検証のイメージ図

図1 QCD(品質/コスト/納期)の設計検証のイメージ図

現実的な対応と総合力の重要性

 1.QCDの優先順位 
 まず大切なのは「QCDの優先順位は合意が得られているか?」ということである。部署によってQCDの優先順位が違うことも多く、紛糾することが多い。開発目標を変更せずとも、場面場面に応じて、優先順位を変えざるを得ない場合は多々発生する。代表的なところでは、試作品において品質的には不十分であるが納期を優先させざるを得ないような場合である。

 2.設計開発の見極め 
 一方、QCDで定めた目標値の達成が難しくなった場合は、新しい考えを導入していく必要がある。その際、商品の設計開発だけで目標が達成できないことは往々にしてある。一般に品質とコストと納期は連動しており、トレードオフの関係になることが多い。それを解決していくのが設計開発を進めることとも言えるが、商品の仕様に限定して考えれば、打てる手は限られてくる。関係者の合意のうえでの話になるが、特にコストなどは設計開発以外の総合的な観点で対策を検討していく必要がある。 

 大切なのは、目の前の現実にどう対応するかであり、どこかに負担をかけるのは不毛な議論になる。商品設計を極めるのは無論大切である。商品設計の良し悪しが量産性に大きく影響するのは至極当然である。しかし、設計にできることは時間や能力なども含めて限界はある。総合的な観点で対応していくこともやはり大切である。

 3.無駄な紛糾を防ぐリスクマネジメント 
 しかし、どう頑張っても開発目標を変更せざるを得ない場合も残念ながら発生する。時間がネックなのであれば量産後、継続改善となることが多い。ただし、時間をかけても改善が見込めない場合、開発を中止するか、目標を見直して継続するかの選択になる。 

 通常は品質第一とも言われるが、顧客に評価いただいている状態であり、折衝も可能性がゼロではない。コストも無論大切であるが、欲を言えば切りがないことは皆知っている。 
 
 しかしながら、量産検証が進めば品質の検証も進んでいくが、「なぜこんなにコストがかかるのか」、「納期がかかるのか」と後でもめるような無駄な紛糾は避けるべきである。 

 そのため、QCDの案件は特にトップ層への情報の共有、相談が大切になる。いったんもめると単なる状況説明も言い訳のように聞こえてしまう。「後でもめそうなことは先にもめておく」の考えがやはり大切である。

品質(Q)の検証

 1.量産検証での品質不具合の原因追究の難しさ 
 第6 回「デザインレビューで大切なポイント」で紹介したが、品質の不具合が発生した場合、その真の原因についてデータをベースに定量的に議論することが大切である。その際に、原理原則と現実/データの間を帰納的な考え、演繹的な考えから仮説を統合して考えることが大切だとも紹介した(図2参照)。
図2 品質不具合の原因追究

図2 品質不具合の原因追究

 しかし、新商品の量産検証で発生する品質不具合は、それまで経験したことのない不具合であることが多い。また、データも十分ではない。工程Aで発生した不具合であっても、ほかの工程で検証していないので、工程の違いかどうかもわからない。そもそも測定していないデータは土俵にすら上がらない。 

 また、これは量産品の品質クレームにも当てはまるが、早期解決が求められる。

 2.関係者とのブレストで原因追究 
 そもそもデータが少ないため帰納的な考えよりも、演繹的な考えから原因を追究する必要がある。そのためには関係者でブレインストーミング(ブレスト)を行い、仮説を立てて、検証していくことが大切である。 

 NG 品の観察結果、発生工程の観察結果から「原因はこれだ!」といった仮説を立てるのであるが、特性要因やオペレーションから考えるとデータが不足している中ではあまり意味をなさない。 

 その際は、やはり、複数人でブレストを行うのが良い。想定範囲から論理的に原因を絞り込んでいくことになるので、一人よりも、複数で議論した方が想定範囲を広くとれる。また、ブレストした結果、具体的に再現実験や強調試験対策へとつなげていくためにも、関係者に参加してもらった方が次のアクションにつなげやすいといったメリットもある。品質不具合の原因追究のブレストのイメージを図3に示す。
図3 品質不具合原因追究ブレストのイメージ

図3 品質不具合原因追究ブレストのイメージ

 「原因を追究するのでブレストというよりは議論ではないか?」と思われるかもしれないが、筆者は批判禁止のブレストの考えは仮説を立てるうえでも大切だと考えている。批判どころか、直感や思い付きも大歓迎、人の仮説に賛成する立場で原因までの道筋を一緒に考えることが大切である。直観や思い付きがピント外れであれば通常、発言者が発言を撤回するし、仮説に無理があれば自然と淘汰される。 

 仮説なので1 つに絞る必要はないが、現実に検証するには限度がある。自然に淘汰され現実的なところで落ち着けばよいが、そうもいかない場合は、最終的には参加者の投票で絞るしかない。その際、単に挙手で決めるよりも参加者にベスト3を考えてもらって、1位は5点、2位は3点、3位は1 点などとして、総合点で決めることをお勧めする。開発者は特に重み付けをしてもおもしろい。個人の思いが反映されやすく、差もつきやすいので、結果に対する納得感が得られやすいと筆者は感じている。
26 件
〈 1 / 2 〉

関連記事