ISO9001/ISO14001 コンサルティング・研修
39 7.3.1項  設計・開発の計画 実務の視点による
ISO9001:2000の解説(新版) 
35-02-39
7.3.1 設計・開発の計画
[第1節] 組織は、製品の設計・開発の計画を策定し、管理しなければならない。
[第2節] 設計・開発の計画において、組織は次の事項を明確にしなければならない。
a) 設計・開発の段階
b) 設計・開発の各段階に適した レビュー、検証及び妥当性確認
c) 設計・開発に関する責任及び権限
[第3節] 組織は、効果的な コミュニケーションと責任の明確な割当てを確実にするために、設計・開発に関与するグループ間のインターフェイスを運営管理しなければならない。
[第4節]   設計・開発の進行に応じて、策定した計画を適宜更新しなければならない。
 
 
1. 要 旨

  7.3項は、顧客のニーズと期待、ないし、製品に関する必要条件(7.2.1項)を製品の具体的な製品仕様と品質及び付帯仕様として決定する活動である設計開発活動が、所定の設計開発結果を間違いなく、また、所定の期間や予算で達成できるように設計開発活動を管理する必要とその要件を規定している。組織は、品質マネジメントシステムの計画 (5.4.2項)の一環として設計開発活動の効果的実行を管理する設計管理の手はずを7.3項に規定される要件を満たすよう確立し、この手はずに基づいて個々の契約又は受注に対する設計開発の実行を管理しなければならない。
 
  本項では、設計開発活動の効果的な実行管理の基礎として、設計開発の計画を策定する必要、及び、その要件を規定している。
 
  設計開発活動は、個々の契約又は注文に対して必要な設計開発結果を所定の期限までに確実に出すことができるような実行計画の下で行わなければならない。この実行計画では、目標、手段、日程、責任者、及び、進捗管理の方法を明確にし、それぞれの設計業務実行の手順を決め、必要な資源を割当て使用できるようにしなければならない。設計開発活動は、この実行計画と定められた手はずに則って実行し、活動の進行により目標の達成のために必要が生じれば手はずを変更しなければならない。組織は設計開発活動を管理する手はずの中に、設計開発の実行計画を決める手はずを含めなければならない。
 
 
2. 背景 及び 関連事項
2-1. 設計・開発
(1) 設計開発
  規格の『設計・開発』は『要求事項を製品、プロセス、システムの、規定された特性又は仕様書に変換する一連のプロセス』と定義される#27。本項は製品の設計開発であるから、『要求事項』はJIS和訳『製品要求事項』を指し、製品関連要件 (7.2.1項)のことである。これは規格では顧客関連要件 (5.2項)と呼ばれる顧客のニーズと期待を満たす製品はどのようでなければならないかを、組織が満たすべき製品の仕様や品質の必要条件として表したものである。製品の仕様や品質を具体的定量的に表す指標が『特性』である。『仕様書』は『要求事項を記述した文書』と定義され#26、注記に『製品仕様書、性能仕様書、図面』が例示されているから、この場合は製品の一連の『特性』を列記した文書を意味する。
 
  一般に顧客のニーズと期待は製品の機能や性能の形で表され、製品関連要件 (7.2.1項)とは、製品に必要な機能や性能とその水準で表される。一方、これはどのような製品かという場合は例えば製品を構成する材料の種類、寸法や形状、部品構成や組立て手段等々の、製品仕様と品質で実現される。設計開発とは製品の機能や性能の必要条件を満たすことのできる製品仕様と品質を決める活動である。
 
  規格執筆者のひとり(22m)は、「組織が製品実現のプロセスの計画に必要な製品特性の詳細を与えられていないか、まだ把握していない場合には、製品の設計開発を行うことが必要である」と説明している。製品実現に必要な特性とは製品仕様と品質、更には付帯的仕様のことであり、組織がこれを製品関連要件としての必要な機能や性能とその水準からは直ちに決めることができない技術的不確定要素がある場合には設計開発活動が必要になる。必要と判断した機能や性能とその水準を満たす構造や機能或いは製品仕様と品質が、確立した手順に則って直ちに決めることができるような形態の取引や製品では設計開発活動は不要である。このような場合の製品仕様と品質を決める活動は規格では製品実現の計画 (7.1項)であり、実務的には品質設計と呼ぶ。
 
