7.3　設計・開発

7.3.1　設計・開発の計画

　組織は、製品の設計・開発の計画を策定し、管理すること。

　設計・開発の計画において、組織は次の事項を明確にすること。

　組織は、効果的なコミュニケーションと責任の明確な割当てとを確実にするために、設計・開発に関与するグループ間のインタフェースを運営管理すること。

　設計・開発の進行に応じて、策定した計画を適宜更新すること。

7.3.2　設計・開発へのインプット

　製品要求事項に関連するインプットを明確にし、記録を維持すること(4.2.4参照)。インプットには次の事項を含めること。

　これらのインプットについては、その適切性をレビューすること。要求事項は、漏れがなく、あいまい(曖昧)ではなく、かつ、相反することがないこと。

7.3.3　設計・開発からのアウトプット

　設計・開発からのアウトプットは、設計・開発へのインプットと対比した検証ができるような様式で提示されること。また、次の段階に進める前に、承認を受けること。設計・開発からのアウトプットは次の状態であること。

7.3.4　設計・開発のレビュー

　設計・開発の適切な段階において、次の事項を目的として、計画されたとおりに(7.3.1参照)体系的なレビューを行うこと。

　レビューへの参加者として、レビューの対象となっている設計・開発段階に関連する部門の代表が含まれていること。このレビューの結果の記録及び必要な処置があればその記録を維持すること(4.2.4参照)。

7.3.5　設計・開発の検証

　設計・開発からのアウトプットが、設計・開発へのインプットで与えられている要求事項を満たしていることを確実にするために、計画されたとおりに(7.3.1参照)検証を実施すること。この検証の結果の記録及び必要な処置があればその記録を維持すること(4.2.4参照)。

7.3.6　設計・開発の妥当性確認

　結果として得られる製品が、指定された用途又は意図された用途に応じた要求事項を清たし得ることを確実にするために、計画した方法(7.3.1参照)に従って、設計・開発の妥当性確認を実施すること。実行可能な場合にはいつでも、製品の引渡し又は提供の前に、妥当性確認を完了すること。妥当性確認の結果の記録及び必要な処置があればその記録を維持すること(4.2.4参照)。

7.3.7　設計・開発の変更管理

　設計・開発の変更を明確にし、記録を維持すること。変更に対して、レビュー、検証及び妥当性確認を適宜行い、その変更を実施する前に承認すること。設計・開発の変更のレビューには、その変更が、製品を構成する要素及び既に引き渡されている製品に及ばす影響の評価を含めること。変更のレビューの結果の記録及び必要な処置があればその記録を維持すること(4.2.4参照)。

