ISO9000：品質マネジメントのデザインレビュー（DR）

デザインレビュー（DR：Design Review）は、ISO9000の設計・開発の重要なポイントの１つです。

技術部の内部監査でも、レビューをやっているにもかかわらず、具体的ンレビューで何をするのか聞いてみると、逆に次のようなやりとりになることも少なくありませんでした。

社員

デザインレビュー（DR）とは、何ですか？

はかせ

ISO9000のデザインレビューとは設計審査の事で、図面や仕様書などを技術部以外の人も含めて確認することです。

社員

設計審査って何だろう？

商品開発に関する会議のことかな・・・。

「設計審査」、「技術部以外の人も含めて確認すること」、分かったような、分からないような回答なので、改めてデザインレビューについて考えてみました。

はじめに：モノづくりの設計・開発に関するクレームあれこれ
ISO9000シリーズのデザインレビューとは
設計・開発とデザインレビューの例
設計・開発のDR（設計審査）の要求事項
余談：規格の「３．設計・開発」についての一考察
まとめ

はじめに：モノづくりの設計・開発に関するクレームあれこれ

モノづくりといっても、ISO9000の対象は、形のあるモノ、ソフトウェア、情報システム（基幹システム）等に加え、サービスも含まれ様々です。

しかし、作るモノは違えども、うまくいっていない現場の苦労には、共通すること、よく似ている部分もありますので、いくつか列挙してみます。

ソフトウェア開発では

2000年代はじめに、ソフトウェア開発のコンサルの方の話の中で、今でも印象に残っている言葉があります。

以下、印象に残った言葉の主旨を列挙してみます。

ソフトウェアにバグ（虫）はいない。
- バグも仕様だ。
バグと言っているうちは、バグはなくならない。
- ソフトウェアの品質は上がらない。
お客様の要求を満足する仕様は、開発側が作る。
- 要求事項の確認と妥当性の確認の２つがある。

当時、商品企画を担当していたましたが、

仕様（設計仕様）は、開発側が作る。
妥当性の確認

について納得した反面、ほぼ開発側（技術者）には伝わっていないような印象を受けた覚えがあります。

情報システムの改修では

基幹システムの仕様の変更や機能追加などの改修が終わった頃、ソフトウェア改修の依頼者と開発側（社内開発、外部委託）との間に問題（クレーム）が発生すると、開発側の回答は、

「仕様通りです。」

に終始します。

現在進めている機能追加の中でソフトウェアを変更して欲しいと言うと、

「仕様追加となります（別費用です）。」

との決まり文句になります。

なぜ、このようなことが繰り返されるのでしょうか？

情報システムの開発や運用マネージャーの経験からは、そもそものソフトウェア改修の仕様決めの段階で、開発側は、

「完成した後の顧客要望やクレームに対し、言い訳、理由付けをするために、設計仕様をお客様の要求に当てはめている。」

ためだと考えています。

悲しい（厳しい）現実ですが、

「お客様の要望を満足する仕様を作る。」

のではなく、

「できること（仕様）にお客様の要望を当てはめている。」

ということです。

幸運にもお客様の要望（やりたいこと）が、開発側の技術力（設計・開発力）とマッチングぐすれば、お客様は満足するのでしょうが、この様なケースは滅多にありません。

最終的に開発予算の配分の中で、できることをやりましょうとなってしまう。

基幹システムや周辺ツールでこのような機能追加や改修が続くと、次の様な別の問題が発生し、静かに積みあがっていきます。

ユーザー側は、既存のソフトウェアで自分が楽になる方法を探し始める。
システム周りの周辺ツールが自然発生し、増殖を始める。
周辺ツールは、作成者の退職などでどうにもならなくなり、情報システムに泣きつくことになる。
情報システムでは、仕様も分からない既存ツールの開発要求に対し、終わりなき開発？が始まる。

モノづくりでは

モノづくりは、図面ありきで行われるのが大原則ですが、多品種少量（１品）製作で問題（クレーム）が減らない場合には、業界を問わず現場では次のような状態となっているようです。

「社内ルールでは、技術部の発行する図面が必須」にもかかわらず、納期優先で既存図面に手書きで修正し、製造を外注先に丸投げする。
「社内ルールでは、品証による外注からの受入検査で合格品を出荷する」にもかかわらず、外注先ではムリしてモノを作るが、納期に間に合わないと現場に直送してしまう。

