「品質マニュアル3.0」：設計・開発管理規定

「品質マニュアル3.0」の関連規定の１つ、「設計・開発管理規定」の一例です。

はかせ

「設計・開発管理規定」は、まず設計・開発のフローを作成し、詳細を規定に記載するようにして作りました。

1.　目的

本規定は、当社における設計・開発に係る手順等を定め、設計・開発を効率的に運用することを目的とする。

2.　適用範囲

本規定は、当社の設計・開発業務に適用する。

設計・開発は、技術部が担当する。

3.　設計及び開発に関する用語の定義

当社の「レビュー」について補足する。

レビューとは、

• 設計・開発における様々なプロセスで行われる審査（設計審査等）、チェックや確認などの総称
• 開発会議やデザインレビュー（DR）を含む。
• 各種検証や妥当性確認もレビューの１つ（１種）である。

なお、デザインレビューとは、JISやISO9000シリーズでは設計審査と定義されており、設計・開発に関する成果物を複数の部署や専門家などでチェックする。

4.　責任及び技術組織

（１）設計・開発に係わる承認

設計・開発に関する承認は、技術部長又は技術部長が認めた者が行う。

（２）設計・開発業務に係わる資格

設計・開発は、下表に示す必要な資格をもった者が担当する。

技術部長は、自部署の技術員を力量マップにより評価し、各資格を認定する。認定した資格は資格者リストに登録する。

5.　設計・開発プロセスの手順と記録

設計・開発フローは、次の２つからなる。

• 既存製品の改良（変更）
• 新製品（既存製品の改良ではない製品）

設計・開発プロセスの概要を下図「設計・開発基本フロー」に示す。

はかせ

設計・開発のプロセスとしてはフロー図のようになります。各プロセスを実務にいかに当てはめるかがポイントです。盛り込み過ぎると当然ながら形骸化して、内部監査や審査対策というムダが生まれてしまいます。

設計・開発フロー

5.1　設計における留意事項

開発担当者及び責任者は、以下を考慮して設計・開発をする。

• 合理的に必要強度、素材、要求仕様を検討しコストを低減すること

• 加工、組立、表面処理などを考慮し、製品の品質が安定し信頼性のある手法とすること
• 加工設備・加工能力を考慮して加工方法を選択すること
• 過去の開発・設計問題の故障事例を調べ未然に故障を防止（予防）すること

• 製品の使用状況や明確に顧客から要求はされていない製品が備えるべき機能などを十分考慮すること

• 地球環境への配慮
  • 地球環境への影響を軽減する製品設計を行うため、材料、加工、組立、表面処理、表示、梱包材、分解や廃棄の容易性などを考慮する。
  • 参照：「環境レビュー標準」

5.2　仕様書の作成、管理

（１）仕様書の作成

開発担当者は、「仕様書」を作成し、技術部長の承認を得る。

「仕様書」は、「仕様書作成標準」に基づき、以下の事項を含める。

• 製品開発の目的や使用状況
• 設計検討事項：要求機能や作業性、安全性への配慮など
• 製品評価方法：機械的強度、性能試験方法、顧客の要求試験項目など
• 代替可能材料や関連製品など

（２）仕様書の管理

仕様書は、図面と同様に管理する。

5.3　図面作成のルール

開発担当者は、下表の標準に基づき図面を作成する。

図面や仕様書等は、図面管理システムにより管理する。

6.　設計・開発の依頼（製品企画の提案）

6.1　製品企画書の作成

営業部長は、「製品企画書」を作成し、技術部長に製品開発を依頼する。

参考：「製品企画書」に記載する項目の例

• 製品の名称
  • 製品をイメージしやすいキャッチコピーは、製品イメージが伝わりやすく開発にもプラスになります。
• 図面の種類
  • 量産製品なのか特注品なのか
  • 検討図、試作図、冶具の製作図など