(2) 特性
  規格では、あるもの、ある物事がどのようなものであるのかは『特性』として表される。原文は"characteristic"であり、規格では「際立った/顕著な特徴/特質」と定義される#26。『特性』とは言っても「性質」という意味ではなく、ものや物事の様々な特徴、特質という意味であり、それがどのようなものか、他とどのように異なるかを特性指標とその水準の特性値によって具体的に表すことができるという概念の『特性』である。目に見えるハードウェア製品だけでなく目に見えないサービスも『特性』で表され、製品だけでなく プロセス(業務)や システム業務体系)もどのようなものであるかはそれぞれ一連の『特性』で表される。ただし、 規格には、特性指標や特性値という表現が見られないから、用語『特性』が指標と水準を包含した具体的、定量的な特徴/特質という意味で用いられていると受けとめるのがよい。
 
   規格では、『特性』には、物質的な(機械的、電気的、化学的、生物学的など)、感覚的な(嗅覚、触覚、味覚、視覚、聴覚的など)、行動上の(礼儀正しさ、正直さ、誠実さなど)、時間に関係する(正確さ、信頼性、利用可能度など)、人間工学的な(生理的、安全性など)、機能上(飛行機の最高速度)の、各『特性』があると説明されている#26-1。
 
 例えば、金属薄板がどのようなものかは物質的な特性である化学成分と機械的性質及び寸法という『特性』で表すことができる。ここに機械的性質という『特性』は例えば強度や加工性の指標と水準で表される。置き時計がどのようなものかは、物質的な特性である寸法、デザインや素材、構造と時間に関係する特性である正確さ、信頼性という『特性』で表すことができる。時間に関係する特性である正確さは例えば1年間で生じる進みや遅れの時間という指標と水準で表される。レストランの料理は物質的な特性である素材、外観、食器と感覚的な特性である味覚、嗅覚、視覚で表すことができる。感覚的な特性である味覚は例えば想定対象客層に合うかどうかを指標とし関係者の試食評価で水準が決められる。
 
@ 性能特性と構造特性
 製品の『特性』は実務的には、製品はどのようなものかの製品の実体を表すのに用いる構造特性と、製品が顧客に提供する価値に関する性能特性に分けて考えることができる。前者は製品の構造や媒体、寸法、外観などに関する『特性』であり、後者は機能、性能、効用、効能などに関する『特性』である。ある製品を特定又は識別するには一般に、この両『特性』を明確にすることが必要である。
 
  これを製品4類型#13-1で考えると例えば、ハードウェア製品や素材製品の構造特性は、外観、寸法、構造や構成要素、組成、動作機構などであり、性能特性には機能、性能、強度、美麗さなどがある。 ソフトウェア製品では、コンピュータープログラム゙など情報の種類や表現、構成とその担体、装丁が構造特性であり、それにより何ができるか、何に役立つかの特徴が性能特性である。 サービス製品の場合は、輸送業の何を何でどこに運ぶかに関する特徴、納税申告代行業では財務諸表や申告書の内容の特徴、食堂業の料理の特徴が構造特性であり、迅速さや品質保持能力など、正確さや作成に必要な資料の少なさなど、味や食器の感じなどが、それぞれの性能特性である。今日、顧客は地球環境保全に対する関心と利害関係を強めているから、顧客に提供する価値として製品の環境破壊への影響の少なさ又は環境保全への寄与の大きさが重要となってきている。ISO14001の「製品・サービスの環境側面」#10は、ISO9001では製品の性能特性に相当する。
   
  規格の概念における7.1 a)項の製品に対する品質目標 は『特性』の狙い及び許容範囲を具体的、定量的に表すものであり、製品関連要件 は必要な『特性』の指標とその水準を概念的又は定性的に表すものと考えるのがよい。
 
製品の設計開発は一般に、製品関連要件 から決められる必要な性能特性を基にして、これを実現する構造特性を決める活動である。決められた製品関連要件から狙いの性能特性を決める活動が設計開発活動に含まれる場合もある。
 
A 品質特性
  なお94年版では品質#2-1は実質的に特性指標の水準又はその優劣を指し、顧客と合意の合否判定を基準に優劣が判断され、優れていれば顧客満足が得られると考えられていた。00年版では顧客の想いを受けて組織が合否判定基準を決めるが、特性指標の優劣がこれを基準に判断されることには変わらない。しかし、00年版では特性指標とその水準を顧客がどのように受けとめるかが製品の顧客満足度である。00年版では品質#2-2の定義において『特性』の優劣の基準を顧客の受けとめ方に置くべきことを明確にし、品質が実質的に顧客満足度のことを指すことになった(2a)。
 
  また、00年版では顧客満足に関係する製品やプロセス(業務)の『特性』は『品質特性』と呼ばれる#2-3。この品質特性は、製品やプロセス(業務)に固有の『特性』を指し、価格など製品の本質ではない付与され『特性』は品質特性ではないとされている#2-3-1。つまり、規格の顧客満足の追求は価格を直接的手段とすることを意図していないということである。
 
(3) 設計と開発
  94年版では『設計(design)』であったが、00年版では「設計及び開発(design and development)」となった。 この用語の変更の理由として規格執筆者のひとり(22n)は、同じような活動でも産業分野によっては「設計」と呼び、「開発」と呼び、更には、「設計及び開発」と呼ぶなど様々であるので、より広く受け入れられるような用語としたと説明している。規格では世の中では「設計」と「開発」が同義語である場合と、全体の設計開発活動の中の異なる段階を指すものとして使われる場合があると説明している。JISはこの説明を受けて『設計・開発』と表記したと説明している(146a)。
 
  英語では"design"は「物事がどのようなものか、どのように機能するのかを、図面を作成したり、模型を作ったりして、決める活動」であり、"development"は「何か新規な又は進歩したものを作る、又は、創造する活動」である(101)。日本の産業界の実務では一般に「開発」の方が「設計」より目標と方法に新規な要素が多く、目標達成の不確かさが高いというように受けとめられるから、「設計」と「開発」の違いは英語の"design"と"development"の違いに対応している。「設計開発」という言葉もよく使われるが、多少なりとも開発的要素が含まれる設計活動を指すことが多い。
 
   
