設計・開発のプロセスは、一般的には商品の企画を審査し、開発することが決まると、構想設計、詳細設計、試作、製作と進みます。
会社や業界により様々だとは思うのですが、モノづくりであれば、商品企画はアイディア、詳細設計は製作図とイメージしやすいのですが、その間の構想設計のアウトプットは何かと考えてみると、次のようにイメージできませんでした。
- 商品企画は、図面はあくまでも参考図面（イメージ図）でモノとしての実現可能性はたぶん作れるだろうという段階。
- 承認図は、実際にモノづくりができる図面だから、構想設計のアウトプットではない。
となると、一般的に構想設計は、次のようなことをすると考えました。
- 設計の大枠を決める。
- 商品企画のイメージと、実際の製品イメージとがずれていないかを確認する。
つまり、構想設計では製品イメージの実現可能性について検討することになります。
構想設計がイメージできないということは、商品企画から設計開発の間のプロセスに何か問題があるのではないかと考えていたところ、技術の内部監査チェックリスト作成と実施により同じような問題に気づきました。
商品企画といっても、基本的な形状や機能が決まっていて、お客様の要求や要望に合わせ微修正するような製品のケースがあります。この場合、商品企画があいまいでお客様の要求や要望がはっきりしない場合には、構想設計を含め、設計担当者が商品企画のあいまいな部分やお客様の要求や要望を確認します。
前置きが長くなりましたが、ここでは、商品企画を営業が担当し、担当技術1人が設計を担当するケースにおいて、商品企画から設計、製作までの設計・開発プロセスについて説明します。
きっかけは内部監査員教育から
技術部の内部監査を他の監査員にもさせたいと考え、設計・開発を知らない監査員に基本的な知識を教えたり、実際の内部監査の進め方を見せたりしています。
そもそも、設計・開発業務の内部監査が難しい理由を列挙します。
- 品質マニュアルの設計・開発に関する部分は、要求事項をどのようにして満足させるかは、設計・開発業務規程を参照するようにしている。
- 設計・開発規定は、ISO9001の認証取得時に作成したものがベースになっていて、要求事項を満たしてはいるが、設計・開発プロセスが大規模なメーカー用のもので、20名程度の小規模メーカーのプロセスを規定に合わせている。
少々乱暴な例えになりますが、大企業の設計・開発プロセスを、１人の設計者がお客様の要望に合わせて従来製品の派生開発（過去図面の修正）をしているモノづくりに適用しようとしていることに無理があるということです。
このような状態なので、内部監査をする場合には、
- ISO9001の設計・開発に関する要求事項をある程度理解している。
- 設計・開発とこれに関連する営業や調達を含めた実業務についての業務知識がある。
ことを前提に、相手のISO9001についての知識と実務レベルを考慮して、いわば探るような感じで設計・開発の業務フローを片手に質問していました。
これは、内部監査を受ける技術部長や技術担当の立場になると、QMSの設計・開発プロセスの話をしても、ISO9001の設計・開発プロセスで求められていることと、実際の設計・開発業務との関係が不明確なため、業務改善に資する内部監査を目指しても監査員に負荷がかかり過ぎるということにもなり、コミュニケーションが取れなければ内部監査そのものが成立しなくなる可能性さえあるということです。
そこで、内部監査を他の監査員に教えるため、設計・開発規定からチェックリストを作成し、設計・開発業務フローと合わせて内部監査を進めることにしましたが、そこで新たな問題が明らかになりました。
設計・開発用内部監査チェックリストを作成するも新たな問題発生
内部監査を他の監査員に教えるため、設計・開発規定からチェックリストを作成し、設計・開発業務フローと合わせて内部監査を進めることにしました。
作成した設計・開発用チェックリストを使い内部監査をやってみると、次のような問題が明らかになりました。
- チェックリストのボリュームが大き過ぎる。その割、監査中記入する部分の方が少ない。
- 設計・開発規定とフロートの関係が分かりにくい。
そこで、内部監査のために設計・開発フローを見直しに取りかかりました。
設計・開発フローを見直してみると
具体的には、設計・開発のプロセスと実務とを関連付けて、各プロセスで行うことや必要な記録を含めた設計・開発フローを作るところから始めました。
ここまでやってみると、設計・開発規定の見直しが必要なことが分かってきました。技術にも実際の設計・開発についてヒアリングをしたのですが、特に分かりにくかったのが「構想設計」です。
お客様の要望から詳細設計までは、大きく次のプロセスに分けてみたものの、
- お客様の要望をまとめて、商品イメージ（企画）を設計のインプット情報にする。
- 構想設計
- 詳細設計：実際の設計
構想設計で何をしているのかをイメージできず、さらに構想設計と詳細設計について調べたり、設計担当者にヒアリングをしていくと、次のことが分かってきました。
- 構想設計というより、詳細設計に入る前のプロセスとして、商品企画では漠然としたイメージしかないため、お客様の要求を再度確認してイメージを形にする作業をしている。
- CADで言えば、スケッチ、モデル空間での作業をしながら、実現可能性を検討している。
つまり、
- 漠然としたお客様の要求を、これまでの経験からある程度パターン化されているので、企画と構想設計を事実上設計担当者がやっている。
というのが実態の様です。
さらに、これを補足する情報として、次の様な声がありました。
- 商品企画書を読んでみたが商品イメージが分からない。
- 具体的なイメージをつかめない商品企画では、実際のモノ（形）になるかどうか分からないため、設計者は商品企画と構想設計を含めて要求を明らかにし実現可能性を検討し、イメージを形にしている。
- 大袈裟に言うと設計担当が新商品開発のプロマネを兼務している状態。
これでは、設計・開発に起因するミスやトラブルがなくならないはずだと妙に納得しました。
設計・開発規定の見直しについてはここでは触れず、構想設計、詳細設計と各々のDRについて説明します。
改めて構想設計と詳細設計と各々のDRについて整理
改めて構想設計と詳細設計と各々のDRについて整理してみた結果を以下に示します。
構想設計：製品イメージと企画とがずれていないか、設計の大枠
構想設計とは、基本設計とも呼ばれ、製品の全体像を具体的にしていきます。
例えば、筐体（ケース）と組み込む部品（基板等）とのスペースの奪い合い、可動部分による制約などについて大枠が決まります。
また、企画の内容と構想設計に整合性があるか、詳細設計に移行できるかを判断します。
構想設計のDR（デザインレビュー）
構想設計のデザインレビューは検討課題が多いため、往々にして広く浅くの議論になりがちです。デザインレビューを進める際には、論点を明確にしておくことが重要です。
デザインレビューでは、次のことについても考慮します。
- 「初めてだから（やったことがないから）」、「手間がかかる」などリスクを避けようとしていないか。
- 無難なモノ、できそうなモノを作ろうとしていないか。
- 顧客要求と称し、何でもありの要望、願望となっていないか。
詳細設計：細部を決めていく
詳細設計では、基本設計を元に部品等の細部を決めていきます。
ソフトウェアであれば、実際のコーディングの作業になります。
詳細設計の内容が、機能や信頼性、生産性やコストの面で妥当かどうかを確認し、試作に移行できるかどうかを判断します。
この際、次のことなどが判断材料となります。
- 社内規格や業界規格を遵守しているか。
- 標準部品を採用しているか。
- 安全性や信頼性、操作性、生産性など、あらゆる視点から問題点はないか。
また、
- 構想設計のデザインレビューで指摘した事項が反映されているか。
なども併せて確認します。
詳細設計のDR
詳細設計で明らかになった問題点や課題などは、関係者で協議し必要であれば仕様変更などを行います。
構想設計は商品企画？それとも設計？
これまでの様な検討をしてみたところ次の様な質問が出てきました。
- 構想設計は、商品企画で検討することなのか？
- 構想設計は、設計の一部なのか？
一般的には、
- 設計の中で、構想設計後に詳細設計を行います。
しかし、設計担当が1人で使用や図面作成をするようなモノづくりでは、次の様な理由により、設計者が構想設計を含めて商品企画を実現可能なものにまとめているケースが少なくありません。
- 営業担当者が作成した商品企画の情報、つまりインプット情報（顧客の要求）があいまいである。
- 設計担当者は、あいまいなインプット情報（顧客の要求）を確認し、構想設計を進め顧客に提案している。
そして、顧客承認が取れると詳細設計を進める。
文章で説明すると分かりにくいので、下図で説明します。
構想設計は商品企画か設計なのかのイメージ
図１ 構想設計は商品企画か設計なのかのイメージ
ここでは、20名規模のモノづくりの会社をイメージしてください。
上図左側のフローの様に各プロセスごとに仕事が進むのが一般的なフローで、大きな品質問題が発生することはほとんどありません。
ここでは、上図右のフローで、「営業がお客様の要求を把握できないまま、技術に設計を依頼する」ケースを例に説明します。
- 商品企画（顧客要望のヒアリング）は、お客様との窓口は営業が担当しています（社長も営業の1人の場合もあります）。
- 営業はお客様との窓口となり、お客様の要求やら要望やらを聞いてきます。
- 営業は社内で担当技術（1人の場合がほとんどで、複数の仕事を抱えているのも常態）に聞いてきたお客様要求を説明しますが、残念ながらあいまいで担当技術は検討ができません。
このため、仕方なく、
- 担当技術が商品企画の最初の段階、お客様へのヒアリングを初めからやり直す。
ことになります。
こうなってくると、
- お客様は営業ではなく技術と連絡を取りたがる。
- 連絡が取れないと営業にクレームを入れる。
- 担当技術がお客様の要望に対応（設計変更含め）しなければならなくなる。
- 担当技術が設計に使う時間がますます少なくなる。
つまり、設計や図面の品質が落ちることになります。
こうなると、製作での失敗や手戻り、検査工数の増加、手直しの発生と、負のスパイラルの完成です。
こうしてみると、設計品質や図面品質が上がらない、その結果、製品品質が上がらない理由は、モノづくりのプロセスそのものに課題があるということだと考えています。
最後に：3D CADを設計・開発全体の改善に
現在の設計・開発では、3D CAD使われCAEシミュレーションも使われています。
3D CADによる図面作成工数は、2D CAD数はよりも増えますので、シミュレーションを活用した試作削減や設計ノウハウの蓄積を積極的に行い、設計・開発全体の改善に利用したいものです。
まとめ
モノづくりの設計・開発では、商品企画はアイディア、詳細設計は製作図とイメージしやすいのですが、構想設計のアウトプットは何かと考えてみると、イメージできませんでした。
技術の内部監査のチェックリスト作り、内部監査をやっても、やはり、構想設計で何をやっているか分からず、最終的には、商品企画（お客様要求を含むインプット情報）があいまいだから、構想設計に相当する部分を商品企画と合わせて担当技術がやっている事実が見えてきました。
こうしてみると、設計品質や図面品質が上がらない、その結果、製品品質が上がらない理由は、モノづくりのプロセスそのものに課題があると考えています。
ここでは、構想設計について、以下の項目で説明しました。
- きっかけは内部監査員教育から
- 設計・開発用内部監査チェックリストを作成するも新たな問題発生
- 設計・開発フローを見直してみると
- 改めて構想設計と詳細設計と各々のDRについて整理
- 構想設計：製品イメージと
- 企画とがずれていないか、設計の大枠
- 構想設計のDR（デザインレビュー）
- 詳細設計：細部を決めていく
- 詳細設計のDR
- 構想設計は商品企画？それとも設計？
- 最後に：3D CADを設計・開発全体の改善に
