注:このページに記載された内容の全部もしくはその一部を、ホームページ・オーナーの許可なく商用の目的でインターネット上もしくは他の媒体で掲載することを禁ずる。
Quality Management System 品質マネージメント・システム
プロセス管理計画

最終更新日: 05/08/2000



実施事項 20: 設計・開発


タスク 10:

設計・開発の計画作成

責任者:

(氏名記入)

部門:

設計・開発

実施の頻度:

使用するツール:

参照手順書:

指針:

製品とサービスは、新規市場もしくは特異な顧客要求事項を満たすために設計される。現存し妥当性が確認された製品の設計は、特定された注文もしくは契約仕様に対してしばしば採用される。当該条項は、設計もしくは開発プロジェクトに適用され、現存し妥当性が確認された設計が顧客要求事項を満たすために採用されている場合の注文には適用されない。顧客あるいはその他が設計内容を提示している場合には、当該条項の要求事項は適用されない。
製品設計プロジェクトは、期待されたアウトプットおよび品質目標を達成するために計画される。当該計画は以下を記述する;
設計プロセスの相もしくは段階,
それぞれの段階に必要となるレビュー、検証、妥当性確認の活動もしくは手段 ,
設計もしくは開発に必要なる要員、その責任と権限,
プロジェクトに入手可能とならしめなけれなばらない、もしくは必要な経営資源 ,
プロセス全般に亘って関与されるべき他部門もしくはインターフェース、および利用されるべきコミュニケーションの手段 .

当該設計計画は、設計・開発部長により作成され、レビューされ、プロジェクトの進捗にしたがって更新される。
ライフサイクル、製品の安全性、信頼性、耐久性、環境面、廃棄面およびその他のリスクを考慮すること。製品が使用中の破損する可能性やその結果のリスクを評価すること。

実践確認:


方針
(注:ここに記述されているプロセスは、組織によって大きく変わる)

1.1 設計・開発部長は、顧客要求事項および「引き合い要望書(RFQ)」の性能上の要求をレビュー・解釈する責任を有し、当社が提案提出を行うべきかを確認するために「提案レビュー」時に販売部長に推薦内容を提出する。設計・開発部長は、適切なる設計詳細および販売並びに見積書作成のための技術上の条件を提供する。

1.2 設計・開発部長は、「引き合い要望書(RFQ)」と契約内容との差異が解消され、当社が契約上の要求事項を満たすことができることを確認するためにポスト審査会議に出席する。契約内容の確認並びに設計レビュー活動に対し積極的なインプット行うことができる他の部門長および技術担当者あるいは専門職は、明確に特定される。

2 設計・開発計画作成

2.1 設計・開発部長は、いかなる設計活動を開始する前に「設計計画」を確立する責任を有する。「設計計画」は、設計プロセスを段階に分解し、設計活動を明確にし、おのおのの特定された活動を実行するための責任を任命する。また、「設計計画」には、設計レビューを含む設計、検証および妥当性確認のスケジュールが立てられる。

2.2 「設計計画」は、いつ個々の活動が完了されるべきかを示すプロジェクト・スケジュールを含む。

2.3 設計・開発部長は、おのおのの設計レビューの後「設計計画」を更新する。もし追加的経営資源が必要なる場合、設計・開発部長は、承認されていない経費を使用する前に販売部長に通知する。

2.4 「設計計画」は、以下のみと限定はしないが、生産図面、材料の詳細もしくは組み立て・建設指示書を含む設計アウトプットを明確にする。

2.5 現存する検証された、あるいは妥当性確認が行われた設計に対する変更、もしくは小規模開発は、当該「設計計画作成」から除外される。そのような場合でなければ、ここで使われている用語「設計」には開発活動が含まれる。

インプット文書 書式番号 インプット手段 保留期間 保管場所 責任者
アウトプット文書 書式番号 アウトプッ手段 保留期間 保管場所 責任者
最終更新日: 05/08/2000

タスク 20:

設計・開発プロセスへのインプット

責任者:

(氏名記入)

部門:

設計・開発

実施の頻度:

使用するツール:

参照手順書:

指針:

設計・開発プロセスへのインプット

