構造化知識研究所ホームへ

会社概要

パートナー

用語集

お気軽にお問い合わせください。

お問い合わせフォームはこちら

A Leading Provider of Structured Knowledge Management

構造化知識研究所とは
SSMとは
サービス内容
ソフトウェア
未然防止の部屋
ダウンロード

Now Here!
HOME

未然防止の部屋

設計プロセスとデザインレビュー



設計プロセスとデザインレビュー


デザインレビュー(DR)の基本ならびに設計開発プロセス全体から見たデザインレビューの位置づけについて解説します。また設計の妥当性確認との関係について補足します。

デザインレビューとは
設計開発の各段階の具体的なDR
DRと設計検証/設計の妥当性確認の関係
おわりに/参考・引用文献



デザインレビューとは




デザインレビュー(Design Review、以後DR)とは、製品ならびにその生産から廃棄に至るライフサイクルの設計計画のアウトプットとその導出プロセスに対して、機能、性能、安全性、信頼性、操作性、デザイン、生産性、保全性、廃棄性、コスト、法令・規制、納期などの顧客要求や設計開発目標に関わるすべての品質特性の見地から、妥当性の評価ならびに問題点の摘出を行い、次の設計開発のステップへ移行できるかどうかを判断する組織的活動です。
DRは、設計審査というニュアンスだけでなく、組織全体で設計計画の質を高めるための活動として広く認識されています。DRの“デザイン”とは、狭義の製品設計ではなく、商品企画から製品設計を経て生産準備、販売サービスに至る各段階の計画内容のアウトプットと、それを導出する業務プロセスを指します。一方“レビュー”は、審査、再検討、振り返りを行なうという意味をもちます。
DRは、ひとによって様々な解釈がされていますが、主に以下のような種類が挙げられます。

タイプ1:発注者から受ける審査
タイプ2:開発プロセスの移行審査、承認
タイプ3:計画の評価、問題点抽出の組織的活動
タイプ4:主に部内で非公式に行なわれる技術的検討

タイプ1は、製品やシステムの発注者が発注仕様書をもとに製品設計や開発段階の問題点とその対策を確認する会議[1]であり、製品やシステムの受注者が主催します。このタイプのDRは、古くから米国において航空機、宇宙、兵器システムのような複合度の高いシステムの発注者が受注者に義務付けて行なわれており、日本においても自動車部品の受発注などの垂直的な契約関係においてしばしば適用されています。

タイプ2は、商品企画、製品企画、製品設計、生産準備などの各設計開発段階の最終時点で、その段階で行なわれた計画業務が開発目的に適合していることを確認、承認し、次の段階に移行することを決定する会議です。営業、設計、生産技術、品質保証、購買、製造などその製品のライフサイクルに関わる全ての部署が参画し、機能、性能、コスト、法令・規制などの要求仕様を満たし、信頼性、安全性などの様々な問題点に対する予防処置が適切に実施されていることを確認します。このDRは開発管理において重要なマイルストーンになる会議であり、会議の目的上、審査のニュアンスが強いものです。

タイプ3は、商品企画、設計から生産、保守・サービスに至るまでの各設計開発段階の途中において、区切りのよいタイミングで専門家を集め、各段階の設計計画内容の問題点の摘出と対策可否検討を行なう会議です。このDRでは、審査色の強いタイプ2のDRと異なり、品質、安全性、操作性、コストなど、それぞれの領域の専門家ならびに組織全体のノウハウを活用して徹底的に問題点の洗い出しを行います。したがって設計計画のアウトプットの質をつくりこむことに大変重要な役割を果たすDRです。また、このDRでは、設計計画のアウトプットの導出過程(例えば、設計計算の進め方や試験計画立案方法など)についても、問題点や抜けがないかどうかチェックします。なおタイプ3のDRは、フォーマルデザインレビュー(FDR)[2]と呼ばれることもあります。

