|
ISO9001／ISO14001 ｺﾝｻﾙﾃｨﾝｸﾞ・研修 | |
| 7.3.2項 設計・開発への ｲﾝﾌﾟｯﾄ | 実務の視点による ISO9001:2000の解説 <その40> |
35-01-40 |
7.3.2 設計・開発への ｲﾝﾌﾟｯﾄ
|
|||||||||||||||||||||||||||
|
1. [7.3.2項]の概要 設計開発の計画では、顧客のﾆｰｽﾞと期待を満たすように製品の仕様が決められることを確実にするよう、設計開発活動の目標と活動の進め方を決めることが必要である。 本項は、設計開発活動の目標と活動の進め方を適切に決めるための要件を規定している。 2. 設計・開発への ｲﾝﾌﾟｯﾄ (1) 設計開発活動の条件 規格の設計開発とは、特性#2として表されていない顧客のﾆｰｽﾞと期待たる顧客要求事項(5.2項)を組織の有する設計開発能力によって、特性に変換して製品仕様たる製品要求事項(7.2.1項)を確定する活動である(1)。 規格で「特性」とは「そのものを識別するための特徴」であり、特性には、物理的、感覚的、行動的、時間的、人間工学的、機能的の各特性がある。 一方、品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑの活動或いは業務は、規格では ﾌﾟﾛｾｽ であり、ﾌﾟﾛｾｽ とは ｲﾝﾌﾟｯﾄ を ｱｳﾄﾌﾟｯﾄ に変換する活動と定義される#1。 従って、設計開発活動の ｲﾝﾌﾟｯﾄ とは一義的には、顧客のﾆｰｽﾞと期待であり、それらを実現する製品の特性として表された仕様が ｱｳﾄﾌﾟｯﾄ である。設計開発 ｲﾝﾌﾟｯﾄ とは、ｱｳﾄﾌﾟｯﾄ の目標であり、製品仕様に関する設計開発活動の達成目標である。 これを、C.MacNee氏らは、設計開発の ｲﾝﾌﾟｯﾄ とは「設計開発活動が何を達成すべきか」を明確にするものである(2)と表現している。 一方、規格は設計開発の ｲﾝﾌﾟｯﾄ を「製品要求事項に関連する ｲﾝﾌﾟｯﾄ」として、製品仕様以外の ｲﾝﾌﾟｯﾄ のあることを示唆している。 この ｲﾝﾌﾟｯﾄ（input)に関して規格は特段の定義をしていないから、一般英語のinputの意味で考えると「仕事や ﾌﾟﾛｼﾞｪｸﾄ の完遂のために投入される時間、知識、考え等」(4)と、目標だけではなく、その達成の手段も含まれる。 ところで、ｲﾝﾌﾟｯﾄ の製品の仕様は、当該製品に必要な顧客満足を得るという観点だけでなく、組織の製造又はｻｰﾋﾞｽ提供能力やｺｽﾄなど組織の事業上の都合をも考慮されたものでなければならない(7.2.1項)。 また、 設計開発活動はその目標をどのように達成してもよいというのではなく、組織の品質方針や設計開発活動の業務効率、或いは、製品の製造及びｻｰﾋﾞｽ提供の経済性や効率性など組織のﾆｰｽﾞを満たして目標を達成しなければならない。 設計開発活動の効果的、効率的な実行のために組織が定めた手順や基準、資源もある。 これらも「製品要求事項に関連する ｲﾝﾌﾟｯﾄ」である。設計開発の ｲﾝﾌﾟｯﾄ とは、設計開発される製品仕様に対する目標と共に、その仕様の満たし方、満たす方法論に関する方針や考え方を含む設計開発活動の条件という意味である。 設計開発の ｲﾝﾌﾟｯﾄ には、設計開発活動に関係して適用されなければならないすべての要件が含まれていなければならない(3)。 (2) 性能特性と構造特性 規格では、その製品が有する一連の特性によって、製品がどのようなものであるかが表わされる。 規格には特に区別した表現は見られないが、種々の特性を、製品の媒体、構造、外観などの構造特性と機能や効能、効用などの性能特性に分けて考えるとわかり易い。 ただし、例えば、小型であること、廃棄時の分解容易さ、見た目の好感度などを機能や効能とする製品では、一般には構造特性である寸法、組立構造、外観の特性が性能特性となるなど、どれかひとつの特性が構造特性又は性能特性のどちらかであるというような意味の分類ではない。 顧客のﾆｰｽﾞと期待は一般に、製品の機能、性能や効能、効用に関して表明され、或いは、把握される。 従って、設計開発活動では、ｲﾝﾌﾟｯﾄ は性能特性、ｱｳﾄﾌﾟｯﾄ は構造特性で表されるのが一般的である。 設計開発活動では、把握し又は決定した顧客のﾆｰｽﾞと期待に適う性能特性を、組織の事業上の都合も加味して、効果的、効率的、経済的に実現する製品の構造特性が決定される。 この ｱｳﾄﾌﾟｯﾄ の前提となる諸条件が設計開発の ｲﾝﾌﾟｯﾄ である。 なお、新規なﾆｰｽﾞや期待とそれを満たす新規な技術を探索するような研究開発では、製品の新規な機能や効能が ｱｳﾄﾌﾟｯﾄ であることもある。 3. 設計・開発への ｲﾝﾌﾟｯﾄ の決定 (1) 製品仕様の目標 顧客のﾆｰｽﾞと期待に関する設計開発の ｲﾝﾌﾟｯﾄ は、設計開発の目標とする製品の機能や効能であり、当該製品が製造又はｻｰﾋﾞｽ提供され顧客に引渡された結果で、必要な顧客満足が得られるかどうかの鍵であり、この ｲﾝﾌﾟｯﾄ の決定は設計開発活動の最も重要な事項である。 ｱｳﾄﾌﾟｯﾄ は特性で表された製品仕様である。顧客のﾆｰｽﾞと期待を間違いなく満たす製品であるためには、その製品仕様は、の4つの視点から評価して決定されなければならない(7.2.1項)。 a) 顧客の意向を反映した仕様 b) 顧客満足向上のために必要な仕様 c) 製品に適用される法規制を満たすための仕様 d) 組織の都合による追加的仕様 設計開発の ｲﾝﾌﾟｯﾄ は、ｱｳﾄﾌﾟｯﾄ たる製品仕様に対する目標を示すものであるから、ｲﾝﾌﾟｯﾄ もこれら4つの観点で検討され、決定されることが必要である。 この7.2.1 a)〜c)項は、必要な顧客満足が確実に得られることを図る観点であり、d)項はﾌﾞﾗﾝﾄﾞ戦略や製品実現の能力、効率や経済性など組織の都合を織込む観点である。但し、7.2.1項は、製品仕様の決定のための要件として記述されており、本項は設計開発の目標として記述しているから、両者の表現が異なり、亜条項の対応関係にもずれがある。 (2) 設計開発基準 設計開発活動は新規な製品に関して行われるが、全く新規ということはほとんどなく、組織の事業範囲の製品である限り、過去に同様の製品の設計開発を行っている。 設計開発活動を常に一から計画し実行するのは効率的ではない。 ある性能特性を構造特性に変換する技術的手段は一般にはひとつではなく、設計開発活動では狙いの製品に最も適切な技術的手段が選択され適用される。 この判断は単に技術的合理性の観点からの判断ではなく、顧客満足向上のため、或いは、組織の都合のためという品質ﾏﾈｼﾞﾒﾝﾄ の観点を含めた判断でなければならない。 それぞれの狙いの性能特性を実現するために適用できる技術的手段をできる限り整理し明確にして文書化し、個々の設計開発活動の計画においてこれを参照し、設計開発の条件としてその適切な選択、適用を決定するような手順の確立が、設計開発活動の有効性と効率性の確保に寄与する。 未知の部分を解決した設計開発活動の結果をこの設計開発基準に織込み、製品の使用結果による顧客の評価又は苦情によってこれを変更するという繰り返しの中で、組織の設計開発能力を向上させることができる。 この設計開発基準には、製品に適用される法規制は当然、織込まれ、また、業界の基準や国家規格、国際規格も必要により取り入れられる。 また、部品や原材料或いは製品引渡しや引渡し後の活動を標準化することも含まれる。 特定顧客や特定製品に限られる使用上の必要、苦情対応などのために、特別な設計開発基準を設定することもある。明確な体系的に整理された設計開発の基準の確立が困難な場合は、過去の設計開発活動の記録を適切に管理し、必要に応じて参照できるようにすることが大切である。 4. 規格要求事項とその真意 (1) 製品要求事項に関連する ｲﾝﾌﾟｯﾄ を明確にする [第1節 前半] 設計開発の ｲﾝﾌﾟｯﾄ とは、設計開発活動の条件を意味し、設計開発活動の結果を意味する「設計開発からのｱｳﾄﾌﾟｯﾄ」(7.3.3項)に対する目標でもある。 ｲﾝﾌﾟｯﾄ には、製品仕様に対する目標と設計開発活動に対する条件の2種類がある。普通、前者は製品に必要な性能特性、後者は設計開発に関する方針や基準、条件として表される。 「明確」の原英語は determine（決定する）である。 組織は、設計開発する製品が必要な顧客満足を得られる製品であることを確実にし、また、設計開発活動の効果的、効率的な実行を確実にするための設計開発活動の条件を決定する手順を確立しなければならない。 設計開発条件を適切に、また、抜けなく決定するには、a)〜d)項の観点から検討する必要がある。 規格は、成約又は受注した製品、或いは、企画又は開発する新製品に対して、必要な顧客満足が得られ且つ組織の事業上の必要を満たすような製品仕様を効果的に決定するための要件を、7.2.1項（製品要求事項の決定）に規定している。 設計開発条件のひとつとしての製品仕様の目標を効果的に決定するための要件も、これと同じである。 製品仕様の目標をまず、7.2.1 a)〜d)項の観点から検討し、決定した上で、本項の a)〜d)項に照らして、設計開発条件として適切であることを確認するというのが、規格の意図である。 本項の a)〜d)項に関して解説書では、規格理解の容易さのため各項に相当する事例が挙げられるが、どの事項がa)〜d)項のどれに相当するのかの議論は規格の意図ではない。例えば、電子製品の有害物質規制は ｲﾝﾌﾟｯﾄ のb)項に相当するとされるが、契約で機械の使用安全規格が規定されれば ｲﾝﾌﾟｯﾄ のa)項に該当し、既存製品の仕様を表す組織の製品規格は c)項又はd)項に分類されるなど、規格や法規制といってもまちまちである。 規格の意図は、何がa)〜d)の各項に相当するかを明確にすることではなく、設計開発条件の決定に際して a)〜d)項の観点が検討され、決定された設計開発条件に a)〜d)項に関して必要な事項が含まれていることを確実にするということである。 (2) 記録を維持する [第1節 後半] 決定した設計開発条件は、設計開発の計画書(7.3.1項)の一部として計画書又は付属文書に記述することが必要である。 この記録には、設計開発条件の決定や適切性の ﾚﾋﾞｭｰ において問題になった事項や変更された事項もあれば含めることが必要である。 設計開発計画書は、設計開発活動の管理のために使用され、記録された設計開発条件は、設計開発の結果(7.3.3項)の合否判定(7.3.5項)のために使用される。 設計開発条件の決定の経緯に関する記録は、設計開発の進捗不良や製品の顧客不満足などの事態が生じた場合の原因追求のための情報として使用される。 (3) ｲﾝﾌﾟｯﾄ には次の事項を含める [第2節 前段記述] 設計開発条件を決定する場合は、製品仕様の目標をまず、7.2.1 a)〜d)項の観点で抜けなく適切に決定し、それと設計開発の進め方に関する必要事項を合わせて、次の a)〜d)項の観点から検討し、抜けがないか、適切かを判断しなければならない。 決定した必要事項は、確実に設計開発条件に織込まれなければならない。 (4) 機能及び性能に関する要求事項 [箇条書き a)項] 製品が顧客に与える利益は、顧客が製品から得る効能、効用であり、それをもたらす製品の機能、性能である。 製品に関する顧客のﾆｰｽﾞと期待とは基本的に、製品の機能や性能、或いは、効能、効用に関するﾆｰｽﾞと期待である。 機械製品の外観や寸法、素材製品の色や臭い、ｿﾌﾄｳｪｱ製品の文書分量(説明書)、ｻｰﾋﾞｽ の待合室(医療)、整備員服装(自動車整備)などは一般には機能及び性能とは関係しない構造特性であるが、それ自身が顧客のﾆｰｽﾞ又は期待となることもあり得るから、その場合はそれらも機能及び性能である。 また、構造特性だから、顧客満足に関係しないとは限らない。 極端に大きい、色がけばけばしいなど機能や性能と無関係でもある一線を越えると問題になることもあり得る。 目標とする機能及び性能を実現する製品としてその構造特性を決めるのが設計開発活動であるが、契約又は受注した製品で顧客の意向の中の構造特性が明確になっていたり、既存製品との比較で構造特性もほとんど明確になっている場合がある。 顧客が製品を使用する環境との相性も顧客満足には重要な要素であり、これに構造特性が関係する場合が少なくない。 機能及び性能に関する必要事項だけではなく、構造特性に関する必要事項もあれば、設計開発条件として織り込まなければならない。 (5) 適用される法令・規制要求事項 [箇条書き b)項] 本項は、意図、内容共に 7.2.1 c)項と同じである。 対象は製品に適用される法令等に限定され、法令だけでなく、工業規格や農業規格、或いは、業界や組織の行動指針や独自規格、又は、公表し、或いは顧客に約束した自主的規制や努力目標も含まれる。 環境規制も製品に適用されるものは当然、対象になる。 製品を海外に輸出する場合は、輸出先の法令その他の規制も対象にしなければならない。 この観点で設計開発条件を検討し決定するためには、法令その他の規制がしばしば制定、改正されるという実態に照らして、適用が必要な法令その他の規制を、その制定や改正の動向を含み、的確に把握する手順が確立していることが必要である。 (6) 以前の類似した設計から得られた情報 [箇条書き c)項] 設計開発活動は基本的に、不明な部分を明確にする活動である。 すべての設計開発活動をいちからやるより、過去の経験でわかっているところは初めから適用することにした方が効率的である。 このような知見は、個別の設計開発の記録、顧客の苦情の設計開発による解決事例の記録から得られるが、これらを体系的に整理して設計開発ﾃﾞｰﾀ集、設計開発事例集にまとめていくことが、過去の知見を効果的に活用するために大切である。 更には、組織のﾆｰｽﾞと品質方針を加味した設計開発基準を確立し、これを設計開発の指針或いは基準とすることによって設計開発活動の有効性、効率性を高めることができる。 (7) 設計・開発に不可欠なその他の要求事項 [箇条書き d)項] 原英語 essential を「不可欠」と和訳することは適切であるが、ここでは「抜けてはいけないその他の要求事項」という意味に受け取るのがよい。 設計開発条件の適切な抜けのない決定のために、 a)〜c)項の観点からの検討だけでよいのか、他にもあるなら、それも設計開発条件の決定の手順に織り込まなければならないという趣旨であろう。 D.Hoyle氏(5)は、「( a)〜c)項で）特定された要求事項の他にも、満たさなければならない要求事項があるかもしれない」として、7.2.1 d)項に関係する組織の方針や国内や海外の政策を例示している。 この他にはこの英文の解釈に触れた解説書は見当たらない。 (8) ｲﾝﾌﾟｯﾄ について、その適切性を ﾚﾋﾞｭｰ する [第3節] この場合の「ﾚﾋﾞｭｰ (review)」は、「批判的に又は意図的に検討する」(4)の意味である。 設計開発条件を正式に決定する前には、それらが適切であるかどうかを、定められた関係者によって検討されなければならない。 当該製品の顧客のﾆｰｽﾞと期待が正しく捉えられ、組織の事業上の都合を加味して適切に製品仕様の目標に反映されているかの判断が誤っておれば、設計開発活動は無価値になり、製品は顧客に受け入れられない事態となる。 顧客の直接的な意思表明のない状況で着手される新製品の企画や開発においては、とりわけ顧客の潜在ﾆｰｽﾞや期待が正しく捉えられているかの判断が重要である。 検討の結果は上記(2)の設計開発記録に含めなければならない。 (9) 要求事項は漏れがなく、曖昧でなく、相反することがない [第4節] この「要求事項」は、上記のa)〜d)項の「要求事項」を指す。 上記(8)の ｲﾝﾌﾟｯﾄ を ﾚﾋﾞｭｰ する際の観点の一部と考えればよい。 これら要求事項、つまり、設計開発条件は、設計の段階や個別の活動(7.3.1 a)項)毎の設計開発条件に細分化され、また、設計開発の結果の合否は、この設計開発条件に照らして判断される(7.3.5項)。 設計開発条件はひとつひとつ明確に分けて具体的に記述され、合否判定が可能なように“達成度判定可能な表現”で表されていなければならない。 引用規格条項 #1 ISO9000, 3.4.1; #2 ISO9000, 3.5.1 引用文献 (英文献及び * 印は著者による翻訳) (1) ISO/TC176: ISO9001:2000“1.2 適用”に関する指針, N524R3,13 Feb. 2002;付属書,指針2 (2) C.MacNee他: Transition to ISO9001:2000, BSI Publications,2001; p.36 (3) J.Kanholm: ISO9000:2000 New Requirements 3rd Edition,AQA Co.; p.42 (4) Oxford Advanced Learner’s Dictionary, Oxford University Press (5) D.Hoyle: ISO9000 Quality systems Handbook,Butterworth-Heinemann,2001; p.419 |
| H20.2.15 |
 |
 |
禁無断転載 (個人的使用のための複写歓迎) |
|
| ｻﾆｰﾋﾙｽﾞ ｺﾝｻﾙﾀﾝﾄ事務所 〒458-0031 名古屋市緑区旭出２−９０９ | |||