2-2. 設計管理
(1) 設計管理の意義
  規格格の意図の品質保証における設計管理の重要性について、94年版関連の指針規格(145b)は「製品の安全性、性能、信頼性のような必然の品質や法規制要件は設計開発段階で決まる。設計の欠陥が品質問題を引き起こす主因となることがある。」と説明している。米国の食品医薬品局(FDA)が1996年に医療機器に関する規制を見直し、設計管理の要件を含めた時にはその背景を「統計によると医療機器のリコールの44%が不適切な設計管理の結果である」と説明していた(84)。苦情の対象でなくとも、例えば、性能劣化が速い、錆び易い、故障し易い、壊れ易い、扱いにくいなどという種類の顧客の不満の原因のほとんどは設計開発の問題である。
   
製品実現における不良品、異常品の発生防止とそれらの除去を確実にする日常の品質管理、品質保証の活動は、設計開発結果で決めた製品仕様と品質を満たすことを確実にする活動であり、その製品仕様と品質が顧客のニーズと期待に応え得るものであることを確実にする活動が設計管理活動である。これに関して00年版指針規格(132j)は、製品の設計に当たっては、製品の基本的機能や性能だけでなく、安全と健康、試験容易性、有用性、使い勝手、信頼性、耐久性、人間工学的観点、環境への影響、廃棄、起き得る問題対応など顧客が潜在的に期待している性能についても考慮しなければならないと説明している。
また、設計開発結果で決めた製品仕様の良し悪しが製品実現における不良品の発生と検査や試験での見落としに影響する。設計開発結果の製品仕様と品質は製品実現の業務手順、必要な資源を決め、製品実現コストに影響を及ぼし、供給者の選定の自由度を制約する。設計管理の狙いには、製品実現業務から顧客の製品使用と廃棄に至るまでの様々な問題を前広に予測し、対処し、発生の防止を図ることが含まれる。
 
(2) 設計管理の方法論
  最初の品質保証規格とされる米国の兵器購入契約条件たるMILQ5898Aの設計管理は製品図面の管理を扱ったものであるが、日本製品の品質競争力に対応して1979年に作成された英国の品質保証規格BS9999では設計管理の要件が規定されていた。
 
  これを基礎として作成された1987年のISO9001初版(4.4)では、設計管理の5種の要素と要件が規定されていたが、94年版(4.4)で『設計審査(デザインレビュー)』が独立した設計管理要素となり、『設計の妥当性確認』が新たな設計管理要素として追加された。つまり、 初版の設計管理では、『設計審査(デザインレビュー)』が『認定試験、立証』や『別法による計算』と同列の『設計検証』のひとつの方法として規定されており、『設計の妥当性確認』の概念は存在していなかった。レビュー と妥当性確認 は、米国の軍需産業と航空宇宙産業の高価で複雑な製品の、使用時の間違いない機能性能の発揮と故障の防止といった信頼性、爆発や不慮の事故における乗員や操作員に対する安全性といった問題を防止する設計管理の方法論として開発され、主として供給者にその実行が求められた。
 
  また、設計開発活動の責任分担と関連部門の参画に関する規定と記述が初版から94年版を経て整理され00年版で確定した。00年版の設計管理の方法論は、設計開発活動の計画、インプット、アウトプット、レビュー、検証、妥当性確認、設計変更 という7種の設計管理要素とそれぞれの要件とで構成され、08年版にもごくわずかな文言の変更だけでそのまま受け継がれている。
米国食品医薬品局(FDA)の1996年制定の医療機器に関する設計管理規定(21 CFR Part820)(84)もこの7種の管理要素を基礎として、生産移行の管理、設計履歴記録の保存、危機及び危害予測の実行の3つの設計管理要素が追加されているが、これらは実質的にISO9001の7要素に含まれているから表現だけの違いであり、ISO9001の設計管理の方法論と同じである。このことから1990年代半ばになって世界の各界で設計管理の方法論が整理され、7種の設計管理要素として定着しつつあったものと考えられ、今日のISO9001の設計管理の方法論が事実上の世界標準となっていると考えられる。
 
  日本でも機械、造船、土木建築、自動車産業など製品設計がISO9001と同等の管理要素と要件を踏まえた設計管理の方法論の下で設計開発の管理が行われてきたことを窺わせる設計管理の概念と手法の書籍や報告も少なくない。「設計審査(デザインレビュー)」は1976年発足の日科技連の信頼性デザイン・レビュー委員会(83a)の音頭で1980年代に大企業を中心に拡がったといわれる。ただし、「設計計画」「設計審査(デザインレビュー)」を除いて、7つの管理要素の用語がそのまま用いられ、それぞれの活動として区別されて行われているということではない。例えば、検証 と妥当性確認 は一般に「品質確認」と呼ばれる活動に含まれ、目標通りの製品仕様と品質の具現化の管理は例えばt「品質追求」や「品質つくりこみ」という用語と概念で整理されている。
 