タイプ4は、主に設計開発の業務担当者が所属する部内で、都度非公式に開催される技術検討会です。このDRは、他のDRと異なり開発計画において公式に準備されることはなく、必要に応じて少人数の関係者で適宜開催されます。またタイプ3のように専門家を正式に招集するものでありませんが、業務担当者が、自発的に部課内の有識者を集めて、設計計画の進捗に応じて適時助言をもらう会議で、早期に問題点を摘出し対策を打つために必要不可欠な小集団活動です。このタイプは、正式にDRと呼ぶものではないかもしれませんが、インフォーマルデザインレビュー(IDR)[2]と呼ばれることもあります。



設計開発の各段階の具体的なDR




設計トラブルが発生すると、その原因として、しばしば設計管理、特にDRの進め方のまずさが指摘されます。しかし実際にはDRの質の問題ではなく、DR以前の設計計画の進め方に致命的な原因、反省点があるものも少なくありません。たとえ優れたDR運営ができていてもDRへのインプットがひどければ、DRでの改善にも限界があります。したがってDRで討議する内容・範囲と、DRでは深い討議はせず詳細は設計者自身が責任をもって細かくセルフレビューしておく内容を分け、設計者自らがメリハリをつけてデザインレビューに臨むことが重要です。
ここでは、量産品の設計開発を仮定し、図1に例示する設計開発フローの概略ならびにDRに沿って、設計計画でやるべきこととDRで実施すべきことの要点を述べます。なお、図1のフローは、詳細をかなり割愛した簡略的なものであり、また一品物の開発やアプリケーションソフトの開発では色々と異なる部分もあるが、厳密な部分は、紙面の都合で割愛させて頂くことをご容赦ください。また各フロー内のDRは、開発製品の新規性や重要度の大きさによって、選択的に実施されることもご留意ください。

図1 開発フロー例
図1 開発フロー例

(1)商品企画
新製品開発は、全く新しい技術開発もあれば、従来製品やそれに実装している技術を応用した流用開発まで多種多様です。いずれにしても商品企画では、その新規性の程度に応じて、顧客の明示的、暗黙的なニーズを踏まえて顧客の要求事項(品質、価格、納期など)や関連法令・規制などを整理し、他社比較によるセールスポイントを明確にしなければなりません。自社生産・外注の大まかな方針や販売ルートの確保も必要です。また新規性が高いものほど先行的に技術開発を行い、要求仕様を具現化する能力を確保しておくことが重要です。
商品企画DRでは、これらの企画検討案を踏まえ、経営的に製品開発に移行してよいかどうかを判断します。また顧客ヒアリングや市場調査に対して適切な分析がなされ、その結果が要求仕様書に反映されていることをチェックしておく必要があります。要求仕様書に問題があると、その後の製品企画や設計に大きな変更や手戻りを発生させてしまいます。ソフトウエア製品では、商品企画段階で行なわれる要求定義が不十分で要求仕様書が正しく作成できず、最終的に客先でクレームが発生することが少なくありません。何よりもはじめが肝心です。
DRの開催前には、例えば、要求仕様書のほか、商品企画書、市場調査報告書、要求品質展開表など企画に関係する文書をデータパッケージとして準備し、参加者に事前に配布します。またDR時の討議内容に抜けがないように、商品企画の必要性や企画内容の妥当性があるかどうか等をまとめた商品企画DR検討チェックリストを予め手元に準備して活用すれば、討議の質を高めることもできます。

(2)製品企画
製品企画では顧客の要求を然るべき技術的仕様に変換し、製品としての狙いの品質を定めます。またその狙いを実現する上でのネック技術がないかどうかを把握します。新規性の高い製品の場合は、要求事項から設計すべき技術的特性を展開するために、品質機能展開、特に品質表(表1)を活用することもあります。品質表によって、顧客の要求事項と狙いの品質の対応を体系的に可視化できます。

表1 品質表
表1 品質表

