7.4.2　購買製品の検証

(1)　規定の趣旨

• ここでは、組織が購買品を受取るときには、受入検査、その他の活動を実施するように要求している。

(2)　本文

• 2000年版では、“組織又はその顧客が、供給者先で検証を実施することにした場合には、組織は、その検証の要領及び購買製品のリリース（出荷許可）の方法を購買情報の中に明確にすること。”とあった。現実的には“出荷許可”しか考えられないので、2000年版ではあえて限定し訳出した経緯がある。しかし、必ずしもそうではなく、中間工程で検証することもあり得るので、2008年版では“(出荷許可）”を削除した。
• リリースは、JIS Q 9000の定義にあるように“プロセスの次の段階に進めることを認めること。”であり、中間工程及び最終工程（出荷）の両方にありうることが読み取れる。

7.3.3　設計・開発からのアウトプット

(1)　規定の趣旨

• 組織は、設計・開発を実施した後、設計・開発からの出力が適正なものかを検証したうえで、次の段階に進めてよいかを決めなければならない。ここでは、設計・開発からのアウトプットとしてa)～d)の4項目を規定している。

(2)　検証ができるような様式

• “･････インプットと対比した検証ができるような様式で提示されること”が、“･････インプットと対比した検証を行うのに適した形式でなければならない”に変更された。これは、“検証ができるような様式”の表現が明確でないという提案を受けた形である。

(3)　注記

• “設計の範囲に製品を保護、補完する‘パッケージ’は含まれるのかを明確にしてほしい”とのユーザ調査結果があり、議論した結果である。
• 文案として“製造及びサービスの提供は製品の保存を含む”を提示したが、“製品保護のみの表現で、ユーザへの製品情報がない”、“7.5.5と関連付けがない”などの反論があり、さらに議論をかわした。
  その結果、製品の保存が製品の品質に影響を及ぼす場合には含める必要があるため、注記が追加された。

(4)　本文

• “様式”から“形式”に変更した。これは、様式という語訳が“書式”をイメージさせるからである。

7.3.2　設計・開発へのインプット

(1)　規定の趣旨

• ここでは、製品の設計及びそれ以降の展開（開発：development）の計画作成を規定している。設計・開発の計画は、a)～c)の3項目を明確にしたものでなければならない。特にb)では、設計・開発のレビュー、検証及び、妥当性確認の三つの明確化を要求している。また、効果的なコミュニケーション及び責任の割当てなども要求している。

(2)　本文

• 主文には“include”（含む）とあるが、このことはa)～d)のインプットだけが設計・開発へのインプットの全てではないことに留意する必要がある。したがって、設計・開発へのインプットの適切性のレビューは、a)～d)に限らず、製品要求事項に関連するものすべてである。

7.3.1　設計・開発の計画

(1)　規定の趣旨

• ここでは、製品の設計及びそれ以降の展開（開発：development）の計画作成を規定している。設計・開発の計画は、a)～c)の3項目を明確にしたものでなければならない。特にb)では、設計・開発のレビュー、検証及び、妥当性確認の三つの明確化を要求している。また、効果的なコミュニケーション及び責任の割当てなども要求している。

(2)　注記

• “設計・開発のレビュー、検証及び妥当性確認は、異なった目的を持っている。”とある。設計・開発のレビューとは、設計の適切な段階で設計のアウトプットが要求事項を満たすことができるかどうかの適切性、有効性などを評価することである。設計・開発の検証とは、設計からのアウトプットがインプットで与えられている要求事項を満たしているかを確認することである。また、設計・開発の妥当性確認とは、結果として得られる製品が指定された用途又は意図された用途を満たし得ることを確実にすることである。
• このように、設計・開発における三つの要求事項は、それぞれ異なる目的を持っているが、例えばレビューを設計・開発の最終段階で計画的に実施することで検証の目的もカバーできる組織や製品があるかもしれない。同様に、レビューとしてロールプレイ、模擬演技／リハーサルなどを行うサービス業などでは、内部の目で見ればレビューであるが、顧客の目で見れば妥当性確認になるかもしれない。
• “何が設計か”は、何が製品かによって変る。例えば、サプライチェーン上流組織である親企業が市場に提供する最終製品を設計する場合は、当然のことながら設計とはその最終製品の設計である。親企業から最終製品の設計図が供給され、その製品のユニットのアセンブル（組立て）を専業とする組織の場合、設計とは、提供する“部組み品”サブユニット）の組立て方の設計である。
• 親企業では設計とはみなされなかったプロセス設計が、次のサプライチェーン組織においては設計とみなされることを意味している。例えば、コンピュータが製品であるセットメーカでは“コンピュータそのものが設計の対象”である。しかし、コンピュータのサブユニット組立てが製品の組織においては、“サブユニットの組立て方”が設計になるであろう。

