ISO9000（品質マネジメントシステム）の中でも定評のある「設計・開発プロセス」のはずなのですが、残念ながら次の様な声が聞こえてきます。
- 設計・開発の質も量も改善されない。
- 初期不良が減らず、リコールはなくならない。
- DR（デザインレビュー）はやっているけれど効果が見えない。
そこで、20名規模のモノづくりメーカーを想定して、設計・開発プロセスを見直してみます。
ここでは、ISO9000（品質マネジメント）の規格が要求する設計・開発プロセスについて振り返ります。
今更感のある方もいるかと思いますが、品質マネジメント規格が求めていることと自社の設計・開発プロセスの現状とを比較するよい機会にもなると考えています。
まずは、設計・開発の個々のプロセスというよりは、モノづくり全体を振り返ってみてはいかがでしょうか？
あるモノづくりメーカーの社長さんからの相談
ある日のこと、社長さんから次のようなお話がありました。
ISO9001は2015版に更新してそれなりに役立っているとは思うのだが、肝心のモノづくりの成果がみえてこない。
どうしたらよいのだろうか？
社長さんの言われた「モノづくりの成果」とは、どの様なことなのかもう少し具体的に教えていただけませんか？
しばし、現状について聴かせて頂いた内容を列挙してみます。
- ISO9000の開発プロセスは優れていると聞くのだが、我が社ではメリットというか成果が見えてこない。
- 内部監査やマネジメントレビューに審査準備も大変な様子だ。
- 新商品に限らず、マイナーチェンジでも、開発は計画通りにいかず納期も開発予算もオーバーしている。
- 出荷後もトラブルがなくならない。
- お客様からも「製品トラブルがなくならないが、御社の開発品の品質は大丈夫か？」といった声が聞こえてくる。
社長さんが指示されたことなどはないですか？
製品トラブルやクレームが出た時に、何が問題なのか考えるように言ってはみたのだが・・・。
その後、聴かせて頂いたことを列挙します。
- デザインレビュー（DR）では、説明者以外は沈黙している。
- 質問してみると、できないなどの言い訳が先に出てくる。
- DRで少し厳しく追及すると、技術、営業、商品企画も同じことを言う。
- 技術：既存品の設計変更や飛び込みの仕事もあり、依頼されても考える時間がとれない。（言い訳）
- 営業：技術に何か頼もうとすると、忙しくてできないと言われるばかり。（不満）
- 商品企画：開発が始まってからの要求仕様の変更で、設計の手戻りが発生するのは分かるが、営業がお客様要求だと言っているので何とかして欲しい。（お願い）
博士、どうしたらいいだろう？
正直なところ、認証維持のための品質マネジメントを運用しているメーカーでは、よく聞く話です。
- 設計・開発が上手く回っていない。
- ISO9000を導入したのに書類ばかりで、製品開発の役に立っているように思えない。
これは、
- ISO9000の品質マネジメントに問題があるのでしょうか？
- ISO9000の規格で要求されていることのレベルが高すぎるからなのでしょうか？
私は以下の様に考えています。
- ISO9000の品質マネジメントの仕組みはよくできている。
- 自社に合わせて導入すれば、しなくてよい失敗を未然に防ぎ、アイディアを商品というモノに変えていくプロセスを効率よく進めることができる。
では、なぜ品質マネジメントの成果が見えてこないのでしょうか？
少々極端な例ですが、以下の様なケースが考えられます。
- ISO9000導入時にコンサルの薦めるままに、（大企業向け）サンプルから品質マニュアルや規定を形式的に作ってしまった。
- 自社の実態にあった品質マニュアルや規定ではないので、（おそらく意識していないうちに）品質マニュアルや規定を守ることが品質マネジメントの目的となってしまった。
- ISO9000の認証は取得できたものの、例えば自社の設計・開発のフローとISO（品質マニュアルと規定）の設計・開発フローの２本立ての運用となてしまった。
- ISOの外部審査（更新審査やサーベイランス）前には、書類の準備が必須となる。同様に、内部監査などでも書類の準備が必須となり、「ISO＝書類の準備」のイメージが定着する。これは、設計・開発フローのDRでも同様となる。
では、どうすればよかったのか？
品質マネジメント導入の重要なポイントの１つは、「自社の業務フローをISO9000の規格要求に当てはめる。」ことです。
「ISOの規格要求に自社を合わせる」と、現場では「ISO導入により手間が増えただけで、メリットがない。」といった状況になってしまいます。
こうなると、あるべき姿に向けて動き出そうとしても逆回転を止めて、前に進み始めることは簡単ではありません。
それでは、ISO9000（品質マネジメント）の求める設計・開発フローとはどの様なものなのかについて説明します。
参考：ISO9000シリーズ（品質マネジメント）の歴史
1990年代日本の自動車産業（業界）は世界を驚かせ、ヨーロッパ（現EU）でその成功原因を調査し、体系化（規格化）してできたものがISO9000シリーズです。
その後も改訂が加えられ、今ではISO9001：2015として経営等の統合が求められるようになっています。
ISO9000シリーズ（品質マネジメント）の歴史については、以下の記事をご参照ください。
大企業（モノづくりなら自動車メーカー）の設計・開発プロセス
モノづくりメーカーとして大企業となっている会社の設計・開発プロセスを形だけ真似ても、自社の設計・開発プロセスには適合しません。機能不全になり、ISOの形骸化に直結してしまうということです。
そこで、まずは設計・開発についてISO9000の規格が要求している設計・開発フローについて説明します。
参考：モノづくりメーカーの設計・開発フローの１例については、「製造・開発管理規定」もご参照ください。
下図は、モノづくりメーカーで量産品を対象にした開発フローの１例です。
部品単体や特注品、ソフトウェアの開発でも大筋は同様のフローになると考えています。
量産品の設計・開発フローの１例
図 量産品の設計・開発フローの１例
以下、各プロセスについてデザインレビュー（DR）焦点をあてて説明します。
大企業ならまだしも、中小企業の製品開発でこれだけのDRができるのか、必要なのか、意味があるのかについてに考えてみたことがありますか？
なお、設計・開発（モノづくり）では、製品規模の大小にかかわらず、各プロセスの中で様々な分析をし優先度を判断をしていくことになります。
この際の判断基準となる主な要素には次のようなものがあります。
| 要素 | 補足説明 |
|---|---|
| 品質（Quality） |
|
| コスト（Cost） |
|
| 納期（Delivery date） |
|
| 特許（Patent） |
|
商品企画
商品企画というと市場調査（想定するお客様のニーズ調査）が出てきますが、調査の目的を明確にしておかないと、多大な労力をかけた割には形だけの調査になりがちです。
そもそも、お客様の言ったとおりのモノを作ったとしてもそのお客様は満足するかもしれませんが、別のお客様も満足するかどうかは分かりませんし、複数の要望（要求）を同時に満足できないため、結果的に妥協したように見えてしまうこともよくある話です。
だからこそ、「売れる商品を企画する」のは面白いのですが、成功を続ける（大きな失敗をしないようにする）ためには、自社製品全体の商品企画についてのビジョン（構想、戦略）が必要になり、作った後でも見直しを続けないとあっという間に行き当たりばったり、出たとこ勝負の商品企画になってしまいます。
先行開発には、次のようなものがあり必要に応じて実施します。
- 今は社内技術としてもっていないこれから必要になる技術の調査、取得
- 市場の反応をみるための小規模の開発
商品企画のDR
市場調査や先行開発の結果から開発する商品の「商品企画書」、「仕様書」を作ります。
なお、ここでの「仕様書」は、実際のモノづくり（設計や製造）に必要な仕様もあるでしょうが、開発する製品に求める要求をできるだけ具体的に上げておくことが「売れる商品企画」のポイントになると考えています。
商品企画のDRで、開発する商品のアイディアの具体化を進めるかどうか判断します。
開発計画のDR
商品企画DRで合意した結果から、ねらいの品質と技術課題の洗い出しなどをして、開発計画を立てていきます。
アイディア（イメージ）から具体的なモノづくりの計画（開発品の原価、開発期間）を作っていくことになりますが、あくまでも概算になります。
開発計画のDRで、設計に進めるかどうか決まりますし、開発予算の総額と最終納期が決まります。
肝心の仕様はこの段階では決まっていないので、開発予算（工数）や開発期間は変更になることを想定し、そのリスクを管理していくことが必要です。
商品企画の中でありがちなことを以下に列挙します。こららについていかにしてリスクを管理し、バランスをとっていくかが製品開発のプロジェクト成功には不可欠です。
- 設計が始まると開発予算の変更は大変なので多めに見積もりたい。
- 開発側は、経験した方法で開発を進めたがる（挑戦したくない）。
- 新技術の調査という別の目的を入れ込んでくることがある。
以上、商品企画についてまとめると、開発品の原価や開発期間は、リアルな計画というより理想的な願望に近いケースもあり、営業、商品企画、技術の力関係や、経営層の判断により決まってくることが多いように感じています。
商品企画の担当としては、売れる（ことに疑問を持たない）商品を企画しているということが前提にはなりますが、自分を守る上司と経営層を味方につけておくことが実は重要です。
設計
設計では、基本設計（全体の構想設計）、詳細設計、試作・試験を行います。
類似製品の開発を流用することもありますし、技術的なチャレンジ（小型化、コスト削減など）を含む場合もあります。
設計には3D CADが使われ製品のモデルを作る工数が大きくなっていますので、シミュレーションを積極的に活用し手戻りのない設計検証を進め、試作品の数量を最小限にする設計・開発が主流になっています。
別の見方をすると、設計の質が求められており、単に形状モデルを作るだけでは、試作や量産後（製品出荷後）のトラブルの種を蒔いてしまうことになります。
リスク管理の面では、設計が始まってから技術的に大きな課題がみつかったり、予定していた技術者のリソース（工数）が不足するといったことも起こりますので、新規だから大変で派生開発だから簡単だといったようなことはありません。
設計では、レビューが４回もありますが、上図の設計開発フローのように植え方下に必ず進むわけではありません。試作や試験の結果、基本設計の見直しが必要になることもあり、製品原価や製品出荷予定に影響が出てくることになりす。
設計のレビューを以下に列挙します。
基本設計（構想設計）のDR
基本設計とは、構想設計とも呼ばれ、製品の全体像を具体的にしていきます。
筐体（ケース）と組み込む部品（基板等）とのスペースの奪い合い、可動部分による制約などについて大枠が決まります。
詳細設計のDR
詳細設計では、基本設計を元に部品等の細部を決めていきます。
ソフトウェアであれば、実際のコーディングの作業になります。
詳細設計で明らかになった問題点や課題などは、関係者で協議し必要であれば仕様変更などを行います。
試作・試験のDR
試作品を設計通りに作れるか、シミュレーション通りの強度はあるかなどを性能試験や耐久性試験などで確認します。
CAEで事前にチェックしているとはいえ、CAEの結果が正しいかどうかは設計者が評価します。人がやることであるならば、ヒューマンエラーや確認モレがないとは言い切れません。
また、部品を組み合わせて初めて分かるといった技術的なこともあるため、設計担当以外のメンバーによるレビューは必要かつ有効です。
生産時に問題となったり、コスト削減に有効な対策がある場合には、設計変更を行い図面などを修正します。
製品設計審査（DR）
設計を完了し量産するかどうかを判断します。
- 設計検証の内容の例
- 品質、コスト、納期、法規制などのインプットとアウトプット情報
- 設計の妥当性確認など
審査で承認となると設計が完了し、正式図面となります。
生産（量産）準備
量産の準備段階です。
素材や部品の手配から、実際に製品をどのように組み立てていくかを決めていきます。
工程設計のDR
量産方法について、品質工程図（工程ごとの管理項目などを決める）や作業手順書などをレビューします。
必要に応じ設計変更や品質工程図などの修正をします。
生産移行審査（DR）
ジグなどを含む設備設計や調達を行い、量産試作をします。
生産準備を完了とし量産試作に移るかどうかレビューします。
生産（量産）
初期流動管理は、量産品の品質のばらつきなどを確認するほか、歩留まり改善など、実際に量産してみないと分からない問題への対応などを行います。
最初の量産では、目標量より小さい製造ロットから生産を始め、品質などを確認しながら目標とする生産量に段階的に増やしていきます。
初期生産のDR
工程が安定しているか、工程能力や原価などが目標値を達成してるか評価し、通常の生産に移行するかどうかレビューします。
販売・サービス
製品出荷後の技術サポート、メンテナンスや廃棄などを行います。
不具合対応の他、製品や生産工程などの情報を収集し製品の改良を行います。
その他のプロセス
設計・開発（モノづくり）において、上図の設計・開発フローの通りモノづくりが進むことはありません。
そのため、設計変更と製品開発全体の振り返りが重要です。
設計変更（変更管理）のDR
製品開発（モノづくり）を始めると、製品の設計、生産、量産だけでなく、出荷後にも様々な問題や社内外の要求があり、変更が発生します。
変更つまり、図面や仕様などの修正が行われます。
このため、設計変更はが起きるこという前提で、設計変更の内容をレビューし管理することが必要になります。
設計変更のDRで確認することの例を以下に列挙します。
- 設計変更の原因や背景となる問題に対し、変更内容（仕様）が適切か？
- 要求された仕様変更に対して、変更内容（仕様）が適切か？
- 設計変更による新たな問題（不具合）が生じないように、設計変更の影響を受ける関連部分を含めた設計変更を行なっているか？
- 設計変更内容を正しく関連部署に連絡し、各部署で管理しているか？
トラブルの主な原因には、新規の技術、トレードオフ、設計変更があり、設計変更が上げられます。
設計変更がトラブルにつながるのは、設計変更を急いでやらなければならない（緊急性）ことが多いため、必然的に設計変更による検討の質も量（時間）も不足するためです。
設計変更のために新たな設計変更を産んでしまう負の連鎖は何としても防ぎたいものです。
振り返り（顧客満足の調査や反省会）
開発した製品を実際に使うお客様の使用状況や満足度（感想）を調査することが、妥当性確認のためにも必要なのですが、これはなかなか難しいというのが現実です。
実際には、出荷後の不具合（クレーム）や生産工程の不具合情報などから、問題点や原因を分析して対策（是正処置）をしています。
これらの情報をその場限りの対策とするのではなく、設計・開発の進め方という視点で見直すことがポイントです。これにより、次の設計・開発への課題を抽出することができます。
ある製品の設計・開発の中で、最後になりますが重要な活動であり、ISO9001：2015の組織の知識の１つになると考えています。
まとめ
ISOを取ったけれども設計品質は上がらないし、設計起因のトラブルが減らないといった悩みを聞くことは少なくありません。
ここでは、ISO9000の設計・開発プロセスを自社で活用するため、まずはISO規格が求める開発フローについて以下の項目で、まとめています。
- あるモノづくりメーカーの社長さんからの相談
- 大企業（モノづくりなら自動車メーカー）の設計・開発プロセス
- 商品企画
- 設計
- 生産（量産準備）
- 生産（量産）
- 販売・サービス
- その他のプロセス
