デザインインとデザインレビュー | 事業企画

デザインインとデザインレビューは、製品やシステムの開発プロセスにおいて品質や信頼性を確保し、効率的な開発を実現するために重要な概念です。それぞれの目的、活用事例、注意点を説明します。

デザインイン（Design-In）

目的

デザインインとは、製品開発の初期段階から、サプライヤーや顧客などの外部ステークホルダーを積極的に関与させ、彼らの技術や要求事項を製品設計に組み込むことです。これにより、開発の後半での設計変更や修正を減らし、スムーズな開発プロセスを実現します。また、信頼性や品質の向上、コスト削減、開発期間の短縮を目指します。

活用事例

電子機器開発: 電子部品の選定において、初期段階から部品メーカーと協力し、技術的な適合性や供給の安定性を確認しながら設計を進める。これにより、後の段階での部品変更や調達問題を防ぐ。
自動車産業: 自動車メーカーがエンジンやトランスミッションなどの主要コンポーネントを外部のサプライヤーと共同で開発する。サプライヤーの専門技術を活かし、車両全体の性能や燃費を向上させる。
ITシステム開発: システム設計時にクライアントのニーズや運用環境に合わせたカスタマイズを早期に取り入れ、最適なソリューションを提供。

注意点

要件の明確化: 初期段階で正確に要件を定義しなければ、誤った設計が後の段階でコストと時間のロスを招く可能性があります。
コミュニケーションの重要性: サプライヤーや顧客とのコミュニケーションが不足すると、期待する成果が得られない場合があります。頻繁なフィードバックと調整が必要です。
柔軟性の確保: 初期に決定した設計に固執しすぎると、後に技術進展や環境変化に対応できなくなるリスクがあります。

デザインレビュー（Design Review）

目的

デザインレビューとは、製品やシステムの開発プロセスにおいて、設計段階で定期的に関係者が集まり、設計内容の確認・評価を行うプロセスです。目的は、設計が要求仕様や目標性能を満たしているか、問題がないか、リスクが適切に管理されているかを確認し、早期に不具合を発見して修正することです。

活用事例

ソフトウェア開発: ソフトウェア設計の各段階（要件定義、アーキテクチャ設計、コーディングなど）で、プロジェクトメンバーや外部の技術者がレビューを行い、バグや設計上の問題点を早期に特定。
航空宇宙産業: 航空機の設計段階で、専門家チームによるデザインレビューを行い、安全性や規格への適合を確認する。設計の一部を修正することで、後の検査やテストでの失敗を防止。
建設プロジェクト: 建築物の設計図面や構造計算書をレビューし、施工前に法規制や耐久性、安全性の問題がないかを確認。

注意点

タイミングの重要性: デザインレビューは適切なタイミングで行わなければ意味を失います。設計が進行しすぎてからのレビューは、修正が困難になる可能性があります。
レビューの質: 形式的なレビューでは、実質的な問題を見落とすリスクがあります。詳細なチェックと、経験豊富なメンバーによる検証が不可欠です。
ステークホルダーの適切な選定: 関係する全ての部署や専門家を参加させないと、見落としや誤解が生じやすくなります。関連する部門や外部の専門家を含めた多角的なレビューが必要です。

ISO9001 : 2015のDR要求事項

ISO9001:2015におけるデザインレビューの要求事項を確認しておきます。

8.2.3 製品及びサービスに関する要求事項のレビュー

は，製品及びサービスを顧客に提供することをコミットメントする前に，次の事項を含め，レビューを行わなければならない。

顧客が規定した要求事項。これには引渡し及び引渡し後の活動に関する要求事項を含む。

顧客が明示してはいないが，指定された用途又は意図された用途が既知である場合，それらの用途に応じた要求事項

組織が規定した要求事項

製品及びサービスに適用される法令・規制要求事項

以前に提示されたものと異なる，契約又は注文の要求事項

　組織は，契約又は注文の要求事項が以前に定めたものと異なる場合には，それが解決されていることを確実にしなければならない。

　顧客がその要求事項を書面で示さない場合には，組織は，顧客要求事項を受諾する前に確認しなければならない。

注記インターネット販売などの幾つかの状況では，注文ごとの正式なレビューは実用的ではない。
その代わりとして，レビューには，カタログなどの，関連する製品情報が含まれ得る。

8.2.3.2 組織は，該当する場合には，必ず，次の事項に関する文書化した情報を保持しなければならない。

a) レビューの結果
b) 製品及びサービスに関する新たな要求事項
引用: ISO 9001：2015

ポイントは、「顧客に提供することをコミットメントする前」というタイミングです。
具体的には、顧客との契約に至る前にデザインレビューを実施して、自組織の能力と理解が顧客の要求しているものと合致しているということを確認します。

8.3.4 設計・開発の管理

組織は，次の事項を確実にするために，設計・開発プロセスを管理しなければならない。
a) 達成すべき結果を定める。　(P)
b) 設計・開発(D)の結果の，要求事項を満たす能力を評価するために，レビューを行う。(C)
c) 設計・開発からのアウトプットが，インプットの要求事項を満たすことを確実にするために，検証活動を行う。
d) 結果として得られる製品及びサービスが，指定された用途又は意図された用途に応じた要求事項を満たすことを確実にするために，妥当性確認活動を行う。(C)
e) レビュー，又は検証及び妥当性確認の活動中に明確になった問題に対して必要な処置をとる。 (A)
f) これらの活動についての文書化した情報を保持する

注記設計・開発のレビュー，検証及び妥当性確認は，異なる目的をもつ。これらは，組織の製品及びサービスに応じた適切な形で，個別に又は組み合わせて行うことができる。
引用: ISO 9001：2015

この項目のa)～e)は、設計・開発プロセス中にPDCAサイクルをまわすことを要求していると言えます。
a)の達成すべき結果は、「要求事項」を満たすための評価基準 (KPI)となります。
f)は記録を保持することによって、トレーサビリティの確保を意図しています。そして、将来のデザインレビューにも活用します。

また、デザインレビュー、検証、妥当性確認、と３つの似たような単語が使われています。
いずれも「確認」と言い換えれば意味は通じますが、厳密には意味が異なります。
比較表は次の通りです (定義はISO9000から引用しました)。

	デザインレビュー	検証	妥当性確認
定義 ISO 9000:2015	設定された目標を達成するための対象の適切性、妥当性又は有効性の確定	客観的証拠を提示することによって、規定要求事項が満たされていることを確認すること	客観的証拠を提示することによって、特定の意図された用途又は適用に関する要求事項が満たされていることを確認すること
目的 ISO9001: 2015, 8.3.4	[1]設計・開発の結果が要求事項を満たしているか評価する [2]問題を明確にし、必要な処置を提案する	設計・開発からのアウトプットが設計・開発へのインプットで与えられている要求事項を満たしていることを確実にする	結果として得られる製品が、指定された用途又は意図された用途に応じた要求事項を満たしうることを確実にする
言い換えると、、、	道筋から逸れていないか？	基準に沿っているか？	最終アウトプットである、製品・サービスが、うまく機能するか？