新しい製品・サービスの具体的な詳細をあらかじめ決めよう

（前回の続き）

「設計・開発」のプロセスをどのように管理するか？（8.3.4）

8.3.4では、8.3.2で明確にした計画に従って、レビュー、検証、妥当性確認を含む設計・開発活動を適切に実施し、管理することが要求されています。

ここにあるレビュー、検証、妥当性確認は、それぞれ以下のような異なる目的を持っています。

• レビュー：設計・開発の結果が要求事項を満たすことができるかを評価するため
• 検証：設計・開発からのアウトプットが、インプット要求事項を満たせるようにするため
• 妥当性確認：結果として得られる製品・サービスが、指定された用途や意図された用途に応じた要求事項を満たせるようにするため

「レビュー」「検証」「妥当性確認」の違い

なお、注記では、これら3つの活動（レビュー、検証、妥当性確認）は、製品・サービスに応じて、同時に実施することもできるし、あるいは個別に実施することが可能であると説明されています。

「設計・開発」の結果はどのようなものでなければならないか？（8.3.5）

設計・開発は、製品・サービスが必要な要求事項を満たせるようにその仕様を確定し、以降のプロセスによってその製品・サービスを提供することができるようにするために実施する活動です。従って、設計・開発からのアウトプットは、インプットされた要求事項を満たすものであり、かつ以降のプロセス（購買や製造・サービス提供）に対して適切な情報を提供するものでなければなりません。

このアウトプットは組織の製品・サービスのタイプによって当然異なります。製造業であれば図面や仕様書、手順書、現物見本といった形で示されることが多いでしょうし、レストランや食品製造業であれば原材料仕様書やレシピ、サービス業であれば手順書やサービスメニューといったものになるでしょう。

これらのアウトプットは、設計活動の結果として文書化した情報（記録）を保持することが新たに要求されています。なお、これらのアウトプットは、以降のプロセス（購買や製造・サービス提供）にとっては指示書や手順書として（つまり文書として）使用されることになります。

「設計・開発」の変更をどのように管理するか？（8.3.6）

組織において、設計変更を正しく処理しなかったために、後々大きな問題を発生してしまうケースがしばしば起こります。このようなことのないように、設計・開発に対して行われた変更を適切に管理することが重要です。設計・開発の変更は次のようなケースで起こることが多いでしょう。

• 顧客や供給者等から変更の要求があった場合
• 規制要求事項等の変更があった場合
• 設計後にエラーが発見された場合
• 製品・サービスのパフォーマンスや機能を改善しようとする場合など

ここで組織は、設計・開発の変更を「特定し、レビューし、管理」することが要求されています。ここでは「検証」「妥当性確認」は明示されていないが、それは「管理」に含まれていると考え、製品・サービスの適合に悪影響がないことを保証するのに必要な程度、これらを実施しなければなりません。

更に、本項においても文書化した情報（記録）の保持が要求されています。なお、「設計・開発の変更」「レビューの結果」「悪影響を防止するための処置」に加えて「変更の許可」についても文書化した情報の保持が要求されている点に注意が必要です。