• 販売分野、想定している顧客
• 設計開発の目的や必要性
• 用途（使用する場所、使い方など）
• 類似品があるのか、想定している価格、機能、特許など
• 開発形態（自社開発か共同開発か）
• 主な仕様
  • できるだけ具体的、かつ優先順位を考慮します。
• 法令･規制要求事項
• 採算性
  • 製造数量と製造期間（いつまで製造するか）
  • 目標製造原価、目標売価、開発費用など
• 製品発売予定日と開発スケジュール
• 特許や工業所有権
• その他（特記事項など）

6.2　開発方法の選択（製品企画書の受付、開発担当者・責任者の指名）

技術部長は、「製品企画書」の内容を確認する。

既存製品の改良の場合、技術部長は、開発担当者を指名する。

新規開発（既存製品の改良、改修ではない製品）の場合、技術部長は、開発担当者及び開発責任者を指名する。

6.3　開発業務の開始

開発担当者は「製品企画書」により、「開発計画」、「インプット情報」を作成し、開発業務を開始する。

なお、契約又は注文の要求事項が、提示されたものと異なる場合には、それについて解決されていることを営業部長に確認する。

設計・開発に当たり、以下の点を考慮する。

• 「インプット情報」
  • インプットに対する正確なアウトプット情報の確保
• 「仕様書」、「図面」など
  • 購買、製造及びサービス提供のための必要な情報
• 「仕様書」、「図面」など
  • 必要な合否判定基準の明示
• 「仕様書」、新製品に関する情報など
  • 安全な使用及び適正な使用に不可欠な製品の特性

6.4　「製品企画書」の管理

設計・開発期間中、担当者は「製品企画書」を保管する。

設計・開発が終了した場合、設計・開発期日の実績を記入し、技術部長の承認を得る。

「製品企画書」の原本は、技術部が管理する。

7.　関係者間の情報交換（コミュニケーション）

（１）関係者間の打ち合わせ

開発責任者は、必要に応じて関係者を招集して「打合せ」を行う。

開発担当者は、「打合せ議事録」を作成する。

（２）開発会議（ＤＲを含む）

技術部長は、以下について開発会議でレビューや報告を行う。

• 開発のＧＯ＆ＳＴＯＰ判断をする場合
• 「開発計画」を作成し、インプット情報、及び、製品に関連する要求事項のレビュー結果がまとまり、インプットの適切性をレビューする場合
• 計画段階のアウトプットについてレビューする場合
• 強度計算書、試験報告書などの検証についてレビューする場合
• 試作図を作成した段階
• 開発の妥当性確認の実施方法についてレビューする場合
• デザインレビュー（ＤＲ）を実施する場合
• その他、進捗状況、試験・結果の報告をする場合

8.　設計・開発の計画

(1)「開発計画」の作成、承認

開発担当者は、「開発計画」を作成し、開発責任者が検討し、技術部長が承認する。

開発担当者は、「開発計画」に実績を記入する。

技術部長は、「開発計画」により進捗を管理をし、必要な段階でその進捗及びアウトプットを開発会議にて報告する。

(2)「開発計画」の変更

開発担当者は、開発の進展度合いに応じて「開発計画」の変更が必要な場合、開発責任者が検討し、技術部長に報告する。

技術部長は、必要に応じて開発会議で報告する。

(3)「開発計画」の最終確認

開発担当者は、記入された項目すべての予定が完了した場合、開発結果を技術部長に報告する。

技術部長は、必要に応じて開発会議で報告する。

9.　設計・開発のインプット

9.1　製品に関連する要求事項のレビュー

（１）開発担当者は「インプット情報」により、製品に関連する要求事項をレビューするための資料を作成する。

「インプット情報」は技術部長の承認を得て、開発会議でレビューを行う。このレビューは、当社が顧客に製品を提供するコミット（契約や受諾）をする前に実施する。

（２）開発担当者は、このレビューの結果の記録、及び必要な処置があればその記録を管理する。

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

