|
ISO9001／ISO14001 ｺﾝｻﾙﾃｨﾝｸﾞ・研修 | |
| 7.3.1項 設計・開発の計画 | 実務の視点による ISO9001:2000の解説 <その39> |
35-01-39 |
|
7.3項 設計・開発 7.3.1項 設計・開発の計画
|
|||||||||||||||||||||||||||
|
１． [7.3.1項]の趣旨 7.3項は、顧客のﾆｰｽﾞと期待を「特性」の形で製品仕様として確定する活動である設計開発活動が、所定の目標を間違いなく所定の期間、予算で達成できるように、設計開発活動を管理する必要を示唆し、その要件を規定している。 本項では、設計開発活動の効果的な実行管理の基礎として、設計開発の計画を策定する必要、及び、その要件を規定している。 ２． 設計・開発 (1) 設計と開発 94年版では「設計」であったが、2000年版では「設計及び開発（design and development）」となった。 これについて規格執筆者のC.MacNee氏らは、同じような活動でも産業分野によっては「設計」と呼び、「開発」と呼び、更には、「設計及び開発」と呼ぶなど様々々であるので、より広く受け入れられるようにする目的で用語を変えたと説明(2-a)している。 一方、“設計”と“開発”が同義語である使われ方と、全体の設計開発活動の中の異なる段階として区別して使われる場合があるとする規格の説明があり#2、これを受けてJIS和訳では「設計・開発」と表記されている(3)。 産業界で製品の設計開発というと、ある目的の機能や品質を製品として具体化することである。 “設計”と“開発”とは目的は同じだが、一般に、「開発」の方が「設計」より目標と活動に新規な方法や要素が含まれており、活動の目標達成の確実性がより低いというような違いで、理解されている。 英語では(1)、「設計（design）」は「物事がどのようなものか、どのように機能するのかを、図面を作成したり、模型を作ったりして、決める活動」であり、「開発（ｄｅｖｅｌｏｐｍｅｎｔ）」は「何か新規な又は進歩したものを作る、又は、創造する活動」である。 日本語と同じように、両者を製品の具現化活動として比較すると、“開発”の方が“設計”より新しいことや不確実なことに取り組むという感じが強い。 規格では、製品実現のﾌﾟﾛｾｽ の手順と資源を用意する活動を、ﾌﾟﾛｾｽ の「計画及び開発（JIS和訳では「構築」）」することと規定し、後者が develop である(7.1項)。 この場合の英語の解釈では、既存の製品実現の体制にない工程や設備、方法などを必要とするような製品実現の計画を、 plan（計画）でなく、 develop（開発）と呼んでいると理解されている(5-c)。 このように規格では、「開発（develop）」をdesign や plan と区別して使用しているようであるが、どのような場合が「開発」で、どのような場合はそうでないのかを区別することが意図ではなく、表現の正確さのために使い分けていると考えられる。 設計開発に関して、 design と development の違いに触れた英語の解説書も見当たらないし、 94年版と同じ design で押し通している解説書もあるから、英語としても両者の相違を区別するまでのことはないようだ。 (2) 製品の特性 規格では、それがどのような製品であるかを表す指標を「特性」と言う。 「特性」とは「そのものを識別するための特徴*」のことである#3から、“性質”の意味の“特性”だけではない。 一連の特性によって、製品がどのようなものであるかを表現し、その製品を特定し、他の製品と識別することができる。 規格では、特性には、物質的な(機械的、電気的、化学的、生物学的など)、感覚的な(嗅覚、触覚、味覚、視覚、聴覚的など)、行動上の(礼儀正しさ、正直さ、誠実さなど)、時間に関係する(正確さ、信頼性、利用可能度など)、人間工学的な(生理的、安全性など)、機能上(飛行機の最高速度)の、各特性があると説明されている#4。 実務的には、特性は、製品の媒体、構造や外観などの構造特性と、機能や効用などの性能特性に分けて考えることができる。製品を特定又は識別するには一般に、この両特性を明確にすることが必要である。 これを製品4類型#6で考えると例えば、ﾊｰﾄﾞｳｪｱ製品や素材製品の構造特性は、外観、寸法、構造や構成要素、組成、動作機構などであり、性能特性には機能、性能、強度、美麗さなどがある。 ｿﾌﾄｳｪｱ製品では、ｺﾝﾋﾟｭｰﾀｰﾌﾟﾛｸﾞﾗﾑﾞや各種文書の内容の特徴が構造特性であり、それにより何ができるか、何に役立つかの特徴が性能特性である。 ｻｰﾋﾞｽ製品の場合は、輸送業の何を何でどこに運ぶかに関する特徴、納税申告代行業では財務諸表や申告書の内容の特徴、食堂業の料理の特徴が構造特性であり、迅速さや品質保持能力など、正確さや作成に必要な資料の少なさなど、味や食器の感じなどが、それぞれの性能特性である。今日、顧客は地球環境保全に対する関心と利害関係を強めているから、顧客に提供する価値として製品の環境破壊への影響の少なさ又は環境保全への寄与の大きさが重要となってきている。 ISO14001での、組織が管理し又は影響力を及ぼすことのできる「製品・ｻｰﾋﾞｽの環境側面」#10は、ISO9001では製品の性能特性に相当する。 規格では、製品要求事項に関連する製品の特性は「製品の品質特性」#11と呼ばれる。 この製品の品質特性は「製品に固有の特性*」を指し、価格など製品の本質ではない付与された特性は品質特性ではないとされている。 製品引渡し活動や引渡し後の活動の要件は製品要求事項に含まれるが、例えば包装や製品輸送の品質は製品の品質特性には含まれない。しかし、例えば製品の製造とその宅配を事業とする場合には、製造されたものと宅配ｻｰﾋﾞｽの両方が製品である#6から、製品輸送の品質も品質特性である。 (3) 設計開発の必要性 規格では、「設計・開発」は「要求事項を製品、ﾌﾟﾛｾｽ、ｼｽﾃﾑの、規定された特性に、又は、仕様書に変換する一連のﾌﾟﾛｾｽ*」と定義されている#1。 定義によると、製品の設計開発は顧客要求事項を、製品を特定或いは識別する「特性」として明確にする活動である。 「仕様書」は「要求事項を記述した文書」と定義#5されているが、製品仕様書、性能仕様書、図面が例示されている#7から、必要な事項を体系的に整理したり、図面に表すことも設計開発活動の範疇である。 IAF指針(4)は、設計開発は伝統的に有形の製品を対象とするものと考えられてきたが、製品がｻｰﾋﾞｽの場合にも同じように対象とすることができるとの説明を加えている。 規格の意図において製品の設計開発活動を行う必要があるのは、「組織が、その製品実現ﾌﾟﾛｾｽを計画するために必要な製品の特性を与えられておらず、それら特性を顧客要求事項や規制当局要求事項に基づいて明確にしなければならない」場合である(4)。 製品に関する顧客のﾆｰｽﾞと期待は、顧客要求事項(5.2項)と呼ばれ、それを反映し、他の必要も取り入れて、このような製品なら顧客満足が得られると判断して決定した製品の仕様が、製品要求事項(7.2.1項)である。 “ﾆｰｽﾞと期待”は、必要事項或いは要件（JIS和訳は「要求事項」）でしか表現できないことも多いが、製品仕様たる製品要求事項はそれぞれが「特性」として具体的に、定量的に明確にされていなければならない。 製品仕様が決定されると、これはその製品実現の業務又は工程の目標である「製品の品質目標」に変換され(7.1 a)項)、その実現を図る製品実現の計画に供される(7.1項)。 しかし、組織が把握し決定した当該製品に対するﾆｰｽﾞと期待から直ちに製品の仕様の「特性」まで具体化ができない場合は、設計開発活動によって、ﾆｰｽﾞや期待を必要な「特性」として確定することが必要である。 顧客のﾆｰｽﾞや期待が製品の仕様で示される場合があっても、大抵は性能特性に限られるから、それを満たす既存の製品群がなければ、設計開発活動によって構造特性を新たに決定して製品の仕様を確定する必要がある。 ３． 設計・開発の管理 (1) 設計開発活動の管理 設計開発活動は、考えや必要を具体的なものとして創造する活動である。 未知への旅であるから、予想しない障害に遭遇し進路の変更を迫られることがあり得るが、目標の変更は許されない(5-a)。 活動が多岐にわたり、多くの人々が設計開発活動を分担し、また、組織内外に多くの関係者が存在し、予算や日程の制約もある。 設計開発活動が所定の顧客のﾆｰｽﾞと期待を満たす製品を、定められた期間内で間違いなく創造するためには、設計開発活動を管理された状態で実行することが必要である。 規格は7.3項全体で、設計開発活動の効果的な管理のための要素とそれぞれの要件を規定している。 これらの管理の要点は、次の通りと考えられる。 ① 設計開発活動全体の実行責任者を明確にする。 ② 実行計画を策定し、これを実行管理の基礎とする。 ③ 設計開発活動を機能、目的別の個別活動に分割し、個別の各活動の進捗と結果、及び、活動間の成果引渡しを管理する。 ④ 設計開発活動の担当者、内外の関係者の間の情報交換、協力の体制を維持する。 ⑤ 目標達成に至る設計開発活動の節目を明確にし、節目毎に責任者及び関係者によって各活動の進捗と実績を評価し、全体目標達成のための方向づけを行う。 ⑥ 活動の実績、判断や議論についての記録を残す。 規格における製品の設計開発では、設計開発の目標、つまり、顧客のﾆｰｽﾞと期待たる顧客要求事項を正しく決定することが、とりわけ重要である。 これを誤れば、これを満たす製品を首尾よく設計開発して、その製品を顧客に引き渡しても顧客満足は得られない。 契約や注文を受けた製品では、顧客のなにがしかの意志表示があるが、特定の契約や注文と無関係に新製品の企画、開発を行うような場合は、設計開発目標は組織としての決定事項としなければならないこともある。 この場合は、顧客のﾆｰｽﾞと期待や市場の変化を監視し、新製品の必要を判断する手順が合わせて確立していなければならない。 設計開発で確定された製品仕様は、製造又はｻｰﾋﾞｽ提供により製品として具現化される。 設計開発と製造又はｻｰﾋﾞｽ提供とは業務機能が異質であり、普通はこれらは別の部門或いは別の人々が担う。 規格では設計開発活動は、設計開発の目標の決定から設計開発の結果の製品仕様が顧客のﾆｰｽﾞと期待を満たすことを確認するところまでであり、その責任には購買や製造又はｻｰﾋﾞｽ提供に関する必要事項の明確化も含まれている。 実務では、この設計開発活動の製造又はｻｰﾋﾞｽ提供活動との責任の境界を明確にすること、すなわち、設計開発結果を製品の製造又はｻｰﾋﾞｽ提供に移す手順を明確に決めておくことが重要である。 組織内の製品実現の一連の業務又は工程の一環として設計開発を行う場合は、仕様書や図面の承認、模型試験などによる確認で、製品実現の次の工程に移行する。 試作や顧客での見本による評価又は試験販売によって、製品の顧客満足を確認してから、製品化を決定し、又は、製造又はｻｰﾋﾞｽ提供に移行する場合もある。 また、量産、量販を意図した新製品の設計開発の場合は、製造又はｻｰﾋﾞｽ提供の体制を整備し確立するまで、又は、実際に試験的に製造又はｻｰﾋﾞｽ提供して確認するまで、或いは、顧客に引渡して問題のないことを確認するまで、を設計開発活動に含めるか、設計開発活動の責任を残すというような場合もある。 (2) 設計開発活動の計画 設計開発活動が所定の顧客のﾆｰｽﾞと期待を満たす製品を、定められた期間内で間違いなく創造するための設計開発活動の管理の基礎となるのが、設計開発の実行計画である。 実行計画では、設計開発活動の範囲と責任を明確にし、そのために必要な種々の個別活動を特定し、それぞれの個別活動の目標と責任者、期間、期限を定め、そして、各個別活動間での業務の引渡しの責任を明確にし、更に、節目節目での全体活動の進捗評価と方向づけの機会を決めておくことが必要である。 これら計画は、設計開発の目的など必要事項と合わせて計画書として文書化することが必要である。 計画書は、いわゆるﾌﾛｰﾁｬｰﾄ形式で表されることが多く、複雑な設計開発活動の場合は、ﾌﾟﾛｼﾞｪｸの管理手法である ガントチャート、パート(PERT)チャート、CPMチャートが用いられることがある(7-a)。 計画書の書式や内容は、設計開発の実行管理の手段として適当なものとして決めればよい。 規格は設計開発の実行管理の要素を7.3項で規定しているから、計画書の書式は、これらの要素が明確になり、また、計画の進捗に応じて必要な書き込みが出来、記録としての体裁を考慮したものであるのが実用的である。 ４． 7.3項の要求事項の適用 設計とは「ある目的を具体化するもくろみ」(9)であり、英語でも「考えや必要を具体化すること」というような概念であり、規格の設計開発の定義も「要求事項を特性又は仕様書に変換するﾌﾟﾛｾｽ」と広い。 この定義でも、顧客要求事項の決定、その製品要求事項への変換、製品実現の計画もすべて設計開発の活動と考えることができる。そこで、規格適合性を語る時に問題となるのが、どのような活動に7章の要求事項を適用しなければならないかであるが、それら要求事項の適用が当該の活動の効果的実行に必要か、資するかという点で判断するべきである。 7.3項は、個別の契約又は注文毎の製品実現の計画の一環として、設計開発活動によって製品仕様を「特性」として具体化、確定する業種業態への適用を主体に書かれている。 この場合は、契約又は注文の顧客のﾆｰｽﾞや期待を正しく、一定の期間内で間違いなく、製品仕様に変換しなければならず、7.3項の設計開発の管理はこの目的に最もよく適合する。 しかし、同じ状況の業種業態でも、既成の服にﾎﾟｹｯﾄを付けるなどのﾃﾞｻﾞｲﾝの変更や市販機械部品の顧客使用に合うような修正を例に挙げて、多様な顧客の必要に応えるのに既存の実績のある製品仕様を選択適用したり又は修正するだけの場合は、7章の設計開発活動に当らないという解釈もある(8-a)。 目標が明確であり、簡単な設計開発で直ちに製造又はｻｰﾋﾞｽ提供に移れるからである。 ｶﾀﾛｸﾞやﾒﾆｭｰ型製品の新製品規格や開発の場合など、顧客の特定の意思表示のない状況で、推量したﾆｰｽﾞと期待を満たす製品を設計開発する場合に対しては、94年版ではその設計管理#9の要求事項の適用の必要はなかったが、2000年版では7.3項の設計開発の要求事項は適用すべきと、一般に考えられている(2-b)(5-b)。 これは、設計開発の管理が、94年版では「契約又は注文要求事項」たる「規定要求事項」を満たすことを確実にするためであり、2000年版では、「顧客が契約で決めることも、組織自身が決めることも」ある#8とされる顧客要求事項を製品の特性に確実に変換するためであるという違いで説明することもできる。 しかし、設計開発活動の効果的な実行のためには7.3項の適用が必要であるという規格の趣旨からは、設計開発がどのようなきっかけ、目的かということは 7.3項適用の要否の判断には影響しないはずである。 この観点からも妥当な解釈であると言える。 顧客のﾆｰｽﾞと期待を念頭に置く新規な製品技術の研究開発、或いは、商品化計画のない状況での新規な性能や機能又は構造の製品の探索などに対しては、規格の要求事項の適用は一般に不要とされている。 このような活動の場合は、担当者の創造性や革新性の発揮が重要であり、決められた目標達成を図る規格の管理の手段の適用はあまり意味がないと考えられるからである。 しかし、事業戦略に多少とも関係するのなら、正否を明確にすべき期限を設定し、進捗を管理した方がよいから、7.3項の要求事項をそれなりに適用することも必要になるかもしれない。 また、製品実現の計画は、定義から ﾌﾟﾛｾｽ の設計開発に相当する。 従って、規格適合性上では「製品の設計開発」(7.3.1項)と限定された7.3項の適用の必要はない。 しかし、製品実現の計画活動が長期間を要し、活動が単純でなく、関係者が多い場合など、或いは、結果の適切さを、試作や試験又は試験販売で確認する必要がある場合などでは、設計開発管理の手順の適用が、計画活動を円滑に進め、期間内に完了させる上で効果的であることもある。 規格が製品実現の計画活動への7.3項適用の可能性に言及しているのは、この意味からである(7.1項 参考2)。 ５． 規格要求事項とその真意 7.3項では、所定の狙いを所定の期間、資源で完了するよう効果的に設計開発活動を行うために必要な管理の要件が規定されている。 この管理の要件は、7つの管理項目に分けて、7.3.1～7.3.7項に、それぞれに規定されている。 7.3.1項 計画 = 実行管理の基礎となる設計開発活動の計画を策定する 7.3.2項 ｲﾝﾌﾟｯﾄ = 設計開発の目標を正しく、明確に決める 7.3.3項 ｱｳﾄﾌﾟｯﾄ = 設計開発の結果を目標に照らして明確にする 7.3.4項 ﾚﾋﾞｭｰ = 進捗と結果の体系的評価により、活動を目標達成に方向づける 7.3.5項 検証 = 結果が目標を満たしていることを確実にする 7.3.6項 妥当性確認 = 結果の製品の所定の使用に対する実用性を確実にする 7.3.7項 変更管理 = 変更がもたらす問題に対処する 組織は、設計開発の対象を明確にし、設計開発の着手を判断する責任、設計開発を実行する責任を含む、製品の設計開発に関する手順を確立し、その中で、7.3.1～7.3.7項の要求事項を満たすように、設計開発活動を管理する手順を確立しなければならない。 設計開発の活動はこの手順に則って実行され、管理されなければならない。 (1) 製品の設計・開発の計画を策定し、管理する [第1節] 標題の英原文は、 design and development planning であり、品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑのけ計画(5.4.2項)や製品実現の計画(7.1項)と同じ planning （計画活動）である。 条文は、 plan and control (計画し、管理する) である。 planning も plan も、規格の中の他の「計画」と同じく、「前もって手はずを整える」(6)であり、一般には手順と資源を用意することである。 しかし、この場合は、設計開発の実行を管理する基礎となる計画の意味であり、必要な活動、責任者、日程を中心に手順と資源を用意するという内容の実行計画を意味する。 この意味で「計画を策定する」とのJIS和訳は適当である。 設計開発活動の実行管理を効果的に行うためには、普通、計画は文書に記述することが必要である(4.2.1 d)項)。 組織は、設計開発活動が所定の期限内に所定の結果を出すことを確実にするために、設計開発活動を計画し、文書に記述する手順を確立しなければならない。 設計開発活動の定められた必要が生じた場合は、定められた実計画書を作成し、これを用いて設計開発活動の実行を管理しなければならない。 (2) 設計・開発の計画において、次の事項を明確にする [前段記述] 「明確にする」は determine で、「決定する」である。 所定の結果を所定の期間、予算内で確実に出すための効果的な設計開発活動を定め、必要を用意し、かつ、実行管理の基礎とするために、設計開発の実行計画を策定することが必要である。 この計画を効果的なものとするためには、計画の中で次のa)～c)項を決定し、明確にしなければならない。 (3) 設計・開発の段階 [ a)項] 設計開発活動では、予期せぬ結果が生じたり、進捗に手間取ったり、多くの設計開発事項があると各事項の設計開発活動の進捗に食い違いが生じたりすることがある。 未知の部分があると、それを解決しないと、次の設計開発の活動の詳細を決めることができない。 複雑な製品の、また、長期間にわたる設計開発ほど、このような問題が起き易い。 設計開発の最終期限が来てから問題に気付いても遅い。一歩一歩着実に、しかし真っ直ぐに、期限内に目標を達成するような設計開発活動とすることが必要である。 これには、設計開発活動を最終目標までの進捗に係わるいくつかの段階に分け、それぞれの段階で機能や目的別に個別の活動に分け、それぞれの日程や期間を明確にする管理の方式が効果的である。 この方式では、個別活動間の相互関係が明確にされ、全体責任者や関係者によって段階毎に、かつ、決められた時期に進捗が評価され、時に計画の活動が見直され、次の段階以降の方向づけが行われる。 設計開発の計画書には、このような段階と各段階の個別活動と相互関係と日程、及び、これらから成る設計開発活動全体の構造や構成をうまく表すことが大切である。 なお、機械製品などを中心によく見られる設計開発の段階としては、ﾌｨｰｼﾞﾋﾞﾘﾃｨｽﾀﾃﾞｨ(実現可能性検討)、概念設計、構造設計、詳細設計、開発(試作評価など) などがあり、 顧客による評価、生産準備、量産試験などの実用化の段階や、新製品の仕様設計が設計開発活動に含められることがある。 (4) 各段階に適したﾚﾋﾞｭｰ、検証及び妥当性確認 [ b)項] 設計開発の計画では、設計開発活動が間違いなく目標を達成するために必要な、設計開発の各段階の実行状況と結果の監視又は評価の方法を決めておくことが必要である。 監視や評価の方法には、ﾚﾋﾞｭｰ、検証、妥当性確認がある。 ﾚﾋﾞｭｰ は、「ある事項が所定の目標達成という観点で適当か、十分か、有効かを決定するために行われる活動*」#12であり、 設計開発活動を目標達成に方向づけるために活動の目標や前提条件、進捗や結果を評価、検討する活動である。 検証は、「規定要求事項が満たされことを客観的証拠によって明らかにすること*」#13であり、設計開発の各活動がその狙いの通りであることを科学的に証明する活動である。 妥当性確認は、「特定の意図された使用又は適用に関する要求事項が満たされことを客観的証拠によって明らかにすること*」#14であり、設計開発した製品が実際に使用されて問題が起きないことを証明する活動である。 いずれも、PDCAｻｲｸﾙのP,Aに相当する活動であり、それぞれに関する要件は、7.3.4, 7.3.5, 7.3.6の各項に規定されている。 これらの活動は基本的には、全体としての設計開発活動、及び、設計開発活動の各段階に関して実施することが必要である。 また、規格では言及していないが設計開発活動の各段階がそれぞれ特定の目的、目標の個別活動から構成されている場合は、それらのそれぞれについても実施することが必要である。 しかし、これらはすべての場合に一律である必要はなく、それぞれの段階や活動の目的や重要性に応じた規模や詳しさ、方法でよい。 とりわけ妥当性確認は本来、最終製品に関して実施するべきものであるから、その前の段階では実施しないのが普通である。 設計開発活動の計画では、どの段階でどのような ﾚﾋﾞｭｰ、検証、妥当性確認を実施するか、必要かつ十分なものとして決めておかなければならない。 (5) 責任及び権限 [ c)項] 責任及び権限は、人々や各ｸﾞﾙｰﾌﾟ又は個別の各活動の役割の意味である。 設計開発の計画では、定めた個別活動を初め、各段階で行う ﾚﾋﾞｭｰ、検証、妥当性確認など各業務、活動に関して、実行し、参画し、承認する人々を明確にしていなければならない。 (6) ｸﾞﾙｰﾌﾟ間のｲﾝﾀｰﾌｪｲｽを運営管理する [第3節] ｲﾝﾀｰﾌｪｲｽ (interface)は、2つのものが会い又は作用し合う「接点」のこと(1)であり、転じて、「接点で生じる相互作用又は行われる情報交換の手段」の意味を持つ(10)。 解説書(5-d)(7-b)(8-b)では、情報交換の機会と方法というような意味に解されている。 また、JIS和訳「責任の割当」の英原文はassignment of responsibilitiesであり、「責任の分担」の方が条文の意図に適う。 すなわち、規格の意図は、「組織は、設計開発活動を行う異なるｸﾞﾙｰﾌﾟ間の接点の業務を、効果的な情報交換と明確な責任分担を確保できるように管理しなければならない」ということである。 多くの人々が機能や目的別のｸﾞｰﾌﾟに分かれて個別の活動を分担するような設計開発活動では、その効果的な推進のためには、相互の意思疎通、情報共有、共通理解が不可欠である。 関連ある個別活動同士では相手の進捗状況を知っておくことが必要であり、相手の活動に影響する事項は相互に連絡し合うことが必要である。 また、ある事項は相手からの連絡を待っていればよいのか、こちらから働きかけなければならないのか、或いは、この事はあのｸﾞﾙｰﾌﾟ又は活動で処理されるのか、自分のｸﾞﾙｰﾌﾟでやらなければならないのか等々の ｸﾞﾙｰﾌﾟ間の責任分担が共通認識となっていなければならない。 ｸﾞﾙｰﾌﾟ とは、設計開発活動に係わる人々のことであり、組織内で設計開発を直接分担する人々だけでなく、製品のﾆｰｽﾞに係わり合いのある人々、予算などで設計開発活動を支援する人々などの関係者を含み、更に、設計開発の請負い者、設計開発した製品の原料や部品の納入者、顧客など組織の外の人々も含まれる。 多くの人々、部門が品質ﾏﾈｼﾞﾒﾝﾄの目標に向かって協働している組織において、業務が効果的に行われるための組織の管理（ﾏﾈｼﾞﾒﾝﾄ）に、ﾄｯﾌﾟのﾘｰﾀﾞｰｼｯﾌﾟ(5.1項)、責任及び権限の割当(5.5.1項)、内部ｺﾐｭﾆｹｰｼｮﾝ(5.5.3項)、外部関係者とのｺﾐｭﾆｹｰｼｮﾝ(7.2.3項)の必要をはじめ、各条項で各業務の要件が規定されているが、組織全体よりは小規模だが多くの人々、ｸﾞﾙｰﾌﾟが協働する設計開発活動にも同様の必要がある。 これを規格は 本条文で、接点の管理(ﾏﾈｼﾞﾒﾝﾄ)とひと言で言っている。 具体的に接点の業務とは、設計開発活動を分担する個別の活動、関係する部門、外部の組織の関係者の間での、業務結果のやりとり、文書のやりとり、情報のやりとり、或いは、相互連絡といったようなことである。 設計開発活動の規模によるが一般には、節目での ﾚﾋﾞｭｰ、検証、妥当性確認の活動を必要な関係者の参画、参加を得て行うこと、関係するｸﾞﾙｰﾌﾟ間の定期会議の開催や定期報告書の交換(7-b)、設計開発記録の交換(8-b)などが、接点業務の管理の方法とされる。 (7) 設計・開発の進行に応じて、計画を適宜更新する [第4節] 「適宜」の英原文は、 as appropriate であり、「必要なら」の意味である。 設計開発活動の進捗によって未知の部分が明確になり、また、予想外の問題に遭遇することがあるから、一旦決めた設計開発の計画を詳細化し、又は、変更する必要が生ずる。 当初計画に追加や変更の必要が生じたならば、最新の状況を反映する計画に更新しなければならない。 当然、それぞれの活動の責任者が承認しなければならず、他の活動或いは全体の設計開発活動に影響する変更は、関係者の承認と全体責任者の承認が必要になる。 他の活動に影響を及ぼす計画の変更の連絡、協議、その活動の責任者による承認は、上記(6)の接点業務の管理の事例でもある。 引用規格条項 #1 ISO9000, 3.4.4 #2 ISO9000, 3.4.4 参考1. #3 ISO9000, 3.5.1 #4 ISO9000, 3.5.1 参考1. #5 ISO9000, 3.7.3 参考 #6 ISO9000, 3.4.2 参考1. #7 ISO9000, 3.7.3 #8 ISO9000, 2.1 #9 ISO9001:1994, 4.4.1 #10 ISO14001:2004, 4.3.1 #11 ISO9000, 3.5.2 引用文献 (英文献及び 文中の* 印は著者による翻訳) (1) S.Wehnmeier他: Oxford Advanced Learner’s Dictionary, Oxford University Press (2) C.MacNee他: Transition to ISO9001:2000, BSI Publications,2001; a-p.37, b-p.35 (3) 日本規格協会: JISQ9001:2000規格書, 巻末解説, 3.2 f), p.解12 (4) ISO/TC176: ISO9001:2000“1.2 適用”に関する指針、N524R3,13 February 2002;付属書,指針2 (5) D.Hoyle: ISO9000 Quality systems Handbook,Butterworth-Heinemann,2001; a-p.401, b-p.356，c-p.357, d-p.412 (6) ISO/TC176: ISO9001/9004:2000の用語に関する指針、17 May 2001, N526R (7) C.A.Cianfrani他: ISO9001:2000 Explained,ASQ Quality Oress,2001; a-p.92, b-p.93 (8) ISO/TC176: ISO9001 for Small Businesses, ISO中央事務局,2002; a-p.91, b-p.93 (9) 新村 出: 広辞苑、第3版、岩波書店、昭58年12月6日 (10) Merriam-Webster’s Collegiate Dictionary, Merriam-Webster Inc |
| H20.2. 8(改 H20.3.9) |
 |
 |
禁無断転載 (個人的使用のための複写歓迎) |
|
| ｻﾆｰﾋﾙｽﾞ ｺﾝｻﾙﾀﾝﾄ事務所 〒458-0031 名古屋市緑区旭出２－９０９ | |||