おはようございます！マネジメントオフィスいまむらの今村敦剛です。
ISO9001:2015年版 各箇条解説シリーズ。今日は箇条8.3の中でも中盤の8.3.3「設計・開発へのインプット」と、8.3.4「設計・開発の管理」について、規格要求事項の解説を中心にやっていきたいと思います。
スポンサーリンク
動画でも解説しています（無料・登録不要）
箇条8.3.3と8.3.4の位置づけ
まずいつものように、箇条8.3.3と8.3.4の位置づけを確認しましょう。
箇条８「運用」は、全体的いうと、製品やサービスの作り込みの部分だというお話をしました。その中で箇条8.3は、お客さんのニーズを、実際の製品・サービスの具体的な仕様におとしこむためのパートという位置づけでしたね。
箇条8.3は、細かく６つの項目から成り立っています。今日説明するのはまず箇条8.3.3「設計・開発へのインプット」は、設計・開発するにあたって、どういう情報を考慮すべきなのかを定めています。設計・開発をするにあたっては、適切な情報が漏れなく、抜けなく揃っていないと、あとで大変なことになるかもしれませんからね。そして8.3.4「設計・開発の管理」は、設計・開発を行う一連のプロセスにおいて、進め方・やり方の管理と結果の管理の２つについて定めたものです。
箇条8.3.3「設計・開発へのインプット」の規格要求事項
では箇条8.3.3「設計・開発へのインプット」の規格要求事項を見てみましょう。
製品・サービスの具体的な仕様を決めるにあたって、最低でもa)からe)までの5つについて考慮をしなさい、と言っていますね。考慮をする、というのは、検討は必ずしないといけないですけれども、検討した結果、除外することもできる、という意味でしたよね。
a)から順番に見ていきたいと思いますが、a)は製品・サービスの機能や性能に関することですね。これはわかりやすいと思いますね。何か新しい製品をつくるにあたって、どのくらいの寸法、どのくらいの硬さ、どのくらいの耐久性などが必要か、という情報ですね。それらの性能や機能によって、製品の仕様は変わってきますからね。
b)は以前の類似の設計・開発活動から得られた情報ということですが、似たような製品やサービスの設計・開発を手掛けたことがあるのであれば、その際の情報も参考にしなさいということですね。これには、過去の類似の設計開発における成功事例や失敗事例なんかも含まれるでしょうね。箇条7.1.6にかかれている「組織の知識」にも該当する情報かもしれません。
c)は、法令・規制要求事項ということで、製品やサービスに適用される法令や規制要求事項を考慮しないといけないんですが、これは結構重要で、審査でも注目するところですね。法令や規制を考えずに設計・開発をしてしまうと、しらないうちに法令違反を犯してしまったなんてことになりかねませんからね。これは当然、顧客の不満足につながりかねないことですけれども、もっというと、自社の評判を著しく毀損するようなリスクにもなりかねないわけですよね。ただし実際は、自社の製品やサービスに適用される法令や規制要求事項を、漏れなく網羅するというのはなかなか難しいことです。全ての法律や規制に熟知している人なんてそうそういませんからね。行政機関や弁護士さん、もしくはその分野の専門家などに相談をして、確認する必要があるでしょうね。
d)はちょっとわかりにくいかもしれません。これは、例えば環境を配慮して、うちは廃プラスチックのリサイクル素材しか使いません、みたいな、我社のポリシーがあれば、それも考慮しなさいということですね。時事的なことで例えて、人権侵害国や戦争を仕掛けた国から輸入したものは使わない、みたいなポリシーもあるかもしれませんね。
e)もちょっとわかりにくいですね。端的に言うと、リスクを考えなさいということですね。こういう故障や不良が起きる可能性があるとか、こうした使われ方をされると、こんな不具合や事故が起きる、といったようなものですね。製造業などではFMEAという故障や不具合防止のための分析手法がありますが、そうしたものだと考えるとわかりやすいかもしれません。ISO9001が2015年版から、リスクという考え方を重視した規格に変わっていますが、そのリスクに対する考え方が強く反映された項目と言っていいでしょう。
この5つが最低限考慮すべきことなのですが、これ以外にも、例えばその製品をどうやって作るのかという現場サイドの工程とか、現場の作業者の安全のことも考慮したほうがいいかもしれませんし、当然、財政的なものも考慮したほうがいいですよね。
そして、これらのインプットは、文書化した情報の保持、つまり記録を取ることが要求されています。お客さんからの図面とか仕様書とか、社内の設計開発会議の議事録とか、そういうものが該当するんでしょうね。
箇条8.3.4「設計・開発の管理」の規格要求事項
つづいて8.3.4「設計・開発の管理」について説明していきましょう。冒頭で、この箇条8.3.4については、設計・開発を行う一連のプロセスにおいて、進め方・やり方の管理と結果の管理の２つについて定めたものです、と話をしました。これがどういうことかをこの図を使って説明をしたいと思いますが、箇条8.3の全体的な流れというのはこういう感じになっているんですね。
そして8.3.4は、ピンクで示されたところなんですが、それぞれの設計開発のプロセスでのやり方を管理している部分と、アウトプット、つまり結果を管理している部分に分かれています。
8.3.4の規格要求事項では、a)からf)までの6つの細かい要求事項があるのですが、誤解を恐れずにわかりやすいようにめちゃくちゃシンプルにいうと、a)とb)が、進め方・やり方の管理のことを指していて、c)とd)、e)が最終結果の管理のことを指していると考えるとわかりやすいかもしれません。f)は文書化した情報、つまり記録の保持のことなので、全体に関係することですね。
では、規格要求事項を見ていきましょう。a)とb)は、進め方・やり方の管理のことでしたので、これはセットで説明します。
a)は、設計・開発のそれぞれの段階において、どんな結果を実現しているのかということを定めなさいということです。先程の図でいうと、真ん中の「設計及び開発のプロセス」がありますが、実際はこれは細かくいろいろな段階に分かれています。例えば、うどんの新メニューを開発するのであれば、麺を開発する段階、だしを開発する段階、うどんに乗せる具を開発する段階など、いろいろ段階があるはずですよね。その段階ごとに、何を実現できていないといけないのかという、開発目標のようなものを指しているといえばいいでしょうか。そしてb)は、それぞれの段階の結果が、a)の開発目標のようなものを含めて、要求事項を満たしているかどうかを確認しなさいということですね。ちゃんとおいしいうどんの麺ができたかどうかの味見、みたいなことでしょうか。
続いて、c)、d)、e)は最終的な結果の管理のことですが、麺もだしも具も出来上がったうどんを、全部セットにして最終試作品として作り、レビューすなわち確認をするということだと理解するとわかりやすいでしょう。レビューも２つあって、一つが検証です。検証とは、結果が、事前に決めた要求や仕様を満たしているかどうかの検討であって、これはうどんづくりに例えると、最終的に出来上がったレシピ通りにうどんができているかの検討です。一方、妥当性の確認とは、こうしてできたうどんが、お客さんの求めるような「おいしいうどん」になっているかどうか、という、顧客の要求に対して合致しているかどうかの確認のことですね。
