故障モードに基づく設計レビュー

信頼性の基盤は設計変更ではないため、吉村氏は、設計変更を行う場合は、小さな増分で変更すべきだと考えている。設計への混乱は、部品間のインターフェースやシステム間の相互作用に影響を与える変更を断続的に実施することによって生じる。設計を2か所で同時に変更すべきではない。なぜなら、あまりにも多くの変更をあまりにも速く行うと、検出能力よりも早く故障が発生する可能性があるからだ。変更を成功させる鍵の一つは、変更を可視化することである。

議論においては、設計変更案に焦点を当てるべきである。実績のある優れた設計を将来の製品に適用すれば、失敗のリスクは低い。しかし、既存の設計に変更を加えると、失敗の可能性は高まる。

吉村氏は、変更点を軽視するのではなく、理解しようと努めるべきだと助言しています。また、検証テストは設計上の弱点を特定するのに役立つとしながらも、予備設計レビューで行われる有意義な議論でも同様の効果が得られると述べています。吉村氏がここで言及している有意義な議論とは、DRBFM（故障モードに基づく設計レビュー）とも呼ばれるものです。

DRBFMの分析は、優れた設計レビューとFMEAの連携をモデルとしています。包括的で適切に作成されたFMEAは、DRBFMの範囲を決定するための入力（方法論で定義されている他の多くの準備シートも含む）の1つとみなすことができますが、焦点は変更とインターフェースに基づいているため、FMEAは必須ではありません。DRBFMは、製品のあらゆるレベル（設計、プロセス、サプライヤーなど）における変更の新規性に基づいて実装されます。DRBFMの目的は、これらの変更を詳細に議論することで可視化し、品質、コスト、納期に影響を与える可能性のあるあらゆる故障の懸念事項についても検討することです。

GD ³コンセプトの 3 番目の部分。優れた設計レビューの目的の 1 つは、検証テストの結果を検証し、製品のすべての弱点を明らかにすることです。この検証には、GD ³コンセプトのもう 1 つは、テスト結果に基づく設計レビュー (DRBTR) の適用が含まれます。DRBTR を適用する際には、可能な限り、製品テストの完了前、完了中、完了後に観察する必要があります。DRBTR では、検証 (テスト) エンジニアが DRBTR レビューを主導し、テストされた部品を検査し、発生しそうな問題の兆候 (テストの失敗が明らかになる) を探すことが求められます。DRBTR では、設計者とテスト エンジニアが、部門横断的な多角的視点から潜在的な問題 (観察) や弱点について議論し、この情報を共有することが奨励されます。DRBTR では、設計者が実際のテスト ピースを観察し、設計レビューなどのオープンな議論でテスト結果について議論します。さらに、テスト結果を分析する際には、製造上のばらつき、テスト プロファイル、製品の期待される品質と信頼性の目標を考慮する必要があります。このプロセスは、Bill Haughey の電子書籍で詳細に定義されています。^{[ 2 ]}