設計・開発部長は、設計スコープ、機能、性能、法的規制およびその他の情報を記述するに必要なるすべての情報が提供されていることを確認する。最終製品の要求事項に関する完全な理解の下で初回会議と専門職による検討の後、設計者は作業を開始する。不完全で、不明瞭で、矛盾する要求事項は、設計プロセスを開始する以前に顧客あるいはその他の官公庁との間で解決されるべきである。以前に行われた類似の設計および過去の体験はレビューされ設計インプットの一部として使用される。

実践確認:

設計インプット

1.1 設計・開発部長は、工学的並びに関連技術情報が契約に対し最新であり、十分でることを確認する。

1.2 設計・開発部長は、以下のみと限定はしないが、以下を含む設計インプットの文書書類並びに参照文書を収集する。;

以下に関する製品を記述した顧客もしくは契約の仕様書
性能もしくは操作面,
図面、設置パラメーターもしくは制限事項、操作条件,
いかに顧客、法的規制上の要求事項が満たされるかに関する詳細,
設計基準、材料、プロセス要求事項 ,
設計規制条件、設計規格、法的要求事項 ,
検査・テストの基準および期待される結果 ,
 類似の証明された設計への参照または事例


インプット文書 書式番号 インプット手段 保留期間 保管場所 責任者
契約文書
法的要求事項および規制
アウトプット文書 書式番号 アウトプッ手段 保留期間 保管場所 責任者
最終更新日: 05/08/2000

タスク 30:

設計・開発プロセスへのアウトプット

責任者:

(氏名記入)

部門:

設計・開発

実施の頻度:

使用するツール:

参照手順書:

指針:

出来上がった設計は、設計インプットを満足されることを確実にするためにレビューされる。設計のアウトプットには、製品がどのように検証されるか、および合否判定基準が記述される。また、安全性、適正な機能、取り扱い、保管、維持管理に対し重要な活動もしくはサービスを明確にする。
設計者は、製品の安全性と適切な使用方法に重要な特性もしくは性質を明確にする。
設計情報は、図面、材料明細書、作業指示書、あるいはその他の書式に示される。当該文書は、文書管理手順書に要求されているように承認され、日付を付け、参照附を付け、配布される。

実践確認:

設計アウトプット

1.1 設計アウトプット並びに文書は、設計計画に記述される。これには、適切なる場合、以下の事柄を含む。,

加工、組み立て、アウトライン、寸法、接続図面もしくは詳細図 ,
製造図面および材料仕様を含む資材明細書 ,
場所選定図並びに要求事項,
操作、試験、維持管理指示書

1.2 設計アウトプット情報は、購買、生産、設置、検査、並びにサービスに使用される。

1.3 エンジニアリング部長は、文書管理手順書に求められているように設計アウトプットの文書を最新版管理する。

インプット文書 書式番号 インプット手段 保留期間 保管場所 責任者
購買要求書 担当部門長
製造図面
CAD/CAM 詳細図
作業指示書
品質管理指示書
アウトプット文書 書式番号 アウトプッ手段 保留期間 保管場所 責任者
最終更新日: 05/07/2000

タスク 40:

進行中の設計・開発作業のレビュー

責任者:

(氏名記入)

部門:

設計・開発

実施の頻度:

必要に応じて

使用するツール:

参照手順書:

指針:

設計・開発の具現化に関わる部門の代表者は、設計作業の中途で開発された結果をレビューする。レビューでは、設計がプロジェクトのスコープと設計インプットに適合していることが確認される。また、具現化が可能であることを確認し、現実的な、あるいは潜在的な問題点を明らかにし、それらの解決策を提案する。
設計・開発部長は、設計のレビューおよび事後のフォローアップ活動の記録を残す。

実施確認:

設計レビュー

1.1 設計・開発部長は、特定された段階で設計レビューを主導し、契約した要求事項ないしは仕様が満たされ、契約は計画された通りに進捗していることを確認する作業を行う。

1.2 もし契約で特定されているか法的規制によって要求されているならば、設計計算もしくは図面、および設計アウトプットに対して顧客もしくは規制当局の承認が得られていることを確認する。

1.3 設計レビューで使われた図面および詳細は、「予備的な」ものとして取り扱われる。管理文書としての図面は、要求事項に対し完全性、正確性、適合性がレビューされ、エンジニアリング部長によって署名され、日付付けされた時に、加工および現地施工のために発行される。

1.4 適切と見なされた場合、設計は施工中にレビューされる。何らかが行われ図面が「現場施工」として修正されたならば、最終レビューは是正処置を確実に行うために施工終了時に発生する。

