設計開発段階から品質を作り込むことが図れるので、ISO 9001の認証を取得する意義は高いと言える。しかし、小規模企業で設計開発まで入れた品質システムを構築するには、多大な努力が必要となる。よって、仮に簡単な製品開発業務が行われていたとしても、ISO 9002をまず取得してから、ある期間をおいてからISO 9002をISO 9001にアップグレードする手法を強く推薦する。 また、親会社の部品の金型を図面にするなどは、規格の言う設計開発として取り扱う必要はない。工程管理の一部として手順書を作成すればすむことである。以下は、あくまで純粋な設計開発業務に関することを述べていることを、まずお断りしておきたい。

　設計管理

　まず、設計管理の対象となる業務を明確にすることが重要である。まったく新しい製品開発、既製品の改良、既製品の技術サービスなど開発部門では、多くの業務が重複しているのが一般である。特に、基礎研究などを対象にすることは仕組みを複雑にすることになるので、対象業務の決定には慎重であるべきである。もちろん、この決定は、すべて企業の決定事項であり、監査機関の意向を正す必要など一切必要ない。
　では、大手企業を顧客とする中小企業のケースで考えてみる。たとえば、親企業が新製品を開発することになり、一定期間内に要求項目を満たす部品を自社が開発しなければならないことが生じたなどは設計開発の対象業務の好例である。

　設計及び開発の計画

　上記のような部品の設計・開発では、ある程度の開発計画書なりスケジュール表を作成するはずであるから、その計画書に対して誰がいつ何を決めるかを手順書にまとめれば簡単になる。ここで注意したいことは、設計・開発の担当者の資格認定である。資格認定は、社内規格で定めればよい。すなわち、「設計・開発チームリーダーは、チーム員の資格認定を行う責務と権限を持つ」と条文のどこかに入れておけば十分である。

　開発計画書は、開発業務の進展に従って更新する必要がある。開発チームリーダーは、ある段階で簡単な会議を持ち、開発計画書の見直しを行うことを明記すればよい。形式的には単純ものであったとしても、このような見直しは、どの企業でも行っているはずである。「あの測定値は無視して、この方法でもう一度やり直してほしい」と言うのが、それである。大げさに考える必要はない。

　組織上および技術上のインターフェース

　設計開発業務は、単に開発部門が単独で行うことはまずない。営業部門はもちろん、製造工程、配送方法なども配慮しながら進められるのが普通である。そこで、規格は、設計の段階から各部門と連絡・コミュニケーシヨンをとり、その内容の中で設計・開発に影響があるものの記録・文書化を求めている。しかも、それを定期的に行うことが必要となる。この「定期的」とは、各月とかでなく、インターフェース上の問題、たとえば連絡不足による測定事項の欠落などが生じないようにすることである。

　このことは、特に開発の初段階と最終段階では重要になる。初期に十分な打ち合わせを行わず、開発の方向がすこしずれていたなどはよくあることである。また、生産段階に近くなって製造工程上の問題が浮上してきたなどもそれである。

　設計へのインプット

　上で述べたことともつながるが、設計にどれだけの情報をどのような手段で与えるかを明確に文書化していなければならない。特に、法的規制上の要求事項があるか無いかは重要である。たとえば、化学品ならば消防法、道路交通法、あるいはPL法の規制事項が考えられる。ISO9000では、法的規制に対する配慮は重要になる。

　当然ながら、設計・開発者に対し顧客の要求事項をもれなく、しかも正確に確認されなければならない。営業部門との確認事項の最低限を文言で定めることを薦める。たとえば、「営業担当者は、顧客が承認した製品図面を設計・開発担当者に社内連絡メモに添付して送付する」などは、典型的な定めである。

　設計からのアウトプット

　一方、設計・開発部門は、各段階で設計・開発状況を予期した結果に進んでいるかいないかを文書にまとめることが必要である。その内容は、顧客の要求事項を満たしているか否か、その場合判定基準は何か、安全・機能上の特性が 明確にしているかが含まれなくてはならない。特に、品質や製品特性上の初期要求事項（たとえば、寸法公差の幅）を変更せざるをえない場合には、その理由を明確にすべきである。

　デザイン・レビュー（設計審査）

　設計・開発がある程度進展すると、たとえば開発チームリーダーをはじめとした主要な責任者が一同に会して開発状況、設計結果、時間的制限などを見直すことになる。この見直し会議には、必要性があるならば、他部門からの代表者も入れることになる。いずれにしても、重要なことは設計結果が適切であるかどうかを評価できる資格のあるものが「審査」を行うことが要点である。もちろん、この「審査」は、一回だけでなく必要に応じて行われ、記録として残される。

　設計検証

　デザイン・レビュー（設計審査）は、設計開発の内容が予期したとうりの成果が上がっているかどうかが評価される。一方、「設計検証」は、設計・開発が定められたとうりできていること自体を証明する行為となる。すなわち、測定値の計算方式、類似品との比較データ、実車テストなどの結果などを用いて開発製品の評価を行うことである。開発者が通常の業務として行う開発レポートとに等しい。

　 　設計の妥当性確認

　開発品のサンプル提出ができる段階になると、そのサンプルを顧客に送り、その性能や特性を評価してもらうことが一般的に行われていることである。この「妥当性確認」で不具合が指摘されれえば、当然改良・改善をすることになる。それらの行為全般を記録する仕組みがあればよい。