これらの業務は､具体的にどのように流れていくのでしょうか?
製品開発の大きな流れはISO9000シリーズ(品質マネジメントシステムの国際規格)

設計業務の整理によって､あるべき姿として方向性が示されています｡
ISO㈱1の一般要求事項に､ ｢組織は､品質マネジメントシステムを構成するプロセスを明確にし､その相互関係や具体的な方法を明確に定め､これをこの規格に従って設計､設計と普段何気なく使っていますが､設計業務ってどんなことをするのでし運営管理し､問題なく運営できているかどうかを監視し､継続的に改善すること｣とょうか?

定義されています｡

設計者から見た設計業務は､ ｢設計プロセスの流れ｣と｢全社的な開発プロセスの流

ここでプロセスとは､ ｢インプットをアウトプットに変換する一連の活動｣のことをれ｣の2つの視点で捉える必要があります0

いいます｡プロセスのインプットとは､通常､他のプロセスからのアウトプットを指Dt'‑します(図1‑1)01 )設計プロセスの流れ
設計部門の業務は､次の4つのフェーズ(行動単位)に分類できます｡･構想設計･･･‑‑･･･設計者が頭の中でぼんやりとイメージするものを｢どういうレイァゥトで｣｢どんな部品を構成して｣と具現化の目処をつけますoIイ'‑‑=7t'T:十'7芋‑I;‑.‑‑A =J

製品の素性を決めるDNAを作る重要なフェーズです｡･詳細設計･‥‑‑･･･構想設計に基づき､より具体的に形状を決め､強度計算､信頼性､安全性および環境性などを考慮し､与えられたスペース内に収める設計を行います｡製品の性格形成を作り上げる重要なフェーズです｡･試作評価‑‑‑‑‑機能や組立性を設計評価･あるいは第三者評価を行い､設計の図1‑1 lSO9001におけるプロセス妥当性を確認します｡製品にしつけをして生産準備する重要なフェーズです｡･生産フォロ‑ ･･････工場内での初期不良や市場からのクレームに対応し､顧客満足度の向上に努めます｡巣立つ製品を影で支える重要なフェーズです｡

j t t 1 1 ■ J d j①

第1章

設計検討とは?!

亘)設計部門におけるプロセスとは､ ｢企画部門のアウトプット｣である設計するための十分な情報(製品企画書)を｢設計インプット｣として受け取り､設計の成果(生産図面や技術資料など)を｢設計アウトプット｣として後工程に引き渡すことです(図1‑2)｡

2)全社的な開発プロセスの滴れ
忙しい業務の中でも､関連部門との関わりや開発の流れの中にあるイベントを知らなければ､最適なアウトプットを出すことができず､手戻りが発生しやすくなります｡
全社的な開発のプロセスや他部門との関わりを知っておくことで､次に何をすべきかが分かり､先を読むことでスムーズに設計が進行できます｡

製品企画書

ISO9001の中で､製品企画から市場に供給するまでの業務の流れと関連部門の関わ設計インプットりを体系化したものが｢品質保証体系図｣です(図1‑3)0‑‑‑‑構想設計‑‑‑‑開発のステップごとに各部門がどのように関連し､ステップ移行会議を経て次のステップに進むかが分かります｡･構想資料､技術資料作成
製品企画書
品質保証基準書
仮想カタログ餐全体レイアウト構想‑

頻逮 画調ｲｩ要求 冽hｸ

重要機能部分の構想‑

剪們

｢罐r

