2013年5月31日金曜日

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

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

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


デザインレビュー(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 開発フロー例

'via Blog this'

0 件のコメント:

コメントを投稿