更に製品開発に関係する部署(例えば、メカ設計、エレキ設計、ソフトウエア設計、生産技術、購買、製造、品質保証など)における具体的な開発計画(スケジュール、人員、外部委託体制、設計へのインプット、ネック技術への対応方法など)を立案します。
開発計画DRでは、設計へのインプットが明確に整理できているか、狙いの品質やネック技術が適切に把握されているか、スケジュールや人員配置、外部委託先開発体制に問題がないか、原価目標が明示されているか、納期などをチェックし、製品設計への移行審査を行います。
DRの開催前には、開発計画書のほか、品質表、自社他社比較表などをデータパッケージとして準備します。

(3)基本設計
製品企画の後、設計へのインプットに基づいて製品設計を進めます。図1では基本設計に移行しているが、新規性の高い設計開発やハードルの高い技術課題(安全性に関する設計や重要性能設計)に対しては、予め狙いの品質を実現するために概念設計を行い、メカ、エレキ、ソフトなどの各設計部署で配分すべき品質特性と目標値を明確にします。
新規性が低く、既存製品の流用設計で済む場合は、製品企画後、各設計部署で具体的な基本設計に進みます。基本設計では設計へのインプットを実現する主要な機構、制御回路、タイミングチャート、ソフトウエア外部仕様/機能仕様などを考案し、構想図、回路図面、各種仕様書を作成します。
この際、信頼性、安全性の見地から設計部位に対してFTAを実施して、重大なトラブルが発生しないように基本設計で考慮すべき要点を抽出しておく場合があります。また類似技術に関する過去トラブルのノウハウをチェックリスト化し、徹底した再発防止設計の取組みが重要です。また重要な品質特性に関しては、シミュレーションや機能試作・試験などを通じて設計検証を実施します。
基本設計DRでは信頼性、安全性、生産性、保全性、コストなどに関する様々な部署の専門家を召集します。そして基本設計で導出した設計仕様に対する設計検証の適切性を確認し、また設計仕様の問題点摘出ならびに対策可否検討を行ないます。更に専門家の意見を反映し、詳細設計や試作試験への反映事項を明確にすることが大切です。また設計開発の進捗状況や設計開発プロセスの変更点とその影響の有無を確認します。
基本設計DRは検討課題が多い場合、広く浅い議論になりやすいものです。議論がばらばらにならならいように、信頼性、安全性、コストなどそれぞれの領域で適宜、重点的に行なうことを検討したいものです。
基本設計DRにおいて、タイプ4のインフォーマルデザインレビューでは、各種設計図面、仕様書のほか、設計計算書、標準設計チェックリスト、再発防止チェックリスト、FT図など必要なものを用意して、部課内で徹底的なレビューが必要です。タイプ3のフォーマルデザインレビューでは、基本設計DRで各分野の専門家が広く深く検討できるように、可能な限り機能試作品やモックアップ品、または類似既存製品を準備します。
DRでは高度専門家であっても、大小すべての潜在的な問題点を指摘することは難しいものです。DRで専門家からよい指摘を重点的に受けるために、過去の失敗事例、FT図、FMEA表などの資産から再利用可能な知識ベースを整備し、設計者が、DR以前に知識ベースを徹底活用して、自らしっかり再発防止チェックリストやFMEAなどを実施し、予め出来る限りの問題点の摘出と対策実施を実施しておくことが大切です。そして、DRでは広い視点で設計の妥当性を高めてもらう指摘をもらえるようにしておくべきです。

(4)詳細設計
詳細設計では基本設計の後、機構/構造部品、詳細基板、電子部品、内部配線、ソフトウエア内部処理などの詳細仕様を導出し、部品図、内部配線図、ソフトウエア内部仕様書、取扱説明書などの図面や仕様書を作成します。また機能、性能、信頼性要求などに関する設計検証を行うために、一部のアセンブリや部品に対して先行的に試験を実施することもあります。
詳細設計DRでは、基本設計同様に各部署の専門家を招集し、詳細において、設計が正しく行われているか徹底してチェックします。例えば、標準部品を採用しているか、業界規格/社内規格を遵守しているか、信頼性、安全性、操作性、生産性、保全性などの見地から問題点はないか、基本設計DRでの指摘事項を反映しているか、図面記載内容や取扱説明書に不備がないかなどを検討します。またこの後に実施される試作試験に反映すべき事項の抽出も行うことがあります。