担当営業や調達部署は、「とりあえず、お客様からクレームがないからいいや。」とこのような状態を続けると、

現場にモノが着いてから、不具合に気がつく。
担当者間ではどうにもならず大きな問題となる。

こうなると、お金の問題も出てくるため、営業部内の話ではすまなくなり、社内的に問題が表面化する。

そして、「品証何とかして」と泣きつくも、すでに打てる手はなく、関係者の全員が得をしない事後処理が始まります。

ISO9000シリーズのデザインレビューとは

教科書的な内容ですが、ISO9000のデザインレビューについて説明します。

デザインレビュー(設計審査)とは

デザインレビューとは、JISやISO9000シリーズにおいて定義されている設計審査のことです。

開発計画、図面や仕様書などの成果物を、技術部以外の複数の人達にチェックしてもらうための機会（会議）のことです。

デザインレビューの目的

デザインレビューの目的は、各プロセスにおけるアウトプット（成果物）について、開発者（担当者や技術部）の視点だけでは見落としてしまう（見逃してしまう）様な内容を含めて精査し、品質をより確かなものにすることです。

このため、開発者以外の営業、購買（調達）、製造などの関係者を含めてレビューします。

また、デザインレビューにおいて成果物について指摘し合う、様々内意見交換をすることにより、進捗状況や課題などの情報共有にも有効です。

デザインレビューの必要性

デザインレビューが必要な理由には、品質と納期がありますが、これらに加えてコストも不可欠です。

ISO9000の設計・開発では、商品企画でコストについて検討しますが、設計にもコストが含まれていることに注意が必要です。

はかせ

製造コストを決めるのは設計なので、設計においてコストを検討することは重要です。

以下に、品質を確保し納期を守るためのデザインレビューの効果（成果）について説明します。

デザインレビューで品質を確保する

デザインレビューにより得られる成果（効果）は様々ですが、中でも品質の確保がポイントになります。

現在の顧客ニーズは多様化し、従来よりも高度な製品を求められるようになってきています。

製品開発を効率的かつ効果的に進めるためには、様々な切り口や視点から、評価や改善を事前に行うデザインレビューが必要であり、これにより品質を確保することができます。

デザインレビューで納期を守る

今では、品質は当たり前の要求であり、いかに納期を守るかが重要になってきています。

納期管理は、リスク管理の主要なポイントの１つです。

製品の開発には大小の様々なトラブルがつきものですし、トラブルが起きてから対応（対処）するのでは、開発期間は伸びるだけで納期を守れないのは明らかです。

デザインレビューにより、各部署の担当者が様々な視点で評価することにより、トラブル発生を事前に予想し手を打つことができるようになります。

この結果、開発から販売に至る各プロセスの納期遅れを事前に防ぐことにつながります。

設計・開発とデザインレビューの例

設計・開発の流れ（詳細プロセス）とデザインレビューの例を以下に説明します。

デザインレビューを各プロセス毎に行う、いくつかのプロセスをまとめて行うかは、会社により様々です。
デザインレビューの結果、前のプロセスに戻ることもあれば、開発を中止することもあります。

企画：商品として成り立つか、技術的に実現できるか

製品開発においては、顧客のニーズだけでなく、他社（同業だけでなく異業種も）なども考慮したうえで、セールスポイントを明確にします。

また、以下についても検討します。

自社生産か外部委託
自社販売、商社・EC（通販）などの販売ルートの選定と確保

企画段階のデザインレビューでは、以上の内容を踏まえて、

企画に商品性があるか
技術的に実現可能かどうか

を判断します。

事前に準備する企画デザインレビューで使用する文書を以下に列挙します。

要求仕様書、商品の企画書、要求品質など

なお、これらの資料は、参加者に事前に配布しておくと当日のスムーズな進行（実のある議論、意見交換）を期待でき、結果的にデザインレビューの有効性を高めることにつながります。

構想設計：製品イメージと企画とがずれていないか

構想設計の内容と企画に整合性があるか、詳細設計に移行できるかを判断します。

構想設計のデザインレビューは検討課題が多いため、往々にして広く浅くの議論になりがちです。デザインレビューを進める際には、論点を明確にしておくことが重要となります。

デザインレビューでは、次のようなことについても考慮します。