(3) 規格の設計管理論
  世界標準の設計管理7要素は、航空宇宙産業のような高度に複雑な、全くの新規の、或いは、ある意味で未知の用途に対する製品の設計開発をも包含する設計管理の方法論である。ISO9001の規格の設計管理は、品質保証の観点からの設計開発の各活動の実行管理に限定されたものであり、受注と品質設計活動でこうだと決めた顧客のニーズと期待、ないし、これを反映した「製品に関する必要事項」すなわち製品関連要件(7.2.2項)を満たすよう設計開発目標の製品仕様と品質を決め、これを確実に実現させるよう設計開発の各活動の計画と実行と結果を管理することが狙いである。設計管理要素と要件は同じでも、適用或いは満たし方は、このような設計開発の性格と組織の業種業態や設計開発製品に応じた適当なものとすることが大切である。
 
2-3. 7.3項の適用除外
  ISO9001規格は94年版ではISO9001、ISO9002、ISO9003に分かれており、組織の狙いの品質保証の水準に応じて、組織がいずれかの規格を選択することとなっていた。00年版ではすべての業種業態に適用する品質保証を含む顧客満足追求を狙いとする規格としてISO9001に一本化された。このため、組織によっては規格の定める業務が存在せず、又は、特定の規定の適用の必要のない、或いは、適用が不可能な場合があり得ることになった。このような状況に対して規格は『適用除外』という形式を定め、特定の規定を適用しなくても組織の品質保証・顧客満足追求に支障を来すことのない場合があり得ることを明確にした(1.2項)。
 
(1) 成約又は受注した製品に対する設計開発
  TC176指針(1a)では、規格の意図において製品の設計開発活動を行う必要があるのは「組織が、その製品実現プロセスを計画するために必要な製品の『特性』を与えられておらず、それら『特性』を顧客関連要件 や規制当局による規制 に基づいて明確にしなければならない」場合であるとされている。
 
  製品実現の計画(7.1項)は、個々の契約又は注文に対して、顧客のニーズと期待を満たすよう狙いの製品仕様と品質及び付帯仕様を決め、そのような製品を確実に創り出し顧客に引き渡すことができるように製品実現関連業務の実行方法や条件を決める活動である。この狙いの製品仕様と品質及び付帯仕様は『製品に対する品質目標及び要求事項』(7.1 a)項)であり、具体的、定量的に表されていなければならず、規格の表現では一連の『特性』で表されていなければならない。これは顧客関連要件(5.2項)から決められた製品関連要件(7.2.1項)に基づいて製品実現の計画活動の手はずに則って決められる。
 
  例えばプロジェクト型産業や造船、建築、仕立て業、特注機械製造業などでは、顧客の要求に応じて契約や注文毎に異なる多様な製品仕様と品質の製品を創り、引渡すという形態の取引である。このような取引では、顧客の要求は製品の性能機能に関する必要条件が中心であり、個々の契約又は注文の顧客関連要件 や製品関連要件 から組織が満たすべき製品の仕様と品質及び付帯仕様 を『特性』として決めることは一般に技術的に不可能である。組織は、製品に関する必要条件を決める手はず(7.2.1項)に則って顧客関連要件 から製品関連要件 を決め、これから設計開発活動によって製品の仕様と品質及び付帯仕様を『特性』として決める。すなわち、製品実現関連業務の中に設計開発活動を含めることが必要である。
 
  食品包装機械製造業では、顧客関連要件 は省力化、多品種混合生産、騒音規制適合であり、製品関連要件は取扱い可能品種と性状、箱の材質と形状、必要な箱詰め能力、要員数、騒音水準であり、これを満たすように設計開発活動によって機械と部材・部品の構造、適用材料、形状、性能、更に、制御ソフトや付帯設備等の製品仕様と品質 及び付帯仕様 を決める。戸建て住宅建設業では、顧客関連要件 は所有する土地に老親と小中生の二人の子供とエコで大地震に耐えて安楽に過ごすことであり、製品関連要件 は家の造り、間取り、照明やコンセントの位置、内装であり、これを満たすように設計開発活動によって基礎や木組み、屋根の構造、内外壁、窓や扉、給排水や電気配線など詳細な製品仕様と品質及び付帯仕様 を決める。
 
  TC176商業本(20g)では、これと同じ状況の業種業態でも例えば、既成の服にポケットを付けるなどのデザインの変更や市販機械部品の顧客使用に合うような修正を例に挙げて、多様な顧客の必要に応えるのに既存の実績のある製品仕様を選択適用したり又は修正するだけのような場合があり、この場合には設計開発活動は必要でないと説明している。
 
  さらに、カタロク製品やメニュー又は店頭の現物に基づく取引では、製品関連要件 は製品仕様と品質 さらに付帯仕様 そのもので表される。自動車販売業では注文はカタログ表示の車種と選択可能仕様で受付け、レストラン や ホテル では用意した メニュー や宿泊プラン表から顧客が購入する料理やサービス名を指定する。家電や自動車、その他の一般消費者向け製品の製造業では、注文を製品名と色や性能区分などの副仕様を明確にして受ける。つまり、製品関連要件を決める段階で既に『特性』がわかっている。これを製品に対する『品質目標及び要求事項』 として直ちに製品実現の計画 活動を進め、また、製造及びサービス活動の実行(7.5項)に入ることができる。在庫生産方式の場合は直ちに、該当する製品を倉庫から出荷する。すなわち、製品実現関連業務の中には設計開発活動は必要がない。
 
  また、多くの受注量産型の事業がそうであるように、予め合意した製品仕様と品質の製品を契約又は注文毎の顧客の特定の要求やニーズに合わせて創り、引渡すような取引形態も少なくない。組織は契約又は注文毎の顧客の特定の要求に基づき背景のニーズと期待を推定し、満たすべき製品仕様と品質の必要条件たる製品関連要件 を決める。これに基づき、確立した製品実現の計画 の手はずに則って製品の『特性』を決め、『製品に対する品質目標及び要求事項』(7.1 a)項)として表す。従って、このような取引でも製品実現関連業務の中に設計開発活動は必要がない。
 
  例えば金属材料製造業では受注に際して基本的な 顧客関連要件 を鋼材規格名と寸法という具体的な製品仕様 の形で顧客と合意し、注文に独特の用途や納品条件など背景を勘案して製品関連要件 を決める。これを基にして、基本契約に定めた詳細な要件、例えば当該注文に特有の寸法精度や表面欠陥許容限界を織り込み、満たすべき製品仕様と品質及び付帯仕様を決める。金属熱処理業では、支給される金属部品に必要な機械的性質という製品仕様で注文を受ける。組織は用途などこの顧客関連要件 の背景の顧客のニーズと期待、又は、基本契約の詳細仕様とから製品関連要件 を決め、対象の金属部品の化学成分や形状から熱処理条件を決める。
 
  ただし、このような受注量産型の事業でも新規な製品の引き合いや初回注文の場合には設計開発活動が必要な場合もある。例えば、顧客の新規機能製品用の素材や部品の引き合いにおいて、顧客関連要件 から製品関連要件 への変換は出来ても、それを満たす具体的な製品仕様と品質、つまり、製品の『特性』を決めることが、確立した製品実現の計画 の手はず或いは過去の経験などから技術的に不可能な場合である。顧客の新型自動車の狙いの排ガス清浄度を満たす性能の排ガス浄化装置の仕様、顧客の新型ガスタービンの高温環境に耐え得る材料の仕様の決定には、試作品の顧客の評価を含む設計開発活動が必要となる。
 