(5)試作試験
詳細設計DR後に、部品手配、試作を行い、主に実機による試験を実施します。ソフトウエアはコーディングを行い、ICなどが搭載された制御基板などを試作します。試作時には試作問題点管理表などを運用して問題点を整理します。また試験では性能試験や耐久試験などを行い、実機確認が必要とされる設計検証の実施ならびに設計開発の妥当性確認を行います。
試作試験評価では、試作や試験で問題点が発生した場合の原因特定と対策可否検討を行います。また実施された設計開発の妥当性確認の進め方の適切性を評価します。この結果、図面変更が必要な場合は、設計変更(後述)の検討を必ず進め、出図までに図面・仕様書を修正します。

(6)製品設計審査
試作試験評価ならびに必要に応じた設計変更を行い、インフォーマルデザインレビューによる最終的な検図などを実施した後、製品設計完了の審査(タイプ2のDR)を行います。
ここでは、要求仕様書、設計検証報告書、妥当性確認報告書、デザインレビューのフォロー文書などを利用して、設計検証内容(品質、コスト、納期、法令・規制などの設計へのインプットならびに設計のアウトプット)ならびに設計の妥当性の確認内容の適切性を確認します。また、その他設計管理上の品質目標の達成状況なども確認します。この審査承認を受けたら、製品設計は完了し、製品図面は正式に出図されます。

(7)工程設計
工程設計では、生産工程の大計画を立て、各工程のプロセス特性仕様や検査方式などを導出します。図1ではここでの解説の便宜上、製品設計審査後に工程設計に移行されることになっていますが、実際には製品設計と同時に工程設計を進めることも少なくありません。
設計される工程に対しては、工程設計チェックリストや過去の工程不具合事例などを活用して、QC工程表の管理項目や設備仕様、治工具仕様、作業標準、検査基準などを導出します。また工程FMEAを実施して、各工程設計仕様における問題点を早期摘出し、各仕様の妥当性を高めます。
工程設計DRでは、工程設計仕様が製品図面からの要求を満足しているか、工程管理項目は適切か、作業安全性、作業容易性、量産時の工程信頼性・保全性、工程開発スケジュールなどに問題がないかどうかを評価します。

(8)量産試作
工程設計DRの後、量産試作を行ないます。工程設計の設計検証を行って工程能力や製造原価などが要求事項を満足するかどうか確認するとともに、信頼性、保全性などの見地から工程設計の妥当性確認を行ないます。もし、ここで問題が発生すれば、設計変更(後述)の検討を必ず進め、QC工程表や生産図面などの修正を行わなければなりません。

(9)生産移行審査
工程設計の設計検証内容ならびに妥当性確認内容が適切かどうかを確認し、問題がなければ生産準備の完了とし、生産段階に移行します。

(10)設計変更
製品設計や生産準備の過程で何らかの問題や要求仕様変更が発生すると設計変更が行なわれます。この場合、設計変更DRを実施し、以下の内容を確認する必要があります。

・設計変更の背景となる問題または要求仕様変更に対して、変更仕様が適切な対策となっているか
・設計変更による副作用が生じないように変更の影響を受けるアイテムの設計変更を行なっているか
・設計変更内容を正しく関係部署に通知し、正しく構成管理が行なわれているか

設計変更に起因するトラブルは少なくありません。それは設計変更が緊急を要することが多く、上記のような内容に対する検討が必然的に不足してしまうからです。設計変更時には、設計者によって、変更点におけるFMEAを実施することが大切です。

(11)生産
生産段階に入っても初期流動管理状態においては工程が安定しないため、慎重な工程管理が必要となります。
初期生産審査では、初期流動管理状態を脱し、工程能力、原価、生産能力などが目標を達成しているかどうかを評価し、問題がなければ日常的に管理された量産段階へ移行します。