「初めてだから」、「手間がかかる」などリスクを避けようとしていないか。
無難なモノ、できそうなモノを作ろうとしていないか。
顧客要求と称し、何でもありの要望、願望となっていないか。

なお、現在の設計・開発では、3D CADや解析ツールなどのシミュレーションが使われています。

CADデータの入力工数は、従来のポンチ絵などによる工数は格段に増えています。反面、シミュレーションを活用した試作削減や設計ノウハウの蓄積もできる環境になっていますので、設計・開発全体の改善に利用したいものです。

詳細設計

詳細設計の内容が、機能や信頼性、生産性やコストの面で妥当かどうかを確認し、試作に移行できるかどうかを判断します。

この際、

社内規格や業界規格を遵守しているか
標準部品を採用しているか
安全性や信頼性、操作性、生産性など、あらゆる視点から問題点はないか

等が判断材料となります。

また、

構想設計のデザインレビューで指摘した事項が反映されているか

なども併せて確認します。

試作評価：リアルなモノ、形にする

試作の結果（試作品）を見て、企画と相違ないかどうか、量産に移行するかどうかを判断します。

試作評価では部品の手配と試作を行い、実機による試験を実施します。

また、性能試験、耐久試験などから、設計の検証と設計開発の妥当性を確認をします。

評価結果によっては図面や仕様書を修正します。

生産準備と生産：量産

設計の検証や妥当性の確認が適切かどうかを判断します。その結果、問題がなければ生産（量産）に移行します。

生産の初期段階においては、工程が安定しないため、工程管理を重点的に行います。また、工程能力や生産能力、原価などが目標の値を達成しているかを評価し、問題がなければ量産段階へ移行します。

販売：企画、開発、製造の振り返り

製品の量産、販売後には実際の顧客の使用状況、満足度の調査を行います。

不具合に関する情報を収集して是正措置を実施するなかで、設計開発の進行における問題点を洗い出します。

また、設計開発に関する活動全体を総括し、次回の設計開発への課題を明らかにします。

はかせ

開発した製品だけではなく、全製品の中での振り返り。これが商品戦略や開発戦略を形作っていくのですが、ここまでやっている会社は少ないのかもしれません。

設計・開発のDR（設計審査）の要求事項

最後に、設計・開発のDR（設計審査）について、ISO9001：2015の要求事項について説明します。

DR（デザインレビュー）とは

DR（デザインレビュー）の定義は、

設計・開発における様々なプロセスで行われる審査（設計審査等）、チェックや確認などの総称。
開発会議やデザインレビュー（DR）を含む。
検証や妥当性確認もレビューの１つ（１種）である。

少し補足説明を加えると、DR（デザインレビュー）とは、

企画→基本設計→試作→詳細設計→試作→量産といった設計・開発の各プロセス（段階）で、企画、開発、設計、製造、品質、購買などの関係者が集まり、各プロセスで満たすべき項目をそれぞれの観点から評価し、基準を超えている事を確認してから次のステップに進む方法

のことで、後工程からの手戻りを防止する効果があります。

DR（デザインレビュー）の効果を列挙します。

DRでは、設計の成果物（図面や仕様書等）を作成するプロセスとその完成度を設計部署以外の部署（専門家）が審査する。
機能・品質・コスト・納期などを、企画・設計・製造・品証など各分野の専門家が各々の視点で設計内容の妥当性を評価し、問題点を抽出したり、開発を次のプロセスに進める判断を決定する場でもある。
DRには各分野の専門家が参加するため、設計者視点では見落としがちな「つくりやすさ」や「メンテナンスのしやすさ」などを設計に盛り込むことができる。
各部署のメンバーが集まるため、進捗状況の把握・共有や、意思疎通の場とコミュニケーションを深めることを期待できる。

この様に、DRはISO9000シリーズでも規定されているため、各企業はその実施時期や回数、参加者などを定義しプロセスとして運用していますが、DRが当初の目的に沿ったものではなく、DRを行うことが目的となっている残念なケースもあるようです。

規格の要求事項：「8.2.3 製品及びサービスに関する要求事項のレビュー」とポイント

規格（JIS Q 9001：2015）の要求事項（8.2.3.1と8.2.3.2）は以下の通りです。

8.2.3.1　組織は、顧客に提供する製品及びサービスに関する要求事項を満たす能力をもつことを確実にしなければならない。組織は、製品及びサービスを顧客に提供することをコミットメントする前に，次の事項を含め，レビューを行わなければならない。

