ISO9001 2015 8_3 製品及びサービスの設計・開発がわかる
「設計・開発のISO9001 要求事項に対して何を実際やればいいの？」、と困っていませんか？
こういう疑問に答えます。
本記事のテーマ
- ①要求事項の簡略化
- ②品質コストのほとんどが設計・開発
- ③品質を作りこむ設計・開発プロセスを定常的に機能させること
- ④品質を作りこむ設計・開発プロセスを非常時こそ機能させること
①要求事項の簡略化
ISO9001要求事項
ちょっと長いですが、掲載しますね。
8.3 製品及びサービスの設計・開発(クリックで開きます)
8.3.1 一般 組織は，以降の製品及びサービスの提供を確実にするために適切な設計・開発プロセスを確立し，実施し，維持しなければならない。
8.3.2 設計・開発の計画 設計・開発の段階及び管理を決定するに当たって，組織は，次の事項を考慮しなければならない。
a) 設計・開発活動の性質，期間及び複雑さ
b) 要求されるプロセス段階。これには適用される設計・開発のレビューを含む。
c) 要求される，設計・開発の検証及び妥当性確認活動
d) 設計・開発プロセスに関する責任及び権限
e) 製品及びサービスの設計・開発のための内部資源及び外部資源の必要性
f) 設計・開発プロセスに関与する人々の間のインタフェースの管理の必要性
g) 設計・開発プロセスへの顧客及びユーザの参画の必要性
h) 以降の製品及びサービスの提供に関する要求事項
i) 顧客及びその他の密接に関連する利害関係者によって期待される，設計・開発プロセスの管理レベル
j) 設計・開発の要求事項を満たしていることを実証するために必要な文書化した情報
8.3.3 設計・開発へのインプット
組織は，設計・開発する特定の種類の製品及びサービスに不可欠な要求事項を明確にしなければならない。組織は，次の事項を考慮しなければならない。
a) 機能及びパフォーマンスに関する要求事項
b) 以前の類似の設計・開発活動から得られた情報
c) 法令・規制要求事項
d) 組織が実施することをコミットメントしている，標準又は規範（codes of practice）
e) 製品及びサービスの性質に起因する失敗により起こり得る結果
インプットは，設計・開発の目的に対して適切で，漏れがなく，曖昧でないものでなければならない。 設計・開発へのインプット間の相反は，解決しなければならない。 組織は，設計・開発へのインプットに関する文書化した情報を保持しなければならない。
8.3.4 設計・開発の管理
組織は，次の事項を確実にするために，設計・開発プロセスを管理しなければならない。
a) 達成すべき結果を定める。
b) 設計・開発の結果の，要求事項を満たす能力を評価するために，レビューを行う。
c) 設計・開発からのアウトプットが，インプットの要求事項を満たすことを確実にするために，検証活動を行う。
d) 結果として得られる製品及びサービスが，指定された用途又は意図された用途に応じた要求事項を満たすことを確実にするために，妥当性確認活動を行う。
e) レビュー，又は検証及び妥当性確認の活動中に明確になった問題に対して必要な処置をとる。
f) これらの活動についての文書化した情報を保持する。 注記 設計・開発のレビュー，検証及び妥当性確認は，異なる目的をもつ。これらは，組織の製品及びサービスに応じた適切な形で，個別に又は組み合わせて行うことができる。
8.3.5 設計・開発からのアウトプット
組織は，設計・開発からのアウトプットが，次のとおりであることを確実にしなければならない。
a) インプットで与えられた要求事項を満たす。
b) 製品及びサービスの提供に関する以降のプロセスに対して適切である。
c) 必要に応じて，監視及び測定の要求事項，並びに合否判定基準を含むか，又はそれらを参照している。
d) 意図した目的並びに安全で適切な使用及び提供に不可欠な，製品及びサービスの特性を規定している。 組織は，設計・開発のアウトプットについて，文書化した情報を保持しなければならない。
8.3.6 設計・開発の変更 組織は，要求事項への適合に悪影響を及ぼさないことを確実にするために必要な程度まで，製品及びサービスの設計・開発の間又はそれ以降に行われた変更を識別し，レビューし，管理しなければならない。 組織は，次の事項に関する文書化した情報を保持しなければならない。
a) 設計・開発の変更
b) レビューの結果
c) 変更の許可
d) 悪影響を防止するための処置
長いし、難しいですね。わかりやすく理解するために、ポイントを部分的に取り出しましょう。
8.3 製品及びサービスの設計・開発(簡略化)
組織は，設計・開発プロセスを確立、実施、維持する。
8.3.2 設計・開発の計画
a) 設計・開発のプロセス、期間・難しさ
c) 検証及び妥当性の確認
d) 責任及び権限
e) 内部及び外部資源
f) コミュニケーション
j) 要求事項を満たすと実証した文書化した情報
8.3.3 設計・開発へのインプット
a) 機能及びパフォーマンスに関する要求事項
c) 法令・規制要求事項や組織の標準・規範
e) 失敗によるリスク
インプットは，適切で，漏れがなく，曖昧でないもの。
組織は，設計・開発へのインプットに関する文書化した情報を保持する。
8.3.4 設計・開発の管理
a) 達成すべき結果を定める。
b) 要求事項を満たす能力を評価するために，レビューを行う。
c) アウトプットが，インプットの要求事項を満たすことを確実にするための検証。
e) レビュー，又は検証及び妥当性確認中に明確になった問題に対する処置。
f) 文書化した情報を保持。
8.3.5 設計・開発からのアウトプット
a) インプットで与えられた要求事項を満たす。
d) 安全で適切な使用に不可欠な，製品及びサービスの特性を規定。
組織は，設計・開発のアウトプットについて，文書化した情報を保持する。
8.3.6 設計・開発の変更
組織は，変更を識別し，レビュー、管理する。文書化した情報を保持する。
a) 設計・開発の変更
b) レビューの結果
c) 変更の許可
d) 悪影響を防止するための処置
こう簡略すると、理解しやすいですね。
もっと端的に解説すると、
しかし、高い品質を作りこむ設計・開発をどう機能させればよいかを考えるべき
なぜなら、
ISO9001認証は手段
品質の作りこみが目的だからですよね。
②品質コストのほとんどが設計・開発
設計・開発者によって、耳の痛い話をします。
品質トラブル原因の主要因
下図は、「2020年版ものづくり白書」から引用した図です。
品質コスト(トラブル発生原因が自分にあり、無償で対処するコスト)の主要因は上流工程ある、仕様・設計になります。
と、上層部からよく言われませんか？ 「うるせーな」と思いますが、その理由はここにあります。
設計・開発が出す品質コスト要因
前者の設計ミスが主要因なら、単にレベルが低いだけなので、力量をあげればＯＫ。
ほとんどの組織(技術が成熟した組織)は、後者がほとんどです。なぜなら、ミスは検証で事前にあぶりだせるからです。
どういう場面でトラブルの種が発生するか？
次のケースがよくあります。何度もやらかすと、「またか！」と言われますね。
- 設計プロセスを取り巻くインターフェース
- 仕様のヌケモレ
- 仕様には書いていないけど、相手にとって当たり前なもの
- 過去案件はすべてＯＫだったけど、次案件は特例事例と気が付ない場合
- 設計者は知っているけど、仕様担当が知らず、いつの間にか変更してて仕様・設計にズレが生じる場合
と思いますが、現実はこうです。
引渡後、ある期間過ぎて、トラブルが発生した原因を特定すると、設計要因が多く、上の5つのどれかになることが経験上多いです。
なので、設計・開発部門が高い品質を作りこむにはどうすればよいかを考えることが重要です。それを考えて実行すればISO9001の要求事項は満たせます。
③品質を作りこむ設計・開発プロセスを定常的に機能させること
最初はISO9001 2015 8.3 の要求事項を守ること
基本ですが、基本ができることを第１にしないと、臨機応変な対応はできません。
基本要素
- 5W1Hが明確なインプット、アウトプット
- 設計者の力量、責任と権限
- 関係者間とのコミュニケーション・レビューの確実な実施
- 遵守すべきもの(法令、規制)
- 文書化した情報の維持・保持
- 変更管理
- リスク管理 懸案事項
暗記しなくても、設計・開発業務を一通り経験すれば身につくものばかりです。
しかし、これだけでは十分ではありません。特に、非常時の対応が多く、そこで品質を低下させる罠がいっぱい潜んでいます。罠にはまらないために組織として、どんな動きをすればよいかを次に解説します。
④品質を作りこむ設計・開発プロセスを非常時こそ機能させること
設計・開発を悩ます非常時とは?
- 設計・開発後半にさしかかった時の仕様・納期変更
- 別案件のトラブルでリソースが急に求められた時
- コロナ感染で担当者減少・変更を余儀なくされる場合
など、いつ起こるかわからないものですが、よくありますよね。
急な変更や対応に、品質低下の罠が潜んでいます。
非常時でも品質を作りこむには?
では、非常時にどうすればよいか考えましょう。次が挙げられますね。
リスクを低減するために、どんな行動が必要か？
- 設計・開発だけで対処しない周囲を巻き込む
- 定常時から営業とのつながりも重要
- 営業に代わって顧客への提案・説明も必要
- 素早く関係者に情報展開し、完了後は反省会をすること
- 苦労した経験を共有（ナレッジするとかいいます）
自部門の殻に閉じこもるのではなく、プロセス全体の関係者との連携が重要です。必要に応じて、関係者を集めてレビューして懸案事項やリスクの洗い出しをしましょう。
対顧客の場合は、営業担当も万能ではないため、営業担当と一緒に顧客へ出向いて説明や提案する機会も必要です。
苦労した経験は共有してみんなでナレッジ化しましょう。
みんなを巻き込み、リスクを下げつつ、チャンスをものにする動きが取れるためには、日ごろからISO9001 8.3の要求事項を組織内で機能させることと、いつ非常時になっても慌てずに関係者とともに対処できる行動が重要です。
トラブル案件やきつかった業務を挙げてもらって
そこでの苦労話を聞いて「8.3 設計・開発」が
有機的に機能できているかを監査することがあります。
まとめ
ISO9001 2015 8_3 製品及びサービスの設計・開発がわかる をわかりやすく解説しました。
- ①要求事項の簡略化
- ②品質コストのほとんどが設計・開発
- ③品質を作りこむ設計・開発プロセスを定常的に機能させること
- ④品質を作りこむ設計・開発プロセスを非常時こそ機能させること
Warning: count(): Parameter must be an array or an object that implements Countable in /home/qcplanets/qcplanets.com/public_html/wp-content/themes/m_theme/sns.php on line 119