(2) 新商品企画における設計開発
  カタロク製品や メニューによる販売、或いは、量産・量販一般消費者向け製品製造業などでは、日々の契約又は注文受付と製品を創り、顧客に引渡す活動とは別の活動として、次の商品の企画開発が日常業務として行われている。その他の事業でも必要に応じて事業戦略としての製品の範囲の拡大、事業分野の拡大や新規分野への進出が検討される(5.6.3 b)項)。
 
  このような場合の新商品企画は売れる製品を企画することであり、ニーズと期待に関する顧客の意思表示のない状態の中で諸情勢から対象顧客範囲と潜在的に必要又は期待される製品の仕様と品質を確定する活動である。新商品企画活動は一般に、潜在ニーズの把握、製品像の企画、製品仕様と品質の決定、市場評価の各段階から成る。企画した製品像(製品関連要件)を製品仕様と品質に展開することに技術的に不確定要素がある場合は、設計開発活動が必要となる。しかし、設計開発の結果で明確にされ、図面に表され又は試作された仕様と品質の製品にとって最も大切なことは、企画の製品像を満たしているかどうかの如何によらず、売れる可能性がどれほどであるかである。このため、新商品企画の設計開発活動は一般には市場調査や顧客での試験など市場評価を含み、その最終評価と判断を以て完了する。この結果で商品化が決まれば、設備や要員の手配を初め事業活動規模での変更が生じる。これは規格では品質マネジメント システムの変更(5.4.2 b)項)である
 
  一方7.3項は製品実現業務を規定する7章にあり、その設計開発活動は個々の契約又は注文を受付けて、製品を創りあげ、顧客に引渡すための一連の製品実現業務の一環として行われる活動である。7.3項の規定は、契約又は注文の顧客の製品に対する想いである顧客関連要件 を基礎に、満たす必要があると組織が決めた製品に関する必要条件、つまり、製品関連要件 を『特性』の形の製品仕様と品質に、正しく、所定の期間と予算内で変換するための管理の要件である。この結果により、新しい製品としての新しい手順や基準が組織の製造及びサービス活動実行(7.5項)の手はずの中に加わる。
 
  7.3項の設計開発活動は成約又は受注した製品の製品実現業務の一環の日常的活動であり、その結果は新商品企画活動の中の設計開発活動は製品を創り、引渡すという日常活動とは異なる戦略的な活動である。7.3項には、商品企活動に重要な、新商品が対応すべき顧客関連要件 の決定や、それを製品関連要件 へ変換すること、また、設計開発結果が狙いの顧客満足を満たすかどうかの観点からの評価することに関する手順と要件の規定は含まれていない。従って、新商品企画活動としての設計開発活動の管理に7.3項を適用することは規格の意図ではなく、適用しても意味がない。
 
  実務ではこの他にも、顧客のニーズと期待を念頭に置く新規な製品技術の研究開発、或いは、商品化計画のない状況での新規な性能や機能又は構造の製品の探索などといった設計開発に似た活動が存在する。これらに対しても7.3項の適用は意味がない。
 
   製品実現業務ではない設計開発活動に7.3項を適用すべきという解説(23r)もあり、規格執筆者のひとり(22m)もこれを示唆している。これらの解説は、この種の設計開発活動に対して、所定の期間と予算で間違いなく製品関連要件 を製品の『特性』に変換するという7.3項の管理の要件を適用することが、そのこと自体には効果的であるということを述べているものと考えられる。
 
  なお、94年版の指針規格(138e)には『仕様及び設計における品質』という標題で設計開発活動の在り方を詳しく説明しているが、この設計開発活動の範囲には組織の事業活動の基盤とする製品、つまり、契約又は注文のない状態での顧客の潜在ニーズを満たす製品の設計開発が含まれている。このため、その設計開発活動には、顧客のニーズ及び満足の観点からの設計開発結果の評価、製造体制の確立、顧客ニーズの変化の観点からの定期的な設計開発結果の見直しの各活動が含まれていた。
 