(12)顧客満足度調査/反省会
顧客の実際の使用状況ならびに満足度を調査するとともに、市場や工程の不具合情報の収集ならびに是正処置を通じ、設計開発の進め方における問題点を抽出します。またこれらを通じて、今回の設計開発活動全体を総括し、設計検証、妥当性確認ならびにデザインレビューの改善点などを含め、次回設計開発への課題を整理します。これも最後の重要な活動です。


DRと設計検証/設計の妥当性確認の関係




DRと設計検証、設計の妥当性確認の間には少しニュアンスの違いがあります。設計検証とは、各設計開発の段階において、その段階時点でのアウトプットが設計開発のインプットで与えられている要求事項を満たしているかどうかを確認することです。一方、設計の妥当性確認とは、最終的に設計開発の結果として得られる製品や工程が意図された用途において要求事項を含む顧客のニーズを満足する能力をもつことを確認することです。(図2

図2 DRと設計検証・妥当性確認の関係
図2 DRと設計検証・妥当性確認の関係

設計検証は、基本設計や詳細設計の各段階で都度行なわれ、最終的には製品仕様が要求仕様書を確実に満足していることの確認というかたちで行なわれることが多いものです。しかし顧客ニーズは、明示的に記載されている要求仕様以外にも多様に存在します。したがって実際の顧客の使用状況を想定し、要求仕様書に明文化されていない暗黙的(または当然の)顧客のニーズを十分に満足する能力があることを確かめる必要があります。設計の妥当性確認は、主に実機試作品による試験や客先での設置、試運転などを通じてこの能力の評価を行なうものです。
一方、デザインレビューでは、設計仕様に潜在する様々な問題点を多様な視点から摘出し、設計検証や設計の妥当性確認の活動が適切に実施されているかどうかを確認し、その結果、設計開発プロセスを次段階へ移行してよいかどうかを判断するものです。
なお、上述した「設計の妥当性確認」はあくまでも妥当性を確認することであって設計の妥当性をつくりこむ活動ではありません。また実機試験によって然るべき妥当性がつくりこまれていることをすべて確認することは事実上困難です。設計の妥当性をつくりこむのは、あくまでも妥当性確認以前の設計計画です。したがって設計者が顧客の使用方法や環境条件を予めしっかりと把握し、設計チェックリストや過去の不具合事例ならびにFMEAやFTAなどを活用しながら、設計計画内容の妥当性を自らしっかりとつくりこむことが大切です。またデザインレビューでは、営業やサービス部門を含む多くの専門家から、設計の妥当性に関する問題点を積極的に指摘してもらい、早めに対策を打っておくことが大切です。


おわりに




DRを通してすべての設計の問題点を摘出することは困難です。設計トラブルを低減させるためには、組織が保有する経験やノウハウを予め総動員して、できる限り質の高い設計を前倒しし、DRに無駄な負担をかけすぎないようにする設計支援のしくみが必要です。特に、設計者が本来、自身のFMEAで事前に把握しておくべきような事項がDRで指摘されているような状況では非常に効率が悪いだけでなく、DRの本来の意義が損なわれます。DRで指摘されるまでもなく、再発防止設計はもとより、できる限り未然防止設計できるように、設計者自身がトラブル知識をしっかり活用する仕組みを設計プロセス全体で構築することが重要です。トラブル未然防止のための知識の構造化ならびにSSMは、健全なDRを実施するための前提の設計プロセスを強力に支援します。

【参考・引用文献】
[1]小野寺勝重(2002):「実践デザインレビュー手法」、日科技連出版
[2]市田嵩(1989):「デザインレビュー事例集」、日科技連出版
[3]田村泰彦(2008):「トラブル未然防止のための知識の構造化」、日本規格協会







FMEA/FTA





設計プロセスとデザインレビュー




保守ユーザ専用ページ








Copyright (C) 2006-2008 構造化知識研究所 All Rights Reserved.

サイトマップ

当サイトのご利用にあたって

個人情報の取扱について