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

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

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

スポンサーリンク

前回の記事はこちら

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

一般的な設計開発のプロセスとはどういうものなのか

設計開発に関して内部監査で確認すべきポイントをお話する前提として、そもそも設計開発のプロセスってどういうものなのか、一般的な例をざっくりと見ていただきたいと思います。設計開発しようとする製品やサービスによってもプロセスは異なりますし、もちろん会社によっても違うので、あくまでも一つの例として説明をします。（これがわからないと、有効な監査ができません）

設計開発を行うのは、新しい製品やサービスを作るときです。新しい製品やサービスも思いつきで作ることはありません。必ずなにかのニーズようなものがあって、それをもとに「こういう製品やサービスを作ったらどうだろう」とアイデアが出ます。この企画の部分は、ISO9001でいうと、箇条8.2の「製品及びサービスに関する要求事項」の守備範囲です。

「こういう製品・サービスを作ろう」というアイデアがきっかけとなり、設計開発プロセスが始まります。まず「基本設計」では、大まかにこのような設計にしようと考えます。例えば新しいスマホを設計する場合は、画面のサイズは6.5インチにしようとか、バッテリーは少なくとも10時間は持つようにしよう、といった感じです。続いて「詳細設計」では、形状や寸法を事細かく決めます。本体は何番の種類のステンレスを使って、縦が何ミリで横が何ミリで幅が何ミリで…という感じです。詳細設計では、いくつものハードやソフトの設計が、同時並行的に行われることもよくあります。

詳細設計ができれば、その設計を元に「試作」します。スマホだとプロトタイプを作るイメージですね。そしてプロトタイプを「評価」します。具体的には、バッテリーテストをして、本当に10時間持つかどうかを確かめたり、検査員が数時間にわたってゲームをプレイして、パフォーマンスなどを確認したりします。
ところで、設計・開発プロセスの全般にわたって、横串を指すような管理のプロセスがあります。このスマホの設計開発をいつまでに何をするのかというスケジュール管理であったり、コストの管理であったり、設計開発プロセスで使うモノやヒトの管理であったり、設計開発プロジェクトメンバー間のやり取りの管理などがあります。

こうした取り組みをやり遂げて、思い描いていた製品が、ちゃんと設計できていることが確認できれば、設計開発のプロセスは終わりです。その次は、量産するための製造プロセス、量産にあたってサプライヤーから部品などを調達するプロセス、プロモーション活動のプロセスなどがあります。設計開発のプロセスは、こういう流れの中に位置づけられます。

デザインレビュー（DR）とはなにか？

設計開発の各段階の節目にはデザインレビューと呼ばれる会議を行うことが一般的です。

デザインレビューとは、設計が必要な条件を満たしているか、何か問題がないかをチェックし、次のステップに進む準備ができているかを確認する場のことです。この図では、基本設計の後、詳細設計の後、試作品完成の後に1回ずつデザインレビューをやっていますが、どのタイミングで、何回くらいデザインレビューをやるのかという決まりはありません。一般的には、高度で複雑な製品であるほど、デザインレビューの頻度も多くなるでしょう。また詳細設計で、いくつものハードやソフトの設計が、同時並行的に行われる際にも、小規模なデザインレビューを行うような場合もあるかもしれません。

デザインレビューでは、どのような人たちが、どのような話し合いをするのでしょうか。

参加者は、設計部門だけではなく、営業や製造、品証、生産技術などの関連部門から責任・力量ある人が参加することが一般的です。場合によっては顧客や、調達先や外注先などの外部の人が同席することもありえます。多くの人が参加して話し合うのは、設計部門だけではよい設計ができないからです。加工や組み立てのしやすい設計にするためには製造部門からの意見を聞いたほうがよいですし、お客さんの要望や事情をよく知る営業の意見も聞いたほうがいいですからね。まあ、人が多いと決められなかったり話が脱線したりするというデメリットもありますが、今日はその辺には触れないでおきます。

デザインレビューでは、こうした各部門の責任者が集まり、仕様や設計上の問題点・不備がないかを確認します。不備があれば改善点について話し合います。これはもちろん、設計品質を高めるためですが、後で問題に気づいて手戻りするようなことを避けるためでもありますね。デザインレビューではそのほか、適切に設計されているかどうかの判定をする場合もあります。ここでOKが出たら、次のステップに進めます。なお、デザインレビューの結果は記録することが、ISO9001の箇条8.3.4でも求められています。なぜかというと、後々問題があった時に、なぜそういう設計にOKを出したのかという理由を、さかのぼって明らかにできるからですね。

設計開発のインプットとアウトプットとはなにか？

ところで、設計開発のプロセスでは、インプットとアウトプットという考えがあります。

インプットというのは、設計開発をするにあたって参考にするものや情報です。わかりやすいのはユーザーのニーズですね。新型スマホについて、ユーザーが「大画面で大容量バッテリーのスマホがほしい」と言ったとします。そうしたユーザーの声をインプットとして、設計開発に取り組むわけですね。一方アウトプットというのは、設計開発をした結果、生み出されるもののことです。具体的には図面とか仕様書などがあるでしょう。

設計開発プロセス全般のインプットとアウトプットはもちろんありますが、個別の段階ごとのインプットとアウトプットもあるでしょうね。なお、ISO9001では、インプットとアウトプットは記録することが要求されています。もし万が一不良や不具合が出てしまったときに、設計上どこに原因があったかを遡って調べる手がかりにもなるからですね。