(1)開発担当者は「インプット情報」によりインプット情報を明確にする。

「インプット情報」には以下の内容が含まれていることを確認し、不足する場合は営業部と協議し解決する。

「インプット情報」は技術部長の承認を得て、開発会議でその適切性についてレビューを行う。

• 機能及び性能に関する要求事項
  • 顧客が規定した要求事項。
  • 引渡し時及び後の活動に関する要求事項を含む
• 適用可能な場合には、以前の類似した設計から得られた情報
• 製品に適用される法令・規制要求事項
• 開発に不可欠なその他の要求事項
  • 顧客が明示していないが、指定された用途または意図された用途に応じた要求事項
  • 必要と判断される追加要求事項
• 製品に要求される基準を満たさなかった場合に生じる影響等
• 工業所有権に関する要求事項

(2)技術部は、設計のためにインプットされる要求事項を記載した「製品企画書」、「インプット情報」等の文書を管理する。

なお、環境レビューは「環境レビュー標準」に従い実施する。

(3)開発からのアウトプットがインプットの要求事項を満たしていることを、開発会議にて報告し、各部門からの審査を受けることにより確認する。

設計検証の方法を以下に示す。

• 設計検証者による図面仕様の検証
• 強度計算による設計強度の検証
• 過去の試験結果の引用による設計検証
• 試作又は試験による設計検証

アウトプット成果物を下表に示す。

(4)技術部長は、開発からのアウトプットの承認を行う。

技術部は、開発からのアウトプットを関係部門に報告する。

(5)「図面」、「仕様書」等は、図面管理システムで管理する。

図面管理システムで管理する文書は、以下の通り。

• 図面及び仕様書
• 強度計算書、試験報告書など
• 顧客から示された仕様書などの外部発行文書

10．　設計・開発の管理（レビュー・検証・妥当性確認）

10.1　設計・開発の審査（開発会議、設計・開発のレビュー）

(1)開発の適切な段階において、次の事項を開発会議においてレビューする。

• 設計・開発の結果が要求事項を満たせるかどうかを評価する｡
• 問題を明確にし、必要な処置を提案する｡

(2)レビューには、レビューの目的に関連する部署の代表者が参加するものとする。

(3)技術部長は、このレビューの結果の記録、及び必要な処置があればその記録を管理する。

10.2　設計・開発の検証

(1)開発責任者又は開発担当者は、開発からのアウトプットが開発へのインプットで与えられている要求事項を満足していることを確実にするため、開発の適切な段階で検証を実施する。

下記のいずれかの方法で客観的証拠を提示すること。

• 図面の検証
  • 部品の配置、製造方法などについて図面を検証する。
• 強度計算による検証
  • 理論強度に対する設計の安全性を評価する。
• 試験結果の引用による検証
  • 同一の設計要素に対して、共通で使用できる「試験結果報告書」等を使用して検証する。
• 試作又は試験による検証
  • 試作による検証結果を「試験報告書」取りまとめる。

(2)試作品の検査について

試作品の検査を必要とする場合は、品質保証部に依頼する。

(3)開発責任者又は開発担当者は、検証結果の記録及び必要な処置があればそれを記録し、技術部長が承認する。

10.3　デザインレビュー（ＤＲ）

(1)技術部長は、以下の場合デザインレビュー（ＤＲ）を実施する。

• 量産試作相当品の評価を顧客に依頼する場合
• 量産に移行する場合
• その他の場合
  • 新規顧客に納入する場合
  • 生産工程又は生産場所の変更を行なった場合
  • 仕様などの確認が必要な場合

(2)技術部長は、開発品について開発会議でデザインレビューを実施する。

(3)デザインレビューで使用する資料の例を下表に示す。

(4)デザインレビューの結果は、開発会議で報告し、開発会議議事録に記録する。

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

開発責任者は、「開発計画」に記載された開発テーマ、顧客のニーズに対して、開発の妥当性確認を行う。

