|
ISO9001／ISO14001 ｺﾝｻﾙﾃｨﾝｸﾞ・研修 | |
| 7.3.4項 設計開発の ﾚﾋﾞｭｰ | 実務の視点による ISO9001:2000の解説 <その42> |
35-01-42 |
7.3.4 設計・開発の ﾚﾋﾞｭｰ
|
|||||||||||||||||||||||
|
1. [7.3.4項]の概要 本項は、設計開発における ﾚﾋﾞｭｰ が、設計開発活動が必要な結果を出すように設計開発活動を方向づける活動であることを明確にし、そのような ﾚﾋﾞｭｰ としての要件を規定している。 2. 設計・開発の ﾚﾋﾞｭｰ (1) ﾚﾋﾞｭｰ ﾚﾋﾞｭｰ (review)は、「再び見る」であり(2)、転じて、「必要なら変えるという意図をもって行う検討」ということを意味する(1)。 規格は、「ﾚﾋﾞｭｰ」とは「対象とするある事項が、所定の目標達成という観点で適当か、十分か、有効かを決定するために行われる活動*」#1である。 「設計・開発の ﾚﾋﾞｭｰ」の検討の対象は設計開発活動であり、規格ではこの他に、検討対象が品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑ である「ﾏﾈｼﾞﾒﾝﾄ ﾚﾋﾞｭｰ」(5.6項)、契約や取引内容である「製品要求事項のﾚﾋﾞｭｰ」(7.2.2項)など、他の事項を検討対象とする ﾚﾋﾞｭｰ も取扱っている。 (2) 設計開発活動における ﾚﾋﾞｭｰ JIS和訳「設計・開発の ﾚﾋﾞｭｰ」は、「設計開発活動における ﾚﾋﾞｭｰ」の意味であり、設計開発活動を対象とする ﾚﾋﾞｭｰ である。 設計開発活動における ﾚﾋﾞｭｰ は、設計開発活動の進捗又は結果を評価し、問題を特定し、解決策を講じるために実施される。 この ﾚﾋﾞｭｰでの評価の観点については、本項( a)項)では「設計開発活動の結果の、要求事項を満たす能力を評価する」$1と規定され、94年版では「ﾃﾞｻﾞｲﾝ・ﾚﾋﾞｭｰ（設計審査）」と呼ばれていたが、その定義#2で「設計結果の、品質要求事項を満たす能力を評価する」と規定されていた。 ここに、「満たす能力」は ability to meet と capability to fulfil であるから、「満たすことができる」という意味である。 すなわち、設計開発活動における ﾚﾋﾞｭｰ での評価とは、検討対象の設計開発活動をこのまま続けて、その結果が「要求事項」を満たすこと、つまり、当該設計開発活動の目標を達成することが出来そうかの評価である。 同じ監視又は評価に関係する手段である検証(7.3.5項)や妥当性確認(7.3.6項)が、それぞれの要件が満たされているかどうかを客観的証拠によって明らかにする活動であるのに対して、ﾚﾋﾞｭｰ では、これら明らかにされた事実を以降の設計開発活動の目標の達成の観点からどう考えるか、だからどうしなければならないかを検討する。 その上で、当該設計開発活動をこのまま進めてよいか、計画の通り次の段階に移ってもよいのかどうかを判断し、目標達成を困難又は不可能にする問題を特定し、解決のための必要な処置を決める。 或いは、目標の変更(7.3.7項)を含む設計開発の計画の更新をする(7.3.1項)。 設計開発活動における ﾚﾋﾞｭｰは、 設計開発活動が必要な結果を、計画の通りの期限や資源の範囲内で出すことを確実にするよう、設計開発活動を方向づけることが目的である。 また、ﾚﾋﾞｭｰ の結果は、設計開発活動で重要な決定或いは承認を行なう場合に、そのための判断の根拠を形成する。 ﾚﾋﾞｭｰ による設計開発活動の方向づけは、設計開発により顧客の ﾆｰｽﾞと期待を満たす製品仕様の製品を得ること、及び、設計開発活動の進捗の日程を管理することの、2つの観点で行なわれる。 この ために ﾚﾋﾞｭｰ を、設計開発活動のどの段階、どの時点で、どのような方法で行うことが必要かは、設計開発活動の性格や規模、困難さなどにより様々である。 組織は当該の設計開発活動に適した効果的、効率的な ﾚﾋﾞｭｰ の実施を設計開発の計画に定めなければならない(7.3.1 b)項)。 ISO9004は、ﾚﾋﾞｭｰ が「設計開発の諸目標が達成されることを最終的に判断する」ことであるとして、ﾚﾋﾞｭｰ で評価する事項として、設計開発条件、検証や妥当性確認の結果、設計開発活動の進捗状況、設計開発活動の変更の管理状況、問題の特定と対策などを例示している#3。 規格は、設計開発活動の目標と前提条件の決定に際する ﾚﾋﾞｭｰ の必要(7.3.2項)を規定し、設計開発結果の確定に関しても責任者による承認の必要(7.3.3項)を規定することによって ﾚﾋﾞｭｰ の必要を示唆している。 これらが正しくなければ、当該製品を顧客に引渡しても顧客満足は得られず、従って設計開発や製品実現の諸活動の費用と労苦は無に帰すことになるから、設計開発活動における最も重要な ﾚﾋﾞｭｰである。 とりわけ、具体的な契約や受注を前提とせずに行われる製品企画や新製品開発など顧客の意向の直接的表明のない場合においては、顧客のﾆｰｽﾞや期待の決定には多角的な検討が必要である。 94年版の ﾃﾞｻﾞｲﾝ・ﾚﾋﾞｭｰ が「文書化され、包括的で体系的な活動」と規定#2されていたように、本項でも設計開発のﾚﾋﾞｭｰ は「体系的な ﾚﾋﾞｭｰ」でなければならないと規定されている。 設計開発活動における ﾚﾋﾞｭｰは、各関係者がその責任及び権限或いは担当する業務領域のそれぞれの観点から問題を評価し、必要な処置を提議する総合的な検討でなければならない。とりわけ、設計開発結果の確定には、設計開発条件が間違いなく満たされており、製品が必要な顧客を得るであろうことを、設計開発条件の決定に参画したすべての関係者が判断する必要があり、同時に製品実現諸業務の関係者がその製品実現が可能であることを判断することも必要である。 3. 規格要求事項とその真意 (1) 適切な段階で、計画された通りに体系的 ﾚﾋﾞｭｰ を行なう [第1文 (1)] 「計画された通り」の英原文は planned arrangement (計画された手はず)であり、(7.3.1参照)という注釈が付されているから、設計開発の計画(7.3.1項)に従って、という意味である。 設計開発活動の効果的、効率的実行のための管理の手段として、設計開発活動 の ﾚﾋﾞｭｰ を計画し、実施しなければならない。「体系的な」ﾚﾋﾞｭｰ とは、本項の他のすべての要求事項を満たして行なわれる ﾚﾋﾞｭｰ のことである。 この「適切な段階で ﾚﾋﾞｭｰ を行なう」を、「各段階に適した ﾚﾋﾞｭｰ 」という設計開発の計画の規定(7.3.1 b)項)と比較すると、ﾚﾋﾞｭｰ は設計開発活動の段階のすべてでは行なう必要はないという意味に受けとめられる。 しかし、本来、全体設計開発活動の区切りとなるような状況が“設計開発活動の段階(stage)”であるから、この段階自身にPDCAｻｲｸﾙを適用する必要があり、どの段階にも ﾚﾋﾞｭｰ は必要である。ところで94年版では、“設計開発活動の段階”を決めるという規定のないまま、ﾚﾋﾞｭｰ、検証、妥当性確認のいずれについても「設計の適切な段階で」実施するよう規定#4されていたから、この「段階（stage)」は “段階”を含む“時点”とか“局面”の意味で理解されてきた。2000年版では「設計の適切な段階で」との表現は ﾚﾋﾞｭｰ の実施に対してのみ残されており、残されたこの「段階」は94年版の概念での「段階」であると考えられる。 従って、こちらの「段階」は7.2.1 a）項の「設計開発活動の段階」ではなく、段階の最後の時点と中間の重要な局面をも含む「適切な段階」の意味であると解釈することで、本項と7.3.1 b)項の2つの表現を矛盾なく理解することができる。 組織は、設計開発の段階と段階の接点、或いは、各段階の中間の重要な局面などなど節目節目で 体系的ﾚﾋﾞｭｰ を実施し、設計開発活動及び引続く製品供給のための活動の道を誤らせないようにしなければならない。 このために必要な ﾚﾋﾞｭｰ の時点と方法を設計開発の計画(7.3.1 b)項)に定めておかなければならない。 (2) 次の事項を目的として体系的 ﾚﾋﾞｭｰ を行なう [第1文 (2)] 設計開発活動における ﾚﾋﾞｭｰは、次のa), b)項を行なう活動である。 この ﾚﾋﾞｭｰ は、下記3.(5)の要求事項を満たすなど、体系的に実行されなければならない。 (3) 設計開発結果が要求事項を満たせるかどうかを評価する [箇条書き a)項] JISは英原文$1の「〜の能力を評価する」を「〜できるかどうかを評価する」と和訳して、文意を適切に表している。 この「要求事項」には修飾語がないが、文脈から設計開発の目標、つまり、設計開発活動で達成すべき事項と理解される。 すなわち、設計開発条件の決定に関する ﾚﾋﾞｭｰ (7.3.2項)では例えば、「要求事項」は顧客のﾆｰｽﾞと期待を満たす製品仕様の製品であり、設計開発活動が「要求事項」を達成するのに十分かどうかの観点で設計開発条件を評価する。 設計開発活動の途中の時点や局面での ﾚﾋﾞｭｰにおいては例えば、「要求事項」は設計開発活動の定められた目標であり、それまでの設計開発活動やその時点での設計開発活動の状況や結果を、設計開発活動をこのまま計画通りに進めた場合にどうなるか、目標を達成できるかどうかの観点で評価する。 設計開発結果の確定、承認のための ﾚﾋﾞｭｰ では例えば、「要求事項」は顧客のﾆｰｽﾞと期待、及び、設計開発の結果を受け取る組織内のﾆｰｽﾞと期待に相当し#3、設計開発結果の製品で必要な顧客満足を得ることができそうか、また、技術的、経済的に製品実現が可能かどうかの観点で設計開発活動の結果を評価する。 (4) 問題を明確にし、必要な処置を提案する [箇条書き b)項] JIS和訳「問題を明確にする」は identify any possible problemsであり、何か問題と思われることがあれば、それを特定することという意味である。「提案する」はpropose であり、一般には「提案する、提議する」であるが、設計開発活動の責任者を初めすべての関係者が参画する体系的な ﾚﾋﾞｭｰ であるから、「計画する」(5)(6)である。 問題解決のための処置を計画する、又は、処置を講ずるという意味である。 英文解説書も、「設計 ﾚﾋﾞｭｰ は、問題点を特定し、問題が大きくなる前に解決するよう処置をとる」(7)、「もし ﾚﾋﾞｭｰ で問題を検出したなら、これに対処する処置を決めなければならない」(8)と説明している。「提案」は規格の意図ではない。 (5) ﾚﾋﾞｭｰ の参加者には、対象の設計・開発段階に関連する部門の代表が含まれている [第2節 第1文] ﾚﾋﾞｭｰ を設計開発の各段階で行なうとの前提で、その「段階に関連する部門の代表」という表現になっている。 「関連する部門」とは、その段階の設計開発の目標や結果によって担当業務が影響を受ける、或いは、目標や結果に部分的にでも責任を有する部門という意味であり、「代表 (representative)」とは、ﾚﾋﾞｭｰ で当該部門の担当する業務機能の観点で情報を評価し、意見を述べ、ﾚﾋﾞｭｰ の結論を認めることができる能力と責任及び権限を有する者という意味である。 (6) ﾚﾋﾞｭｰ の結果の記録及び必要な処置があればその記録を維持する [第2節 第2文] 何をどのように評価し、どのような問題を議論し、どのように問題解決したか、又は、どのような解決策の実施を決めたかを含めて、ﾚﾋﾞｭｰ の結論を記録しなければならない。 この記録の伝達によって関係者の共通理解を補強し、また、当該 ﾚﾋﾞｭｰ に関係のない設計開発活動の他の関係者に設計開発活動の進捗を知らしめることができる。 この記録を維持することにより、後日の設計開発活動又は製品実現活動や製品の顧客による使用において問題が生じた場合の原因追求の手掛かりとして役立たせることができる。 計画した解決策の記録は、その実行の管理のために利用することができる。遭遇した問題と成功した解決策の記録は、以後の設計開発活動の効果的、効率的実行のための情報として活用することができる。 引用規格条項 #1 ISO9000, 3.8.7; #2 ISO9000, 3.11; #3 IS09004, 7.3.3 引用英原文 $1 to evaluate the ability of the results of design and development to meet requirements 引用文献 (英文献及び 文中の* 印は著者による翻訳) (1) Oxford Advanced Learner’s Dictionary, Oxford University Press (2) Merriam-Webster’s Collegiate Dictionary, Merriam-Webster Inc (5) 海野文男他: 実用英語大辞典、日刊ｱｿｼｴｰﾂ、1998.6.26 (6) EDｸﾞﾙｰﾌﾟ:英辞郎、PDIC for Windows (7) D.Hoyle: ISO9000 Quality systems Handbook,Butterworth-Heinemann,2001; p.430 (8) ISO/TC176: ISO9001 for Small Businesses, ISO中央事務局,2002; p.95 |
| H20.2.29(改 H20.3.10, 3.13) |
 |
 |
禁無断転載 (個人的使用のための複写歓迎) |
|
| ｻﾆｰﾋﾙｽﾞ ｺﾝｻﾙﾀﾝﾄ事務所 〒458-0031 名古屋市緑区旭出２−９０９ | |||