薄ﾆﾅCﾂSｩ,ﾂF8環[垂垂享頭V俯F"

佇2騫ﾒ4898+Yfﾚ'Fｲ剪[〒]剪Q(品質)､C(コスト)､D(納期)見通し
企画認定会議詳･詳細内容の設計
細･強度計算.安全性.環境確認

設計･開発部門

濾翠

刳J発設計

r
設計デザインレヒ 價+I+I‑

部品図作成. 剋詩

翠: ;(10窄芸)iCo,(諾) ､ D (納期)見通し

組立性検証
設計評価､第三者評価
不具合の修正設計

餐‑

1‑

1‑､句タ‑

剳舶i図作成剔gみ立て性評･̲{汝̲.葦等.'

ｶ2DR2) l

剽ﾊ産準備

剄H程評価

量産TザインL/ヒユ‑tDRRー 劔‑

設計アウトプッ
生産図面
技術資料

丶ｩJﾙDi.

剔謗O者評価l 剞ﾝ計品質デザインレヒ

Q(品質)､C(コスト) ､D(納期)見通しI=i=二;

製品制作

i̲ここ二二二二ここ.⊥■■J

生産部門
･‑+義寮

俶yw

儉ﾉHB

傀弍ｨ｢三重二ｬyyﾒ劍

掣Di.

ｶ2

出荷品質評価出荷l 剪…耳 チ

儼俯

饑

4

7H5

ｸ5H

ｸ7(5

原因調査.処置.対策 劔

対策の検証
l

図1‑2

①

設計インプットと設計アウトプット

図1‑3

劔幡ﾂ

品質保証体系図
第1章

設計検討とは?!

(∋従来型の進んでは戻るという開発のむだを解決するために､関連部門が設計初期段開発プロセスとナレッジデータ
設計検討が十分でないまま次のステップへ移行すると､不具合が発生しては修正を繰り返す､対策部品を作ってはさらに修正を繰り返すというむだの多い開発になってしまいます｡企業に利益を反映させる活動とはいえません｡･試作品の評価手戻り作業が多く発生し､設計のやり直しや部品再手配による開発期階に入り込み､要求事項を明確にし､対策案をともに考え協力することでスムーズな生産移行を目指す｢フロントローディング型開発｣が現在の開発スタイルの主流です｡
この活動によって試作段階はもとより､生産段階での手戻りを極限まで減少させて開発期間の短縮､経費削減などの開発の効率化を狙うものです｡
フロントローディング型開発のポイントは､ ｢事前の課題抽出力｣と｢事前の課題解決力｣ですoよって､設計段階で検討するためにより多くの工数(様々な部門担当者の検討時間)を掛けなければいけないのです｡

間の遅延､設計工数の増大･評価をすり抜けた不具合が生産後に発覚し､部品の大量廃棄､再手配､工場内や市場改造によるクレーム対策費用の発生

フロントローディング型
開発スタイル

従来の開発プロセスでは､モノができてから検討するウェイトが高かったのですが､それをフロントローディング開発では､モノができる前､つまり設計段階で課題をつぶしこむことにウェイトを高くします(図1‑4)0

作っては試す､試しては作るの繰り返し‑大量生産すると､新しい不具合が発見される

従来の開発プロセス

図ト4

開発プロセスの変化

フロントロ‑ディング型開発とは､開発の初期段階(Front)で､その後の製造段階で生じる問題点を把握し､事前に設計に作り込んでおくこと(Ij)ading)で､品質向上と開発期間短縮を図る手法をいいます｡∈)第1章

設計検討とは?!

(ラ品質機能展開表を利用して､横軸に既知である試験評価項目を設計検討項目とし､設計検討とは縦軸に機能するユニットやブロックを展開させれば､その部位で何を検討しなければいけないかが明確になりますoユニットやブロックごとに検討すべき項目を選択し○印をつければ設計検討すべき総数が明確になります○そして設計者が検討した数を塗設計検討とは､読んで字のごとく｢設計内容を検討すること｣です0

りつぶすことで大まかな設計の進捗管理に利用できます｡もちろん､検討した内容を設計現場で｢設計検討｣という言葉を使う場合､ ｢設計段階で事前に起こりうる不具合上司や先輩がチェックしなければ､これは機能しません｡を予測し対策を検討すること｣という解釈になります｡
設計要素 劔

もちろん､設計者は構想設計の段階で課題を抽出し､それを解決できる構造を決め､ｹV俶Ivﾂ劍ｴ､)4佶:(馼ﾘ

詳細設計を行っています｡ところが､それでも後工程や市場に出てから不具合が発生します｡若手技術者の育成をおろそかにしたことで､彼らは知識が乏しいことに加え､勘だ

No. h6ｨ6(6r ブロック 俶 ﾆdS 豆 傀 yﾒ 鰾 ｭB 収 納 杏 量 儉rh搬送モl夕負荷トルク鳴 Lr Yﾒ グ リ ッ プ 力 ﾒ 6" 4 ｴ

ﾕﾂ ,b ﾆﾞr

けに頼り､あと一歩踏み込んだ経験や理論に基づく検討をせず､安易な対策だけで安心しているからではないでしょうか｡
ABC‑X AOOOO

設計経験の少ない若い技術者にとって､いま設計している構造に対して｢あと一歩踏み込んだ経験や勘に基づく検討をどうすれば良いのか?｣頭をひねっても想像もつきません｡やみくもに思いつきで課題を洗い出してもポイントがずれ､むだな作業がY'Y

9ﾂ上部ユニット

A1000

A2000

剔

A3000増えるだけです｡

そこで論理的に検討するために､次の2つの視点で検証することができます｡

○ｲｲ

作表示部

投入口部
搬送部

A4000ｲｲｲ○
○

ｲ○

フレーム部

｢事前の事実検証｣ ‑‑･既知の試験評価項目の検証ならびに過去の不具合や各種安全規格などを確認し､その原因となる要素をつぶしこ

図1‑6

品質機能展開表の例

む､あるいは繰り返さないよう対処すること｡｢事前の仮説検証｣ ‑‑予測できない不具合を仮説し､さらに踏み込んで潜在する課題を見つけ､想定できる対策を打つこと｡

体裁を気にするあまり検討項目を増やし過ぎると､進捗を管理･更新するための数が膨大になり､管理するための時間が増えてしまいます｡これでは本末転倒です!
最小限にスリム化した品質機能展開表を作り上げることがポイントです｡

1 )事前の事実検証
事実検証は､試験評価項目や過去不具合など既知の事実に対して､机上で検証できる項目をコツコツこなしていけば対応することができます｡
この事前の事実検証は､設計進捗管理のツールとしても活用できます｡

お前は､一日中､し､課題を上司が事前に指摘することができましたが､ CAD導入後は計画図の内容や星取表を数えるのが仕事になっとるやないか!

進捗などの全体像が見えなくなりました｡そのため､ CADを使えない上司は､進捗度(byCAD導入以前ではドラフター上の紙に描いた計画図から上司が進捗度合いを判断上司)合いを設計担当者の自己申告やCAD上の線のボリュームから判断せざるを得ません｡
つまり設計進捗を論理的に把握する手段がなくなったのです｡
そこで進捗を把握するひとつの手段として､ QFD (品質機能展開)を利用することができます｡品質機能展開表は製品の設計段階からの品質保証を目的とした設計アプローチツールです｡①

第1章

設計検討とは?I①2)事前の仮説検証
仮説とは､ある現象(本書では課題)を合理的に説明するために､仮に立てる説のことです｡実験などによる検証を通じて事実と合致すれば定説となります｡

仮説は､単なる推論ではなく実験結果を基礎とするという考え方､つまり理論や法仮説検証は､様々な視点や経験から論理的に仮説を導き､潜在する不具合原因をつぶしこむ作業を行うことで､決して当てずっぽうで推測することではありません｡
仮説を立てるためには､原理原則を理解し､技術的な理論や技術者の成功や失敗の経験を踏まえて､第3章で説明するFMEAなどの解析手法を活用します｡

則を確立するプロセスに不可欠なものです｡

部材を自然落下だけに依存させず､滞留させるための原理を考えると､水分や静電気による吸着が考えられます｡そして､この水分や静電気が発生する環境を考えると､温度変化であり摩擦による帯電なのです｡

原理原則は､高等の技術的知識だけでなく､身近な生活体験の中にヒントが隠されています｡濡れた壁に何かが貼り付いたり､下敷きをこすると静電気が発生して髪の毛を吸い寄せたりと､身の回りで発生する自然現象を応用すれば良いのです｡
仮説を設定するためには､ナレッジデータを活用するとともに､必要に応じてCAE(コンビュ‑タによる設計支援)を使って解析を行うことも重要です｡このCAE解析にもナレッジデータが有効に働きます｡

CAEを使う場合､どうしても設計部門だけのツールと誤解されますが､他部門が積極的に活用し全社的なツールにしなければ､ CAEは宝の持ち腐れになります.

｢通路が曲がっていると部材が引っかかり滞留する危険性あり｣という課題は､構想段階で誰でも思いつく基本的なものです｡それに対して｢通路を直線とし､通路壁による接触抵抗を下げる｣という構造だけで設計者は根本対策できたと思い込んでしまいます｡これによって設計者は課題から解放され､精神的負担が少なくなります｡
仮説検証
たとえば､重力を利用して部材を落下させる構造において､
課題: ｢通路が曲がっていると部材が引っかかり滞留する危険性がある｣
設計案: ｢通路を直線とし､通路壁による接触抵抗を下げる｣
仮説1 : ｢環境温度の変化により､落下通路が結露すると部材が通路に貼りつく

機能性:匡体の強度設計

機能性:電子機器の放熱設計

生産性:樹脂充填性かもしれない｡落下抵抗を少なくするために通路の表面を滑らかにすればするほど､結露によって部材が貼り付きやすくなるはず･‑‑｣

図1‑7

CAE解析の活用

対応策: ｢結露の表面張力によって貼りつかない構造を考慮すべきである｣
一例)接触面積を最小限にするよう滑らかな凹凸を付けるなど
仮説2 : ｢通路の材質によっては､部材が高速落下する際の摩擦によって､通紘面が帯電し部材が静電気で滞留するかもしれない｣
対応策: ｢除竃を図る構造を考慮すべきである｣
一例)通路に導電材料を使用､除電部材の追加など

斥､)

第1章

設計検討とは?!

㊦