7.2.1　製品に関連する要求事項の明確化

(1)　規定の趣旨

• ここでは、7.1の“a)製品に対する品質目標及び要求事項”を受けて、製品に関連する要求事項を明確にすることを規定している。組織は、規格が規定しているa)～d)の4項目を明確にしなければならない。

(2)　a)項

• a)にある“引渡し後の活動”の例示を、注記を新たに設けて示すことになった。これは引渡し後の活動とはどのようなものかを明確にしてほしいというユーザ調査結果が あったことによる。
• 注記に例示されているような引渡し後の活動は、契約時に明確にしておくことがポイントである。ただし、引渡し後の活動は、いつ引渡されたかが明確にならないと、その活動が定義できないことに留意しなければならない。

(3)　c)項

• “製品に関連する法令・規制要求事項”から “製品に適用される法令・規制要求事項”に変更された。製品に焦点を絞った法令・規制要求事項を意味するように変えたいということである。

(4)　d)項

• “d)組織が必要と考える追加要求事項”とする案も検討されたが、本質的な変更ではないとして、JIS Q 9001:2008では、“d)組織が必要と判断する追加要求事項すべて”とした。“すべて”を追加したのは原文“any”の意味を汲んだものである。

7.1　製品実現の計画

(1)　規定の趣旨

• 箇条７全体で、組織の製品を実現させるプロセスについて規定している。7.1では、 製品を実現させるプロセスを明確にし、それら一連のプロセスをどのように展開して いくかの“製品実現の計画”策定を要求している。規格はa)～d)までの4項目を規定 し、製品実現の計画に該当するものを明確にすることを求めている。また、記録の作成 が求められている

(2)　c)項

• c)の記述に“測定”を追加したが、これは次に示す4.1、7.5.1、7.6の記述との整合性 を向上させた結果である。修正後は、“c)その製品のための検証、妥当性確認、監視、測定、検査及び試験活動、並びに製品合否判定基準”となった。

6.4　作業環境

(1)　規定の趣旨

• 製品要求事項への適合を達成させるために必要な"作業環境"を明確にして、運営管理することをここで規定している。対象は製品の品質に影響を与える要素であり、人に関係するものは求めていない。例えば、労働安全や人へのモチベーションなどはここでの規定に含まれない。

(2)　本文

• "製品要求事項への適合を達成するために必要な作業環境を列挙する"ことこそがISO9001では重要で、それを達成することに注力しなければならないが、その列挙する方法は組織が決めればよい。
• 代替案として、注記を新たに設け、規格の意図する作業環境を例示することになった。規格は、"製品の品質に影響のある"作業環境を意図しており、作業者の安全を確保する作業環境は意図していない（食品の品質に影響する衛生は意図している）。この箇条の実務への適用においては、作業者の保護（安全問題）と製品の品質保護とは一体になる場合もあり得るので、一体化されることを否定するわけではないが、規格の意図はあくまでも製品の品質の確保にあるのであって、作業者の保護にあるのではないことを明確にしておきたい。
• 人に関する部分（社会的・心理的要因、表彰制度、人間工学的側面）は除外している。

6.3　インフラストラクチャー

(1)　規格の趣旨

• 組織が製品を実現させるためには、主要なプロセスである箇条７だけでは不十分であ る。組織には必ず主要なプロセスを支える支援プロセスや基盤（インフラストラクチ ャー）があり、それらが維持されなければ品質マネジメントシステムも維持されない。 例えば、ここに規定されている輸送、通信、情報システムなども支援プロセスである。 当然のことながら、建物、電気、ハード・ソフト設備もインフラストラクチャーの対象になる。
• c)の支援体制に“情報システム”が追加された。
  “情報システム”の意味するものは、情報関係のハードウエア（機器・装置など）及　びそれを機能させるためのすべてのものである。例えば、情報システム室などが機能するすべてのもの、顧客クレーム、顧客の意見などの蓄積の仕組みなどがあげられる。