a)顧客が規定した要求事項。これには引渡し及び引渡し後の活動に関する要求事項を含む。

b)顧客が明示してはいないが、指定された用途又は意図された用途が既知である場合、それらの用途に応じた要求事項

c)組織が規定した要求事項

d)製品及びサービスに適用される法令・規制要求事項

e)以前に提示されたものと異なる、契約又は注文の要求事項

組織は、契約又は注文の要求事項が以前に定めたものと異なる場合には、それが解決されていることを確実にしなければならない。

顧客がその要求事項を書面で示さない場合には、組織は、顧客要求事項を受諾する前に確認しなければならない。

注記：インターネット販売など幾つかの状況では、注文ごとの正式なレビューは実用的ではない。その代わりとして、レビューには、カタログなどの関連する製品情報が含まれ得る。

8.2.3.2　組織は、該当する場合には、必ず、次の事項に関する文書化した情報を保持しなければならない。

a)レビューの結果

b)製品及びサービスに関する新たな要求事項

「JIS Q 9001：2015　品質マネジメントシステム－要求事項」より引用

上記の規格要求事項（JIS Q 9001：2015　8.2.3.1と8.2.3.2）では、製品及びサービスに関する顧客の要求事項としてa)からe)をレビューすることが求められています。

ポイントを以下に列挙します。

レビューは、契約や受注といった製品及びサービスを提供することを約束する行為の前に実施します。
- 例えば、見積時の仕様書で契約前に確認した内容と、契約内容が変更になっている場合には、その差異を明確にして顧客と合意することが必要です。
口頭での注文など顧客が要求事項を書面で提示しない場合（口頭での注文）には、注文を受ける前に、会社側から顧客から聞きとったニーズなどを記録して提示し、確認を得ることなどが必要になります。
顧客要求事項の変更管理については、独立した箇条となっており、重視されています。
- 追加要求事項や要求事項の変更の際にもレビューを行なう。
- 追加や変更された要求事項の内容と対応、問題と解決方法などについても文書化した情報を変更し管理（保持）します。

規格の要求事項：「8.3.4 設計・開発の管理」とポイント

規格（JIS Q 9001：2015）の要求事項（8.3.4）は以下の通りです。

8.3.4　設計・開発の管理

組織は、次の事項を確実にするために、設計・開発プロセスを管理しなければならない。

a) 達成すべき結果を定める。

b) 設計・開発の結果の、要求事項を満たす能力を評価するために、レビューを行う。

c) 設計・開発からのアウトプットが、インプットの要求事項を満たすことを確実にするために、検証活動を行う。

d) 結果として得られる製品及びサービスが、指定された用途又は意図された用途に応じた要求事項を満たすことを確実にするために、妥当性確認活動を行う。

e) レビュー、又は検証及び妥当性確認の活動中に明確になった問題に対して必要な処置をとる。

f) これらの活動についての文書化した情報を保持する。

注記：設計・開発のレビュー、検証及び妥当性確認は、異なる目的をもつ。これらは、組織の製品及びサービスに応じた適切な形で、個別に又は組み合わせて行うことができる。

「JIS Q 9001：2015　品質マネジメントシステム－要求事項」より引用

上記の規格要求事項（JIS Q 9001：2015　8.3.4）では、注記にある通り、設計・開発のレビュー、検証と妥当性確認が求められています。

注記にある、「設計開発のレビュー、検証、妥当性確認が、異なる目的を持つ」ことがポイントで、以下に列挙します。

a)の「達成すべき結果を定める」とは、計画した各プロセス（段階）での設計･開発のアウトプット（成果物）が、計画された機能や性能を満たすことを確認し、設計･開発プロセスの進捗を管理することです。
b)の「レビュー」とは、8.3.2 b)で決定した段階（プロセス）で実施します。
c)の「検証」とは、設計･開発の検証のことであり、設計･開発へのインプット（8.3.3 項）で明示された要求事項を、設計･開発のアウトプットが満たしていることを検証することです。
d)の「妥当性確認」とは、設計･開発の検証よりも広い観点・視点で、より現実に近い状態で設定した品質特性の妥当性を確認することである。

はかせ

妥当性確認は、図面や仕様書を確認することではなく、顧客要求を満足しているかどうかを確認することです。