(3) プロセスの設計開発
  なお、規格では製品の仕様が『特性』で表されている場合の、その製品実現の方法を決める活動は「プロセスの設計開発」である。この「プロセスの設計開発」活動は規格では製品実現の計画活動であり、7.1 b)〜d)項を決めることに相当する。規格は、この製品実現の計画活動は品質マネジメント システムの計画の一環として確立した製品実現の計画の手はずに則って行うべきことしか規定していない。しかし、「製品実現のプロセスを計画及び開発する」という表現で製品実現の計画の手はずの中に「プロセスの設計開発」が含まれることのあることを示唆している。例えば、製造業で製造工程を決めることができても、その詳細な工程条件の決定には試験や試行錯誤的取組みが必要なこともあり得る。7.1項末尾の注記2の「製品実現プロセスの開発に7.3項の要件を適用してもよい」はこのような場合についての規格の意図の表現である。すなわち、所定の製品実現の計画を間違いなく所定の期間や予算で達成できるようにするには、その活動を7.3項の要件に則って管理するのが効果的であるということである。
 
 
3. 規格要求事項とその真意
  設計開発活動は、考えや必要を具体的なものとして創造する活動である。 未知への旅であるから、予想しない障害に遭遇し進路の変更を迫られることがあり得るが、顧客と合意し組織が必要と決めた目標の変更は許されない。また、成約又は受注済であるから日程の制約があり、活動の進行に紆余曲折のないことはもとより、ほぼ計画通りの進捗が必要であり、予算上の制約もある。複雑な製品では、設計開発の活動が多岐にわたり、多くの人々が設計開発活動を分担し、また、組織内外に多くの関係者が存在する。このような環境の下に、設計開発活動が組織が必要と考える顧客のニーズと期待を満たす製品の仕様と品質及び付帯仕様を間違いなく、また、定められた期間と予算内で決めるためには、設計開発活動を管理された状態で実行することが必要である。
 
  94年版では4.4.1項で『製品の設計を管理し、検証する手順を文書に定め、維持すること』と規定した上で、管理や検証項目と要件を4.4.2〜4.4.9項に分けて規定していた。00年版では、旧版4.4.1項の記述を省き、設計開発活動の管理のための要件を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項 変更管理 = 変更がもたらす問題に対処する
 
  これら設計管理要素と要件の規定には94年版とは表現の違いがあるが、趣旨や意図は変わっていない。TC176指針(1a)では、伝統的に有形の製品を対象とするものと考えられてきた設計開発だが、製品がサービスの場合にも7.3項が適用されることがあり得ると述べ、すべての業種業態向けの規定になったことを示唆している。しかし実際には条文表現もほとんど変わっておらず、実質的に機械工業など製造業主体の規格であった94年版の設計開発の、しかも相当に高度で複雑な製品の設計開発の実態や考え方をそのまま引き継いだものとなっている。
 
  組織は、個々の契約又は注文に対す設計開発活動が所定の期限内に所定の資源で所定の結果を出すことを確実にするよう、設計開発活動を管理する手はずを品質マネジメント システムの計画 (5.4.1項)の一環として整えなければならない。この設計開発活動を管理する手はずは、7.3.1〜7.3.7項の各管理活動の手はずを含んでいなければならない。組織は個々の契約又は注文に対する製品の設計開発を、この設計開発活動管理の手はずに則って実行を管理しなければならない。
 