参考6	`変更のレビュー'とは、変更に対して適宜行われたレビュー、検証及び妥当性確認のことである。

◇設計・開発管理制度の有無と、その運用

　有効回答率が全体の約3分の1と、会員企業において設計・開発を必要としない下請業務が多い状況を浮かび上がらせる結果となった。但し、元請企業であるか自社製品を持つ場合には必須の制度である。

　

解説

7.3　設計・開発

(1)「設計」及び「開発」の定義は数々あるが、図面作成のみが設計ではなく、サービス分野においても設計という機能が、分野によっては発生する。設計とは契約によって規定された製品・サービス等の成果を実現させるために必要となる製造工程・サービス工程・使用部材・使用外注アウトソーシング・付帯業務をどのようにするかを計画した書面であるということも言える。従って、使用物品の購買計画も、分野によっては「仕様」として、設計に区分される場合もある。以下に4業種への適用事例も含めた解説表を記載する。

(2)「設計・開発」の項目が適用となるには、自社で設計成果が管理統制でき、つまり、例えば「設計変更伺い」などをどこかに出すことなく、自社の判断で「設計・開発」上の変更事項を決定できることが前提となる。これが可能となるのは、“元請”としての仕事で、可能性として多いのは“自社ブランド”の仕事であると言うことができよう。

(3)この「設計・開発」という規定内容は、具体的に適用させるならば、以下のような流れで運用されることをまず理解するのが好ましい。規格の流れは意味合いの繋がりを主体にしたため綺麗な流れにはなっていないことを留意する。

(1)開発・設計工程の計画書を作成する。作成に当たっては前頁の工程の流れを、自社の内容にマッチさせ作成する。但し、流れは「試作」は作成する予定がなければ抜くことも可能だが、「レビュー」が「検証」に吸収され1回のみの検証となること以外は、各項目はマッチさせるために細密になっていくことはあっても、省略することはできないであろう。

(2)設計・開発の計画書には、各設計・開発段階における「責任」「権限」の明確化が要求されているが、これは該当する手順書に担当する職位に対する「責任」「権限」が別の標準書や手順書に記載されていれば、それらを引用する形でまとめると良い。

(3)設計・開発に関与するグループ間の「インターフェース」の運営管理が要求されているが、これは、組織・職位間における情報伝達の体系を求めているものであって、「組織・職位」を縦軸に、設計・開発「文書」を横軸にしたマトリックスを作成し、その伝達関係を示せばよい。

(4)設計・開発において、以下を明確にすることがその目的であり、計画においても反映させる。

(5)設計・開発の標準化をする場合のポイントであるが、このQMSというものが外部に審査されるということがなければ、リスク管理の側面から、過去の異常事例の教訓や余り想定できない事態へ考察なども、その技術基準、特にチェックリスト的なものに入れて見るのも面白いかもしれない。しかし、書いたら全て実行し確実な有効性が求められているISO9001である。このような内容は、任意的に取捨選択ができるように、ISOの管理の対象外でするのが妥当であろう。

(6)多少ニュアンスが分かって戴けたと思うが、ISO自体は外部による審査も絡むため、完璧が基準である。それも外の人間が分かるように極めてというか全て論理の世界である。これはこれで、好き嫌いや主観などが入らない分、非常に合理性はあるのだが。但し、この「設計・開発」のように、その内容そのものが定常化できない、しかも創造性や工夫が絶えず求められる世界の自称とは余りにもかけ離れている感もなくはない。

(7)それでは「設計・開発」の標準化、それもISOバージョンではどうしたら良いか。これは、必要最低限の管理項目のみで標準化するということに尽きるかもしれない。通常に任意性が高い設計管理でおいてすら、設計担当者への管理は、最低限度にすることが良しとされているのである。もし、論理的なガチガチの管理をしたら、それこそ管理の嫌いな設計マンたちからブーイングの嵐が吹き荒れるか、成果の質が下がるか、納期が相当遅れるかのいずれかの状況に陥ってしまうであろう。

(8)この項目の主題である設計・開発の「計画」であるが、これも表記の仕方などにも配慮願いたい。通常、設計関係の計画は、見やすい使いやすい点から、線表(ガントチャート)で示されることも多いと思うが、線表は変化への対応は非常に困難であるということに注意したい。相手はISOである。論理的に管理を求めてくるのである。計画書はもうその日から変更が待っていることが多いと思う。表記の仕方を数字だけにするなどして、その後の変化に対応するような標準化を志向したい。

(9)設計・開発計画の「管理」に関しては、以下の事項を実施する必要がある。

(10)上記(9)のうち、特に[3]の「適宜修正・更新」に対しては、その実施の困難さから注意を要する。　(前述)

(1)「7.3.2設計・開発のインプット」及び「7.3.3設計開発からのアウトプット」は相関があり、以下のように記載できる。

(2)「インプット」とは設計・開発工程に対する“情報の提供”であり、「アウトプット」とは設計・開発工程において作成された設計図や仕様などの“設計・開発の成果”を指す。

(3)製品・サービス要求事項に関連する「インプット情報」の明確化の“程度”は以下の通りとなる。

(4)設計・開発へのインプット情報は、その“適切性”をレビュー(検証)することが必要と規定されているが、程度問題の検証となるため、その判断が可能なプロフェッショナルが当たることが必要となる。

(5)インプット情報となる“要求事項”は以下要件を満足することが必要となる。

(1)「アウトプット」がどういうものかを設定しておく必要があり、かっ以下を内容的に満足させねばならない。

(2)規格では“アウトプットの状態”として次のa)からd)が提示されているが、これらは状態というよりも、成果自体の「合否判定基準」というべき内容であるといえる。その理由はコメントとして記す。

(1)設計・開発工程における「検証」について、その3段階を対比できるようにまず内容を対比表にしてみる。

(2)設計・開発」プロセスにおける流れを以下にその概要も含めて提示する。

(3)「設計・開発のレビュー」は設計・開発全体の工程から見ると、部分的だが専門的な塊である設計・開発プロセスに対する検証とする意味合いが強いようである。

(4)これに対して「設計・開発の検証」の位置付けは、工程全体が終了する段階での最終的(もしくはそれに近い)検証であるといえる。それ故、インプット事項全てとの対比検証も出てくる。

(5)「設計・開発の妥当性確認」は、どうもその前提に「試作」またはそれを経ないで実際に製作してしまった「実機」で、設計・開発で計画した機能なり性能が、実現しているかどうかを検証するという位置付けである。そのことから、“妥当性確認”なのである。

(1)設計・開発の変更内容は明確化することは当然であるが、その変更において該当する「レビュー」「検証」「妥当性確認」を適宜実施し承認を得る。但し、変更時の作成及び承認は、当初行われた際と同じ職位に当たる者が行うのが基本であろう。