先週に引き続き、デザインレビューのご説明、第2回目です。

 

 

第1回は、デザインレビュー（DR）とはなにか、そしてその目的のお話をしました。

第2回目は、これを実施する基本手順と、これを効果的に実施するための要件などについて説明をしましょう。

 

 

 

 

３．DR実施の基本手順

 

実は、DRを実施する上で決められた特別な手順というのはありません。

前回に説明していることを、その組織なり、製品なりに応じて実施すればよいだけです。

一般的な手順を次に書いておきます。前回の説明を時系列的に並べただけかもしれませんが、復習のつもりでお読みください。

運用上の留意点も書き添えておきます。

 

(1)当該製品の設計の段階に応じて、マイルストンとする段階（DRを行う時期）を決める。

・製品やプロジェクトの性質、規模、複雑さなどにより効果的・効率的な段階を選定する

 

(2) それぞれの段階のDRにおける以下の事項などを決めて承認を得る。

a.　DR重点事項（ねらい）

b.　招集する部門及び専門家

c.　設計者から提供する資料・情報

d.　必要とするチェックリスト

e.　DR承認者

 

・各段階のDRのねらいを明確にして、これを達成するために最適な計画とする。

 

(3)各段階のDR実施前になると、DR事務局から開催の案内を出す。

 

(4)設計者から参加者に事前資料を配付する。

・当日配布では十分なレビューが出来ないので事前配布する。

 

(5)DRを実施し、DR承認者による承認があれば、設計の次の段階に進む。

・次項「効果的なデザインレビューのための3つの要件」を参照

 

(6)DRで設計に対する処置が決定された時は、これを明確に記録しておき、次の段階のDRで処置の状況を確認する。

 

(7)最後のDRが完了すると、生産化に移行する。

 

 

 

 

４．効果的なデザインレビューのための3つの要件

 

DRを効果的なものにするための、特に大事な要件には、次の３つがあります。

 

a.　適切な審査者を得ること

 

社内の関連する部門の人が参加すればよいというものではありません。当該製品で使用される技術分野に深い知識を持った人で無ければ意味がありません。また、各段階の重要なDR内容に関連した知識を持った人が必ず参加することが必要です。さらに、DRの結果のフォローに責任をもって対応できる人が参加する必要があります。DRの計画段階で、それぞれのDRでの参加者をあらかじめ決めておくとよいでしょう。

 

b.　審査者に設計内容を理解してもらえる資料を準備すること

 

設計内容を正しく伝わるように説明することは当然のことです。

設計図だけを見せられても十分な評価が出来ません。

その設計に至った過程や、根拠となる情報が必要です。

またDRの当日に資料を提示されても同じです。

各段階のDRで提示される資料を、データパッケージとしてあらかじめ決めておくとよいでしょう。

次回の事例では、その例を紹介します。

 

c.　適切な指摘を促すDR用チェックリストが必要である

 

DR参加者の知識は、必ずしもすべてを呼び覚まされるとは限りません。

またすべての知識を正確に記憶しているとも限りません。

せっかくの知識をフルに活用するためにも、専門分野の人々の知識をある程度可視化したチェックリストが必要です。

チェックリストの各項目と照合しながらに確認していくというよりは、適度に抽象化された用語から発生するかもしれない不具合を思い起こすことができるような「視点・観点」の集まりのようなものの方が役に立つと思います。

無論、DRにおいて審査すべき項目の重点は，製品の種類によって異なりますから、経験を積みながら、このようなチェックリストを充実させていくことも大事なことです。

 

例えば、製品安全性への対策は特に製品責任(PL)と関係するので，対策状況の確認が必要です。

PL対策の評価の際には，関連法規・規制，危険の程度，環境条件，使用条件，記録の保管など多くの面から漏れのないチェックが欠かせないので、これらの項目をチェックリストにして設計を評価するのです。

 

 

 

５．DRで活用される代表的な手法

 

上記４のb.で説明した“審査者に設計内容を理解してもらえる”ために、活用されることがある代表的な手法を挙げておきます。

a.　品質表、品質機能展開表：

顧客の要求事項と品質特性との関連をマトリックスで表したものです。

日常用語や行動で示される顧客の要求を、製品を構成する部分に対する技術的仕様に変換される過程を説明する資料としてDRには提示されることがあります。

 

b.　信頼性ブロック図、FTA(Fault Tree Analysis)：

設計対象の製品やシステムを構成するサブシステムやユニット、部品のレベルまで分解していく過程を系統的に表し、さらには定量的に信頼度計算を行ったものです。

当該製品の信頼性目標の妥当性や、信頼性に関する設計改善の必要性などについて評価する説明資料としてDRには提示されることがあります。

 

c.　FMEA(Failure Mode and Effect Analysis)：

製品やその構成要素に対して起こりうる故障を想定し，その影響を評価し，必要なら設計変更，設計計算，試験などへ結びつけるものです。

量産化後に起きうる故障に対して、これを未然に防止する設計となっているかについて評価する説明資料としてDRには提示されることがあります。

 

d.　PERT（Program Evaluation and Review Technique）：

製品開発の日程計画をネットワーク図で表したものです。

それぞれのイベントの計画日数が分かるようになっており、クリティカルパスとして重点的に管理すべき日程が分かるようにしておきます。

設計開発のスケジュールが妥当なものであるか、あるいは計画通りに進捗しているか評価する説明資料としてDRには提示されることがあります。

 

ただしこれらの手法が必ず活用されなければならないと言うことではありません。

当該新製品の性質（特に新規性、安全性など）、規模、複雑さなどにより決定されるべきです。

注意しなければならないのは、DRの形骸化です。

DRのために必要な手法ではなく、より完全な設計をするために必要な手法であるかどうかを判断基準として活用されるとよいでしょう。

 

（丸山　昇）