(1) 組織は、製品の設計・開発の計画を策定し、管理しなければならない。 [第1節]
  標題の原文は"design and development planning"であり、条文は「計画し、管理する(plan and control)」である。これら『計画』は品質マネジメントシステムの計画(5.4.2項)や製品実現の計画(7.1項)と同じ「計画活動(planning)」であり、「前もって手はずを整える」活動を意味する(6)。一般には手順と資源を用意することであるが、この場合は設計開発の実行を管理する基礎となる実行計画を意味するから、必要な活動と責任者、日程を決め、設計開発の方法や基準の適用と電算機や試作設備など資源の使用を決めることが主体である。当然新たな手順を確立し資源を用意しなければならないこともある。
 
  組織は、設計開発活動が所定の期限内に所定の資源で所定の結果を出すことを確実にする(21p)ための設計開発活動の管理の手はずの一環として、設計開発の実行計画を作成する手はずを確立し、これに則って個々の契約又は注文に対する設計開発実行計画を作成し、設計開発活動の実行を管理しなければならない。
 
  規格は直接的に規定していないが、設計開発活動の実行管理を効果的に行うためには通常、実行計画は文書に記述することが必要である(4.2.1 d)項)。また、実行計画の決定に責任者の承認を必要とする場合があり得る。これは規格では実行計画を文書化した場合の文書の承認に相当する(4.2.3 a)項)。
 
(2) 設計・開発の計画において、組織は次の事項を明確にしなければならない。 [第2節]
  『明確にする』は「決定する」である$6。 設計開発活動の実行を効果的に管理できる設計開発の実行計画であるためには、次のa)〜c)項を適切に決めて、実行計画の中に含めなければならない。
 
  計画書の書式や内容は、設計開発の実行管理の手段として適当なものとして決めればよい。規格執筆者のひとり(21p)は、人、時期、情報等を含むフローチャート形式に表すことが多いとして、例としてプロジェクの管理手法であるガントチャート、パート(PERT)チャート、CPMチャートを挙げている(21p)。実行計画の複雑さは設計開発活動の複雑さと不確定要素の多さに応じた適当なものであることが大切である。
 
  規格は設計開発の実行管理の要素を7.3項で規定しているから、これらの要素の計画が明確になり、また、計画の進捗に応じて必要な書き込みが出来、実行の結果や承認の実績をそのまま記録としての使用できる体裁を持ったものが、通常の小規模の実行を管理する計画書として実務的である。詳細な情報はこの計画書に添付することで規模の大きな設計開発活動にも対応できる。
 
(3) 設計・開発の段階 [ a)項]
  設計開発活動では、予期せぬ結果が生じたり、進捗に手間取ったり、多くの設計開発事項があると各事項の設計開発活動の進捗に食い違いが生じたりすることがある。 未知の部分があると、それを解決しないと、次の設計開発の活動の詳細を決めることができない。 複雑な製品の、また、長期間にわたる設計開発ほど、このような問題が起き易い。 設計開発の最終期限が来てから問題に気付いても遅い。一歩一歩着実に、しかし真っ直ぐに、期限内に目標を達成するような設計開発活動とすることが必要である。
 
   これには、設計開発活動を最終目標までの進捗に係わるいくつかの段階に分け、それぞれの段階で機能や目的別に個別の活動に分け、それぞれの責任者、期間、期限する管理の方式が効果的である。 この方式では、個別活動間の相互関係が明確にされ、全体責任者や関係者によって段階毎に、かつ、決められた時期に進捗が評価され、時に計画の活動が見直され、次の段階以降の方向づけが行われる。 設計開発の計画書には、このような段階と各段階の個別活動と相互関係と日程、及び、これらから成る設計開発活動全体の構造や構成をうまく表すことが大切である。
 
  なお、機械製品などを中心によく見られる設計開発の段階としては、要求仕様決定→概念設計→実体設計→詳細設計→開発(試作評価など) 、仕様決定→概念設計→予備設計→基本設計→詳細設計→製品評価、設計企画→ポンチ絵→計画図→最終計画図→部品図→組立図→製品性能評価、などがある。簡単な設計開発では仕様決定と設計との2段階で済む。
 
