【内部監査レベルアップ講座】設計・開発プロセスってどんなの？どうやって内部監査する？(3)

おはようございます！マネジメントオフィスいまむらの今村敦剛です。

内部監査レベルアップ講座、今回は設計開発プロセスの内部監査についてお話をします。設計開発は、内部監査が難しいところなんですよね。しかし新製品・新サービスの品質保証にとって超重要なプロセスなので、一般的な設計開発プロセスの例を説明したうえで、内部監査の具体的方法を解説します。

前回の記事はこちら

動画でも解説しています（無料・登録不要）

設計開発プロセスの内部監査の方法（規格にそってやる場合）

では内部監査のやり方について説明をしていきます。規格に従って監査をするというのがオーソドックスなやり方だとは思います。

規格に従って内部監査をする場合は、まず「設計開発の計画」の確認をするのが一般的でしょう。どういう手順で、どういうスケジュールで、どういうリソースを使って設計開発を進めるかという計画のようなものがあるかどうかの確認ですね。ちなみにISO9001の規格としては、計画を文書化しないといけないとまでは言っていません。

続いてはインプットとアウトプットの確認です。インプットとアウトプットが文書化されているかどうかですかね。またインプットに漏れや抜けがないかということもあるでしょう。そしてアウトプットは、インプットで定めた要件を満たしているかどうかというのも、規格に従った監査であれば確認したいポイントでしょう。アウトプットは、インプットで定めた要件を満たしているかどうかというのは、例えば、「大画面で大容量バッテリーのスマホがほしい」というユーザーの声がインプットとしてあれば、アウトプット…すなわち図面や仕様書を見て、大画面で大容量バッテリーになっていることを確認する、といったイメージです。

そして適切な段階で、デザインレビューを行っているかどうか、そしてデザインレビューの記録を保持しているかも確認します。

……とまあ、規格にそった監査のやり方だとこんな感じになるのが一般的でしょうけど、設計開発プロセスは文書化の要求が多いから。どうしても文書の確認になりがちなんですよね。品質上重要なプロセスであるがゆえに、文書化要求が多いのも仕方ないとは個人的には思いますけど。

もっとも、認証取得後まもないような時であれば、文書の確認中心でも仕方ないでしょうけど、ちょっと形式的です。また設計開発プロセスは、設計開発の部外者から見ると理解が難しいんですよね。先程、インプットに漏れや抜けがなかったかとか、アウトプットはきちんとインプットを満たしているかを確認するとサラッと言いましたけれども、その業界、その会社の設計開発のやり方に熟知している人じゃないと、そう簡単にはわからないんじゃないかと思います。同じ会社の人であっても、設計する製品・サービスの複雑さによってもプロセスが変わってきますので、結局は設計の当事者でなければ監査も難しいんじゃないかと思います。（身も蓋もない言い草ですけど）

こうしたことが理由になって、設計開発のプロセスの部外者が監査をやると、形式的なものにどうしてもなりがちです。

設計開発プロセスの内部監査の方法（品質上の結果からさかのぼってやる場合）

じゃあどうするかですけど、設計開発が原因となっておきたクレームや不具合の有無を確認して、そこから時間をさかのぼって、何がいけなかったのかを探していくというやり方があります。

設計開発が原因となっておきたクレームや不具合があったということは、設計開発プロセスが有効でない可能性……つまり設計開発プロセスに弱いところがある疑いがあるからですね。その弱いところがどこなのかを、設計開発部門の人と一緒に探していくというような監査のやり方ですね。それぞれの段階で、どういう問いかけをすればよいか、例をいくつか挙げていますので、参考にしてみてください。

設計開発が原因のクレーム・不適合からさかのぼる方法だけではなく、設計開発部門が立てた品質目標をもとにして、時間を遡って考えてみるという方法もあります。

たとえば、目標を達成できてないとか、目標は達成できているけど、過去の傾向を見ると改善が停滞しているような場合も、設計開発のプロセスのどこかに問題があるかもしれません。それを設計開発部門の人と一緒に見つけるような監査のやり方ですね。クレームもないし、品質目標も問題ない、という場合は、設計開発部門の課題やリスクとか、監視測定項目に焦点を当てて内部監査をするという方法もあります。

設計開発プロセスでよくあるのは、加工や組み付けのしやすさを考慮できていない図面を作ってしまって、製造部門から怒られるようなことがありますよね。あとは設計開発の期限が迫っているので、デザインレビューでも「懸念はあるけどまあこのくらい大丈夫だろう」という見通しで判定をしたけれども、それが後々トラブルになるというリスクなんかもありがちですよね。そうした課題やリスクが、設計開発のプロセスのどこで歯止めになっているかというのを確認するというのも、やり方の一つかなと思います。

さかのぼって監査をする方法や、課題・リスク・監視測定結果などからプロセスの問題を見るというやり方は、設計開発プロセスだけではなく、ほかのプロセスでも有効な監査手法だと思います。形式的になってしまうのは仕方ない面もありますが、できる限り有効性を高める監査ができるよう、いろんな視点で考えていただければと思います。