モノづくりメーカーで、開発レベルを上げるためISOを導入したにもかかわらず、次のような話は珍しくはないようです。
- 開発レベルを上げたくて、設計・開発プロセスには定評のあるISOを導入し品質マニュアルに設計・開発規定なども整備したところ、設計者は頑張っているようだが成果は見えず、今や疲れてしまっているようだ。
- 設計に原因があるトラブルが減りそうな気配もなく、形だけのDR（デザインレビュー）など新たな問題が増えているようだ。
例え、ISO9000の認証取得がないと受注できないからといった消極的な理由で始めたISOでも、ISO9000で求められる設計・開発のプロセスそのものに問題があるわけではありません。
これまで何となくやってきた自社の設計・開発プロセスを、ISO導入の際自社に合わせた形で導入しなかったのため上記のような状態に陥り、現場ではどうにもならず困っているのではないかと考えています。
前置きが長くなりましたが、ここでは、図面と仕様書の他に必要な、図面を描く前に検討することは何なのか、モノづくりを料理に例え、料理のレシピに相当する設計の文書について考えてみます。
トラブルの原因や設計・開発プロセスについては、次の記事にまとめていますので、ご参照ください。
ISOの設計・開発プロセスの悩みを解決する方法はないのか？
これまでに、ISOの設計・開発をモノづくりの中小メーカーに適したプロセスや成果物については何度も考えているのですが、今だこれだという正解（方法）には至らず、考えては行き詰まり、時間をおいてからリセットしてはまた考えることを繰り返しています。
2019年10月に、ISO設計・開発プロセスを改善する参考になるのではないかと思い以下の本を読んでみました。
「ライバルを打ち負かす設計指南書 攻めの設計戦略」 國井良昌（著）日経BP出版
設計・開発の悩みを解決するためのヒントが書かれているような気がしているのですが、実際に自分で考え始めてみると、何をしているのか分からなくなることも多く、予想していた以上に時間がかかっています。
何度か読んでみて、ようやく著者の考え方についてある程度理解できてきたような気がしますので、図面と仕様書以外の設計に必要な文書についてまとめてみることにしました。
設計・開発で具体的に何をするのかといった基本的、本質的なことを白紙的に考えることにもなり、悩みながら少しづつ頭の中が整理されていく感じです。
モノづくりに必要な文書って何だろう？
ここでは、モノづくりと料理を比べて、各々を開発するために必要なプロセスや文書について考えてみます。
モノづくりと弁当（料理）の開発を比較してみると下表のようになります。
| 企業向け製品開発 | 弁当（料理）の開発 |
|---|---|
| 商品企画 | 商品企画 |
| DR：企画の審査 | DR：企画の審査 |
| 設計に関する書類 | レシピ |
| DR：設計の審査 | DR：レシピの審査 |
| 製作図面 | 材料、調理方法 |
| 試作 | 試作 |
| 試作の評価 | 試作の評価 |
| 量産 | 量産 |
表１ モノづくりとしての弁当（料理）の開発プロセス
表１の通り、モノづくりでは図面と仕様書しかありませんが、モノづくりでは図面と仕様書だけで、料理で言うレシピに相当するものになるのでしょうか？
料理の上手い下手はありますが、それはモノづくりも同じです。
レシピは、料理を作るための材料や調理方法などが書いてあります。
レシピ通りに作れば、同じように作れるための手順書のようなものがレシピであるとも考えられそうです。
私が作れる数少ない料理の１つ焼きそばを例に、どうやって焼きそばができるかを整理してみると下図の様になります。
私が作れる焼きそばの材料は図の通りですが、できあがりはイラストとは違います。
（丸ちゃんシリーズは、流石の美味しさです。）
博士の焼きそばができるまでのイメージ
図１ 博士の焼きそばができるまでのイメージ
上図からレシピには、ざっくりと以下の内容が含まれます。
- 材料の選定
- 材料の下準備
- 調理（炒める温度、材料の投入順番、炒め具合）
- 仕上げ（ソースで味付け）
- 盛り付け
それでは、いわゆるモノづくりについて商品企画から製造までのプロセスと文書等をまとめてみると下表のようになります。
| プロセス | プロセスの主な内容 | 文書等 |
|---|---|---|
| 商品企画 | 商品企画 | 商品企画書 |
| 要求仕様書作成 | （要求）仕様書 | |
| 設計 | 商品の使用目的 | 設計書？ |
| 設計思想（設計方針：コスト優先、納期優先等） | 設計書？ | |
| 材料や部品の選択 | 設計書？ | |
| 設計課題 | 設計書？ | |
| 主要諸元 | 設計書？ | |
| CAE | CAEのまとめ（報告書） | |
| 細部設計書 | 図面や仕様書の補足文書 | |
| FMEA | FMEAのまとめ（報告書） | |
| DR（設計審査） | 設計品質（図面、仕様書）の確認 | |
| 構想設計 | 図面、仕様書 | |
| 製図・検図 | 図面、仕様書 | |
| 試作 | 試作（モノづくり） | |
| 試作評価 | ||
| （試作評価） | 図面通りできていればOK | |
| 量産 | 製図・検図 | |
| 量産 | ||
| （量産評価） | 図面通りできていればOK |
表２ モノづくりのプロセスと文書
この中で、「細部設計書」とは図面や仕様書を補足するものと考えると、上図の博士の焼きそばができるまでの図は、表２から商品企画、試作、量産を除いた部分に相当し、これをレシピと考えてもよさそうです。
IT系の情報システムの開発の場合は、細部設計書の内容に要件定義などの具体的な文書等がありますが、モノづくりにおいては双方の暗黙知（分かっているだろう）であいまいなままに進んでいることが多いのではないでしょうか。
表２の設計から「設計書？」の部分を抜き出すと、設計書には次のことが含まれています。
- 商品の使用目的
- 設計思想（設計方針：コスト優先、納期優先等）
- 材料や部品の選択
- 設計課題
- 主要諸元
つまり、モノのレシピは、表２の設計部分に相当すると考えても大きな間違いではなさそうです。
レシピにあって設計にないものは、レシピに含まれる内容で、図面と仕様書以外のモノ（設計書？）であり、DR（設計審査）はレシピの審査ということになります。
冒頭で紹介した参考図書「ライバルを打ち負かす設計指南書 攻めの設計戦略」に書かれている設計書のポイントは、私の理解では次の２点です。
- 設計書により、QCDを判断することができる。
- 設計書は、6W2Hでまとめる。
QCDは、品質、コスト、納期（設計・開発のスピード）のことです。
6W2Hについては、参考図書「ライバルを打ち負かす設計指南書 攻めの設計戦略」の6W2Hの定義を引用したのが下表です。（定義については、私の理解した言葉に置き換えています。）
- 6W2Hとは、5W1Hに、WhomとHow muchの２つを加えたものです。
| 6W2H | QCD | 定義 |
|---|---|---|
| why | Q | 開発の目的と理由（なぜ、開発するのか？）を書きます。 |
| Who | Q | 開発する主役（設計者）を書きます。 |
| Whom | Q | 誰のために開発する商品（部品）か？ |
| Where | Q | どこで使う商品（部品）か？ |
| What | Q | 開発するものは何か？ 例：商品（部品）、機能、システム、ソフトウエア等 |
| How | Q | QCDを満たすために、 何人で、どのように開発するのか、 どのような技術を取捨選択（採用）するのか、 を具体的に書きます。 |
| How much | C | 製品原価や販売価格を書きます。 開発費や、経済効果等を含める場合もあります。 |
| When | D | 期日、納期とスケジュールを書きます。 |
表３ 設計書の6W2Hの定義
表３を見ると商品企画の段階では、意見が出ても具体的に決まっていない（そもそも決められない）項目もあります。
立場によってトレードオフの意味は様々
図面と仕様書にコスト（C）と納期（D）は、出てきません。
製品開発において品質は当然のことと言われていますが、企画段階から、構想設計、詳細設計、試作、製造と進むにつれ、コストや納期を優先するために、品質とのトレードオフが発生します。
しかし、コストと納期についての情報を含まない、図面と仕様書だけで設計・開発が進んでいるということは、コストと納期を無視して設計・開発を進めているとも言えます。
設計・開発以外の関係者は、
製品の形が現実のモノとして見えるようになってくるにしたがい、いつ完成するのか（納期）、幾らで製造できるのか（コスト）について正確な数字を知りたいのですが、他の関係者は違うことを考えています。
設計・開発の現場では、
品質（機能）を落としてでも納期に間に合わせるか、品質（機能）は営業側の要求が強く落とせないから納期には間に合わないな、間に合わせるには外部委託等開発費がさらに必要になるなと思っている（でも言わない）。
製造現場では、
目先の製造コストを達成することしか見えていない、保証期間内で製造上の問題がでなければ、設計変更をしてもよいとさえ思っている（でも言えない）。
商品企画の経験や見聞きしたことを振り返ってみると、
失敗するプロジェクトは、
製品開発の関係者間の合意や協力など誰も考えていない、自分の担当部分さえ計画通り、予算通りであればよいと考えているのかなと邪推したくもなる。失敗した開発プロジェクトあるあるです。
成功したプロジェクトは、
売れると思った商品のQCDのバランスをとりながら設計・開発、製造を進め、後から振り返るとうまい具合に関係者間の調整をしているものです。（結果オーライなだけであり、これがよい方法だというわけではありません。）
これは、私の理解なのですが、参考図書では、「設計開発のマネジメント（進捗管理）のツールとして6W2Hの週報を利用することにより、設計・開発がうまくいくと提案している。」のではないかと考えています。
また、6W2Hによる週報フォーマットは、関係者間の調整（だけではありませんが）にも有効なツールとして使えそうです。
プロジェクトの成功は、リスク管理にありますが、そのツールとしても6W2Hは使えそうだということです。
次項で、6W2Hを週報で利用する方法について説明します。
6W2Hを利用した週報による設計・開発の進捗管理
ここで言う設計・開発の進捗管理は、プロジェクトマネジメントそのものです。
ここでは、6W2Hによる週報の定義について、
- 設計書の使用目的の明確化関すること
- 設計書の設計思想に関すること
- 設計書の使用目的と設計思想の両方に関すること
について、QCDのどれに該当するかと合わせて説明します。
なお、下表の「自分」とは、設計リーダーと置き換えると分かりやすいと思います。
設計書の使用目的の明確化に関すること
| 6W2H | QCD | 6W2Hによる週報定義 |
|---|---|---|
| why | Q |
|
| Who | Q |
|
| Whom | Q |
|
| Where | Q |
|
| What | Q |
|
| How | Q |
|
表４ 6W2Hの週報：設計書の使用目的の明確化に関すること
設計書の設計思想に関すること
| 6W2H | QCD | 6W2Hによる週報定義 |
|---|---|---|
| What | Q |
|
| How | Q |
|
| How much | C |
|
| When | D |
|
表５ 6W2Hの週報：設計書の設計思想に関すること
設計書の使用目的と設計思想の両方に関すること
表４と表５の両方にある、設計書の次の２項目、
- 使用目的の明確化
- 設計思想
各々のWhatとHowが重要なポイントになります。
| 6W2H | QCD | 6W2Hによる週報定義 |
|---|---|---|
| What | Q |
|
| How | Q |
|
表６ 6W2Hの週報：設計書の使用目的と設計思想の両方に関すること
参考：設計や仕様に係る用語
モノづくりでは、明確な定義がないというか会社や製品により異なるため定義の様なものがみつからなかったので、基幹システムなどのIT系のシステム開発での定義を参考までに以下に示します。
基幹システムなどのIT系のシステム開発では、「仕様書や設計書に書かれていないことは、開発に含まれていない。」と言われてしまうこともあり、モノづくりよりも設計手法がが進んでいるわけではないと考えています。
確信を持つまでには至っていないのですが、昔はそれでよかったのかもれないモノづくりの設計のあいまいさが、開発を依頼する側と開発する側との間で文書等で言語化されず、問題となっているのではないかと考えています。
基本設計と詳細設計
- 基本設計は、システムを外から見たときどういう動きをするか、何をするのかを決めたもので、外部設計ともよばれる。
- 詳細設計は、基本設計で決められた動きを、どうやって実現するかを決めたもので、内部設計とも呼ばれる。
仕様書と設計書
- 仕様書は 、何を作るのかをまとめた説明資料
- 設計書は 、どうやって作るのかを説明した資料
まとめ
ISOの中でも定評のある設計・開発プロセスを、品質マニュアルや設計・開発規定に定めたのに、設計者は頑張っているようだが設計トラブルも減らず、形だけのDRなど新たな問題が出ているのが実情で、設計を何とかしたいと悩むモノづくりメーカーは少なくないようです。
ここでは、図面と仕様書の他に必要なもの（設計の文書）、図面を描く前に検討することは何なのか、モノづくりを料理に例え、料理のレシピに相当する設計の文書について、以下の項目でまとめました。
- ISOの設計・開発プロセスの悩みを解決する方法はないのか？
- モノづくりに必要な文書って何だろう？
- 立場によってトレードオフの意味は様々
- 6W2Hを利用した週報による設計・開発の進捗管理
- 設計書の使用目的の明確化に関すること
- 設計書の設計思想に関すること
- 設計書の使用目的と設計思想の両方に関すること
- 参考：設計や仕様に係る用語
- 基本設計と詳細設計
- 仕様書と設計書