妥当性確認の結果及び必要な処置があればそれを記録し、技術部長が承認し管理する。

(1)量産試作検証を行った場合

試験結果をまとめ、技術的な問題が解決されていることを確認する。

(2)初期流動管理を行った場合

検査結果を品質保証部から入手し、開発の妥当性確認を行う。

(3)その他の場合

顧客了承が得られた場合には、現場にて実用試験を行い、その結果を取りまとめ開発の妥当性確認を行う。

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

(1)開発からのアウトプットは、次の状態となるようにする。

• 開発へのインプットで与えられた要求事項を満たす。
• 購買、製造及びサービス提供に対して適切な情報を提供する。
  • ここでいう購買、製造及びサービス提供とは、「外注を使う場合」、「製造またはサービスの提供」、「部品、資材、原料などの購入」、｢梱包や包装など製品の保存｣などのことである。
• 製品の合否判定基準を含むか、又はそれを参照している。
• 安全な使用及び適正な使用に不可欠な製品の特性を明確にする。

(2)開発担当者は、開発からのアウトプットとして「インプット情報」の各項目に対比した形でアウトブット文書を選択し作成する。

作成するアウトプット文書は、次の通り。

• 図面、仕様書
• 強度計算書、試験報告書
• 取扱説明書　など

12.　設計・開発の変更管理（図面等の変更・廃止）

(1)以下に該当する場合、変更内容及び変更する文書（図面、仕様書等）を明確にし、変更する文書に変更内容を記録する。

なお、次の理由による図面の変更・廃止は、営業部の確認後、技術部が変更・廃止処置を行う。

• 技術部から立案した設計変更
• 関連部署（顧客の要請を含む）から依頼された設計変更
• 顧客からのクレームにより設計変更が必要となった場合

(2)変更に対し、必要に応じ、審査、検証、デザインレビュー及び妥当性確認を適切に行う。変更は、承認後に実施する。

なお、審査等の結果、及び必要な処置があればその記録を管理する。

(3)設計・開発の変更の審査、検証、デザインレビュー及び妥当性確認では、変更によって製品の他の部分に影響が出ないか、及び変更により既出荷製品との間に問題が生じないかどうか確認する。

13.　試作管理

13.1　試作依頼

開発段階における検証のため、顧客に試作品を提供する場合、開発担当者は以下の内容を明確にして技術部長に申請する。

• 試作目的
• 試作か量産試作か。有償か無償か。
• 希望する試作費用
• 顧客名
• 購入品（材料等）の名称
• 図面番号
• 試作品数量と希望納期
• 試作検証を行う場合、試験期日、試験報告完了予定日、試験方法

13.2　試作の評価

開発担当者は、検証項目に従い評価を行い試験報告書を作成し、技術部長の承認を得る。

試作品が顧客提出のためのものである場合は、必ず品質保証部長の承認を得る。開発担当者は、試作過程で発生した問題点等があれば、試験報告書に記録する。

14.　図面等の管理

図面等は、図面管理システムで管理する。

仕様書、図面等は、承認された後、図面管理システムに登録する。

【参考】製図に関するJIS規格の一例

図面作成（製図）には、CADが普通に使われるようになっていあます。CADのソフトウェアも3D CADが普及していますが、2D　CADもなくなった訳ではないようです。

製図もPCとソフトウェアで行うので、製図に関するJIS規格を意識することはほとんどないかと思いますが、製図の際準拠している基本的なJIS規格と公差に関するJIS規格を紹介します。

JIS規格の最新版については、以下からJIS規格を検索してご確認をお願いします。

日本工業標準調査会の「JIS検索」

製図関連のJIS規格

公差（寸法許容限界）に関するJIS規格

まとめ

ここでは、「品質マニュアル3.0」の関連規定の１つ、「設計・開発管理規定」の一例について説明しました。

はかせ

ISO9000の中でも定評のある設計・開発プロセスです。

自社に合わせて導入し、活用してください。