インプット文書 書式番号 インプット手段 保留期間 保管場所 責任者
設計レビュー記録 設計・開発部長
アウトプット文書 書式番号 アウトプッ手段 保留期間 保管場所 責任者
最終更新日: 05/08/2000

タスク 50:

設計・開発の検証

責任者:

(氏名記入)

部門:

設計・開発

実施の頻度:

必要に応じて

使用するツール:

参照手順書:

指針:

設計のアウトプットが設計インプット要求事項を満たすことを確認もしくは立証するために検証されねばならない。設計は、新規の設計と類似の証明された設計を比較することによって、あるいは実際使用あるいは試験によって検証されうるかもしれない。設計・開発部長は、プロジェクトの適切なる段階で設計を検証し、その結果をレビューのために渡す責任を有する。設計の検証活動の記録はファイルされる。

実施確認:

検証

1.1 契約の要求事項に対する適合性は、必要に応じて、充分なる比較計算、試験あるいは経験による支持される類似の要求事項を持つ前回の設計と比較することによって立証ないしは検証される。最終設計のレビューには、すべての関連するデータ分析が含まれる。

1.2 代替計算およびその他の設計活動のために使用されるコンピュータ・ソフトウエアおよびその他の支援は設計・開発部長によって認定され、承認される。もし、また必要なる場合、市販ソフトウエアは、可能なる場合常に、試験あるいは適合証明書を条件にして注文される。社内開発のソフトウエアは使用前に試験され、承認される。

1.3 設計・開発部長は、契約ファイルに設計および契約検証記録を保管する。

インプット文書 書式番号 インプット手段 保留期間 保管場所 責任者
検証記録書式
アウトプット文書 書式番号 アウトプッ手段 保留期間 保管場所 責任者
最終更新日: 05/08/2000

タスク 60:

設計・開発の妥当性確認

責任者:

(氏名記入)

部門:

設計・開発

実施の頻度:

プロジェクトの終了時

使用するツール:

参照手順書:

指針:

妥当性確認は設計プロセスの最終段階であり、製品が顧客要求事項および使用時の期待を満たし、あるいはその能力を有することを確認する意図を持って行われる。
設計の妥当性確認プロセスは、検査および試験の計画、もしくは品質計画書に記述される。エンジニアリング部長は、最終の設計レビューのために設計の妥当性を確認する責任を有する。

実施確認:

妥当性確認

1.1 完成した設計もしくは開発は、適用できる場合、以下によって妥当性が確認される;

契約で特定された検査および試験、要求事項ないしは業界の基準に対して完全に合格している,
規制当局の製品証明要求事項に対し適合性を立証する ,
現地設置、試験および完全な実地性能

1.2 妥当性確認には、「設計計画」に明示されている場合、顧客あるいはその他の利害関係者が関与する場合もあり得る。

インプット文書 書式番号 インプット手段 保留期間 保管場所 責任者
妥当性確認報告書
アウトプット文書 書式番号 アウトプッ手段 保留期間 保管場所 責任者
最終更新日: 05/07/2000

タスク 70:

変更

責任者:

(氏名記入)

部門:

設計・開発

実施の頻度:

必要に応じて

使用するツール:

参照手順書:

指針:


変更は、製造のために配布される前に権限所有者によってレビューされ、承認される。文書管理手順に記載されているプロセスが適用される。
設計・開発プロジェクトの記録は、設計・開発部長によって保管される。
製品の計画されたサービス・ライフ中現行の類似製品の使用性もしくは性能に影響する設計変更は考慮される。

実施確認:

設計・開発の変更

1.1 設計変更は「設計変更要望書」によって列挙され、設計・開発部長によって承認されたプロジェクトもしくは契約スコープでの変更によって確認される。

1.2 設計インプットへの変更は、変更が以前に承認された設計検証または妥当性確認の結果に影響を及ぼすかどうかを決定するために、設計・開発部長によって明確化され、レビューされる。

1.3 設計もしくは開発が完成した後に変更を管理するために設計変更管理は文書化される。

1.4 ある設計変更に関係する設計活動は、当該手順書に記載されている新規設計に適用されるのと同じ規則と管理に従う。D

インプット文書 書式番号 インプット手段 保留期間 保管場所 責任者
変更要望書書式
アウトプット文書 書式番号 アウトプッ手段 保留期間 保管場所 責任者
最終更新日: 05/08/2000