おはようございます！マネジメントオフィスいまむらの今村敦剛です。
ISO9001:2015年版 各箇条解説シリーズ。今日も箇条8.3「製品及びサービスの設計・開発」の続きをやっていきましょう。今日は箇条8.3の中でも終盤の8.3.5「設計・開発からのアウトプット」と、8.3.6「設計・開発の変更」について、規格要求事項の解説を中心にやっていきたいと思います。
動画でも解説しています（無料・登録不要）
箇条8.3.5と8.3.6の位置づけ
まずいつものように、箇条8.3.5と8.3.6の位置づけを確認しましょう。
箇条８「運用」は、全体的いうと、製品やサービスの作り込みの部分だというお話をしました。その中で箇条8.3は、お客さんのニーズを、実際の製品・サービスの具体的な仕様におとしこむためのパートという位置づけでしたね。
箇条8.3は、細かく６つの項目から成り立っています。今日説明するのはまず箇条8.3.5「設計・開発からのアウトプット」は、設計・開発という行為をした後に仕上がる成果物についての要求事項を示したものです。一般的には図面とか仕様書、サービス規定書などがアウトプットとなるでしょう。そしてそして8.3.6「設計・開発の変更」は、設計・開発を行う一連のプロセスにおいて、変更が合った場合にしなければならないことについて定めたものです。
8.3.5「設計・開発からのアウトプット」の規格要求事項
では箇条8.3.5「設計・開発からのアウトプット」の規格要求事項を見てみましょう。
この箇条では、製品・サービスの設計・開発行為の後に仕上がる成果物について、最低でもここにあるa)からd)までの4つを満たしなさい、と言っています。
a)から順番に見ていきたいと思いますが、a)はインプットの要求事項へ適合しなさいということです。箇条8.3.3では、設計・開発のインプットとして、製品・サービスの機能や性能に関する要求事項や、法令・規制要求事項などを考慮しなさいと要求してましたね。つまり、狙い通りの機能や性能が実現できるか、法令や規制要求事項はクリアできているかなどを確実にしなさい、ということです。
b)はパッと読んだだけではちょっとわかりにくいですね。設計・開発からのアウトプットとしては、一般的には図面とか仕様書、サービス規定書などがありますけれども、b)が言おうとしているのは、こうした図面や仕様書通りの製品が生産できること、またはサービスの提供ができることを確実にしなさい、ということですね。図面はできたのはいいけれども、そのとおりに製造できないということのないようにしなさい、ということでもあります。もちろん製造だけではなく、営業とかマーケティングとか、検査・品質保証、アフターサービスなどもちゃんとできなければダメですね。
c)もちょっと難しく感じるかもしれませんが、要は検査に必要なことがあれば決めておきなさい、ということですね。ここは「必要に応じて」と書いています。製造業でのものづくりなどでは、検査の方法とか基準を決めるのはそんなに難しくありませんが、サービス業の場合は結構難しいですね。例えば私はコンサルというサービス業をやっていますが、コンサルサービスを提供しているときの私の言動とか立ち振舞とかがサービスの品質に関わってきます。こういうのは寸法とか重さのように、明確に測定したり合否を判定したりするのが難しいですよね。なんとなく「よかった」とか「わるかった」とかいう形で評価されますのでね。そういうことがあるので「必要に応じて」という表現なのだと思います。もちろん、明確な評価や判定が必要ならば必ず、測定方法や基準なども定めないといけないでしょう。
d)もちょっとわかりにくいですね。目的を果たすために重要なこと、安全を実現するために重要なことの特性を、アウトプットで定めなさいということです。例えば、うどんの提供だと、美味しいうどんを作るために重要なこと（麺のコシとか味）や、安全なうどんを作るために重要なこと（原材料の消費期限を守っていることや、異物混入のないこと）などはしっかりと要件を定めなさいということでしょうか。反面、目的を果たす上でそれほど重要でないもの、安全ともあまり関わらないもの、例えばうどんを入れる器の色みたいなことは、別に定めくてもかまいませんもんね。あまり変な色のものはいやですけれども。
そしてアウトプットは文書化した情報を保持しないといけません。図面とか仕様書、サービス規定書などのアウトプットは、書面で残す必要がありますね。また、ちゃんと設計・開発のプロセスがアウトプットまでたどり着いているという証拠としても、例えば、設計及び開発プロセスが完了していることを示す情報、例えば設計開発スケジュールの管理表なども残しておいたほうがよいかもしれませんね。
8.3.6の「設計・開発の変更」の規格要求事項
では、箇条8.3の最後、8.3.6の「設計・開発の変更」です。ここはそれほど難しくはありません。設計・開発に限った話ではありませんが、何かをやっている途中や、何かを終えた後に変更せざるをえないことが起きるのはよくあることです。この8.3.6では、設計開発へのインプットや、設計開発からのアウトプットが、何らかの理由で変更になった際の取り扱いを定めています。
一般的には「ここの設計を変えたほうがいいんじゃない？」という声があがった出所などを確認し、それを関係各部署に周知することになるでしょう。その上で、どう変更するかを検討し、変更した場合の影響の評価も必要ですね。変更を実施する前に、適切なポジションの人、もしくは場合によっては顧客が承認をする必要もあるでしょうね。そうした変更手続きを行って、それらを記録しておきなさいということです。