設計・開発の機能について正しく理解されている企業はまだまだ少ない。
特にレビューについての理解である。
・・・以前にも言及しましたので、少しダブりますがご容赦下さい・・・。
規格を見渡してみると、“７．３設計・開発”についてが、一番ページ数（字数）を割いていることに先ずは驚きます。
“４．２文書化に関する要求事項”よりも多いですね！
７．３項の構成内容は、
７．３．１設計・開発の計画
７．３．２設計・開発へのインプット
７．３．３設計・開発からのアウトプット
７．３．４設計・開発のレビュー
７．３．５設計・開発の検証
７．３．６設計・開発の妥当性確認
７．３．７設計・開発の変更管理の７項目である。
他の章項とは違って随分細密に規定されていることが分かります。
２０００年版制定の時に、インプットとアウトプットに分けて規定することはしないと編集方針で言われていた筈が、出来上がってみると、５．６マネジメントレビューと本項の２項で採用された。
ボリュームといい、規定の細かさといい、随分力が入ったものだ。
このことが企業の負担を強いていることは否めない。
（適用除外の手はあるが、全く設計・開発の機能がない組織は少なく、結局は（審査を意識して）フルスペックを仕組みとしてまとめてしまうため、過剰な仕組み構築と運用が求められてしまっているのでは？）
設計・開発のレビューについては、規格は次のように規定しています。
①設計・開発の適切な段階において、
②次の事項を目的として、
ａ）設計・開発の結果が要求事項を満たせるかどうかを評価する
（検証・試験結果の評価）
ｂ）問題を明確にし、必要な処置を提案する
（問題があれば、前のプロセスに戻すか、次のプロセスで処置→指示する）
③計画されたとおりに体系的なレビューを行わなければならない
④レビューへの参加者には、・・・部門を代表する者が含まれていなければならない
レビューとは以上のように、検証・試験結果を基に、関係者で議論して、問題を明確にして、このまま開発を進めるかどうか、何が解決すべき課題かを検討する、或いは関係者の叡智を集める場のことである。
多くは何らかの会議が行われる（簡単に言えばレビューとは会議体のこと！）。
しかし、マニュアルを見せてもらうと、検証と同じようなことが書かれている、或いは規格の文言をそのまま書き写してあるケースが多い。
その原因に、規格の構成順序と構成に起因するのかも知れない。
規格は、インプット、アウトプット、レビュー、検証、妥当性確認の順で書かれている。
インプットとアウトプットとが関係するのはレビューではなく、検証、或いは妥当性確認です。
レビューと検証・妥当性確認とは別次元の概念です。
５つの項目が並列に書かれていること自体、おかしなこととも思います。
誤解を生む原因になっているかも知れません。
（しかし、規格は仕事の流れが書かれているのではなく、能力を実証するための重要な事項についてのチェックリストだから止む得ない。
それならそれで、この項の規定は、①設計・開発の計画②設計・開発のレビュー③変更管理の３つに集約して記述するぐらいで良かったのでは・・？と思っている。少なくとも、インプット、アウトプットの項立ては余分！）
規格は、２００８年版の改定で、次のような注記を追記しました。
設計・開発のレビュー、検証及び妥当性の確認は、異なった目的を持っている。それらは、製品及び組織に適するように、個々に又はどのような組み合わせでも、実施し、記録することができる。
分かりにくい説明ですが、それぞれの機能は異なるが、実際の場では、そのいくつかは、同時に起こる、ことを言っている。検証とレビューとが同時に行われている、正確に言えば、検証結果がレビュー時に検討されていることは通例である。やはり、世界的に混乱（誤解）が起こっていることから、注釈を付けたのでしょう。
図は、ＩＳＯ事務局が発行した「中小企業のためのＩＳＯ９０００－何をなすべきか ＩＳＯ/ＴＣ１７６からの助言」に掲載されているものです。これを見れば一目瞭然ですね
。
※図が不鮮明で申し訳ないですね。
メインのプロセスは、ユーザーのニーズ→設計インプット→設計プロセス→設計アウトプット→製品
その上に、デザイン・レビュー、また下に、検証、更にその下に、妥当性確認 です。
デザイン・レビューは必要に応じて随所に行われ、かつ検証や妥当確認（検証と同じ概念）と同時に起こりうるわけですね。
特にレビューについての理解である。
・・・以前にも言及しましたので、少しダブりますがご容赦下さい・・・。
規格を見渡してみると、“７．３設計・開発”についてが、一番ページ数（字数）を割いていることに先ずは驚きます。
“４．２文書化に関する要求事項”よりも多いですね！
７．３項の構成内容は、
７．３．１設計・開発の計画
７．３．２設計・開発へのインプット
７．３．３設計・開発からのアウトプット
７．３．４設計・開発のレビュー
７．３．５設計・開発の検証
７．３．６設計・開発の妥当性確認
７．３．７設計・開発の変更管理の７項目である。
他の章項とは違って随分細密に規定されていることが分かります。
２０００年版制定の時に、インプットとアウトプットに分けて規定することはしないと編集方針で言われていた筈が、出来上がってみると、５．６マネジメントレビューと本項の２項で採用された。
ボリュームといい、規定の細かさといい、随分力が入ったものだ。
このことが企業の負担を強いていることは否めない。
（適用除外の手はあるが、全く設計・開発の機能がない組織は少なく、結局は（審査を意識して）フルスペックを仕組みとしてまとめてしまうため、過剰な仕組み構築と運用が求められてしまっているのでは？）
設計・開発のレビューについては、規格は次のように規定しています。
①設計・開発の適切な段階において、
②次の事項を目的として、
ａ）設計・開発の結果が要求事項を満たせるかどうかを評価する
（検証・試験結果の評価）
ｂ）問題を明確にし、必要な処置を提案する
（問題があれば、前のプロセスに戻すか、次のプロセスで処置→指示する）
③計画されたとおりに体系的なレビューを行わなければならない
④レビューへの参加者には、・・・部門を代表する者が含まれていなければならない
レビューとは以上のように、検証・試験結果を基に、関係者で議論して、問題を明確にして、このまま開発を進めるかどうか、何が解決すべき課題かを検討する、或いは関係者の叡智を集める場のことである。
多くは何らかの会議が行われる（簡単に言えばレビューとは会議体のこと！）。
しかし、マニュアルを見せてもらうと、検証と同じようなことが書かれている、或いは規格の文言をそのまま書き写してあるケースが多い。
その原因に、規格の構成順序と構成に起因するのかも知れない。
規格は、インプット、アウトプット、レビュー、検証、妥当性確認の順で書かれている。
インプットとアウトプットとが関係するのはレビューではなく、検証、或いは妥当性確認です。
レビューと検証・妥当性確認とは別次元の概念です。
５つの項目が並列に書かれていること自体、おかしなこととも思います。
誤解を生む原因になっているかも知れません。
（しかし、規格は仕事の流れが書かれているのではなく、能力を実証するための重要な事項についてのチェックリストだから止む得ない。
それならそれで、この項の規定は、①設計・開発の計画②設計・開発のレビュー③変更管理の３つに集約して記述するぐらいで良かったのでは・・？と思っている。少なくとも、インプット、アウトプットの項立ては余分！）
規格は、２００８年版の改定で、次のような注記を追記しました。
設計・開発のレビュー、検証及び妥当性の確認は、異なった目的を持っている。それらは、製品及び組織に適するように、個々に又はどのような組み合わせでも、実施し、記録することができる。
分かりにくい説明ですが、それぞれの機能は異なるが、実際の場では、そのいくつかは、同時に起こる、ことを言っている。検証とレビューとが同時に行われている、正確に言えば、検証結果がレビュー時に検討されていることは通例である。やはり、世界的に混乱（誤解）が起こっていることから、注釈を付けたのでしょう。
図は、ＩＳＯ事務局が発行した「中小企業のためのＩＳＯ９０００－何をなすべきか ＩＳＯ/ＴＣ１７６からの助言」に掲載されているものです。これを見れば一目瞭然ですね
。※図が不鮮明で申し訳ないですね。
メインのプロセスは、ユーザーのニーズ→設計インプット→設計プロセス→設計アウトプット→製品
その上に、デザイン・レビュー、また下に、検証、更にその下に、妥当性確認 です。
デザイン・レビューは必要に応じて随所に行われ、かつ検証や妥当確認（検証と同じ概念）と同時に起こりうるわけですね。