|
|
前のページへ｜目次へ｜次のページへ
7.3.6 設計・開発の妥当性確認
|
結果として得られる製品が、指定された用途または意図された用途に応じた要求事項を満たし得ることを確実にするために、計画した方法（7.3.1参照）に従って、設計・開発の妥当性確認を実施すること。実行可能な場合にはいつでも、製品の引渡しまたは提供の前に、妥当性確認を完了すること。妥当性確認の結果の記録及び必要な処置があればその記録を維持すること（4.2.4参照）。
|
1. 設計・開発の妥当性確認とは？
「検証」が設計・開発のアウトプットのリリース以前の行為とすれば、「妥当性確認」は最終製品でリリース前に実施することで、通常、検証後の行為となります。
妥当性確認は原語では“validation”となっており、
・ その製品が本当にその用途・使用（に必要な要件）に見合った適切な設計になっているか。
・ 現実の用途・目的、使用実態、実使用環境に合った設計であるか。
を確かめる行為で、一般的には顧客要求以外の企業独自の項目・方法での確認行為を該当させることが多いようです。
妥当性確認の例としては、
・ 実際の建設、据付け、適用に先立って行うエンジニアリング設計の妥当性確認
・ インストール、使用に先立って行うソフトウェアのアウトプットの妥当性確認
・ 一般に広く提供するのに先立って行うサービスの妥当性確認
・ アプリケーションソフトのα版による顧客評価
・ 料理の試食
・ 船の進水テスト
・ 機械の試運転
・ ロールプレイ・リハーサル・予行演習
などがあり、顧客が決めた要求以上の耐久試験（例えば、最終破壊モードまでの確認）やいじわるテストなども含まれます。
もちろん、この妥当性確認は「7.3.1 設計・開発の計画」で策定された計画に従ったものでなければなりません。
2. 妥当性確認の実施のタイミング
設計・開発の妥当性確認は、「実行可能な場合にはいつでも、製品の引渡し又は提供の前に」実施することが規定されており、原則としては顧客へのリリース（出荷・納入）前に完了していることが要求されていますが、製品・サービスの形態によって異なる場合があります。
例えば、「装置やシステムの一部」を製品としている場合は、顧客に納入し組み合わせてからでないと総合的な確認ができません。
また、妥当性確認は、断片的にできる範囲内で実施せざるを得ない場合もあるし、シミュレーション（模擬）でしか確かめようがない場合もあります。専門家や精通者に設計結果（図面など）を見てもらうことによって妥当性確認をすることもあり得ます。
やむを得ない場合、サービス提供（実施）中または後に、あるいは納入時または後に設計の妥当性確認をせざるを得ないこともあります。
3. 顧客任せはダメ！
試作（試供）品や実物を作って本当に使いものになるかを実際に確かめる場合に、顧客に試してもらい評価してもらうことがあります。
その際に注意しなければならないのは、
・ 妥当性確認をすべき責任はあくまでもその会社にある
・ 顧客の評価をそのまま妥当性確認の結果（結論）にしてはいけない
ということです。
これは規格の中ではとくに表現はされていませんが、「7.4.3 購買製品の検証」における顧客による供給者先での検証結果をそのまま購買先や購買製品の評価結果（結論）としてはならないのと同じ考え方です。つまり、顧客任せにしてはいけない、最終結論は自分たちで出しなさいということです。
4. 妥当性確認の記録
妥当性確認の結果および必要な処置とそのフォローアップは記録に残しておかなければなりませんが、記録の情報がその設計・開発プロジェクトにフィードバックできない場合であっても、事後または別の設計・開発プロジェクトのインプットとすることが重要で、改善につながります。
5. 不適合・改善要望事例と考察
★ヤッスー部長より一言★
（考え中・・・♪）
＜格言＞ ⇒格言募集中！
・ （考え中・・・♪）
|
前のページへ｜目次へ｜次のページへ
|