(4) 設計・開発の各段階に適した レビュー、検証及び妥当性確認 [ b)項]
  設計開発の計画では、設計開発活動が間違いなく目標を達成するために必要な、設計開発の各段階の実行状況と結果の監視又は評価の方法を決めておくことが必要である。規格は監視や評価の方法として『レビュー』『検証』『妥当性確認』を挙げている。これらの活動は一般に、全体としての設計開発活動、及び、設計開発活動の各段階に関して段階の最後に、また、節目節目で、或いは、重要な局面で実施することが必要である。
 
  『レビュー』は「対象事項がその所定の目標の達成という観点で適当か、十分か、又は、効果的かを判定するために行なわれる活動」であり#23、設計開発活動を目標達成に方向づけるために活動の進捗や結果を評価、検討する活動である。『検証』は「規定関連要件が満たされことを客観的証拠によって明らかにすること」であり#28、設計開発の各活動の結果の合否判定を行い、狙いの通りの結果であること確実にする設計開発結果の適合化の活動である。『妥当性確認』は「特定の意図された使用又は適用に関する関連要件が満たされことを客観的証拠によって明らかにすること」であり#29、設計開発した製品が実際に使用されて問題が起きないことを評価、判定し、製品が顧客の使用に堪えるものであることを確実にする設計開発結果の有効化の活動である。 いずれも、PDCA/プロセスアプローチ サイクルのP/計画、A/継続的改善に相当する活動であり、それぞれに関する要件は、7.3.4, 7.3.5, 7.3.6の各項に規定されている。
 
  また、条項末尾の注記では、これら3種の監視測定に係わる活動はそれぞれ目的が異なること、また、必要に応じてすべてを別々に行ってもよいし、いずれかをまとめて行ってもよく、その記録も別々でも一緒でもよいとされている。
 
(5) 設計・開発の責任及び権限 [ c)項 ]
  責任及び権限は、人々や各グループ又は個別の各活動の役割の意味である。 設計開発の計画では、定めた個別活動を初め、各段階で行う レビュー、検証、妥当性確認を含む各業務、活動に関して、実行し、参画し、承認する人々を明確にしていなければならない。
 
(6) 組織は、効果的な コミュニケーションと責任の明確な割当てを確実にするために、設計・開発に関与するグループ間のインターフェイスを運営管理しなければならない。 [第3節]
  『インターフェイス (interface)』は、2つのものが会い又は作用し合う「接点」のこと(101)であり、転じて、「接点で生じる相互作用又は行われる情報交換の手段」の意味を持つ(102)。一般に、情報交換の機会と方法というような意味に解されている(23s)(21q)。 また『責任の割当て(assignment of responsibilities)』は「責任の分担」である。すなわち、規格の意図は、「組織は、設計開発活動に関係する各グループ間で情報交換が効果的に行われ、また、各グループの責任分担が明確になっているように、各グループ間の情報交換業務を管理しなければならない」ということである。
 
  多くの人々が機能や目的別のグループに分かれて個別の活動を分担するような設計開発活動では、その効果的な推進のためには、相互の意思疎通、情報共有、共通理解が不可欠である。 関連ある個別活動同士では相手の進捗状況を知っておくことが必要であり、相手の活動に影響する事項は相互に連絡し合うことが必要である。 また、ある事項は相手からの連絡を待っていればよいのか、こちらから働きかけなければならないのか、或いは、この事はあのグループ又は活動で処理されるのか、自分のグループでやらなければならないのか等々の グループ間の責任分担が共通認識となっていなければならない。 グループ とは、設計開発活動に係わる人々のことであり、組織内で設計開発を直接分担する人々だけでなく、製品のニーズに係わり合いのある人々、予算などで設計開発活動を支援する人々などの関係者を含み、必要により、設計開発の請負い者、設計開発した製品の原料や部品の納入者、顧客など組織の外の人々も含まれる。
 
  グループ間の情報交換業務とは一般には、設計開発活動を分担する個別の活動、関係する部門、外部の組織の関係者の間での相互連絡、業務結果のやりとりであり、例えば、『レビュー』『検証』『妥当性確認』への関係者の参画や参加、定期会議の開催や定期報告書の交換(21q)、実績記録の交換(20g)などである。
 
  94年版では、独立した条項(4.4.3)を設けて、グループ間の組織上、技術上の接点業務を明確にすること、及び、情報交換は文書で行い文書を定期的に見直すことで意思疎通を図ることを規定していた。これは94年版が実質的に対象としていた機械産業界の大規模で複雑、不確定要素の多い設計開発活動を念頭においた規定であったと考えられる。
 
(7) 設計・開発の進行に応じて、策定した計画を適宜更新しなければならない。 [第4節]
  『適宜』の原文は"as appropriate"であり、「必要なら」である$45-3。 設計開発活動の進捗によって未知の部分が明確になり、また、予想外の問題に遭遇し、或いは、予期と異なる展開をすることがあり得る。このような理由で、決めた実行計画と違う取組みが必要となった場合には、設計開発の所定の結果を所定の期間内に出すために、最新の状況を反映する計画に変更しなければならない。
 
  変更は、当該の活動の責任者が、他の活動或いは全体の設計開発活動に影響するかどうかを評価した上で決定しなければならない。他の活動や全体設計開発活動に影響すると考えられる場合は、上記(6)のグループ間情報交換の業接の枠組みの中で伝達、評価、決定を行わな
 
 
 
H24.6.2(修9.27)
禁無断転載  (個人的使用のための複写歓迎)
サニーヒルズ コンサルタント事務所