あまりに有名すぎて、私がコメントするまでもないと思われますが、個人的に開発のアイデア出しでブレストが有効であると思った事が有りません。

それよりも、1対1で自由闊達な議論をした方が遥かに有効であるであると感じていす。

一方、品質問題の原因追及等のように、広い範囲から、原因を絞り込んでいくような場合は、複数名でやはりブレストをするのが有効と思っています。

今回、私が経験から感じていたブレーンストーミングの問題点を的確に説明している図書を見つけましたのでその内容も紹介したいと思います。

開発のアイデア出しにブレストは有効？

　念のためにブレストについて説明すると、複数の参加者で自由にアイデアを出す手法で皆さんも経験されていると思います。

　開発のアイデアを生み出すには、自分が想定している範囲内には答えが見い出せないので、想定範囲を広げる事が必要になります。（左図参照）

　新しいアイデアを生み出すのは直感やヒラメキが大切です。論理的に考えていれば想定範囲内の外には出られません。

そういった観点で考えればブレストは発想が活性化され、アイデア出しには良いかもしれません。

しかし、アイデアはあくまでもアイデアです。実際には現実性を検証して行かなければなりません。

ブレストが開発のアイデア出しに向かない理由は、アイデアを吟味することなく、アイデアを出すことが主目的になるので、検証が行えないままアイデアがどんどん先行して行く事になるからです。

アイデアは発散と収束を繰り返し、少しづつ完成させていくものです。複数のメンバーでブレストした場合、何回も打ち合わせを持ち、収束と発散を繰り返すことは、時間的な制約で難しいのが現状です。

検証は後から行えばよいと思われるでしょうが、現実的に色々出てきたアイデアの中で、どのアイデアを検証していくか決めて行く事になります。

しかし、品質問題の原因調査のように、既にデーターがあるわけではありません。頭の中で仮想実験を行い、現実的かどうか考えて行く事になります。（仮想実験をするには、やはり専門知識も必要です。）

ブレストは、その場ではそのような考えもありかと思いながら、改めて考えてみると単なる思い付きに過ぎないアイデアだったり、開発者が？と思うような内容であっても、そのブレストの場で検討しようとなった場合、確固たる否定理由がない限り否定できないでしょう。

結局アイデアに振り回されやすくなるのが、開発のアイデア出しにブレストが向かないと思う一番の理由です。

ブレストで得られたアイデアは一回、開発者が良く考えた上で再び議論が出来るのであれば有効かもしれませんが、複数のメンバーでそれを期待するのは難しいのではないでしょうか？

　開発のアイデア出しに関しては、別の記事にまとめていますので良ければそちらも参照ください。

商品や開発の新しいアイデアが出ないと悩んでいる方へ、アイデアの生み出し方を紹介します。

色々な情報が頭の中で融合されて、パットひらめくのがアイデアです。その為には問題意識を持つ事が前提になりますが、潜在意識を活用することが大切です。問題意識を持つ　問題意識を持つのが最初になります。自発的に意識した場合は良いですが、強制的に意識...

rakuda0218blog.com

2020.12.28

1対1の議論が開発のアイデア出しに有効な理由

実際、複数人数でブレストをするよりも、普段の同僚（上司もOK）との会話の中で、思いつくまま意見交換を行い（二人ブレスト？）を日常会話として実施する方が遥かに有効と感じています。

　二人ブレストであれば、複数のメンバーで行うブレストによるアイデア出しの効果も期待できるし、出てきたアイデアについても自由に議論できるようになります。複数回の議論を重ねて発散、収束を繰り返すことも可能です。私は５人でブレストを１回するのであれば、５人の人と５回、自分の中で発散、収束を繰り返しながら５回実施した方が有意義だと感じています。

品質問題の原因追及にはブレストが有効

開発のアイデア出しのように、想定範囲を広げてその中から解を見つけて行くような場合にはブレストは向かないと思っています。

　しかし、左図のように、想定範囲を広げるのではなく、ロジカル・シンキングなどにより絞り込んでいき解を見つけて行くような場合はブレストは非常に有効だと思っています。

　なぜらな、個人の想定範囲（知っている事）には限界があるので、想定範囲を広げるためにも複数人でブレストする事が大切です。

想定範囲が広くないと原因追及には漏れが生じます。

開発のアイデアの場合と同様、出てきたアイデア（仮説）は議論しなければなりませんが、状況証拠（データ）をベースにロジカルシンキングに代表されるような論理的な議論が想定範囲から絞り込んでいくような場合には複数人でも可能となります。

逆に、想定範囲を広くしておかないとどうしても漏れが出るので、やはり、複数のメンバーでブレストする事が有効だと思います。

具体的な品質問題の追及方法は別の記事にまとめていますので、良ければそちらを参照して下さい

物理/化学的な不良の原因追及、原因調査。仮説の立て方、コツ

私は不良の原因を追究する方法は、殺人事件を解決するTVドラマで良く出てくるやり方よく似ていると思っています。現行犯逮捕（不良が発生している状況が観察できないか）まず考える出来なければ現場検証、証拠、人間関係から犯人を推測する。（仮説立案）仮...

rakuda0218blog.com

2021.01.28

自分の発想力を高めるには？（参考図書より）

「メタ認知　あなたの頭はもっと良くなる」　中公新書ラクレ　三宮真知子著（大阪大学名誉教授、鳴門教育大学名誉教授）に私の想いを代弁してくれているような記載があったので紹介いたします。

（ブレーンストーミングによって）他の人がどんなアイデアを思いついたのかを知ることは大切ですが、先に人の考えを聞いてしまうと、どうしてもそれに影響されてしまい、自分で徹底的に考える事をしにくくなる可能性が有ります。

従って、自分の発想力そのものを高めるためのトレーニングは、やはり個別に行う必要が有ります。（中略）私たちは、他者の考えに触れる機会を確保しつつ、個人の発想力を高めるトレーニング法を開発しました。まず自分で、これ以上は無理というまで考えた後で、他者の考えを色々と呈示する方法です。（中略）「まずは自分で限界まで考えてみる→他者の考えに触れる。→自分の考えを見直す」という事を繰り返すトレーニングです。

メタ認知　あなたの頭はもっと良くなる　中公新書ラクレ　三宮真知子（大阪大学名誉教授、鳴門教育大学名誉教授）著、P132～133より

著者の方は、討論が思考を複眼的にする　とも記載されています。

討論において、自分とは異なる考えを持つ人の意見に耳を傾ける事が役立ちます。（中略）「賛成」や「反対」といった主張は同じでも主張の根拠が異なる場合が有ります。意見というものが、様々な根拠によって組み立てられているという事を知ることは大切です。

討論はまさにこうした貴重な機会を提供してくれるものです。また、討論の際には、「討論によって自分の考え方を複眼的にする」というメタ認知的な目的を意識しながら望むとより効果的です。

メタ認知　あなたの頭はもっと良くなる　中公新書ラクレ　三宮真知子（大阪大学名誉教授、鳴門教育大学名誉教授）著、P134～135より

まさしく、私の想いを代弁していただいているように思いました。著作の中では、「IPE（Idea Post-Exposure)パラダイム」と名づけ、その効果も記載されています。

まとめ

狩野モデル

設計/開発を進める上で、お客様の要求事項、要求品質を洗い出すのが最初と言われています。

しかし、お客様の要求品質の種類によって、その要求品質を洗い出す方法は考えないと的確な要求はつかめないと考えています。

お客様の要求品質の種類については「狩野モデル」と呼ばれるモデルが有ります。

右の図のように、他社との差別化につながる魅力的品質、競合他社との性能比較をされる一元的品質、取りこぼしが許されない当たり前品質に分ける事が出来ると考えられています。

狩野モデルで分類されている、魅力的品質、一元的品質、当たり前品質を的確に引き出す方法を考えたいと思います、

お客様の要望をどうやって引き出すか？

魅力的な品質

魅力的な商品は、潜在ニーズを把握する必要が有ります。

お客様が気が付いていないニーズをいち早くとらえる必要が有るので、取り扱っている商品によって、潜在ニーズの引き出し方は違ってくるのではないでしょうか？

B to Bの場合

私はB to Bで電子部材、あるいは液晶用のガラス基板を扱う部署にいたので、直接のお客様だけでなく、その先のお客様、業界のロードマップなど、色々な情報から、直接のお客様と未来について議論することでニーズを引き出すことが大切になります。

そのことを模式的に示したのが図1：「魅力的な品質」を引き出す方法です。

お客様でも適切な部署の方（キーマン)と議論をすることが大切になってきます。また、具体的な形が無いわけですから、コンセプト、あるいはストーリーを話する事が大切になります。

B to Cの場合

一方、一般消費者向けに商品やサービスを提供されているような方は、ただ、単純に聞いただけでは一元的な要望しか出てこないような気がします。

一般的には、消費者の行動を観察すると良い、あるいは、何か要望が出た時のその理由を聞くのが良い。とも言われているようですが、難しいような気がします。

何かのTVで見ましたがアイリスオーヤマさんは、商品を使い倒して開発のアイデアを得るとのことでした。

魅力的な品質を引っ張り出すのが仕事だと思う事で、意識がそこに向き、より的確な潜在ニーズが引き出せると思われ、非常に良い方法だと思いました。

また、世の中の新商品と呼ばれるものは、発明者のひらめきや、熱い思いから出てくるものも多々あります。

いずれにしても、お客様にとって、何が魅力的な品質なのかに関しては、各社、扱っている製品、サービスによって個別に考える必要が有ると思います。

一元的品質

お客様からヒヤリングして、最も得られる要望はこの一元的要望でしょう。性能品質と呼ばれるように、日頃。不満に思っているので、お客様の声が直接使えると思います。

なので、仕様書などでスペックを提示し、サンプルを評価してもらえれば、そのFeed Backがそもそも一元的な品質（機能）のFeed　Backになります。

そのことを模式的に示したのが図2:「一元的な品質」を引き出す方法です。

当たり前品質

当たり前品質は制約事項と捉えても良いでしょう。

しかしながら、お客様の要望を聞いても要望事項として挙がってきません。何故なら、当たり前だと思っているからです。

私が、梱包容器の設計を担当していた頃は、事前に流動試験をしているにもかかわらず、数が多く流れるようになると、そもそも、お客様の工程で搬送出来ない。等とといった、当たり前の品質が確保されないことが、恥ずかしながら有りました。

それらの原因は、お客様の工程を流すうえで、どこが危なそうか事前にお互いに十分確認できていなかったことが原因です。

制約条件はお客様も製品の事が良く分かっていないので、何が制約条件になるのか分からないのです。

従って、設計/開発者が実績のある既存品と何が違うのかを明確にして、お客様とどういった問題が起こる可能性が有るのか、前広に協議をすることがどうしても必要になります。

何故なら、既に実績が有る物は問題なく使えている訳ですから、トラブルの原因になるのは、実績の有る物と違う所が原因になるはずであるからです。

そのことを模式的に示したのが図3:「当たり前品質」を引き出す方法です。

既存品が他社品しか無ければ、あらゆる手段を使って、他社品の情報をかき集めるしかありません。

そんなの図面をしっかり確認していないだけだろう。と思われた方。私もそう思っていました。しかし、現実は、図面に記載されていない情報が遥かに多いのが現状です。

ポイントを絞って議論する事が必要不可欠になります。

まとめ

実際に新しい製品を設計開発する場合は、まず、必要な機能を明確にしてそれを達成する具体的な手段を考えるのが一般的な設計開発の流れになります。

具体的な設計開発要素に落とし込んでいく事になりますが、その時に出来るだけ「モジュラー型」つまり、共通部品を活用したり、過去の技術を活用できるように考えて行く事が大切になります。

なぜなら、「モジュラー化」を進める事で機種同士の互換性やメンテナンス性（必要な部材のみ交換する）、設計開発期間の短縮にもつながり、部品の在庫減にもつながるメリットがあるからです。

しかし、部品、コンポーネントの標準化を進めると言っても、注意しなければいけないポイントというのが有ります。

インテグラル型とモジュラー型

• 「インテグラル型」とは
  • 精密な部品を緻密にすり合わせて一つの製品を作り上げる開発手法

• 「モジュラー型」とは
  • 重要な機能を担う部品の連結については標準的なユニットになっていていくつかのユニットを組み合わせる事で製品を作り上げると言うもの

と言われています。このことを概念的に示したのが下記の図です。

私はこの考え方は「コストは必ず半減できる」　三木博幸　日本経済新聞社　に記載されていたので知りました。もともとは、東京大学大学院の藤本隆宏氏が提唱した考え方の様です。

モジュラー型のメリット/デメリット

モジュラー型のメリットは、何と言っても開発期間を短くできる事にあると思います。互換性やメンテナンス性、製造コスト削減にもつながります。

一方、標準化された部品のみでは要求された機能は満たせない事は容易に考えられるので、実際の設計においては、どの部分に標準化された部品を使うのか、見極めるのが大切になります。

また、モジュラー型の産業では、必要な部品を集め、それをどのように組み合わせるか？という事になりますので、誰でも参入できるようになる。といったデメリットは有ると思います。

考え方によっては、誰でも参入できることは市場といった点で考えればメリットにもなると思いますが、もの作りのすべてのプロセスをブラックボックス化してきた日本メーカーから見ればデメリットになると思います。

「インテグラル型」から「モジュール型」の流れ

上記、三木博幸氏の書籍のよれば、日本の製造業が伝統的に培ってきたものつくりは、企画から開発、生産、販売、アフターサービスまで一貫して行い、繊細な部品を緻密にすり合わせて一つの製品を作り上げる「モジュラー型」です。

しかし、インテグラル型の代表のように言われていた自動車産業も電気自動車に進化するにつれて、電気系統の占める部分が大きくなり、「モジュラー型」の傾向が強くなると考えられます。

市場のスピードについてゆくには、同じ経営資源なら「モジュラー型」の製品開発に投入して短期間で出来るだけ多くの製品を市場に送り込む方が得策であり、この流れは決して後戻りする事は無いだろうとの観測が市場関係者から上がっていると、上記、三木博幸氏の書籍にも記載されています。

実設計の「モジュラー型」で気を付ける事。

商品の市場規模、賞味期限を考慮する

部品の標準化を進めるにあたっては、そのメリットを享受するためには市場規模が大きい事が必要です。標準部品を決めたとしても、数台しか作れないのであればわざわざ標準部品を使うまでもありません。

部品の組み合わせを考えるよりも、それこそ、「インテグラル型」で考えた方が市場規模が小さい場合には良かったりします。

また、標準部品を作るにはコスト投資も必要になるでしょうし、仮に購入するにしても数を多く購入できなければ価格のメリットも望めなくなります。

そればかりか、標準部材を決めたからと言って、それを使う事を第一に考えると、他にしわ寄せがでて、他の開発を進める必要が出てくる場合もあります。

似て非なる標準部材が出来る。

私が経験した中で一番気をつけなければいけない事は、結局標準品と言いながら、似て非なるものが出来てしまう。という事です。

なぜ、似て非なる標準部品が出来てしまうかと言えば、主な理由は二つあると思っています。

国によって調達出来るもの、出来ない物がある。

ネジ一つとっても国によって規格が異なります。国によって調達できない物があったり、調達するにしても非常に高額になる場合が有ります。

樹脂材などは、日本のメーカー品の物を標準とした場合に、中国では購入できない。あるいは、購入するのに非常に高額になる場合も多いです。

そのような事も考慮し、どこまでを標準品とするのか、前述した標準品の市場規模、賞味期限を考慮して決める事が大切になります。

使いやすいように標準品をアレンジする。

前述したように、国によって調達できる、出来ない、といった調達性も大きな要因ですが、これを標準品として決めても、実際の図面を起こす際に、その配置、取り付け方法など、設計者が良かれと思い、取り付け部分が少しだけ異なる等が起こりがちです。

そうなると、生産性上、効果のないものになってしまうばかりか、管理も複雑になり、悪影響が出る事もあります。

似て非なるものに対する対策は？

部品の標準化はリーダーが、自らリーダーシップをとり、色々な部署から情報をもらってデザインレビューでしっかり市場規模や調達性も含めてレビューする事が大切になると思います。

また、設計開発で決めた標準部品とたとえ軽微でも変更したい場合は、設計変更申請を行い、設計開発部署などで一元管理するなどの工夫も必要になると思います。

まとめ

コストダウン設計の基本

商品の価格は設計の良し悪しの影響を大きく受けると言われます。確かのその通りで、機能、品質だけを追求して、設計開発を進めるのではなく、QCD（品質/コスト/納期）のバランスをとって進めるのが大切だと言われます。

そのことを概念的に記載したのが下の図になります。

コストダウン設計に関してはマンパワーの制限などで、商品設計、工程設計、と分ける傾向がみられますが、本来、商品設計と工程設計は不可分です。

実際に作りやすい商品を作らないとコストダウンは到底不可能ですし、品質/機能を実現するのに適切な工程設計をする必要が有ります。

担当が商品設計と工程設計に分かれるのは仕方がない面は有りますが、開発リーダーがまとめ上げることが大切になると思います。

情報収集

お客様の要求事項を如何に吸い上げるかについてはすでに記事にしていますので、そちらを参照ください。

「狩野モデル」における、当たり前品質、一元的品質、魅力的品質、それぞれに情報収集方法を変える必要があると感じています。

【狩野モデル】の「魅力的品質」「一元的品質」「当たり前品質」の対処方法を考える。

お客様の要求事項の種類については「狩野モデル」と呼ばれるモデルが有ります。有って当たりまえの当たり前品質、つねに他社との品質比較にさらされる一元的品質、他社との差別化につながる魅力的品質の対処方法について考えます。　狩野モデルとは狩野モデル...

rakuda0218blog.com

2021.01.04

設計開発企画、

目標コストを決める

私が長年担当していた梱包容器のような購入価格ももちろん大切ですが、実際にガラスを何枚運べるのか？輸送する際に、実際、何パレット運べるのか？といった、使用効率の方が大切になってきます。

仮に、購入品の価格が上がったとしても、ランニングコストが減って、結果的にはプラスになる。あるいは、新規開発品を採用する事で、新規のお客様開拓につながるとか、仮にコストアップになるとしても、それを十分回収できるといった、シナリオを考えて、目標価格を購入部署と決めておく事が大切です。

一般に生産技術の場合は、影響の範囲も広く、特に、新規の設備投資であれば金額も高くなることから、広範囲の階層、部署との合意が必要になります。しかし、しかるベき相手と目標コストを決める事に変わりは有りません。

購入品の場合

実際の購入額は、サプライヤーさんから見積もりを入手しないと分からないところがあります。

サプライヤーさんによっては、新機種なので利益を多めに取りたいなど、こちらの思惑通りにはならないことも多々あります。

サプライヤーさんのコスト構成も正直不明です。ヒヤリングして回答が来たとしても正直に答えられているとは思えません。

設計、開発のレベルでは、コンセプト、考え方として、現行の機種に比べて、材料や生産性、追加加工設備などを想定し、あらかたのコストアップ率、コストダウン率を見積もることになります。

自社開発品の場合

アイデアの段階では、製造などからコスト情報をもらい、コストダウン要因を盛り込んで、コスト予想を開発者がまとめる必要が有ります。

関連部署と協議するには、購入品の場合も同じですが、見積もり条件、コスト試算条件は明確にしておく事が大切です。

この時点では、シナリオによって、結果は大きく変わってきますので、他部署との合意に向けて、開発者が自らのシナリオに自信を持つためにも、開発者がまとめる必要があると思っています。

コスト目標を達成するためのシナリオ

コスト目標をお客様の要望事項として取り込み、それを満足するための開発目標、開発コンセプトを明確にして、要素技術、開発目標、設計仕様に落とし込んで行く事になります。

この辺りも記事にしていますので良ければ参照ください

要求事項を明確にし、現実対比を行い要素技術/設計目標/開発目標にまで落とし込む方法。目標値の決め方。

要求事項を明確にし、現実対比を行い、要素技術/設計仕様/開発目標にまで落とし込む方法は以下のようなイメージです。　QFD「品質機能展開」よりも「開発コンセプト」を導入することで、お客様からより必要な情報が引き出せると感じています。要求事項を...

rakuda0218blog.com

2021.01.05

デザインレビュー

コストが目標コストを達成で競うか否か、自分で試算する必要が有ります。なので、比例費や固定費、損益分岐点、コスト構成など、最低限の経理的な知識は必要です。

目標コストはそのシナリオも含め関係部署と合意しておく事が開発を進める前提！

しかし、この時点では、前提をどう置くかでコストの試算結果は大きく変わりますので、関係部署が納得するシナリオを作る事の方が重要です。

目標コストはお客様の要求事項の一部ですから、それだけで合意出来る物ではありません。かならず、開発目標や開発コンセプト、開発目標や要素技術、設計仕様と合わせて合意してもらう必要が有ります。

そのためにもデザインレビューの段階では、設計部門のメンバーで、他部署と合意する前に、設計部門で案を厳しくチェックする必要が有ります。

コンカレントエンジにリングと呼ばれるようですが、アイデアレベルから他部署を巻き込んで並行して進める事が開発期間短縮のためには必要であるとの論調をよく見かけます。

しかし、一般的には、アイデアの段階から関係部署に話をもっていっても、大体、相手にされないのではないでしょうか？

アイデアの段階では、他部署を巻き込むよりも、少人数で深く議論し、自分なりのシナリオをこれで行けると自信が持てるまで検討する事が非常に大切。尚且つ、少人数でPDCAを早く回し、関係部署と議論できるまでの期間を短くすることの方が大切だと私は感じています。

実際に検証結果が出る前ですので、関係部署と合意できるように理由と根拠（エビデンス）の見直しを行う事になります。

厳しくチェックするのは大切ですが、この時点で、重箱の隅を突っつくような議論は意味が有りません。色々な角度から議論してこの時点では、自分で十分な納得でき、自信を持つ事が大切になると思っています。

設計検証

本格検証に進むには関係部署の了解が必要になります。この時点で、描いていたシナリオは協議の対象となり、合意され、実際に検証が始まると、考えていたシナリオ通りにいかないのが普通です。

考えていたシナリオの、何が実態と合わないのか？を調べて、コストダウン対策をVE、VAの考え方を入れて、考えて行く事になります。

しかし、言うのは簡単ですが、シナリオ通りにいかない場合、そもそも、目標とする機能が達成できていなかったり、品質問題が発生して、コストダウンにまで時間が取れない場合が良くあります。

そんな場合、設計者が判断するのではなく、品質/コスト/納期（QCD）に関しては、決裁者も含め、優先順位、対応方針を関係者で良く共有する事が大切になります。設計者としては、気が重い所は有りますが避けては通れません。後で揉めるより先に揉める方が遥かに効率的です。

購入品の場合は見積もりを取る事になります。

社内で開発が終了するのは加工、組み立てを行うようなメーカーでは非常に稀と思われます。副資材、工具などは購入品でしょう。場合によっては加工装置を購入する場合も考えられます。

サプライヤーは通常、付き合いのあるメーカーさんに声をかけることになります。新しいサプライヤーを検討する場合は必要に応じて購買部門と共同で進めて行く事になります。

見逃されがちですが、注意しなければならないのは、部材や、購入品をメーカーと一緒に開発した場合には、1社購買になってしまう事が多い事です。2社購買できるよう、設計と購買部門は協力して行く必要があります。

こちらの方では、考えてきたシナリオをベースに、資材が仕様以外の項目も踏まえ、交渉して行く事になりますが、1社購買である事を見透かされていると、やはり、値段は下がりません。

市販品であれば、代替品の評価は合わせて検討すべきです。

一方、梱包容器などは、個別設計です。知的財産は当方にあり、サンプル作成や量産準備、設計検討にかかる費用などはこちらが負担するので、数量保証などには応じない。といったスタンスで臨みます。受け入れてくれるメーカーさんもありますが、そうはいかないメーカーさんももちろん有ります。その場合は具体的に何を懸念されているのか確認したうえで協議をします。

揉めるのは知的財産の取り扱いや数量保証の事が多いので、具体的に協議し解決をはかります。折り合いがつきそうにない場合には、お断りする必要も出てくるので、最初にはっきりしておく事が大切です。

いずれの場合も機密保持契約や、覚書、あるいは開発委託契約などの契約ではっきりしておく必要があります。

まとめ

開発者がコストを見積もるには、製造などから必要な情報をベースにして、自分が考えたシナリオでコスト見積もりを行う事になります。

従って、最低限の経理知識と、しっかりしたシナリオを立てる事が大切になります。

変動費と固定費

製造コスト、製造原価とも言われますが、製品を作るのにかかる費用です。

製造原価＝変動費+固定費

変動費

生産数量に比例して増えるので、製品１個当たり、比例費はいくらかかるのか？といった観点で考える事が大切です。原単位という言い方をします。

副資材や、原材料の購入単価で比べても、製品一個あたりに使用する量が変われば、費用も変わってきます。原単位は、すべて、製品１個当たりで比較する事で適切な比較が出来る事になります。

ある機種は他の機種に比べて原単位が高いのは何故か？他の工場と比較して何故、原単位が違うのか？等、製造主催のコスト会議に参加すると格好の議論の対象になります。

また、製品1個を作るのにかかるのが比例費なので、不良品であっても、良品であっても同じだけ変動費はかかります。実際にお金が回収できるのは良品になりますので、歩留まり（良品率）が低くなれば、それに比例して、変動（比例）費は高くなります。

歩留まりは、製品の不良、良品、だけではなく、原材料でも、使用できない部分が出てくれば、その分、当然、変動費は高くなります。

変動費の歩留まりの向上や材料の利用効率向上など、製造が使い込んで行ったり、改善活動で改善される余地はありますが、そもそも、製品を作る上での原材料や購入部品などは設計で決まります。

固定費

開発が原価見積もりをする場合、真っ先に気にするのは、減価償却費です。減価償却は、装置など、使用できる期間を見積もり、その期間で装置費用を負担して行く（償却して行く）、といった単純な経理処理上の数字の事です。

昔は、生産設備の減価償却は5年、あるいは10年と言われていましたが、コスト試算する時は、最近は技術の進歩も早く、1年、あるいは、3年で考えるべきと言われることが多いです。（会社や業種によるのかもしれません）

新に装置を購入する必要がある場合は、償却が始まると、その分、固定費が高くなります。しかし、固定費は生産数量に関係なく一定の金額がかかるので、一個製品を作るのも、100個製品を作るのも、結局、例えば、100円といった金額がかかります。

一個の製品で100円の固定費を回収（元を取る）と考えれば、１００円の原価になりますが、100個の製品で回収しようとすれば1円の原価、つまり、それだけ安くすることが出来ます。

なので、通常、固定費を下げるには、生産性を上げて、単位時間あたり、数多く製品が作れる、スループットを上げる事が非常に大切になります。

歩留まりも良い方が、固定費は下がりますが、結局、単位時間当たりの良品が作れる能力が影響しますので、歩留まりが仮に低くても、それ以上に生産性が高ければ、固定費は下がることになります。

作りにくい製品を設計すると当然生産性は上がりませんので、作りやすさを考慮した設計開発が必要になります。

損益分岐点

購入品や、生産技術の場合、開発が実施するコスト見積もりであれば、原単位や歩留まり、生産性（スループット）を見積もれば大体、事足りると思います。

しかし、製品を開発する場合には、実際にお客様に買っていただかないと、原価を回収できません。営業と目標コストを設定する際、必ず、数量とセットになった話になるので、損益分岐点の考えは開発者も理解しておく事が大切になります。

製品の数量が少ないと、実は売ると損失が出ます。ちょうど、損失が出なくなる数量（売上）を損益分岐点と呼びます。（実際には、一般管理費が乗ってくるので、損益分岐点では赤字ですが、、、、）

この場合は、売って損するだけです。なので、必ず、粗利がしっかり確保でるように、価格設定、数量設定を行う必要が出て来ます。

製品設計と工程設計

コストダウン設計に関してはマンパワーの制限などで、商品設計、工程設計、と分ける傾向がみられますが、本来、商品設計と工程設計は不可分です。

実際に作りやすい商品を作らないとコストダウンは到底不可能ですし、品質/機能を実現するのに適切な工程設計をする必要が有ります。

担当が商品設計と工程設計に分かれるのは仕方がない面は有りますが、開発リーダーが適切に指導し、まとめ上げることが大切になると思います。

まとめ

しかし、部材メーカーが完成品メーカーと共同で部材の開発を行い、その帰属を共有とした場合、じつは完成品メーカーは他社からも部材を調達できてしまいます。

契約については、法務部門や知財部門に指導、確認してもらう事が大切です。が大切な成果物の帰属については開発者も必ず関係してきますので知っておく事は大切になります。

各知財契約の特徴

機密保持契約（NDA）

秘密情報の守秘義務および目的外使用の禁止などを記載する契約です。契約を結んだからと言って重要なノウハウはオープンにしてはダメです。また目的外使用の禁止の条項や、サンプルの取り扱いなどは決めておく事が大切になります。

NDAについては記事にしているので良ければ参照ください。

機密保持契約（NDA）を結んでもノウハウは安易に教えてはダメです。その理由と対処方法です。

機密保持契約（NDA）を結べば形式上は開示相手以外にオープンになりません。しかし、ノウハウの帰属と取り扱いを決めておかないと特許と違ってノウハウとしてすら認めてもらえず、勝手に使われるといったリスクが発生します。事前にノウハウの内容を知らせ...

rakuda0218blog.com

2021.08.24

開発委託契約

受託者が開発を行い、委託者が費用を負担する。委託者が受託者が行った開発成果のすべてを独占する事が多いです。開発成果の独占が重要な場合には、共同開発より開発委託の方が適切ともいえます。

取引契約

ビジネスの取り決めなので、一般に開発者はあまり関与しません。しかし、ケースによってはこの契約で知財成果の帰属や利用を決める場合もあります。

共同開発契約

開発実施要項、具体的には、開発の目的から始まり、開発期間や、役割/費用負担、開発の進め方などを取り決めます。

しかし、一番揉める原因になるのは成果物の帰属・利用（製造・販売・バックグラウンド特許を含む単独特許の取り扱い（ライセンスを含む）、第3者へのライセンス）等です。

成果の帰属

発明者の所属に帰属させる、

一方の当事者の発明の場合は単独帰属、両方の発明者が創作した場合は共有

ごく自然な取り決めですが、具体的に進めると、明確な区分けは難しく実質的に開発業務を担当している側に有利に働いたり、技術力の強い側に有利に働きがちです。

自社がすでに持っている技術、成果物は何か。新たに生み出された成果物は何か？

必ず、事前にこれは私の技術ですよ。と相手にも納得してもらう事が大切です。後で言えば揉める事になります。なので、単独で出願できるものは、まず出願しておく事が大前提になってきます。

新たに生み出された成果物に対して共有とするためには、発明者たる貢献をしたのか？という所もポイントになります。単に課題を与えた、あるいは、評価しただけでは発明者とは通常みなされません。

しかし、通常は結果においても議論をするのが通例であり、この領域を白黒はっきりするのは難しく、グレーの所は残ります。

新しい発明はすべて共有とする。

従って、新たに生み出された成果物については帰属は無条件に共有にしようといった契約もあり得ます。

しかし、この場合、技術力が弱い方が有利にはなってしまいます。発明者たる貢献をしなくても成果物は帰属するからです。そのために、貢献度も加味して成果物の利用は別途協議する。といった考えもあります。

共有成果の利用

共有成果の共有者の同意の要否

日本の場合、契約で特に定めない場合、

• 製造販売等の自社実施、第三者への侵害訴訟の提起については、同意は不要
• ただし、第三者への持ち分譲渡や実施許諾については同意が必要になります。

成果の帰属による売買への影響

上の図は、部品特許と完成品特許を両方とも成果は共有とした場合、部品メーカー、完成品メーカはともに自由に特許を実施する事が出来ます。

しかし、完成品メーカーが部品特許を実施する場合、A社から購入しても良いですし、自社で作っても良いですし、なんと、A社の競合であるC社にも作らせることが出来ます。（米国のhave made権,下請け製造）ただし、C社はB社以外には売れません。

一方、部品メーカーA社は部品をB社の競合であるD社に販売することは可能です。しかし、いくら完成品の特許を共有していても、D社は完成品を作ることは出来ません。実施許諾についてはB社の了解が必要になるからです。

契約に対する考え方

フライングで開発を進めるのはトラブルのもと

契約ではお互いの利益が発生しますので、揉める事が多く、時間がかかることが多くなりがちです。開発を進める方としては、どんどん開発を進めたいのですが、共同で開発を進める場合、やはり成果の帰属とその利用に関して合意しておかないと、後になって開発を中断せざるを得なくなったりします。

NDAに付随する形でも構わないので成果物の帰属とその利用においては事前に合意しておく事が大切になります。

契約ありきで考えない

NDAであっても、こちらから開示した情報だけでなく、相手から入手した情報にも縛りが入ります。いわゆる情報コンタミの問題も発生します。

単に課題を提供しただけでは、通常は発明者とは認められません。役割分担をよく協議する中で、共同開発契約を結ばずに単独で進める事も可能性はあるのではないでしょうか？

また、契約はお互いの利害が関係します。通常の交渉と同じですが、まず活用方針を決めます。落とし所ではなくボトムライン（契約を結ばないライン）を明確にし、そうなった時の代案まで検討しておく。自社の強みも再認識したうえで、交渉相手と最も良いと思える合意を目指す。

といった事が大切になると思います。

参考図書：戦略的交渉入門　日経文庫　田村次郎　隅田浩司　著

まとめ

しかし、この手法はお客様の声（VOC、Voice of Customer)を出発点としています。しかし、お客様はすべてを語ってくれません。

お客様がメーカーの場合、まずはコンセプトをお客様と協議しながら同時に要望事項を聞き出し、既存品との違いは何なのか具体的にして広く前広に協議することが大切です。

QFD　品質機能展開とは？

【資料・ツール解説】QFD（品質機能展開）の手法解説と「品質表」の使い方 | アイアール技術者教育研究所

QFD（品質機能展開）は、日本で開発され、米国をはじめとする世界へ広まった品質管理手法です。 今回はQFDとQFDで用いる各種展開表（品質表など）について解説し、職場のPC等で便利に活用することができるエクセル形式の展開表フォーマットもご紹...

engineer-education.com

以下、上記サイトの抜粋になります。具体的な点数の計算方法は上記サイトには記載されていなかったので私の方で追記しています。

♦まず顧客はどのような品質を欲しているのか（要求品質）を拾い上げ階層構造にまとめ上げる。

実際にお客様の要請は、様々な表現で出てきます。同じような表現が出てくるので共通する要求事項でまとめ、具体的な品質特性と結びつけられるように階層化しておく事が大切になります。

♦次に顧客要求に対して技術的にどのような特性(品質特性）を考慮すべきかをまとめる

♦要求品質と品質特性の関係性を整理するために品質表を作成する。

要求品質と相関が強いと思う項目を◎、相関が有るものを〇、可能性が有るといった程度の物を△で示して、上記の品質表を完成させます

♦製品の品質をどのように企画するのか（企画品質）を設定し、要求品質ウエイトを計算する。

要求品質重要度とは、お客様がその要求品質をどのくらい大切だと思っているか。といった指標です。本来はお客様に評価いただくべきでしょうが、メーカー側で、協議、あるいは、エイや、で5段階で評価しましょう。

続いて、自社、他社の現状を5段階評価しましょう。

例えば一番上の「省エネ性に優れる」であれば、要求品質重要度は5点、自社は3点、他社は3～5点で他社に劣っているとの評価になります。

企画品質とはここでは、どれだけメーカーとして力を入れるかを数値化した物です。

ここでは、「省エネ性に優れる」はお客様が重要視しているにも関わらず、他社より劣っているので特に力を入れようという事で企画品質は5点。としています。

レベルアップ率はここで設定した企画品質、5点は自社の評価3点からどれだけアップさせなければならないか示したものです。ここでは5/3で1.67となります

セールスポイントはまさしく、この企画品質が達成出来たら売りになると思えるか？という事です。ここでは◎を1.5、〇を1.2と点数化しています。

絶対ウエイトは要求品質重要度（5点）×レベルアップ率（1.67）×セールスポイント（1.2）を掛け合わせたもので。「省エネに優れる」の絶対ウエイトは12.5となります。

要求品質ウエイトは絶対ウエイトの合計（37.0）の内、例えば「省エネに優れる」の絶対ウエイトの割合を示したもので12.5/37で33.8％になります。

♦品質特性ウエイトを計算し特に注力すべき品質特性は何かを明確にして設計品質に落とし込む

品質表で要求品質と品質特性の相関性を整理しましたが、ここでは◎を5点、〇を3点、△を1点とします。

要求品質重要度を相関性から重み付けを行い、品質特性の重要度を計算した物が品質特性重要度です。

具体的には、品質特性の効率は、「省エネ特性に優れる」が◎なので5点、それの「要求品質重要度」が5点なので、掛け合わせて（重み付け）25点。

同様に計算して「小水量運転可」は3点、「低振動」は5点、「低騒音」は9点となります。

合計して、25+3+5+9=42になり、効率の品質特性重要度は４２となります。

同様に、要求品質ウエイトを相関性から重み付けを行ったのが品質特性ウエイトです。

例えば、この渦巻ポンプを開発するには、品質特性ウエイトが200点以上の「制振性」「剛性強度」「効率」を重点的に開発して行こう。という事になります。

QFD　品質機能展開の注意点

お客様はすべてを語らない

そもそもお客様の要望、原始データとも、生の声とも言われますが、お客様は基本的にすべてを語ってはくれません。

「狩野モデル」では「当たり前の品質」「一元的品質（機能品質）」「魅力的品質」が有ると言われます。

しかし、お客様の声は基本、機能品質に対する要求です。

魅力的品質

無くても困らない品質なので、有ったらいいなと思う事を色々な人が色々な事を言ってきます。B to Bの場合、その先のお客様の状況、業界のロードマップなど、色々な情報から、直接のお客様と未来について議論することでニーズを引き出すことが大切になります。

一元的品質（機能品質）

競合他社との比較なので分かりやすいので不満として出て来やすい事になります。

当たり前品質

「当たり前の品質」はお客様も当たり前だ！と思っているので表面に出て来ません。当たり前ですよね。（笑）しかし、当たり前の事が確実に出来る事は簡単ではなく、要望というよりは制約条件を明らかにすることが非常に大切になります。

ただし、お客様がメーカーの場合、制約条件はお客様も製品の事が良く分かっていないので、何が制約条件になるのか分からないのです。

従って、設計/開発者が実績のある既存品と何が違うのかを明確にして、お客様とどういった問題が起こる可能性が有るのか、協議をすることが必要になります。

つまり、制約条件を明確にするにはお客様の声を出発点とするだけでは抜けが有り、設計/開発のコンセプトを最初にしっかり組み立て、まずはコンセプトをお客様と協議しながら同時に要望事項を並行して引き出して行く事が大切になると感じています。

設計開発は何かを変更すると影響が色々な所に出て来ます。予想もしていなかったところに出てくることも良くあります。なので、既存品との違いは何なのか明確にして広く前広に協議することが大切です。

お客様ってだれ？

お客様を製品を買ってくれる人、と考えると製品に必要な情報は十分に集まりません。実際にはあなたが開発した製品の影響を受ける人すべてです。社内の後工程の要望はお客様の要望です。

関係者の要求品質をまとめると考えた方が良いでしょう。

私が実施していた品質機能展開方法

私は品質機能展開　QFD　といった手法を知らずに設計/開発をしていました。QFDの手法は確かに要求品質を設計品質に落とし込むのに有効さ手法だと思われましたが、上記の注意点に関してどう扱えばよいのか私が調べたサイトや本には説明が有りませんでした。

参考までに、私が実施していた品質機能展開方法（ふせ方式）を紹介します。良ければ参照してください。

要求事項を明確にし、現実対比を行い要素技術/設計目標/開発目標にまで落とし込む方法。目標値の決め方。

要求事項を明確にし、現実対比を行い、要素技術/設計仕様/開発目標にまで落とし込む方法は以下のようなイメージです。　QFD「品質機能展開」よりも「開発コンセプト」を導入することで、お客様からより必要な情報が引き出せると感じています。要求事項を...

rakuda0218blog.com

2021.01.05

まとめ

設計/開発業務に必要な力量、スキルとは？

ISO9001では組織に以下の事を要求しています。

言われている事は良く分かるのですが、設計開発業務において必要な能力、スキル、力量とは何なのか？を明確にするのは決して簡単ではありません。

設計開発に必要な作業の力量

一番わかりやすいのは資格が必要な作業、溶接とか、電気工事とか、玉掛、フォーク作業など、資格や特別な教育が必要な作業を洗い出すことは簡単で、特に製造現場などの作業者においてはどういった資格が必要か洗い出しておく事は必要です。

開発、設計でも必要な作業は必ずあります。例えば、CADが使えないと図面は書けないでしょう。実験装置を適切に使えないと実験できませんし、評価するにしても評価装置などが正しく使えないと評価できないです。

そのような作業は以下のようなレベル評価をするのが一般的です。

• レベル4：指導ができる
• レベル3：一人で実施できる
• レベル2：指導を受けながら実施できる
• レベル1：補助ができる

評価項目をリストアップしておいて指導者がチェクしてレベルを決める、あるいは、テスト（実技、筆記）を行う。自己申告してもらって面談でレベルを決める。指導員が判断する。等色々あります。

エンジニアに求められる力量とは？

設計/開発のエンジニアに求められる力量は何か？となると、そのような作業が確実に出来る事だけではないはずです。そもそも設計/開発を進めるためには作業が出来るだけでは不十分です。

それでは必要な力量とは何でしょう？

日本語で言えば、○○力と言えば、何となく能力を定量的に示しているように感じてしまいます。

「設計現場力」25のポイント　企画から生産準備までの設計プロセスを改善する　日刊工業新聞社　郷保直によれば、市場・顧客理解力や技術動向理解/判断力、新製品創出力、のイノベーションの視点からからはじまり、スピードの視点、コストの視点、品質の視点、人/社会の視点から25の能力が提案されています。

ISO9001の要求事項から考えれば、

• 顧客/関係者から要求事項を洗い出すコミュニケーション能力/プレゼン能力、
• 品質要求事項の具体的な技術目標への展開力、
• 設計計画/レビュー力
• 固有の技術力、
• デザインレビュー/設計検証力、

などとも言えそうです。

私が思うに、一般的な設計開発のエンジニアに必要な能力は何か？といった議論になるとそれはそれで大切だ、とは思うのですが、それを必要な力量としてしまうと、機能しない物になると思います。

そもそも、必要なものとすると、まず、意見がまとまりません。本人の価値観もあるでしょう。メンバーの得意不得意もあるはずです。

そもそも必要な能力（力量）とするからには、少なくともリーダーは十分な能力を持っている必要が有るでしょう

しかし、リーダー自身もそもそも能力が十分かとなると？マークがつくのではないでしょうか？そのあたりを上手く適材適所で考えて行くのがマネージメントの仕事になってきたりもします。

望ましい能力は個別に、必要な技術はメンバーで共有

つまり、その組織として必要な力量は土台として、全員がその力量を持っている事、必要な事を決め、より望ましい能力は、個別に上長と相談しながら決めて行くのが良いと思います。

この辺りを概念的に示したのが下の図です。

設計開発にとって必要な力量（土台）とは？

設計開発の手順/手続き、それに伴う情報の取り扱い

標準化は本来、設計開発を効率的に進めるのと、属人化を防ぐのが目的だと考えています。

具体的な設計内容はつど変わるかもしれませんが、手順/手続き、それに伴う情報に関しては標準化しておかないと、都度、手続きから議論して行く事になり時間の無駄です。

情報はまさしく設計開発を行うのに非常に大切な道具です。道具は誰でもすぐ使えるように整備しておく必要が有り、そのためにも、標準化しておく事が大切です。

標準化されている内容は当然、組織のメンバーで共有化する必要が有り必要な力量となります。

最低限必要な固有技術/専門知識

力量と言われれば一番イメージがつきやすいのが固有技術/専門知識です。

しかし、全員が共有すべき必要な固有技術とはなんでしょう？無責任なようですが、これに関しては、関係者で協議をして決めて行くしないと思います。

例えば、ガラスの加工技術を開発する際には、加工の原理、副資材（砥石や研磨パッド、砥粒）などの種類と役割、特性に及ぼす影響、過去の研究例などです。

設計の場合であれば、製品の構造や仕様、過去の不具合例、などが挙げられるでしょう。仕事内容に応じた電気的、機械的な素養も必要でしょうし、部品や部材に関する知識も必要でしょう。

実験を考えるような場合は品質工学あるいは実験計画法などが組織には必要だと思えば必要な力量とすればよいでしょう。

しかし、これらは知識ですので、必要に応じて勉強し直すことも可能ですし、開発にどう生かすかは本人の能力次第という所が有ります。

そこは、本人の個別の能力と割り切ることが大切かと思います。

評価方法に関しては作業同様、以下のようなにレベル分けして評価しましょう。レベルの定義つけも関係者で協議して決めれば良いと思いますが、一例としては下記の通りです。

レベル4：指導ができる
レベル3：十分活用できる
レベル2：指導を受けながらでないと活用できない
レベル1：そもそも知識がない

スキルマップ/力量マップ（力量管理表）

個人個人について、組織として必要な力量に対してどのレベルにいるかをまとめたものがスキルマップ、あるいは力量マップ、力量管理表と呼ばれるものです。検索すればすぐに出て来ます。

教育/訓練

スキルマップから、必要な力量を習得していない人は教育、訓練を行う事になります。

新入社員や転勤者に何を導入教育とするのかについても明確にするためにスキルマップは役立ちます。

一方、組織として必要な能力を取得してしまうともう伸ばす能力はないのか？教育/訓練は必要ないのかとなるとそんなことは有りません。

一般的な設計開発に必要な能力を自分の現状の能力/本人の希望からこういった能力を伸ばしたい。といった事を上長と相談し、個人個人、個別に必要なアクションを決めてレビューして行く事が行く事が非常に大切になります。

私が勤めている会社でも、年に一回、自分が伸ばしたいと思っている能力を上長と相談し、具体的にな実施項目を決めて行く。1年後、その結果をレビューする。といった事をスキルマップとは別に実施しています。

まとめ

人は予期せぬ行動をとる、はあまり言われていないと思いますが、すべてのケースを想定は出来ません。状況や環境によっては「なんであんなことしたんだろう？」と思う事もあるでしょうし、病気で意識を失うような場合もあるでしょう。

機械は必ず壊れる、人はミスをするのでそこを技術でカバーする必要が有ります。機械が壊れても、人がミスをしても危険が及ばないような技術を考える。というのが大切な考え方になります。

しかし、ミスを犯すと言いながら人間の教育や、管理システムなどの対策も非常に大切であって、結局トータルで考える必要が有ります。

また、リスクをゼロにすることは不可能です。許容できるリスクは何か？許容できないリスクは何か？を明確にして、許容できないリスクをゼロにすることが安全な状態とも言えます。

管理方法やルールなど組織で守る方法や人に対する教育などについてはお客様に考えるていただくことになりますが、設計側としては取扱説明書にて推奨する作業方法、残リスクを使用上の注意点等を記載、あるいは現物に表記する必要が出て来ます。

製品の安全設計

危険源、リスクの考え方

危険源とは怪我の直接の原因となる現実です。例えば、ライオンが街中をうろついていたらいつ襲われるかわかりません。なので、ライオンは大きな危険源です。

しかし、ライオンがうろついているだけでは問題ありません。ライオンと人間が接触することで襲われる可能性が出てくるのです。

製品もそれだけでは危険ではありません。その製品を取り扱う事で場合によっては危険源ともなり得ます。なので、安全設計を考える上では、「その製品をどのように使うか」、これを明確にしておく必要が有ります。

お客様が必要される「使い勝手」から考えられる使用方法を明確にする

新製品の場合、お客様の使用状況をよく理解するのは実は簡単ではありません。基本、お客様はどのような使い方をするのか見せてくれません。製品もないのに作業の標準書もありません。お客様も、アイデアレベルの製品をどのように使うか？と聞かれても答えようがないでしょう。

なので、お客様から使い勝手に関する要求事項をよく聞いて設計に反映し、取り扱い方法を提案するといった具体的な話に持っていく事が大事になります。

すでに他社品あるいは自社品でも良いですが、実績が有る製品が有るのであれば、その違いを明確にしてお客様と協議するのが非常に大切になります。

使い勝手は操作性と理解しても良いですが、保護具を使う事の是非や、許容できる作業時間や作業人数など、お客様の許容範囲を確認しながら設計を進めて行くのが良いでしょう。

また、設計に必要なお客様のやりとりは極力営業を通さず、設計者が直接話をすることをお勧めします。

業務が忙しく時間が取れない。といった問題は有りますが、今はリモートでも十分画面越しに会話が出来ます。得られる情報は直接話すことではるかに多くなりますし、その場で議論が出来るので仕事は早く進みます。

一方で、その場である程度判断しないといけないところもあり、事前の社内打ち合わせも必要になります。慣れないうちは色々難しく感じるでしょうが場数をこなせばコツがつかめる（相手の言ってくることが読めるように）なってきます。

危険源の同定

使用方法が決まれば、危険源は何かを同定することになります。ISO12100 附属書B、表B.1に詳しいリストが記載されています。良ければそちらを参照ください。項目のみ下記に引用致します。

1. 機械的危険源（電気を切っても油圧や慣性で動くものが有るので注意です。）
2. 電気的危険源
3. 熱的危険源
4. 騒音による危険源
5. 振動による危険源
6. 放射により危険源
7. 材料および物質による危険源
8. 人間工学原則の無視により発生する危険源（ムリな姿勢による腰痛など）
9. 滑り、つまずき、および墜落の危険源
10. 機械が使用される環境に関連する危険源（温湿度、ほこりなど）

危険源はそれだけ考えても考えにくいです。リスクと合わせて、考える事が大切です。

「○○（危険源）が××なので、△△して、■■になる。」

の○○の部分を考えて行く事が大切になります。

リスクアセスメント

リスクアセスメントを行いリスク低減策を検討するのは製品設計でも同じです。

ただし、人の面。管理の面の対策を盛り込むのは実際に使ってもらう人の問題なので、製品の設計について対策できることを考えて行く事になります。

また、具体的に試作品もない段階でリスクアセスメントに力を入れても、製品として完成する時には仕様は大きく違ってくることは多々あります。

従って、洗い出した危険源とそのリスクから、考えられる重大事故を１～3件程度、被害状況と頻度を想定して選び対策を考える。といった簡易的なやり方で良いと思います。

量産前には妥当性確認のためにも、製品によってはリスクアセスメントをしっかり行いましょう。

一般的なリスクアセスメントは記事にしていますので良ければ参照してください。

各業務で共通するリスクマネージメントのプロセス、考え方

リスクアセスメント（リスク評価）を行う事が目的ではありません。点数をつけると如何にも客観的に十分な対策が出来たように思いますが所詮人が想定する話に過ぎません。その為には、適切なメンバーで現状を把握できるような準備をして、まずは、リスクを十分...

rakuda0218blog.com

2022.01.23

設計時の製品安全対策（参考文献：入門テキスト安全学　向殿政男　東洋経済新聞社）

本質的安全設計対策

1. 初めから危険源が無いように設計する。
2. 危険源による危害の大きさを小さくするように設計する。

１，については、例えば毒性のある有機物を無毒の者に変えるとか、機器の空隙・間隔は指、腕、足、頭などが挟まれない幅にする、等です。

２，については人が触る可能性のある所はバリ取りや面取りを行う。あるいは、ぶつかる可能性のある所にはクッション材を貼る。等です。

フールプルーフ

「ポカミス」対策として作業工程などに広く応用されています。

点滴のチューブの接続間違いを防ぐために接続口の形状を特定の物でなければ接続できないようにしたものなどが有名です。

製品設計の応用としてはインターロックが有名です。

ドアを閉めないと電源が入らない電子レンジ、ギアをパーキングに入れないとエンジンがかからない自動車、人間がいない時にしか動かないロボット、等です。

フェイルセーフ

作業工程などへ応用するのであれば、ミスをしたら直ちに気が付く仕組み作り、として考えると色々考えられます。

製品設計としては、エラーが発生しても安全側に向かうように考える事です。一番、確実なのは装置を止める事なので「止まる技術」とも言えます。

例えば、人を射感知するセンサーでは、安全状態が確認出来るときだけ動くようなものを選びましょう。透過型のセンサーにすると壊れて信号が出なくても安全であるとの判断でロボットは動かなくなります。

一方、反射型のセンサーでは、人を感知した時にとめるようになっているので、壊れてもロボットは動きつ続けます。

フォールトトレランス

故障が発生しても機能が保てるようにする事。冗長設計とも言われます。もしAが壊れたらBでカバーする。例えばスペアータイヤなどもそうでしょう。

センサーの数を増やして信頼度を上げたり、部品に壊れにくい物を採用する事も大切になります。システムで言えば複数台のシステムで稼働させることで負荷を分散させるなどもそうです。

まとめ

マスタースケジュール

本格量産設計を進めるにあたっては、開発計画書にマスタースケジュールを記載します。

要素技術は開発内でプロト機や予備試験を通じて開発目標がクリヤーできそうだ。QCD（品質/コスト/納期）も含めて行けそうだ。という事がデザインレビューで確認されて本格検証に進むわけです。

本格検証に進むには量産化するまでのマスタースケジュールを作成し、開発計画書にまとめて各部門と協議することになります。

具体的には以下の記事を参照してください。

開発に必要な社内調整の方法。開発計画書で他部署と前提条件や制約条件のすり合わせを行う。

開発を本格的に進めるにあたっては、他部署を巻き込んで本格的に検証して行く必要があります。その為には前提条件、役割分担などの開発体制を良く擦り合わせておく社内調整が大切になります。　他部署の協力を得るためにも、初めにしっかり「すり合わせ」をし...

rakuda0218blog.com

2021.01.10

開発体制など、具体的な進め方など関係者と協議してマスタースケジュールを確定させて行きます。

本格検証での納期管理

本格検証が始まると、社内だけでなく対外的なお客様も巻き込んで進めて行きます。関係部署も多岐にわたるので、漏れを防ぐのと進捗状況を共有できるようにマスタースケジュールに記載されている項目をもう少しブレークダウンして管理して行く必要が出てきます。

これに関しても記事にしていますので参照してください。

開発のスケジュール管理はどのようにすれば良いか？不確定要素の多い中での管理方法を紹介します。

今回はスケジュール管理、納期管理に関して少し話してみたいと思います。開発・基本設計と本格検証でのスケジュール管理の違い結論から言えば、下記の様な形でまとめられると思います。開発・基本設計マスタースケジュールによるスケジュール管理、設計・開発...

rakuda0218blog.com

2021.05.22

その中で、WBS（作業分解図）/ガントチャートが有効であると説明しましたが、具体的にどのような手順で作成すれば良いのか、今回は解説いたします。

WBS（Work Breakdowm Structure）作業分解図

マスタースケジュールの項目の中で、例えば試作品作成についてWBSを作成します。

初めから作業を出していくと漏れが出るので、試作品を作るには、何が必要かと考えます。部材の手配、組み立てるには、手順書が必要ですし、作業者への教育、検査はどうするか？が考えられます。

部材の手配には、より細かく見ると、部材使用の確認、見積もり入手、発注、色々あります。

そのように、階層ごとに最終的な作業レベルまで分解します。

カツサンドのWBSは縦型では横型になっていますが、階層事に最終的な作業レベルに分解しているのは試作品の場合と同じです。

♦WBS作成時の注意点

実作業レベルまで分解するので実際に作業の責任者に分解してもらう必要が有ります。責任分担表で責任分担を明確に決めても、実際の作業においては必要な情報、成果物に認識違いが生じる事が良くあります。

いわゆる、そっちでやると思ってた。そっちの仕事でしょ？あるいは、一緒にやった方がいいよね。といったように、細かく分解して行くと、色々な微調整が必要になります。

そのためにも、WBSはこれ以上細かく分解できない。というレベルまで分解して考える事が大切です。

WBSをスケジュール化してガントチャートを作成する。

作業の順序付け。

　作業レベルに分解出来たら、どの作業を先にやる必要があるかを整理する必要が有ります。カツサンドの例では上から下に行くにしたがって作業が進んで行く事になります。

各作業の関係性（並列か?直列か？）

作業Aが部材の見積もり入手、作業Fが組立開始だとします。作業B～Eは実際の発注、リードタイムとすると、見積もりがそろわないと部材は発注できませんが、各部材の発注は見積もりがそろえば並行して行えます。

しかし、組み立ては、部品がそろわないと加工できません。

このように、各作業が並行して行えるか？直列（前の作業が終了しないと次の作業が出来な）の処理が出来るのか整理する事が大切です。（それが出来ないとガンチャートを作れない。）

ガントチャート

ガントチャートを作る

WBSで洗い出された作業の順序付け、関係性を整理してスケジュール化した物がガントチャートです。

実績と計画、現在を表現する部分を設ける。

実際に作業が進んでいくと、計画とずれが生じて来ます。遅れるだけでなく早まる場合もあります。そのような計画との差が見えるようにしないと実用的ではありません。

左は計画の上に実績は⇔で記載するのに対し、右側は計画と実績を分けて記載するものです。

他にもイナズマ線と呼ばれるような手法もあるようです。好みの問題が大きいと思うので、見やすいと思う方式を採用すれば良いと思います。

作業の関係性を追記する。

ガントチャートは関係性記載は不向き

作業の関係性を上記の黒の矢印のようにガントチャートに記載することで表現できますが、非常に分かりにくくなります。ガントチャートでは基本、上から下に流れる順番（Water Fallと呼ぶようです）で判断するのが良いと思います。

アローダイアグラム（PERT図）

新QC7つ道具の一つであるアローダイアグラム（PERT図）の例を上記に示します。カツサンドを作る場合のアローダイアグラムです。詳細は他のサイトを検索ください。

作業の関連性は分かりやすくなりますが、作業項目が多くなるとガントチャートよりも非常に分かりにくくなり、進捗確認も一目では分かりにくくなるため、規模の大きな項目には不適です。

また、修正をしにくいのと、パット見ただけでは分かりにくいので、私はガントチャートを使っています。

まとめ

私自身の経験と反省からファシリテーションで大切と思う事を紹介したいと思います。

会議を進める上での注意点

決めるための全体会議では事前擦り合わせ（分科会）が必要

全体会議を決めるための会議と位置付けるのであれば、事前に関係者で深く議論をして方向性は打ち合わせておく必要が有ります。いきなり決める会議で対策はどうしましょうか？と持ち出しては紛糾してくださいと言っているようなものです。

全体会議まで待てない、早くアクションを決めて動く必要がある場合は当然、必要な関係者を集めて議論し、全体会議を待たずに、アクションを決めて行く必要が有ります。

その場合は全体会議では進捗報告、承認、が目的となります。その辺りは臨機応変に対応すべきと思います。

事前準備/オープニング

多くの方がコメントされているように、そもそも何のための会議なのか？決めなければいけないことは何か？タイムスケジュールはどうするか？に関しては事前、遅くても前の日の午前中には関係者にメールなどで周知すべきです。

また、オープニングでもその点は再確認した方が良いと思います。

書記担当を明確にし、議長は進行に専任。

会議中にメモを取るのは正直、時間の無駄ですし、議論に集中しているとメモも取れません。特に、議長が書記も兼ねる方がいますが無理です。

書記は、誰か一人を任命しましょう。また、書記の役割は、自分のノートにメモを取るのでは不十分です。

議論のポイントや、状況が関係者で共有できるように、状況をW.Bに記載して行く事が書記の大切な役割です。

別にW.Bでなくスクリーンに映しても良いですが、自分のメモを常にみんなに見える状態にしておきます。

議論だけでは、内容が頭の中に残らないので、常に、現状、何を話しているのか、参加者に分かるようにします。

その際、資料の説明内容などは書く必要はありません、議論の発言の内容を、主張、その理由、根拠を書くことが大切です。

そのことで、行ったり来たりの無駄な議論も減り、スクリーンやW.Bを見ながらの議論になるので個人攻撃になりにくい。といった利点もあります。

参考図書：戦略的交渉入門、田村次郎・隅田浩司　日経文庫

決める会議では参加者全員の意見を聞く必要は無い。

会議の参加者全員が発言できるように促し、議論を活発化することが大切である旨、色々書かれている事が多いですが、私は、その点は疑問に思っています。

発言される人が限られていたり、自由に発言できない雰囲気が有るのは問題ですが、必ず全員の意見を聞く必要は無いと思っています。

特に全体会議では発言しない人は、発言する必要が無いと思っているから発言しないのです。発言をしない人は参加すべきではない。という人もいますが、どういった話になるのかわからないので参加しておきたいと思っている人もいると思います。

また、会議の時には浮かばなかったアイデアが、その会議の内容を受けて後で思い浮かぶ場合もあります。なので、参加するな。というのもどうかと思います。

ただ、そういった人に発言を求めても正直、時間の無駄です。意見を求めても、誰かの議論の繰り返しだったり、ピントがずれていたりすることが多いです。その為、結果的に無駄な時間が取られ、話が蒸し返されたり、脱線することも多いと思います。

何も発言しない人がいると雰囲気を乱す。という方もいますが、最近は殆どがリアルとリモートで実施されるのが普通ですので、発言するつもりのない方はリモートで参加する方が良いかもしれません。

私は、発言を促すよりは、何も発言しない人で、何か言いたげだった人や、やけに、批判的な意見にうなずいていた人などは、会議の後、個別にフォローするのが良いと思っています。

本当は言いたいことがあったんじゃないの？など個別にフォローするのです。

また、決まった内容に、強くは否定しないけど、十分納得していないという方もいらっしゃいます。そういった方は、発言の言葉尻や、表情から、判断するしかありません。

その場で決まったことに全員が納得している会議など、逆に不自然です。

皆の前で改めて発言するまでもない。と思われているのでしょうから、個別にヒヤリングすることで、良く聞いてくれたとその後の関係が良好になるし、有益な情報が得られる事も多いです。

議論を深める会議（分科会）で発言しないのは時間の無駄

一方、議論を深めるための個別の会議では、参加者は極力絞り、議論すべきです。ここで発言しないのであれば参加している意味が有りません。

透明性を持たせるために、参加者は全員会議で承認しておくべきですが、参加者も極力少なくすることが大切です。

活発に深く議論するには、参加者は多くても4人から5人が良いように思います。

反対意見に耳を傾ける。

先に、参加者全員の意見を聞く必要は無い。と書きましたが、発言が一人に集中したり、会議で自由に発言できないのは問題です。

自由に発言する。となると、誰かの発言に対して、それは違う、と否定するのも自由です。

ただ、相手の発言を十分理解しないうちに、自論で反論するのはやめましょう。誰かが反対意見を主張した時点で、頭ごなしに反論するような場合です。

そのような場合は、理由と根拠、認識している事実まで聞き出しましょう。誰か遮る人がいれば議長が最後まで聞きましょう、、と促し、発言者に最後まで発言してもらいましょう。

話が長い人や、話が良く分からない発言をされる場合は、議長が内容を要約してこういった主張内容で良いですか？理由と根拠は？といった形で話をまとめる事が大切になります。

最後に必ず決定事項を確認

議事録に決定事項を記載するのは当然ですが、会議の最後に必ず確認しておく事が大切です。その際、議長が確認しても良いですが、議長はプロジェクトの推進者であることが多いので、客観的な目で書記の方に確認してもらうのも良い方法だと思います。

議論が紛糾した時の対処方法

全体会議のように意思決定する会議と分科会で問題を深く議論し解決策を探る会議と、目的によって対応は変わってきます。

1. 全体会議では、色々な案件を意思決定し、承認して行く事が大切です。
2. 事前に分科会等で深く議論しておく事が大切になります。
3. 問題を深く議論する会議では対立意見が出るのは至極まっとうな事です。

イメージを下記の図に示し、説明して行きます。

参考図書：理論が伝わる「議論の技術」、倉島　保美（Blue Backs）

①主張、②その理由、③根拠となる事実、を整理する

対立が激化する場合は、色々な意見が出るので紛糾するので、そもそも、話を整理する必要が有ります。感情的なやり合いになると泥沼化するのでそこは議長が止める必要が有ります。

整理するにはまず、お互いの主張とその理由、根拠となる事実を整理します。主張、その理由は違ってしかるべきですが、事実は一つです。

なので、まずは、事実を再確認し、前提を合わせましょう。どちらかが、事実誤認をしていただけ。という場合もあります。そんな場合は、事実を再確認するだけで簡単に合意できたりします。

主張や理由はなぜ自分の考えと違うのか？その辺りを知ろうとして話すことが大切です。しかし、分からない場合は相違点としてとらえておく、一旦、議論をするのはやめるのが大切です。

ミッションから合意できる所を確認する

事実確認が終了し、主張、その理由から相違点が明確になったら、次に共通のミッションの再確認です。ミッションを再確認するだけで、双方の主張を包括する案が出てきたりします。

具体的なメリット/デメリットで協議する。

そこまで、合意が出来たら、相違点の協議になりますが、その主張、理由をその考えはおかしい、等といった議論になるとその人の価値観によるところもあるので平行線になりやすいです。

そこで、お互いに共有できている価値観、ミッションを改めて再認識し、双方の主張を実施した場合のメリット/デメリットを明確にして、一番効果的と思われる案を関係者で協議するのが大切になります。

日頃のコミュニケーション、信頼関係の構築が大切

メリット/デメリットに集中する。といっても言うのは簡単ですが、日頃のコミュニケーションがとれていて信頼関係が構築されている事が前提になります。

以下の記事が参考になると思うので良ければ参照ください。

「ワーク・エンゲージメント」を高めるのに大切なこと。

ワーク・エンゲージメントとは、「仕事に誇りややりがいを感じている」（熱意）「仕事に熱心に取り組んでいる」（没頭)「仕事から活力を得ていきいきとしている」（活力）の三つがそろった状態でありバーンアウト（燃え尽き）の対概念として位置づけられてい...

rakuda0218blog.com

2021.12.04

時間管理

全体会議で紛糾したら別に議論することが大切

全体会議のように決める会議では、一つの案件に時間が取られすぎて、他の案件まで議論できないような場合は時間管理をする必要が有ります。

相手の主張を整理しないと混乱しそうな場合は、改めた方が良いでしょう。

本日は、決められないことが分かったので、改めて関係者で議論することとし、その際に、その会議の参加者と、打ち合わせ日時はその場で決めましょう。そうしないと、打ち合わせ日を確定させるだけでまた一仕事になってしまいます。

また、その際にはメンバーは極力絞りましょう。それこそ、発言の意志のない人は呼ばなくて結構です。ただ、打ち合わせのメンバーも揉める原因にはなるので必ず全体会議で参加者は決める事が大切です。

通常は、そんなに待てないでしょうから、会議が終了後、関係者が時間が取れるのならその日のうちに、多少遅くなっても実施してしまった方が良いと思います。

話の脱線/要領がつかめない発言。

大体、役職が上の方の発言は、人によりますが話が脱線することが多々あります。「そういえば、○○はどうなってる？」など、議題と関係のない事を突然言われる方もいますよね？（うちの会社だけ？）

本人は良かれと思ってなのでしょうが雑談が長い人。新人が雑談したら、注意されそうですが、何故か自分は雑談が許されると思ってしまう人

そういった人は、やはり、議長が軌道修正する必要が有ります。そんな際、W.Bなりスクリーンなりで議論がリアルタイムで共用できていれば、会議の趣旨からずれている事も分かりやすいです。

まとめ

ただ、人は役職により現実を見る視点が異なるのと、個人個人の価値観の違いがあるので、同じ現実を見ても問題の捉え方が違ってきます。また、部署が違えば社内とはいえ利害関係が発生する事が有ります。

本格検証を始める際に、開発計画書で各部署と調整し本格検証に入るわけです。しかし、初めよりも本格検証時の修正や調整の方が遥かに大変というのが実感です。

そういった人の壁や組織の壁は存在するので紛糾するのが正常と考えてステークホルダーをマネージメントして行く事が本格検証を進める上では大切になります。

私の経験、反省も含めて、大切と思う事を書いていきたいと思います。

ステークホルダーの要求事項を収集する

要求事項を収集する

要求には2種類あります。

1. プロジェクトによって生み出される製品やサービスに対する要求事項
2. プロジェクトの進め方に対する要求事項

要求事項の優先順位をつける

要求事項は優先順位付けが必要ですが、優先順位つけも議論の対象になりやすい所です。なぜ、議論の対象になりやすいかと言えば、部署が違えば、人が違えば考え方が違うといった、根本的な問題とは別に、抽象的過ぎて人によって解釈の幅が広すぎるといった問題も往々にしてあると思います。

６W2Hを明確に、更に数値で明確に！！が大切になります。

また、優先順位は関係者の関心も高いが、得てして、あやふやになりがち、誰が決めたんだ！！と紛糾しがちです。全体会議（進捗会議）で毎回リバイスし、確認して行く事も大切になります。

本格検証を進める際には、役割分担と決裁者やインターフェイス、例えば、全体会議を議決会議とし、その会議でアクションアイテムを決めて行くなど、事前に合意したうえで進めて行きます。

しかし、そのような公式の形ですべてが上手く行くという単純な話ではありません。

プロジェクトの進め方は、開発当初に良く議論をするのが大切なのはもちろんですが、ありがちなのは、途中で状況が変わり、進め方の要求事項が変わってくることです。

そんな時、初めに進め方を確認しましたよね！！と反論したくなりますが、大体の場合上手く行きません。それで納得される場合はそれでも良いですが、普通は納得されません。

当初の進め方では何が問題と思い、要求事項が変わって来たのかまずは話を聞いて、要求事項を再確認する事が大切になります。

利害関係者、ステークホルダーを明確にし対応を考える

上記の図はプロジェクトマネジメント実践講座　伊藤大輔　日本実業出版社に記載されていたステークホルダーの対応方針の例から引用しています。

個人的には、右上の位置する関連部署の部門長、右下に位置する現場の作業員の方々の対応について大切な事を経験から紹介したいと思います。

開発の規模、重要度に応じて、関係者の範囲は変わってきます。開発を進める場合、製造、品保、営業は外せません。場合によっては購買部門、経理部門も関係してくるかもしれません。

ステークホルダーをマネージメントする

権限が高い関係者の対応方法

私の経験上では、部門長などからのクレームは課題の優先順位に関する事が最も多かったように思います。

会社の規模やプロジェクトの内容により変わってきますが、このような開発を進めますという場合、初めは部門長の了解を得て進めます。

しかし、都度発生するアクションアイテムを決める全体会議には部門長ではなく、実行部隊の課長クラスが参加して回すことが多いと思います。

その場合、具体的には議事録を回すだけではなく、部門長の意向は都度、確認するようにし、必要があればやはり直接説明する必要があります。その際、当然課長の了解はもらい、一緒に説明に上がるのが良いと思います。

そもそも、部署内の話ですので、部署内で意思統一しといてよ。と思いますが、そうならないこともあります。

何か、懸念が有ればすぐに言ってきてくれる部門長だとこちらも分かりやすいので良いのですが、色々ため込まれてから来られる方もいらっしゃいます。そのような場合、思いが蓄積している分、対応が難しくなります。優先順位について決めた経緯があやふやであれば紛糾するのは必至です。

優先順位は必ず進捗会議で確認して行き、そのような方に対しては、やはり進捗会議に参加してもらったり、定期的に進捗を報告することが大切になります。

　まとめると下の図のようになります。

権限は低い関係者の対応方法

具体的には現場の方々です。実際に作業するにあたって、問題点を一番把握している事も多いです。権限は低いですが影響力は高かったりします。否定的な考えを示す人も多いですが、納得すれば非常に強力な味方になってもらえることも多いです。

アンテナを高くしておいて、まずは相手の考えを傾聴し、対応を考える必要が有ります。その際、目先の問題にとらわれると泥沼化する事もあるので、そもそものミッションは何かから考えられる代案を考えたり、相手の上長と一緒に話をしたりするのも大切になります。

まとめると下の図のようになります。

権限も関係性も低い方の対応方法

直接関係がない立場で色々言っている人に関しては気にしないのが一番です。上手く行けば否定的な意見は自然となくなります。

まとめ

参考図書：プロジェクトマネージメント　実践講座　伊藤大輔　日本実業出版社

私はガラスの梱包容器や梱包材の開発を15年以上担当していました。

また、コンピューターのハードディスクの事業に従事していた時には、開発部に所属しながら品質保証部も兼務し、新規基板の認定業務、受入検査方法の構築を1年半程担当し、10社近くのサプライヤー様と仕事をしてきました。

コンピューターのハードディスクの時に関係していたサプライヤーさんは大手と呼ばれると頃が多かったので、それほど大きな認識のずれは感じませんでした。

しかし、容器開発で多くの中小企業の方々と直接接するようになると、大きな認識のずれを感じる事が多くありました。

普通のサラリーマンよりははるかにサプライヤーさんと深い関わってきたと思っています。その経験から、ご紹介したいと思います。

大切なのは、装置と人

梱包容器の製造メーカーさんは韓国や台湾、日本国内の中堅企業さんにお願いしていました。間に商社さんに入ってもらうのですが、実際に一緒にやっていくには、どれだけこちらの思いを汲んで対応してもらえるか？という事が大切になります。小回りが利くのと、社長さん、あるいは、担当窓口の方の能力が非常に影響します。

私自身、どれだけ助けられたか分かりません。

品質、コスト、納期なども大切ですが、品質はこちらの希望する要求水準を明確に伝え、レベルアップしてもらえれば問題ありません。

私が、お付き合いしてきたメーカーさんも、QMSって何？トレーサビリティーって何？といった感じでしたが、一緒にレベル向上を進めて行きました。

「初めは、色々うるさい事を言ってくる人だと思ったが、品質保証だけでなく、ラインがシンプルになり、工場としての実力も上がった。非常に感謝している。」との言葉をいただき、私も大変うれしかった記憶が有ります。

一方、ガラスのクッション材として使用する紙などは装置産業なので、工場見学でしっかりポイントを確認する事が大切になります。窓口の姿勢も大切なのですが、装置相手なので、やはり対応出来る事には限度が有ります。やはり、装置産業では装置が大切で、改善する、としても限度が有ります。もちろん、装置産業でも人の力は大切なのですが、人の力だけでは何ともならないところが有ります。

人、装置以外のポイント

開発を一緒にやろうとする購入側から見たポイントとして、概して中小企業の方とで認識のずれが大きい部分を紹介します。

価格や短納期、他社への実績、資材から見れば財務状況などもポイントになるでしょうが、この辺りはあまり認識のずれは無いので割愛します。

情報管理能力

購入する側としては、開発品の情報がサプライヤーさんから外に漏れる事を非常に心配します。良く、他社さん向けの図面など、社名が入った形で現場に放置しているようなサプライヤーさんが結構います。他社さん向けの汎用品なので、とあまり気にしていないように見受けられますが、NGです。

また、組み立て工場の場合、材料の加工を外注に出すような場合、依頼元の名前は出さないなど、それなりの対応をいただく必要が出て来ます。

品質保証管理システム

品質管理システム（QMS）は購入する側としては痛い目を見ているので非常に気にします。通常お客様の要求する品質保証管理システムを構築しない限り商売相手として見てもらえません。

品質は現物が良ければOK。クレームは返品してもらって現物を調べれば良いと認識されている方が、結構いらっしゃいます。

ISOの認定の有り無しは私は、といった方が良いかもしれませんが、こだわりません。ISOの認定を取っていても形骸化し、有効に機能していない会社はたくさんあります。

お客様の要求している事を理解して、有効な管理システムを構築することが大切になります。

工程管理能力

私が一番に気にするのは、トレーサビリティー がしっかり確保できるように識別がしっかりと出来ているか？といった点を気にします。その為、基本となる５S、（整理、整頓、清掃、清潔、躾）は気になります。

見栄えの問題ではありません。パット工程を見て、Lot単位の識別が出来ているか。仕掛品がどういった状態であるのか、等がパッと見て分かることが大切になります。

知的財産

　サプライヤーさんと共同で新しい物を開発するような場合は知的財産の取り扱いを明確にしておかないと、後々揉めることになります。

一般には、共同で新しい物を開発するような場合は共同開発契約となるものを結び、開発の内容、役割分担と費用負担、成果物の取り扱いなどを決めて行くのが普通です。

しかし、実際に契約を結ぶとなると、お互いの利害が有るためなかなかまとまりません。共同で開発を進める際は、色々協議しながら進めるのですが、その結果得られた成果物はどちらの物か？を決めるのに揉める事が良くあります。100対0とはならないからです。

数量保証

知的財産の取り扱いもさることながら、揉める事が多いのは数量保証。一緒に開発したのだから、購入する側からすれば出来るだけ他社には売らないで欲しい。一方、売る側からすれば自由に商売がしたいとなるはずです。

実際に、発明が完成する前に協議をすることが多いので、お互い、取らぬ狸の皮算用をしているようなところがあるのでまとまりません。

数量保証で購入する側が何らかの縛りを入れられるとすれば、その開発に購入側はどういった役割を果たし、貢献したか、お互いに了解を取っておく事が非常に大切になります。

サプライヤーさんのサンプルを評価しただけでは縛りは入れられないでしょうが、購入側で開発した評価技術などをサプライヤーさんに開示し使用してもらった場合、その使用に関しては当然縛りを入れたりライセンス契約とするべきです。後で、色々揉めるので、結局、このような場合、開示前にやはり特許出願はしておいた方が良いです。

良くあるのが、購入する側は、開発終了後、例えば3年間は他には売らないで欲しい。等と要請した場合、サプライヤーさんからは、それであれば、数量保証して欲しい。等となるのが通例です。

その時に、お互いの貢献度をベースに協議をするのですが、数量保証や知的財産の取り扱いが明確にできず、開発と並行して協議するような場合、最終的に決裂するようなケースも出て来ます。

担当者間の合意では、話など簡単に覆ります。初めに契約をしっかり結んでおく事が非常に大切になります。

開発契約

共同開発契約は、上記のように、知的財産の取り扱い、数量保証で揉める事も多く、また、契約が締結されれば身動きが取れなくなることもあります。

契約は、その都度、適切な契約を結ぶのが大切になります。

片務契約

開発や設計の結果の所有権、知的財産権は開示する側にある事を前提として、片務の機密保持誓約書を提出してもらう。といった方法が有ります。

一見、非常に無茶な要望のように見えますが、私は梱包容器を作るメーカーさんとは、設計の段階から色々協議をするのですが、すべてのサプライヤーさんに、この片務の機密保持誓約書をお願いしていました。

すでに公知公用の物、開示を受ける側の責によらず公知公用となったもの、自社の独自の技術で開発したと立証できるものは適用外とするのが通例です。

一般に、片務契約は、購入者の専用装置の開発となるので開発品が完成しても公知公用には通常なりません。

購入者との関係性は悪くなる。特許リスクは残る。等の問題は残りますが、仮に設計が完了し、開発品が公知公用となった場合は、他社から公知となった商品の生産依頼があった場合に契約上は作ることは可能になります。

設計、開発が終了した結果の所有権、知的財産権は購入側にあるので、購入側が第3者に作らせることは可能になります。そこは、設計費や開発費を十分回収できる方法を機密保持契約とは別に協議することになります。

後々、揉めないために、設計費や開発費は量産品で回収するのではなく、都度清算するのが望ましいです。

独自に開発した技術をその案件に使うのであれば、それは当然開発した側に所属することになりますので、その旨宣言して、他社向けに使えば良い事になります。

双務契約

実際、既存の材料や、物を改良して行くような場合は双務契約になります。上記に記載したように、基本的に材料の売り手に購入側が何らかの縛りを入れたい場合は、例えば、評価技術で購入側の独自の技術を使用するよう場合はその旨、契約に盛り込んだり、ライセンス契約を考える必要が出て来ます。

まとめ

個人で使う分には頭に入っている事も多いので問題ない？ですが、情報は関係者で閲覧できるようになって初めて有効になります。

その為に大切なことを、私の失敗談を中心に紹介したいと思います。

技術情報の整理

開発にはスピードが要求されますが、その為には特に、調査、予察試験では過去の情報が使えるように整理されている事が非常に大切です。

例えば、過去の不具合例の対策が反映されていなかった。あるいは、過去の開発事例を参考にできず、同じような実験をし、同じような結果になる。等は絶対に避けなければなりません。

過去の流用が出来る出来ないの判断一つにしても、情報の整理が大切になります。

設計/開発に必要な情報

設計仕様、開発目標を達成するために使う情報として以下のようなものがあります。

1. 過去の不具合情報
2. 自社設計の類似技術/関連図面
3. 共通の設計技術の蓄積（シミュレーション技術/データーベース/各種データベース）

　私は担当者一人で梱包容器の設計を始めましたので、特にフォーマット化しなくても頭に入っていたのでそれなりに対応できていました。

　その対応に限界があると思い知らされたのは、メンバーが増え、リーダーとなった時に、過去の情報が整理されていなかったのでメンバーとの情報共有に非常に時間がかかりました。自分もいつ転勤になるかわからない。自分がいなくなっても困らないようにと思い始めました。

　当初は時間を見ながら作業を進めても3か月ぐらいで何とからるだろうと思っていましたが、実際には機能せず、曲がりなりにも機能するようになるのに1年以上かかりました。

情報整理のために大切な事

共通認識、用語の統一を図る。

　情報を整理するのは、数カ月で出来ましたが、実際には誰にも使ってもらえず、役に立ちませんでした。人が検索するときにイメージと違う単語や資料が出てくるとそこで止まってしまい、結局使わなくなってしまいます。

　例えばボルトとネジの違い、部品図/組み立て図、等、私は分かっているではなく、設計メンバーの共通認識を明確にする事。また、検索を想定して用語の統一を計る。たとえば箱、BOX、ケースは箱にする等です。

地道な作業ですが、非常に大切な作業になります。

分類は最低限に

　必須記載項目は、共通認識、共通語である必要があるので、必要最低限な方が良いです。

「過去の不具合情報」についても当初は色々細かく分類しましたが、対象機種と日付、発生工程、お客様の4種類のみとして運用することで特に問題なく運用出来ました。不具合内容はタイトルを見れば想像が出来ます。必要なら中身を見ます。新たな不具合が発生すると分類できなくなります。あえて分類するのはやめました。

　該当件数や商品などによりまちまちです。図面のように、一つの機種で数100枚にもなるようなものは、ある程度、細かく分類する必要はあると思いますが、それでも、共通認識を計ることは前提となります。極力少なくす事は大切だと思います。

また、分類で、その他、を作るとその時点で終了です。ありがちなのは、何か新しい物が発生した際に、どの分類にするか判断がつかないため、その他に入れがちで、結局、何が何だか分からなくなってしまいます。

コード化できるものはコード化する。

　新しい物が出ると、統一用語を都度考えなければなりません。アルファベットと数字で記号化できるものは、ルールを決めておけば、新しい物が出てきても、議論は不要でリストに追加すれば済みます。

　ありがちなのが、コードを見ると、何を表しているのか意味付けをしたくなりますが、新しい物が出てきた時点でコード化出来なければ、その時点で終了です。

　分類同様、意味づけは、必要最低限とし、新しい物が出てきても対応できるような最低限のコード体系にしておく事が必要です。

　コード化しておくと一見して分かりにくいですが、共通認識は得られます。分かりずらければ機種番号：AZ178のように並記するといいかと思います。

管理（共有化）する物、しない物を決める

　管理が必要なのは、共有化が必要なものと、個人で管理すれば良いものとはしっかり議論をして決めておくことが大切です。

　管理が必要なものは、フォーマットも標準化し、関係者に使わせることも大切になります。使いずらい部分は修正しながらでも使い続けないとそこで止まってしまいます。個人で管理すれば良い物は、それこそ個人任せで良いと思います

標準化したら使い続けながら改善して行く

実際に決めたら、メンバーには使ってもらう必要がります。使いながら改善して行かないと定着しません。一時的には能率が下がり、不満も出るかもしれませんが、開発と違って、必ず効果が得られます。信じて進むことが大切だと思います。

　まとめ

事前にノウハウの内容を知らせず、相手にノウハウだと認めさせるのは困難です、どうすれば良いのでしょうか？

知的財産権の帰属について（どっちの技術？）

ノウハウとは？

機密保持契約や、共同開発契約など、契約の種類によらずどちらの技術なのか揉めることになります。なので、契約前に単独で出願できるものは特許出願しておくのが基本です。ただし、問題なのはノウハウです。

契約の必要性について －オプション契約－ | 特許業務法人 三枝国際特許事務所[大阪・東京] SAEGUSA & Partners [Osaka,Tokyo,Japan] (saegusa-pat.co.jp)より

ノウハウとは具体的には以下のようなものが考えられます。

１，や３，は共同開発でも基本的には先方に開示する必要は無いノウハウと思われます。

先方に開示して、勝手に使われて困るのは２の「着想の提供」に当たるような重要なノウハウと思われます。

秘密情報とノウハウの違い

秘密情報は、単なる使用方法などのように第3者（外部）に出されると困る単なる情報とノウハウがある事になります。単なる情報とノウハウは分けて考える必要が有ります。

情報は、相手以外の第3者には形式上開示されないことになりますし、我々が秘密にしておきたいと思っている事でも、不思議と相手はすでに知っていたりすることは良くあります。

第3者の開示されると困るような単なる情報であれば、情報はどんどん開示し、開発を先に進めるべきだと思います。

技術情報だけでなく、ノウハウや他の秘密にしておきたい情報は「営業秘密」と呼ばれ「不正競争防止法」で守られることになります。営業秘密とするにはしっかり管理されている必要が有ります。詳しくは経産省のサイト　営業秘密～営業秘密を守り活用する～ （METI/経済産業省）を参照ください。

なぜ、ノウハウの帰属は揉めるのか？

ノウハウの開示を受ける側から言えば、当然と納得できるのですが、それを厳密に区分するのは非常に困難です。

後になって、あれは、うちのノウハウなので、と主張しても、我々も同様の事を考えていた。あるいはこちらが開示した情報をヒントに考え付いたようなアイデアでも、それとは無関係に創作した。などいかような主張も可能になってしまいます。実際は立証が必要なのですが、そこを追究すると、関係が悪化し、開発そのものが頓挫するリスクも発生します。

知的財産の取り扱い、成果物の取り扱いなど、生々しい話になると揉めるのですが、残念ながらNDAを結ぶ段階では具体的な姿が見えていないので、どうしても抽象的な取り決めになったり、上手く行きそうであれば、改めて共同開発契約など考えましょうとなりがちです。

開示する前に、これは、貴社のノウハウだと認めてもらう必要が有りますが、開示される側から見れば、具体的な内容を教えてもらえないと判断できないという事になります。

ノウハウは契約を結んだとはいえ、開示しないのがやはり基本です。開示不要なノウハウは開示しないとして、開示が必要なノウハウは本当に開示する必要が有るか考えましょう。

ノウハウの帰属を明確にするには？

片務の機密保持誓約書

開発や設計の結果の所有権、知的財産権は開示する側にある事を前提として、片務の機密保持誓約書を提出してもらう。といった方法が有ります。

一見、非常に無茶な要望のように見えますが、私は梱包容器を作るメーカーさんとは、設計の段階から色々協議をするのですが、すべてのメーカーさんに、この片務の機密保持誓約書をお願いしていました。

すでに公知公用の物、開示を受ける側の責によらず公知公用となったもの、自社の独自の技術で開発したと立証できるものは適用外とするのが通例で、また、開示したくない情報は開示しなければ良いだけです。

設計、開発が終了した結果の所有権、知的財産権は購入者側にあるので、相手側が第3者に作らせることは可能になります。そこは、設計費や開発費を十分回収できる方法を機密保持契約とは別に協議することになります。開発委託契約にしてもらう交渉も有効かと思います。

双務の機密保持契約

共同で開発をしないと完成しないような案件では、当然、双務の機密保持契約になりますが成果物の帰属や取り扱いは後々揉めることになります。

従って、重要なノウハウを開示する必要があるような場合は共同開発契約などで、成果物の帰属とその利用を決めてから開示するのが大原則です。

重要なノウハウは先に出さない。

時間がかかっても、重要なノウハウはこちらから先に開示してはダメです。こちらでノウハウを持っているとしてもまずは相手に考えて先に提案してもらう事が大切です。

ノウハウを開示した時点で帰属を確認する。

こちらからノウハウを開示する場合は、開示する前に貴社からの提案もなかったがこれはうちのノウハウで機密情報であると考えている、異議があれば〇×日以内に連絡して欲しいと念押しして了解してもらったうえで開示してました。もちろん記録にも残します。

相手も事前に検討していたというのであれば、何らかの実験結果が有って上手く行かなかった事になりますので、そのデータを要求することが可能になります。その結果で対応を協議することも可能です。実際に、先方の都合で使えない。あるいは分かった上で使わないといった選択もあり得ます。ただ、どちらのノウハウかははっきりします。

オプション契約を活用する。

オプション契約というものが存在します。ノウハウを開示する前に、結ぶ契約でこれを活用するのも、契約が結べる関係なら有効かと思います。

約定の期間（オプション行使期間といいます）内に当該ノウハウを開示し、相手方が当該期間内に当該ノウハウ技術につきライセンスを受けるか否かの選択権（これをオプションといいます）を与える契約をオプション契約といいます。

契約の必要性について －オプション契約－ | 特許業務法人 三枝国際特許事務所[大阪・東京] SAEGUSA & Partners [Osaka,Tokyo,Japan] (saegusa-pat.co.jp)より

共同開発の発明者

実際にはお互いに情報を出しながら開発を進めて行くわけですが、単に課題を提供したり、評価しただけでは発明者となるのは難しいとなります。そう考えると、共願にあたるケースは結構少ないのではないでしょうか？

目的外使用禁止とサンプルの取り扱い

NDAを締結する際には目的を明確にして、目的外使用の禁止するのが通例です。

• 目的外使用の禁止は、情報を開示する側からすれば、他に使われないように出来るだけ具体的に設定することが大切になります。
• 一方、情報を受け取る側では利用の制約は極力広くしたい。となります。

それに付随して、サンプルの取り扱いも注意が必要になる事が有ります。例えば、改善サンプルをもらって、評価するような場合、そもそも、目的に沿った評価だけなら問題は無いでしょうが、もらったサンプルを分析するなどとなると、揉める原因になります。

NDAで事前に取り決めしておくか、取り決めがなくても分析する場合には事前に了解をもらう事が必要になると思います。

まとめ

信頼性、信頼性設計とは

1. 信頼性とは
   • JIS Z8115ではアイテムが与えられた条件の下で，与えられた期間，要求機能を遂行できる能力と定義されています。
2. 信頼性設計とは
   • 必要な期間、故障せず使えるように設計する事と言えます。
   • 従って、必要な期間（目標寿命）あるいは必要な使用回数を決めることも大切になります。

信頼性設計を進めるには図1のような手法を使って、設計にしっかり反映させることが大切と言われています。

実際にその通りなのですが、厄介なのは、信頼性評価もシミュレーションも市場のデーター（実績）と比較しながらテスト条件やシミュレーション条件を調整しないと、精度が著しく落ちる（使えない）といった問題が発生します。

その問題に対して、個人的に進めていた方法を紹介します。

信頼性の市場データが活用できる場合

故障の分類

参考図書：設計開発の品質マネジメント　久米　均著　日科技連

リスク評価（FMEA/FTA）について

FMEAは文字通り、故障モードを想定して、それの対策を考えるといった手法ですので、信頼性設計そのものとも言えます。

しかし、FMEAは想定している範囲内の事しか評価出来ません。

従って、量産する前に、実際に加速評価やシミュレーションを行う事で、想定通りか、想定外の事が起こらないか検証する必要が出て来ます。

信頼性評価/シミュレーションについて

JISなどを見ると、何らかの信頼性評価方法が規定されています。しかしながら、その評価の前提となるテスト条件に当てはまらないケースが新しい開発品では良くあります。

そのような場合、ＪＩＳ等の方法を参考にして、試験条件、シミュレーション条件を決める必要が有ります。

信頼性設計

実際に、信頼性設計については以下のような優先順位で進めるのが良いと言われています。リスク評価、信頼性評価結果を踏まえて、必要があれば設計を見直しましょう。

過去の市場のデータや経験が活用できない場合

部品、モジュールとしての信頼性評価

参考図書、設計開発の品質マネージメント、久米　均　日科技連　、トヨタ必須の１７の品質管理手法を伝授　品質の教科書　皆川　一二　日経BP

部品、モジュールとしての信頼性評価 が効果的でない場合

初期故障対策

故障モードは初期故障、偶発故障、摩耗故障の三つのモードがあると説明いたしました。故障の発生しやすい初期故障と、摩耗故障を優先的に考える必要が有りますが、初期故障は経験からお客様での使われ方、輸送中も含めた使用環境の調査不足が原因である事が、経験上ほとんどです。

使用環境やお客様の使われ方を想定した強調試験により、初期に発生する故障モードを確認する事は可能であるが、いずれにしても、お客様の使われ方や使用環境の精度により結果の精度は異なります。

　従って、信頼性評価よりもお客様としっかり事前協議することが非常に大切になります。以下の記事に詳しく記載していますので参考にしてください。

お客様視点、お客様に寄り添って要望事項/制約条件を洗い出すのはどうすれば良いのか？

お客様の要求事項を洗い出すのはどうすれば良いのか？お客様のライン(使われ方）をよく知る。お客様と議論を通じて要求事項を洗い出す。お客様のライン仕様が決まっていない時は、先に提案し誘導する。定期的に要求事項を確認する。お客様のライン(使われ方...

rakuda0218blog.com

2021.01.03

摩耗故障対策

私が実施していたガラスの梱包容器の信頼性設計、品質保証の概念図を図2に示します。摩耗故障故障が発生するのには時間がかかるので、その間に改めて信頼性を評価するのです。

私が扱ったガラスの梱包容器の場合、お客様と工場を往復するため、工場で管理できるといったメリットが有ります。

設計の段階での信頼性評価は初期故障向けと割り切り、摩耗故障については、強度のシムレーション結果からクラックの管理基準をかなり厳しめに設定し、量産時にNG品を分析、強度評価を行い、その結果をシミュレーションに反映させ、寿命をシミュレーションし、管理基準の見行いました。

お客様の工程に据え置きになるような装置であれば、出荷前に寿命評価は必須になると思います。ただ、装置などであれば、部品、モジュールとしての信頼性評価が有効になるとも思います。

また、寿命評価と言えば、加速評価により、故障の発生率を調べるのが一般的かと思いますが、ワイブル解析するにはそれなりのＮ数が必要になり、お金と時間が非常にかかります。私は、それだけの価値が得られないと考え実施はしませんでした。

状況に応じて、必要な評価方法を考えるのは大切だと思います。

まとめ

開発・基本設計と本格検証でのスケジュール管理の違い

結論から言えば、下記の様な形でまとめられると思います。

開発・基本設計の場合

開発や基本設計の段階では、要素技術開発など不確定要素が多く、緻密な計画を立てても変更になる事が多く無駄になる事が多いです。

しかしながら、事業を前提とした技術開発では、営業、あるいは事業から要請される開発納期は常に存在し、その為に、開発や基礎設計のスケジュールも決まってきます。

個々の実験や評価に関しては漏れがないように工程表に準じるものが必要でしょうが、初めから納期を積み上げても必要な作業が読めない所があり、必然的に意味がなくなってきます。

それよりは必要な開発納期に向け、マスタースケジュールをまず決めて、決めたマイルストーンに向けて短いサイクルでPDCAを回しどんどん先に進めることが私としては非常に大切だと思っています。

開発目標達成のための開発項目はマスタースケジュールを作る際にメンバー間で議論、共有することも大切です。開発目標の優先順位は開発だけでは決められませんが、開発項目の優先順位は開発で決められます。優先順位が低い項目は、”やらない”と決めることも大切になります。

マスタースケジュール、マイルストーンがどう頑張っても遅れると考えられる場合は、早めに決裁者と相談し善後策を協議するのは当然です。

また、すでに記事にしたように日頃から開発、基礎設計の効率化を進めておくことも大切になります。

開発期間を短縮したい！！設計・開発工程の効率化、そのためのリーダーの役割について

設計・開発の効率化を上げるのは非常に大切ですが、簡単ではありません。内部的には標準化や、流用設計を進める事と、外部に対しては役割分担を見直し、整理することが大切だと思っています。いずれもリーダーでないと対応できない問題であると思います。具体...

rakuda0218blog.com

2021.05.12

遅れを取り戻すには？

計画より遅れている場合は当たり前ですが、遅れている原因により対処方法が異なります。

技術的な問題で行き詰まっているのであれば、頑張れ！だけでは解決しません。

経験と知恵をもったベテランの技術者に応援をもらう。あるいは、担当者を変える事も場合によっては必要でしょうが、上手く行かないケースも多々あります。単純に人を増やせば上手く行くというものではありません。

まずは、上司がどんどん現場に入りアイデアを沢山だし、現場を引っ張っていくのが基本です。その上で、何が問題なのか明確にした上で、具体的に人を補強するのなら、実際に何をしてもらいたいのか明確にして、メンバーにもその趣旨をしっかり説明し、納得してもらう事が大切です。

内容が決まっていて、単純に作業時間が取れないような場合は、優先順位をみなおしたり、人員を補強したり、装置が空いていないのが原因なら勤務体系を見直すことも大切です。

本格検証の場合

一方、同じ、開発、設計の段階でも、本格検証では多くの部署に動いてもらい、お客様にサンプルを出して評価、検証を進めて行く事になります。本格検証の段階では、作業レベルに細分化しガンチャートなどでスケジュールを可視化して関係者で共有することが大切になってきます。

本格検証での納期管理

本格検証の場合には、試作品の生産、部材の手配、など、主に製造と共同で進めなければなりませんし、出荷品の出荷検査など具体的にどうするのか品質保証とも協議をしなけばなりません。

全体を統括して推進するのは、いわゆるプロジェクトマネージメントそのものになります。開発の規模によっては、本社の生産統括のメンバーなどがプロジェクトマネージャーになる場合もありますが、いずれにしても開発部署が中心になって動かないと何も進みません。

WBS（Work Breakdowm Structure）作業分解図とは

プロジェクト全体を作業レベルにブレイクダウンし、必要な作業を洗い出したものです。例えば試作品を出荷するために必要な作業は何かを洗い出すことになります。

初めから作業を出していくと漏れが出るので、試作品を作るには、部材の手配、試作手順書の作成、教育、品質評価方法の作成、教育、など、レベルを合わせて順次展開していきます。

作業の順序付け、必要期間を見積もり、ガントチャートを作る。

　作業レベルに分解出来たら、どの作業を先にやる必要があるか整理をして、必要な期間を見積もり、ガンチャートを完成させます。

ガントチャートを完成させる際に、部署ごとに作業をまとめたくなりますが、そうなると、作業の流れが見えなくなります。どの部署の誰が実施するのかも必要ですが、作業に付随する形でまとめましょう。

クリティカルパス

簡単に言えば時間がかかる、クリティカルな作業です。

ガントチャートでまとめると、どこがクリティカルパスなのか一目でわかります。納期調整が必要な場合は、そのクリティカルパスを短くする工夫を考えることになります。

開発部材の納期管理

梱包容器のように購入部材が開発品の場合、納期はメーカーから納期回答をもらうのが通常です。しかしながら、開発品の場合、納期は遅れがちになります。

そんな際は、実際にメーカーさんを訪問し、ガントチャートを一緒に作り、どこが短縮できないか、協議することが必要になります。

メーカーさんから見れば迷惑な所もあると思いますが、それしか手はないと思います。

まとめ

いずれもリーダーでないと対応できない問題であると思います。具体的にどうして行けばよいのか紹介いたします。

設計・開発工程の効率化

量産、事業を前提とした設計・開発（イメージとしては事業部研、事業に直結した設計・開発）の場合、私が入社した30年以上前からずっと言われています、ちなみに、今年が勝負、あるいは今年が変革の年ともなぜか毎年言われています。

今まで、担当者目線で大切と思えることを記事にして来ましたが、主にリーダー目線で私見を整理してみたいと思います。

流用設計、標準化

流用設計、標準化の必要性や大切な事

具体的には「設計開発を標準化するにはどうすれば良いのか、機械設計とプロセス設計について」と題してすでに記事にしているのでそちらを参照ください。

設計、開発は、クリエイティブな活動なので標準化は向かない。ISOも必要ないという方が結構います。

確かに、そういった面はあると思いますが、常に、無から新しい物を生み出しているのでしょうか？そうではないですよね。

もう少し、整理すると以下のような事が言えるのではないでしょうか？

その為には、以下の5つが大切になります。遂行担当は自分だとリーダーが自覚するのが出発点になると思います。

標準化は実際に進めると、非常に難しく、時間もかかります。準備期間の間は逆に効率が落ちますし、導入後も、皆が使えるようになるには時間がかかります。

途中何度か心が折れかけることも多いですが、標準化については時間がかかっても必ず完成できます。一旦上手く行くと、それまで、否定的な事を言っていた人も便利さに気が付き協力者に代わります。

これを実施しないと何も変わりません。「成功の秘訣は成功するまで続ける事」といった言葉があったかと思いますが、標準化においてはその考えが非常に大切だと思っています。

人材教育

人材育成は、OJTが基本と思っていますが必要な知識は教える必要があります。その際、標準化していないと教える側も教わる側も非常に非効率です。

新人に業務理解の為といって標準書を作成させたり、新しい目でルールを作成して欲しい。など、新人に標準化を担当させようとする人もたまにいますが私は全く逆だと思っています。

新人にはまずは、標準化した内容を教え、使わせたうえで、それこそ新しい目で提案してもらえば良いと思います。

部門間協同　分担、整理、調整

部門間協同体制

コンカレット・エンジニアリングは「社内関係部署による同時進行型」で商品開発を行うもので、新商品導入初期段階に品質・原価の作りこみを行い後半でスムーズな展開をはかるものである。

設計開発の品質マネージメント　久米　均　著　日科技連

話としては良く分かりますが、コンカレット・エンジニアリングについて考えてみたいです。

1. 基本設計でのコンカレット体制
   • 要望事項、制約事項の洗い出し、確認が何と言っても大切です。そこが不十分であれば、後々、しっぺ返しが来ます。しかし、それ以上は他部署も具体的に動けないのではないでしょうか？早く設計をまとめてね。となるだけのように思います。
   • 開発目標、開発コンセプトは確かに初めの段階で関係部署と議論することは可能です。実際としては、要望事項、制約事項を確認する際に、当然、開発目標、コンセプト、設計のイメージを話することになり、必然的に議論になります。設計・開発内でコンセンサスを得るにしても関係者の意見を聞いておき参考にすることは大切だと思います。

1. 量産設計でのコンカレット体制
   • 関係部署との協同体制になりますのでまさしくコンカレントな状態です。関係部署が同時に動きますので、関連部署との方向合わせ、役割分担など、開発体制を事前に開発計画書に準じたもので共有化し合意しておく事が非常に大切です。

営業との役割分担

お客様の要望事項や制約事項を確認するのは営業の仕事です。

例外として、お客様が気が付いていない要望事項を明確にしたり、技術的な協議が必要な場合は設計、開発部門が出向いて協議すべきです。当然、営業部門との事前打ち合わせ、事後の情報共有は必要になります。

♦何故、お客様の要望事項や制約事項をまとめるのが営業の仕事なのか？

設計、あるいは開発を進める上で必要な情報をお客様内の様々な人脈を通じて引き出したり、お客様の各部署の要請事項を汲み取り、要望事項や要請事項にまとめ上げるのは営業しかできません。

社内事情も考慮し、お客様の要望事項や制約、スペックに関して交渉が必要になった場合、営業以外できませんし定期的に状況をフォローできるのも営業だけです。

営業のメンバーでも技術的な案件というだけで、拒否反応を示すようなメンバーもいます。逆に、興味津々で技術的な提案をしてくれるメンバーもいます。人それぞれです。

拒絶反応を示すメンバーはには標準化、フォーマット化し、粘り強く、教育すべきですし、それが営業の仕事であることを、営業部に対して（営業の管理職にも）理解してもらう事が大切です。

問い合わせに対しては、私に場合、営業向けの教育資料と、よくある問い合わせをまとめて、問い合わせる前にまずはそのサイトを確認するように周知していきました。

製造との役割分担

製造には試作流動に協力いただくだけでなく、コスト試算、納期管理、FMEAなどのリスク評価、など、協力を仰がなければならないことはたくさんあります。

製造が忙しいとの理由でコスト試算、納期管理を設計・開発が代替するのはご法度です。代わりにやるのではなく、やってもらうのが仕事と思うべきだと思います。

お客様の要求事項・制約事項を確認するにしても製造と共同で進める必要があります。普段から製造の現状にアンテナを高くしておくことと、開発案件、現状の情報を普段の付き合いの中で共有化することが大切だと思います。

サプライヤーとの協同体制

社内で開発が終了するのは加工、組み立てを行うようなメーカーでは非常に稀と思われます。副資材、工具などは購入品でしょう。場合によっては加工装置を購入する場合も考えられます。

サプライヤーは通常、付き合いのあるメーカーさんに声をかけることになります。新しいサプライヤーを検討する場合は必要に応じて購買部門と共同で進めて行く事になります。

見逃されがちですが、注意しなければならないのは、部材や、購入品をメーカーと一緒に開発した場合には、1社購買になってしまう事が多い事です。2社購買できるよう、設計と購買部門は協力して行く必要があります。

市販品で1社購買になってしまっているのなら、代替品の評価も考えるべきです。

一方、梱包容器などは、個別設計です。知的財産は当方にあり、サンプル作成や量産準備、設計検討にかかる費用などはこちらが負担するので、数量保証などには応じない。といったスタンスで臨みます。受け入れてくれるメーカーさんもありますが、そうはいかないメーカーさんももちろん有ります。その場合は具体的に何を懸念されているのか確認したうえで協議をします。

揉めるのは知的財産の取り扱いや数量保証の事が多いので、具体的に協議し解決をはかります。折り合いがつきそうにない場合には、お断りする必要も出てくるので、最初にはっきりしておく事が大切です。

いずれの場合も機密保持契約や、覚書の形ではっきりしておく必要があります。共同開発契約はお互い身動きが取れなくなるのでお勧めしません。

まとめ

VAとVEの違いとは？

VA/VEは価値を上げるために機能、コストをリンクさせて考える。という事で考えれば当たり前の事を言っており、そういった意味ではVAもVEも違いは有りません。

VAとVEの私が認識している違いを以下に示します。

VA提案

VAはValue　Analysisの頭文字であるように、既に、量産されている製品に関して使われるものと思っています。価格交渉の際に、お客様の方から、規格などの見直しも検討するから、どういったコストダウンの提案があるかメーカー側に検討要請があるのが通例だと私は認識しています。

VA提案は規格緩和に限定された話ではありません。梱包材の見直しや、取引の条件の緩和（前広の発注等）、価格交渉の一環ですので、購買と営業がお互いの窓口になるのが通例です。業界によって多少異なるかもしれません。

♦コスト分析

下記の図のようにコスト構成を分析し、考えられるコストダウン策を考える事になります。

VE活動

一方、VEはValue　Engineerigの頭文字であることからも、設計開発の段階で使われ、設計開発そのものである。コストも開発目標の一つの扱いになる。というのが私の認識です。

VEの進め方、VEの5原則とは？

VEは設計開発活動そのものだと書きました。VEの5原則と呼ばれるものがあるのですが、その原則が開発の進め方、そのものと言って良いからです。以下、紹介します。

使用者優先の原則

使用者、（お客様、後工程）から見た時に必要な機能は何なのか？そもそも、必要とされていない機能であれば止めてしまう。それほど重要でなければ優先順位を下げるなどです。

お客様から見た時に必要な機能は、お客様が必要な品質、要求事項とも言えます。なので、お客様の必要な品質、要求事項を的確に把握する必要が有りますが、決して簡単ではありません。

具体的のどうすれば良いのか記事にしていますので良ければ参照ください。

そもそも、機能とはどう考えればよいでしょう。製品の機能と言われればわかりやすいですよね。例えばベルトコンベアーであれば、物を運ぶといった機能があります。もっと言えば、機能だけでは不十分で性能（スペック）が必要です。その為には運ぶものや、もろもろの条件を考えなくてはなりません。

【狩野モデル】の「魅力的品質」「一元的品質」「当たり前品質」の対処方法を考える。

お客様の要求事項の種類については「狩野モデル」と呼ばれるモデルが有ります。有って当たりまえの当たり前品質、つねに他社との品質比較にさらされる一元的品質、他社との差別化につながる魅力的品質の対処方法について考えます。　狩野モデルとは狩野モデル...

rakuda0218blog.com

2021.01.04

機能本位の原則

機能、スペックを満たすために、適切な手段、方法、仕事内容を考えましょうといった話です。つまり、設計のコンセプトを考えましょう。といった話です。

設計コンセプトを基にお客様の要望事項を具体的な開発目標や要素技術、設計仕様、コスト目標に落とし込む事になります。

詳しくは以下の記事を参照ください。

要求事項を明確にし、現実対比を行い要素技術/設計目標/開発目標にまで落とし込む方法。目標値の決め方。

要求事項を明確にし、現実対比を行い、要素技術/設計仕様/開発目標にまで落とし込む方法は以下のようなイメージです。　QFD「品質機能展開」よりも「開発コンセプト」を導入することで、お客様からより必要な情報が引き出せると感じています。要求事項を...

rakuda0218blog.com

2021.01.05

創造による変更の原則（コストダウン）

前提を疑え、等とも言われますが、ECRSや無理、無駄、ムラの考えが参考になります。

一番のコストダウンはその作業をやめてしまう事です。なので、E（その作業がなくせないか？その部品なくせないか？）と考えるのが最初です。そもそも、その作業をやめたら誰が困るのか？、その作業をなくすにはどうすれば良いのか？場合によっては前工程にお願いした方が効率が良い場合もあります。

Cの一緒に出来ないかというのは工程であれば、ながら作業。（設備と人の組み合わせを考える）製品であれば、機能を一つにまとめる。（例えば三色ボールペンや消しゴム付き鉛筆などはそうですね）

Rは順番を入れ替えると上手く行ったりしないか？という事である。折角加工しても、その後の加工で精度を悪化させるのは無駄になります。穴あけ加工してから溶接するよりは可能なら溶接してから加工した方が良い等です。

Sは簡素化、作業そのものや製品そのものを簡素化するという事。

ECRSは順番も大切で、E→C→R、そして最後にSを検討するのが大切となります。

機械設計

部品点数を少なくしたり、機能をまとめたり、後加工が不要な市販品の組み合わせを検討するなど、ECRSは非常に的確な指針と思います。

基本的にはECRSを具体的にどのように機械設計に組み込んでいくか、に関しては部品半減　これならできる「究極のコスト革命」　三木　博幸　日本経済新聞社　をお勧めします。良かったら読んでください。ECRSのお手本のような本だと思います。

プロセス開発

それこそ、新規加工方法の開発、原材料の見直し、部材の寿命向上、装置のスループット向上、経費削減など、色々なアイデアがあるでしょう。前提や機能を疑う必要があります。

見逃されがちですが、注意しなければならないのは、部材や、購入品をメーカーと一緒に開発した場合には、1社購買になってしまう事が多い事です。

そもそも、相見積もりも取れない一社購買ではやはり価格は下がりません。2社購買できるよう、設計と購買部門は協力して行く必要があります。

市販品で1社購買なら、代替品の評価を進めるべきです。

　一方、梱包容器などは、個別設計です。知的財産は当方にあり、サンプル作成や量産準備、設計検討にかかる費用などはこちらが負担するので、数量保証などには応じない。といったスタンスで臨みます。受け入れてくれるメーカーさんもありますが、そうはいかないメーカーさんももちろん有ります。その場合は具体的に何を懸念されているのか確認したうえで協議をします。

　いずれの場合も機密保持契約や、覚書の形ではっきりしておく必要があります。共同開発契約はお互い身動きが取れなくなるのでお勧めしません。

チームデザインの原則

各専門分野から知識や経験を集めて、組織力で進めることです。チームマネージメントの問題に他なりません。

チームマネージメント | ページ 2 | ラクダブログ (rakuda0218blog.com)を良ければ参照ください。

価値向上の原則

　機能、コストの両面から価値の向上を考えようというものです。

VA提案の進め方

VAの場合、提案する側も、評価する側もそれなりに労力をかけるのですが、品質的には問題なさそうな結果であっても、品質が良い方にはいかないので結局認められない事も結構多いです。

しかし、営業マターではありますが、結局仕様の見直しが上手くいかなくても、色々な要因で結局価格が下げられることは珍しくありません。

提案する側としてはどうせ値段は下がるのだから、少しでもプラスの事を勝ち取ろう。の考えの方が良いように思います。（ダメもと　の考えが大切）

評価する側は、果たしてどのくらいのインパクトが有れば承認するのか、「評価だけしました」のムダを排除するためにも、どうなったらVA提案を受け入れるのか関係者で事前に協議しておくのは大切だと思います。

まとめ

QCD（品質/コスト/納期）について

改めて言うまでもなく非常に大切な項目です。すでに、デザインレビューと本格検証の記事で大切と思われることを紹介しました。

この記事では、もう少し具体的にどうすれば良いのか紹介したいと思います。

QCDの基本的な考え

QCDは関係者の合意があれば問題にはなりません。

QCDも通常は品質一番と言われますが、状況によっては納期が最優先になったりもします。優先順位も合意事項です。

欲を言ってはキリがない事はみんな知っていますので、開発コンセプト、目標QCD、本格検証と順を追って合意して行くわけです。途中でハードルが上がることは良くある話ですが、そもそも合意されていた上でハードルが上がるのと、そうでないのでは大違いです。

QCDに限らず、見える化、共有化が大切ですが、QCDの案件は特にトップ層への情報の共有、相談が大切になってきます。「後で揉めそうなことは先に揉めておく」の考えが基本大切になると思います。

ただし、実際に検証してみないと分からないこともあり、その辺りの見極めは必要になります。

デザインレビューでのQCD

品質に関しては、開発目標、設計目標との対比になるので割愛します。コスト/納期に関しては、購入品の場合にはメーカーから見積もりを、社内のプロセス設計であればコスト試算を行います。

コスト試算は、正確には製造あるいは製造管理の方にお願いしなければなりませんが、この段階で通常は受けてもらえないので、開発部門が試算するしかありません。

設計開発部門でもコスト試算が出来る程度の経理的な知識は必修です。

固定費や変動費（比例費）、損益分岐点の考え方、原単位、これぐらいは最低必要かなと思います。ここでは説明しませんが使えるようにしておきましょう。

購入品の場合、見積もりの内訳や詳細を聞いても真実の姿は出て来ません。相見積もりをとるのが基本です。

関連部署と協議の上、開発計画書に落とし込む

本格検証でのQCD

本格検証で目標値に未達な場合には、基本、新しい考えが必要です。何故なら、QCDはそれぞれ連動していているから調整では済まないのが通常だからです。

優先順位は状況により変わります。例えば、梱包容器のような場合、容器が無いと製品が運べないので、納期が最優先になります。コストは一時的に無視無視（納入出来ない損失に比べたら少ない。）品質で問題が考えられる場合は人を派遣して、何か問題があれば、その場で対応する。等という事も実際にあります。

ですから、優先順位を確認し調整の範囲内で良ければそれでよいですが、通常は新しい考えを導入し改善して行く必要があります。

VA（価値分析）、VE（価値工学）を使った見直し

品質/機能の優先順位の見直し、設計開発にとどまらない代替方法の検討等コストダウンネタの検討を進める必要があります。

開発コンセプトを考える際に、価格は現状のままで、機能をアップするとか、ＶＥの考えを導入しています。本格検証で、さらに検討が必要になれば見直すだけです。購入品であれば見積もりの再交渉するのは当然です。

VA・VEは量産品と開発品で区別するような記載がありますが、本格検証では、量産を前提とした開発なのでそのような議論をすること自体意味が無いと思います。

設計の所も、デザインレビューの頃と、開発が進んだ状態で違いが出てきているでしょうから、改めてコストダウンできる所が無いか見直す必要があります。

納期の見直し

ガンチャートの見直し、購入品の場合はメーカーを訪問し、対応を協議する。場合によっては、追加改善により、納期が更に遅れる場合も当然出て来ます。

トップ層（設計検証決裁者）への働きかけ

開発の規模にもよりますが、中小企業の場合、やはり社長さんの決裁が必要になるのではないでしょうか？

トップ層への報告は、問題点も含めた現状報告だけでなく、このまま行ったら、最終的に当初の計画に対してどうなるのか？対策を打った場合にはどうなると考えられるのか？といった形で報告し、最終的な姿の良いケース、悪いケース、両面でイメージしてもらえるような報告が親切かと思います。

また、少なくとも、決裁者には情報の共有ではなく、相談し、意見をもらっておく事が非常に大切です。

組織が大きくなると、関連部署のＴＯＰといっても大勢いたりするので、上司に頼んだり、その部署のメンバーから説明してもらうなどすればよいと思います。

まとめ

確かに、そういった側面は有りますが、すべてに新たな発想が必要な訳ではありません。

過去の事例、図面などの成果物、仕事の進め方/システムなど、標準化出来る所は標準化すべきです。

具体的な設計にしても、流用設計を極力多くして、多くの製品で、極力共通する部品、あるいは技術を使う事を考え、新たな発想が必要な部分は極力少なくすることが大切になってくると思っています。

設計開発の標準化・流用設計の必要性について

効率化

圧倒的に業務の効率化です。物を検索している時間、無駄な設計、および設計検証を省ける効果等を考えればやらない手はありません。

ムダを省くのはコストダウンの常とう手段でもあります。

標準化を進めると、設計者の自由な発想を妨げる、技術的な発展につながらない。と主張される方も多いですが、考え方を逆にした方が良いと思っています。

業務の属人化を防ぐ

業務が属人化する要因、メリット、デメリットは？

その業務で特定の人がいないと勧められない状態を属人化と言うようです。仕事が組織ではなく人についている状態です。

私自身、梱包容器の仕事を開始した当初は、担当一人で社内でも誰も経験したことのない開発項目でしたのでまさしく業務が属人化してしまった経験が有ります。

業務が属人化するのは、短期的には効率的な面もありますが、長期的にはデメリットの方が大きいです。

一番のデメリットは、業務内容を周りは担当者と同じレベルで理解していないので、適切なコメントやアドバイスが出来なくなり、誰もフォロー出来なくなる。

担当者は性格の問題もあるでしょうが、説明、共有化するのも無駄、あるいは時間が取れないと考えてしまい、ますます、自分がやらねば。と自分を追い込んでしまうといった、負のスパイラルに陥っていまう。という事が起こります。（私の場合はそうでした）

自分の地位を守るために業務を抱え込むような場合も一般には有るかもしれません。

後、得られた知識が個人の物になりますので、会社の知識/知見として蓄積されません。後任が来ればまたゼロから始まることになります。

業務の属人化を防ぐには？

色々な事が考えられますが、基本はマネージングの問題だと思います。誰もフォロー出来ない状態になるとそもそも、開発の進め方、システムが機能しません。

その為には、やはり、システムがしっかり確立されておりそのシステムに沿って進める事が大切です。システムが確立されて、しっかり運用することで属人化の問題点が明確に見えてきます。

デザインレビューや本格検証が機能しないと思うのであれば、人員の補強を図るなど何らかの対応を取る必要が有ります。

ただし、単純に人員を増加すれば上手く行くとも限りません。本当に必要な対策は何か？良く考える事が大切になります。

知識を会社の知識としていくにはやはり標準化が必要となってきます。

設計開発の標準化の秘訣

メンバーの意識合わせ

まずは、メンバーに標準化が必要だという事を良く説明し、意識を合わせる必要が有ります。

気が乗らない人がいるのは仕方がないとして、実施する事を承諾してもらう事は必要です。実際にやって効果が実感できれば、反対意見は自然と消滅します。

情報の標準化

情報は、エンジニアにとって非常に大切な仕事道具です。

設計開発に使うすべての情報、例えば、過去のクレーム事例、部品表（ＢＯＭ）、競合他社情報、過去の開発情報などです。

5S活動同様、必要な物が、必要な時に、必要な分だけ、誰でも使えるように維持管理する必要が有ります。

従って、設計/開発の標準化を進めるにあたっては、情報の整理整頓を行う事が初めの一歩になります。

注意点は以下のようになります。

具体的にどう進めるのが良いのかについては別に記事にしていますのでそちらを参照願います。

設計・開発情報の共有化で大切な事。5選

設計/開発において、技術情報は大切な商売道具ですので、いつでも使える状態にしておく事は非常に大切です。個人で使う分には頭に入っている事も多いので問題ない？ですが、情報は関係者で閲覧できるようになって初めて有効になります。その為に大切なことを...

rakuda0218blog.com

2021.11.08

標準化する物、しない物を決める

活動のすべてを標準化しようとすると破綻をきたしますし、すべてを標準化する必要もありません。標準化するものと必要のないものをまずはっきりさせることが大切です。

1. 標準化するには繰り返し使われるか？。
2. 関係者で共有する価値があるか？

の観点で決めて行く事が大切だと思います。繰り返しの頻度だけで見れば1年に1度実施するかどうか、といった作業でも必ず実施されるものであれば標準化する必要が有るでしょう。たまに実施する物程、標準化した方が良いとも言えます。

特に初めは範囲を狭くして、まずは運用させて、問題点を洗い出してから広げて行くのが良いと思います。

例えば、実際に試作品に関しては標準化するが、アイデアを遂行している間は一切管理しないと決めるなどです。QMS（品質管理システム）は構築する必要が有るでしょう。

小さく初めて大きく育てる。の考えが大切だと思います。

一度ルール化したら使う、使わせて改善して行く

標準化は実際に進めると、非常に難しく、時間もかかります。準備期間の間は逆に効率が落ちますし、導入後も、皆が使えるようになるには時間がかかります。

途中何度か心が折れかけることも多いですが、標準化については時間がかかっても必ず完成できます。一旦上手く行くと、それまで、否定的な事を言っていた人も便利さに気が付き協力者に代わります。

その為には、遂行担当は自分だとリーダーが自覚するのが出発点になると思います。

これを実施しないと何も変わりません。「成功の秘訣は成功するまで続ける事」といった言葉があったかと思いますが、標準化においてはその考えが非常に大切だと思っています。

流用設計（機械設計）

（設計の流用化を進める上で）最も重要なのは現在までの設計成果物の２Sを用い、専用の部品・ユニット・製品「カタログ」を完成させ、この「標準カタログ」を設計者同士で共有し、ネタ帳であるこのカタログから仕様を満足する部品、ユニットを検索して流用化を図る事です。

BOMで実践、設計部門改革バイブル（株）大塚商会　谷口　潤氏（著）P111より

谷口氏は、標準カタログから、各部品、ユニットまで、たどり着ける情報の整理（階層化）が大切と言われています。

BOMで実践、設計部門改革バイブル（株）大塚商会　谷口　潤氏（著）は機械設計の標準化に関して、色々なノウハウが記載されています。一読をお勧めいたします。

確かに、社内で何か新しいものを検討する場合、過去の社内情報をまずあたりに行くので、情報が整理されている事は大切だと思います。

流用設計の注意点

しかし、十分に実績がある部品、部材でも、別の製品に使う場合には、まったく同じ条件で使用できるとは限りません。出来ないと考えた方が良いでしょう。

従って、流用する場合には、実績が十分だから大丈夫ではなくて、今回の設計は何が違うか？を確認し、それに対して検証（シミュレーションや計算でも良い）することは必要になります。

結局、デザインレビューで流用設計と新規設計を明確にすることが大切だと思います。

プロセス開発の標準化について

まとめ

「FTA/ロジックツリーとFMEAの組み合わせ」がお勧め方式

FMEAのメリット/デメリットを考えると、次のようにまとめることが出来ます。

ロジックツリーとは？

１．ロジックツリーとは？

　ロジカルシンキング関連の本なり、資料を見ていただければ、必ず出ている考え方です。問題の原因解明や、解決策立案のために、ツリー状に分解して展開していく方式です。

　もれなくダブりなく（MECE）分解して行くことが大切であると言われており、以下のように4種類のロジックツリーがあると言われています。

２、ロジックツリーの例

ネット：どこがマズイ？なぜなぜ分析 簡単な例でわかる | 論理思考補足編 | ロジカルシンキング研修.com (ltkensyu.com)より、抜粋して引用しています。

　リスク対策には２の原因追及ツリータイプを使います。結局なぜなぜ分析をもれなくダブりなく実施しましょう。ということです。

　次の図を見てください。

次の図を見てください。

　所定の電流が流れているのに電気がつかない場合を考えることで、フィラメントが点灯温度に達していない場合が考えられ、場合分けすることでフィラメントの熱容量が大きいなどの原因まで可能性を広げる事が出来るのが分かります。

FTA(故障の木解析）とは？

１、FTA解析例　株式会社イーコンプライアンス　FTAとは？ (ecompliance.co.jp)より引用

　ガス爆発のFTAによる原因解析

　まずガスが爆発するためには、「点火源」と「空気」と「可燃性ガス」が同時に存在しなければならない。ここで空気をなくすことはできないので「空気」は除外する。
「可燃性ガス」が存在するということは、タンクから漏えいしたこと以外に考えられない。図においてこの「タンクからの漏えい」はもうこれ以上原因を展開するできないため非展開事象と呼ぶ。
　非展開事象はひし形で表す。次に「点火源」であるが、「熱源」か「電気火花」か「直火」が原因であると考えられる。
「熱源」と「直火」は非展開事象である。
「電気火花」の原因は「断線」または「ショート」である。
「断線」や「ショート」も非展開事象である。

　ガス爆発の発生を防ぐためには、「熱源」や「直火」を遠ざけ、「断線」や「ショート」や「タンクからの漏えい」を防止すれば良いのである。

ロジックツリー（原因追及ツリー）とFTA(故障の木）のメリット/デメリット

ロジックツリー、FTAのメリット/デメリットを比較すると下の表のようなことが言えると思います。

　製品を据え付けて使用するような場合にはFTAの方が効果的、様々な環境下で使用されたり、移動が伴うような製品の場合はロジックツリーの方が広く考えられ効果的と考えています。

　私が長年担当してきた梱包容器はロジックツリーを使って、輸送方法、荷固め方法など、色々なケースでの原因/要因を評価しています。

なぜリスク対策が必要なのか

通常、季節変動などを考えると本当に品質的に安定しているのかは1年近くWatchする必要がある。その為、強調試験/寿命評価を実施することが多いが、いずれも疑似評価であって、実体を表しているわけではない。

　　設計/開発のメンバーで実施しても効果は薄れる、品保、製造などの他部署のメンバーを参加させるとでより効果的になります。

　通常、品質管理の場合４M、（Man/人、Machin/機械、Material/材料、Method/方法）の切り口で間に合うことが多いが、リスク評価の場合にはMeasurement/検査、測定、Environment/環境の５M+１Eで検討する方が効果的です。

FMEAの実施例（他のリスクアセスメントと同じです）

１．FMEAとは？

　故障モード影響解析と言われると、非常にとっつきにくいと思われますが、やっていることは一般的なリスクの評価方法、例えば環境リスクメンと、あるいは、安全面でのリスクアセスメントと変わりません。そのような経験のある方には非常になじみやすい方法と言えます。

　参考文献：FMEAの基礎＿故障モード影響解析　日本規格協会　Robin E. Mcdermott, Michael R. Beauregard, Raymond J. Mikulak

　FMEAは検出の可能性というのが追加になっていますが、故障が発生しても故障の影響が発生する前に検出される確率を考えているので、発生確率＝発生頻度＊検出可能性と考えたのがFMEAと見れば通常のリスクアセスメントと同じことを言っています。

２、FMEAの進め方

１、事前準備

　各部位の機能をまずは洗い出して機能が発揮できないような故障モード（潜在的故障モード）、その故障が発生した場合の潜在的影響を洗い出す。

２、厳しさを判定する。

• 厳しさ判定基準は公開されているものがあるのでそれを参考にする。（10点満点）
• 故障が発生した場合、負傷や生命の危機が考えられる物（10点）からお客様が故障に気が付かないものまで（1点）
• 点数は司会者が提案する。まとまらない場合はメンバーの投票、平均値を採用すると良い。

３、潜在的故障原因

　なぜなぜ分析、議論によって潜在的故障の原因を記入する。

４、発生頻度を判定する。

• 厳しさ判定基準同様公開されているものがあるのでそれを参考にする。（10点満点）
• 1日に一回以上発生するような物（10点）から5年以上で1回発生するような物（1点）まで

５、現行の管理

　現行の管理方法を記入する

６、検出の可能性を判定する。

• 厳しさ/発生頻度の判定基準同様公開されているものがあるのでそれを参考にする。
• 検査せていない。あるいは検査できない物（10点）から確実に検査できる物（1点）まで

７、リスク優先数を計算する

　リスク計算数＝厳しさ＊発生頻度＊検出可能性

８、対策を打つ故障モードを特定する

　リスク優先数が何点以上であれば対策を打つ、あるいは、点数の高い、Best３などとして対策を打つのが良い。

９、リスクを下げる処置を決める。

１０、リスク評価を再度実施する。

厳しさ/発生頻度/検出可能性を再度評価してリスクが下がったことを確認します。

FMEAの問題点は？

１、時間が非常にかかる。

　網羅的に実施できるといったのが利点であるが、その分、検討する項目が多く、非常に時間がかかる。

２、事前準備の精度/洗い出しの精度に影響される

　他のアセスメントも同じだが、事前準備の精度がリスクアセスメントの精度に反映される。必ず数人で議論しながら実施する事が大切である。

３、開発初期の段階には不向き、量産前の実施が必要

最後に

　FMEAは良い方法ですが、現実的には非常に時間がかかります。具体的には他の方法との組み合わせで、リスク評価を実施しています。具体的には下記の記事を参照ください

FMEA（故障モード影響解析）とFTA(故障の木解析）/ロジックツリーを組み合わせたリスク対策

「FTA/ロジックツリーとFMEAの組み合わせ」がお勧め方式FMEAのメリット/デメリットを考えると、次のようにまとめることが出来ます。メリットデメリットリスクを定量的に評価できる時間がかかる網羅的にリスクを評価できる事前準備の精度により結...

rakuda0218blog.com

2021.01.15

設計審査の体制例を上記のようにまとめました。

• 全関連部署が参加し、情報共有を行い、アクションアイテムや決裁を行う全体会議
• 問題点を明確にした上で少人数で突っ込んだ議論を行う分科会

この二つで進めて行くのが良いと思います。

全体会議

１-1)お客様要求事項の更新

♦社内の要求事項の更新

　お客様要求事項のリストを事前にリバイスしてもらい、当日は変更点のみ共有。優先順位に関して議論が出ればその場で協議

♦お客様の要求事項の更新

　試作品の説明、あるいは、お客様の評価結果を聞く際に要求事項を改めて確認する。その際には設計者が同行するのが望ましい。お客様の関連部署の要求事項は営業にフォローしてもらう。

1-2)開発進捗状況

　要素技術進捗は結果と、目標値とのGap、今後の対応案を簡潔に。設計部門で議論できることは事前に議論しておく。

　試作品流動状況は責任部署から状況を簡潔に報告

　特許関係は、議論すべきことがあれば報告

1-3)開発体制

　議論があれば実施

1-4)量産性評価（品質:Q、コスト:C、納期：D)　

品質、お客様評価結果、コストC：製造によるF.S.評価、納期D：リードタイム

　目標に達しない場合には対策を考える必要はがあるが、コスト/品質/デリバリーは連動するところがあるので新しい考え方を導入する必要が出てくる。

　そこは開発責任者が関係者を招集して別途対応を協議し、全体会議で報告する。その際に、設計審査の決裁者に相談することも大切。

お客様の評価結果は、妥当性の確認も含むので、出荷、輸送、納入、引き渡し、すべての工程で問題点を明確にし、対応を分科会で協議する。

会議進行時の注意事項

これに関しては、記事を一つ書きました。良ければ参考にしてください。

会議の無駄を省き、円滑に本格検証を進める技術、ファシリテーションについて

意思決定はやはり会議で決まる事が多く、会議の進め方をマネージメントするのはやはり大切です。会議を円滑に進める技法をファシリテーションと呼びます。私自身の経験と反省からファシリテーションで大切と思う事を紹介したいと思います。会議を進める上での...

rakuda0218blog.com

2022.02.05

設計審査(クロージング）

開発を進めても必ず、残課題が残ります。そこを明確にしておかないと、開発がいつまでも抜けられない。製造部門で実施した方が良い物をいつまでも開発が抱えていたりしますので、クロージングはそういった意味でも非常に大切です。

相手が何を考えているのか理解することに集中する。

相手の話をよく聞く(議論はその後）

　相手の話を聞くのは簡単ではないか？いつも人の話は聞いているという方、振り返ってみてください。相手は自分とは違う考えをを持っている交渉人です。次に何を言おうか？どう反論しようか考えていませんか？

　話している間は確かに聞いてるけど、開口一番、貴方の考えはおかしい。などと言っていませんか？

　時々、共感的理解が必要だとの趣旨の本も見かけます。心理カウンセリングやコーチングなら別ですが、ビジネスの交渉に共感を第一に考える必要は無いと思います。議論が必要なときに、あの時、分かると言ったじゃないか？と責められかねません。

　よく聞く目的は、相手が何を考えているのかをよく理解しないと、適切な交渉の作戦が立てられないからです。作戦が必要ない程度の問題なら、それこそ、自由に話せばよい。

　作戦が必要なときには合意点と相違点、当方と考えが違う理由、その根拠（事実）、背景、思い、心配事をよく理解するよう、頑張って聞きましょう。

何を心がければよいか？

私が心がけていることは以下の４点

1. 初めから、今日はアクションアイテムは決めない。相手の言うことを理解するのに集中すると決めて話をする
2. 相手にも、少し話だけさせて、色々考えたいから意見を聞かせて。と初めに言っておく
3. 事前ヒヤリングが出来るのは基本1回だけと思ってよく聞く。　
4. 「そうゆうこと」でかたずけない。相手の発言を要約して真意を確認する。

　何か結論を得なければ、アクションアイテムにつなげなければ。と思いがちです。そうなると聞くことに集中できません。

　できれば立ち話が一番いいですが、時間が無いとのことで途中で切り上げなければならないこともあります。話させて、意見を聞かせてといって、時間をもらう方が良いと思っています。

　普通は何度も、同じようなヒヤリングは出来ません。この間、話ましたよね。となるのが普通です。話が出来るのは一回だけと思うべきです。

　聞くのが大切ですが相手の考えをよく理解するために質問は必要です。自分の考えと違う考えに対しては、真意を確認する必要があります。

　ただし、問いただされているように思われると良くないので、「もう少し詳しく教えて。」と相手が答えやすいような形で聞くのが良いです。

　詳しくって何を話せば？となったら、相手の言っていることを要約して「○○って理解したけど合ってる？」と聞くのが良いです。結構、自分が思っているのと違っていたりします。「そういうことか」と勝手に納得しない方が良いです。

　そう思う理由が話の中からわからなかった時には、「私はそう思わないけど、どうしてそう思うの？」とか「そう思うのには何かあったの？」と聞くようにしています。そうすると色々言ってくれることが多いような気がしています。

傾聴スキル/ペーシングスキル

　知っているのと知らないのでは大きな違いがあると思いますので紹介いたします。

コーチングの基礎、日本実業出版社、鈴木義幸監修　コーチ・エイ著より

　鏡のように聞けともよく言われます。そう言われると色々出来そうな気がしませんか？　

交渉内容を考える

状況整理

自分：ミッション+利害関係者、相手：ヒヤリング内容+利害関係者、社内外の状況、相違点（考え方、要求事項、優先順位、反対理由）/合意済事項/ミッション/強みを整理する。（戦略的交渉入門　田村次郎・隅田浩司　日経文庫　日本経済新聞社　より）

交渉内容を考える。

• 相手の提案、反論の根拠となっている理由やデータに矛盾が無いか？
• 双方の要求事項を満たすためにお互いに出来ることはなにか？
• 説得材料は何か（相手のメリット、自分の強み、社内外の状況）
• ミッションから考えられる代案はないか？
• 議論を想定して、譲れないラインを想定しておく。落とし所は交渉結果に過ぎない（戦略的交渉入門　田村次郎・隅田浩司　日経文庫　日本経済新聞社　より

　ミッションから考えるうえで、その問題は今解決しなければならないか？といった事があります。開発が進んで上手くいくと自然に消滅する反対意見も多々あります。本格検証で確認すべきことで色々な意見が出るのなら、まずは開発を進めるのも大切です。

　その時には、協力者、特に役職が上の人の協力、賛同が得られると、やはり会社組織では開発が進みやすくなります。

交渉方法を考える。

　合意しやすい協議事項から始める。状況に応じて複数メンバー/個々の折衝を使い分ける。

他にも色々考えられる方法が何度か引用させていただいている「戦略的交渉入門　田村次郎・隅田浩司　日経文庫　日本経済新聞社」に詳しく書かれています。

　社内での利害調整に関してはP196から記載されております。

　また、理論が伝わる「議論の技術」倉島保美　BLUE BACKS には、立証責任は重いので、相手に説明させる。相手の説明をよく聞いて、相手の矛盾点を見出し、そこを、質問して行くのが、議論上手。相手の意見を遮って、自論を展開するのは結局、水掛け論になりやすい。との記述もありました。非常に面白い、参考になる考えだと思います。

議論が紛糾したら

イメージを下記の図に示し、説明して行きます。

参考図書：理論が伝わる「議論の技術」、倉島　保美（Blue Backs）

①主張、②その理由、③根拠となる事実、を整理する

対立が激化する場合は、色々な意見が出るので紛糾するので、そもそも、話を整理する必要が有ります。

整理するにはまず、お互いの主張とその理由、根拠となる事実を整理します。主張、その理由は違ってしかるべきですが、事実は一つです。

なので、まずは、事実を再確認し、前提を合わせましょう。どちらかが、事実誤認をしていただけ。という場合もあります。そんな場合は、事実を再確認するだけで簡単に合意できたりします。

主張や理由はなぜ自分の考えと違うのか？その辺りを知ろうとして話すことが大切です。しかし、分からない場合は相違点としてとらえておく、一旦、議論をするのはやめるのが大切です。

ミッションから合意できる所を確認する

事実確認が終了し、主張、その理由から相違点が明確になったら、次に共通のミッションの再確認です。ミッションを再確認するだけで、双方の主張を包括する案が出てきたりします。

具体的なメリット/デメリットで協議する。

そこまで、合意が出来たら、相違点の協議になりますが、その主張、理由をその考えはおかしい、等といった議論になるとその人の価値観によるところもあるので平行線になりやすいです。

それよりは、双方の主張を実施した場合のメリット/デメリットを明確にして、一番効果的と思われる案を関係者で協議するのが大切だと思います。

まとめ

先ずは、ネット情報からの紹介です。

富士ゼロックス総合教育研究所 研究室長／首都大学東京 大学院ビジネススクール

非常勤講師 坂本 雅明氏の投稿。

人・組織にかかわる調査報告『人材開発白書』なぜ部門間の協力が進まないのか ～周りを巻き込む3つの方法～　人事ポータルサイト、HRproからの引用です。

企業のミドルマネジャーを対象に、他部門との連携が上手くいかなかった理由を調査しました（『人材開発白書2013』）。1,023人の回答データを統計的に分析したところ、上記の5つに集約されました。との事です。

　この中でも、相互の方針のずれが一番大きな理由とのことです。（図表１参照ください）5に近いほど障害に感じており、1に近いほど障害に感じていません。3は「障害になっているともなっていないともいえない」という中立的な回答です。

それではどうすればどうすれば良いのか？というと以下の三つの方法が提案されています。

　信頼残高とは社会心理学者のEdwin. P. Hollanderが1970年代に提唱した信頼蓄積理論を起源にする。また、信頼に関する世界的権威の山岸俊男も、相手に信頼してもらうためには信頼に値する行動をとり続けなければならないと述べている（山岸俊男(1998)『信頼の構造: こころと社会の進化ゲーム』、東京大学出版会）とのことです。

２、協力を得る具体的な交渉方法は？

　私が部門間の交渉に当たって、大切だと思っていることは以下の3点です。

１、相手が何を考えているのか理解することに集中する。

　私が感じるのは、人の話を聞いた後に、自分の考えと違う場合、すぐに反論する人が多いように思います。

　人の考えを理解するというより、話を聞きながら、反論内容を考えているような人です。交渉はある意味反論を重ねるもので間違いだとは思いませんが、まずは、相手の考えを理解し、自分の考えとの相違点、合意点を明確にするのが大切だと思っています。

　特に、交渉が難航しそうな場合は事前のヒヤリングで相違点/合意点をはっきりさせるのにまずは集中することが大切だと思っています。

２、交渉内容を考える。（Win-Win の考え）

確かに、様々な実際の交渉例を分析していくと、双方が100％満足できているような交渉結果を目にすることはほとんどありません、大半の合意は妥協や譲歩の産物と言ってもいい物ばかりですし、お互いの不満が完全に解消されているわけではないのです。しかし、フィッシャー氏の提唱する「賢明な合意」に近づこうとする努力、すなわち、お互いに100％満足するWin-Win な合意ではなく、お互いの正当な要望を出来り限り反映させようとする努力をしている交渉と、単に駆け引きだけで終わっている交渉の差の大きさだけははっきりしています。

戦略的交渉入門　田村次郎・隅田浩司　日経文庫　日本経済新聞社　P25より引用

まさしくそう思います。

３、交渉方法を考える。

　状況に応じて交渉方法を考えることは大切だと思います。

次回は、もう少し具体的な交渉方法についてお話したいと思います。下記の記事を参照ください。

他の部署との交渉で悩まれている開発者の方へ。交渉の進め方、大切な事を紹介します

相手が何を考えているのか理解することに集中する。相手の話をよく聞く(議論はその後）相手の話をよく聞く目的は？交渉戦略を練るために、交渉相手の考え、心配、要望、思いをよく理解する。相手の考えの合意点、相違点を明確にする。　相手の話を聞くのは簡...

rakuda0218blog.com

2021.01.12

　他部署の協力を得るためにも、初めにしっかり「すり合わせ」をして方向性を合わせる事は非常に大切です。

　有りがちなのは、５Ｗ１Ｈレベルで確認が取れていなかったり、思わぬメンバーから話が違う、聞いていない。とクレームがはいったり、役割分担が不明確で実際に進める際に、それは○○の仕事だと思っていた。などです。

初めから完璧なものは造れませんし、状況も変わっていきます。一度決めたから大丈夫ではなく、その後も確認して行く事は大切ですが、やはり最初がやはり肝心です。

後で揉めるよりは最初に揉めておいた方が実害は絶対に少ないです。

実害だけでなく初めに話せば説明と受け取ってもらえますが、揉めた後で説明しても言い訳のようにとられてしまうから不思議です。

　その為に、私は開発計画書と称した書類を作成し議論していました。以下に開発計画書に記載すべきと思われる項目は以下のようなものになります。

1、背景

開発を始めるに至った背景、社内状況、市場状況等を記載

2、開発の目的・目標

２－１）目的

その開発は何のためにするのか？ということです。例としては以下のようなものを想定しています。

• コストダウンのため、
• A社の参入障壁になっている品質案件で、他社を凌駕し、新規に参入するため、
• B社向けで、他社に劣っている〇△の品質で、他社を凌駕し、シェアーアップを測る。

２－２）目標

目的を達成するための道しるべ、となる目標。５W1Hを入れて、具体的に何を達成すれば良いのか、メンバーが共有できることが非常に大切になります。

３、開発範囲

　対象機種、対象ライン、対象工程等、やらないことも記載した方がはっきりして良い。

４、開発コンセプト

　　目標を達成するためのより具体的な方法、また、開発を進めるにあたっての全体の考え方、という意味で開発コンセプトといった言葉を用いています。

　例えば梱包容器のコスト削減で言えば以下のようになります。

• 容器仕様見直しによる50%以上のコストダウン、
• 品質やハンドリング性能は前機種同等以上、
• 前機種と使用上互換性がある事

５、開発進捗状況

　詳細資料はデザインレビューの結果を添付資料とし、量産対応の目途が得られた旨を簡単に記載。

６、開発体制

6-1)開発責任者

　この開発を進める責任者、他部署とのインターフェイスも務める。

　参考までに私はデザインレビューの際に設計/開発チームのリーダー(課長職相当）が開発規模/困難度に応じて責任者を決める事としていた。役職で事前に決めておいてもよいが、ガイドライン程度で、決定者が誰か決めておく方が運用しやすい。

　社内プロジェクトとなる場合、必ずしも、設計/開発部門のメンバーが責任者にならなくても良い。

6-2)設計審査/決裁者

　開発責任者とは別に最終的な決裁者を決めておく必要がある。決裁者は社内の決裁基準があるのならそれに準じるのが望ましい。

6-3)役割分担/責任者

　設計/開発部門だけではないので役割分担と責任者/メンバーを決める。他部署のメンバーは具体的にどういった仕事をしてもらうのか、イメージを共有し、先方に決めてもらうのが良い。

6-4）インターフェイス

　例えば隔週の進捗会議の開催、等、この会議ですべてのアクションを決めて行く。スケジュールを都度調整するのも大変なので定例会議をお勧めします。

　各部門の考えを集約し、開発計画書にまとめ上げるのは非常に大変です。私も色々失敗して来ました。上手く交渉しまとめ上げていくにはどうすれば良いのか、次回、お話したいと思います。

７、制約条件

お金や人材など無尽蔵にあるわけではありません。本格検証を進める上での制約条件、前提条件を洗い出して初めに確認しておきます。

８、主要マイルストーン/スケジュール

要素技術を量産レベルで問題ないか検証して行くのが本格検証ですので、量産化するまでのマスタースケジュールを作成し、開発計画書にまとめて各部門と協議することになります。

したがって、マスタースケジュールは全体を見渡して、マイルストーンを明確にし、主要な課題を示したスケジュール表となります。

具体的には以下のようなイメージです。

まとめ

本格検証を進めるには各部署の協力が不可欠であり、初めにしっかり検証の進め方、開発体制などの進め方をしっかり「すり合わせ」をして方向性を合わせる事が非常に大切になります。

デザインレビュー

デザインレビューの目的

技術的な何故を開発メンバーで協議しておく事が必要で、それが一番大きな目的です。

　実務上はデザインレビューの結果を開発計画にまとめる事。開発計画を関連部署に説明し、合意を得て開発を進める事になります。

　　関連部署に説明し、レビューを行い、進め方の合意を得るのをデザインレビューと呼ぶ方も多いと思いますが、その場合は、製造なり、品質保証なり、営業の観点の議論になり、技術的な深いレビューは出来ません。

　なので、まえもって、設計/開発のメンバーで徹底的に、その設計の根拠、技術的な内容を深く議論することが大切になります。

参加メンバー

開発メンバ（少人数、最低2人、決裁者の出席は必須）で詳細なレビューを行う。

　参加メンバーを絞り、少数で有効な議論をするのが大切です。他部署メンバーとプロト機／予察評価を共同で実施したような場合は当然、他部門のメンバーも参加してもらう必要があります。

デザインレビュー内容

要求項目から要素技術/開発目標の進捗状況

• 要素技術の進捗状況確認。
• 開発目標の達成状況(達成/未達）
• 問題点の特定と修正。

過去の不具合対策が反映されているか

　この場合、設計上のレビューですので、具体的に物理、化学的な事が原因で発生した不具合について、確実に対策が盛り込まれているかレビューすることになります。

詳しくは以下の記事を参照ください。

未然防止/予防対策に必要な過去のトラブルの上位概念化。一般化。でもどうすれば良い？そのコツ、秘策を紹介します。

一般化、上位概念化一般化、上位概念化の例たとえば、失敗学実践編　濱口哲也・平山貴之　日科技連で紹介されている上記の看護師さんの配薬ミスについて考えます。失敗学実践編　濱口哲也・平山貴之　日科技連　を参考に作成未然防止とは過去に発生した不具合...

rakuda0218blog.com

2021.02.05

他社特許の抵触有無、特許戦略の明確化

• 製品開発の場合は必須
• プロセス開発の場合は侵害検証の可能性は少ないので必須ではない。

マージン評価

●材料加工の場合

　例えば、研磨の場合には加工圧力やスラリー濃度、PAD寿命、研削の場合は砥石の押し込量、砥石寿命等、量産時に管理幅を設定する必要がある項目のマージン評価結果、

　また、特性がそのパラメーターに感度があるのは何故か？その原因まで深堀することが大切です。何故なら、パラメーターの感度は状況が変われば変わることは良くある話で、その時に深堀が出来ていないと、何を、どう考えればよいのか、手が出なくなるためです。

●組み立て加工品の場合

　過負荷評価（シミュレーション）やプロト機での評価（振動試験　etc）

量産性評価（品質/コスト/納期）

• 開発コンセプトに基づいて量産性の評価を行う。
• 他部署と協議をするための原案を作成する。
• 本格的な検証は他部署を巻き込んだ量産設計の所で検証していくことになる。

　組み立て加工の場合、既存の製品と部品/技術の共有化が図れているかのチェックが必要。コストだけでなく、納期(デリバリー）に大きく影響します。

リスク評価

　ISO上は、リスク評価を各ステージで実施するように要求されています。ただ、デザインレビューの段階で細かなFEMAなどを実施しても、その後、細かな所は変わっていくのであまり意味が有りません。制約事項、あるいは市場から退場をせざる負えないノックアウト要因があるのなら開発の前提条件、制約事項、要望事項として洗い出しておくべきで、リスク評価とは異なります。

　デザインレビューの段階では、その設計そのものが、重大クレームや、制約事項に対して適切かのレビューを行う事が大切となります。

一方、量産前にはFTAとFMEAを組み合わせたような詳細なリスク評価は絶対に必要です。

その段階では、量産化を見据えた管理方法の検討段に入っているので、具体的に、管理方法にリスク評価の結果が反映できるので、非常に有効です。

デザインレビューで心がけるべき大切な事、6選

　開発の目的を達成できると自信が持てる。行けそうだと思えることが大切です。

　そうでなければ、人の意見に左右され、議論になりません。自信が持てなければ調査、実験に戻りましょう。

本格検証は、このデザインの検証になりますのでこのデザインレビューで骨組みはほぼ決まります。その為、設計の問題点を想定範囲を広く、感度良く気が付けるようにしておく事が大切です。

私は、下記の６点が必要と感じています。

また、デザインレビューは、改まって実施するのは一回で良いでしょうが、同僚や、上司とは非公式な打ち合わせはタイミングをみてどんどん実施する事も大切な事と思っています。

設計・開発フロー

　デザインレビュー（D.R）、設計検証、設計審査等、色々な言い方がありますが、本ブログでは上記のフロー図のように定義致します。

デザインレビュー：試作品/プロトラインのステージに進むためにレビューを行う。

　　設計審査：量産に移行するにあたって総合的な審査を行う。

自信を得る事。

個人的な考えですが、調査/予察実験の目的は、開発目的が達成できるとの自信を得る事です。自信は事実を積み上げて行く事でしか得られません。

・なぜ自信を持つことが大切か？

　自信を持つというより、量産で問題なく出来るといったイメージを持てるが大切です。また、自信は調査や実験を通してでしか得られません。そうでなければ人の意見に左右されることになります。

　完成形がイメージ出来ていれば、現状と完成形を対比して、何が違うのか？足りないのはなにか？を考えて行く事になります。

　例えば、色々な問題点を指摘された際に、自信があれば、それは〇×なので試作品で確認しましょう。とか、その問題点に関しては○○ではないですか？と議論が出来ます。

　自信を持って議論が出来なければ、素直に調査/実験に戻るべきと思っています。

完成形の詳細が具体的に見せられること。

試作品やパイロットラインに進むには、製造や営業など、関係部署の了解をもらう必要が有ります。その為、完成形が具体的に分かるように基本設計をまとめ上げる事が大切です。

関係部署の人から、後で、思っていたのと違う。そういった物だとは思わなかった。等と言われては、その時点でやらなければならないことが増えます。

余計な仕事を増やさないためにも、詳細に、完成形が具体的に見える形で紹介しましょう。

良く走りながら考える。と言いますが、経験上、走りながら考えるは上手く行きません。

自分で完成形をイメージし、絵を見せる事です。実際には検証してみないと分からないので、そこは走る必要があるのですがそれでいいんです。具体的な絵が無いと相手もあやふやなので、後々揉めることになります。

具体的な絵が相手に伝われば、その時点で議論が出来ますが、あやふやまままでは、議論もぼやけます。

逆の言い方をすると、具体的な絵が描けていないと自信は持てないはずです。

実際には検証してみないと分からないわけですから、自信を持つとは具体的な絵が描けているとも言えます。

ある意味、その通りなのですが、後々、問題が顕在化した場合、影響が大きく、問題も起きくなります。本質的な問題は先送りして良い事は何もありません。

揉めそうなことは先に揉めておく事が大切で、そのためには、出来るだけ、具体的な姿で議論する必要があるという事を特に強調しておきたいです。

少なくとも、思っていた通りに行かない場合には、自分が想定していたのと何が違ったのか？と考えるだけ、傷は少なくて済みます。

また、先に説明しておけば、周りの納得が得られやすかったものを、上手く行かなくなってから、これこれだから大丈夫、と説明しても言い訳のように聞こえてきます。

関係者を巻き込み、開発を進めて行くためには、やはり、自信を持つ事。具体的な絵姿を見せる事の方が大切だと個人的には思っています。

問題を先送りしない

私の経験上、本格検証まで進んで、結局上手く行かず、中止に追い込まれた経験は何個かありますが、それは、やはりその前の、デザインレビューの時にも、完成形を明確にイメージ出来ていなかった。自信がなかったと言うのが有ります。

開発は、次のステージに進む関所のようなものが何回かあります。デザインレビューはその代表です。そこで問題を先送りしない。という事が、当たり前ですが大切だと思います。

この手の話になると、時間が大切。走りながら考える事が大切。という方もいらっしゃいますが、走りながら考えて済む話なら走りながら考えれば良いと思いますが、完成形に自信が持てない物は「急がば回れ」が結局近道だと思っています。

トップ方針などで話がどんどん進んでしまうような場合は要注意となります。

デザインレビュー

インプット情報のレビュー

インプット情報は以下の4点

1. お客様の要求事項
2. 開発目標
3. 設計仕様
4. 開発コンセプト

調査/予察に進む前にデザインレビューの決裁者にインプット情報は決裁をもらっておくことは大切です。

お客様の要求事項は、開発部門と営業など客先対応部門、社内開発の場合はお客様となる製造との事前擦り合わせは必須です。しかし、それ以外の3点は、改めて関係部署と開発計画書の形ですり合わせをするので、まずは、設計/開発部門でしっかり協議し、決裁をもらう事が大切です。

要素技術の検証

まずは、要素技術の検証が必要です。下の図を見てください。開発目標を達成するために、必要な技術として洗い出したのが要素技術です。

要素技術が進まないと開発目標は達成できません。

よって、要素技術の検証を調査（シミュレーション）やプロト機を使った試験を通して開発目標が達成できるかどうか検証することになります。

試作機、プロトラインの仕様まとめ（基本設計）

要素技術で目途が得られたら、実際の試作機、あるいはプロトラインの仕様をまとめることになります。デザインレビューの際の内容は、下記の様になるので、それを意識してまとめる必要が有ります。

まとめ

　QFD「品質機能展開」よりも「開発コンセプト」を導入することで、お客様からより必要な情報が引き出せると感じています。

要求事項を明確にし、現実対比を行い要素技術/設計目標/開発目標にまで落とし込む方法

要求事項

　お客様の要求事項です。お客様はあなたの提供する商品/サービスの良し悪しを判断できる人と定義しますので、対外的なお客様、社内のお客様、いずれも含みます。

しかし、お客様はすべてを語ってはくれません。製品を使ってもらう上で必要な制約条件はお客様も製品の事が良く分かっていないので、何が制約条件になるのか分からないのです。

従って、設計/開発者が実績のある既存品と何が違うのかを明確にして、お客様とどういった問題が起こる可能性が有るのか、協議をすることが必要になります。

つまり、制約条件を明確にするにはお客様の声を出発点とするだけでは抜けが有り、設計/開発のコンセプトを最初にしっかり組み立て、まずはコンセプトをお客様と協議しながら同時に要望事項を並行して引き出して行く事が大切になると感じています。

設計開発は何かを変更すると影響が色々な所に出て来ます。予想もしていなかったところに出てくることも良くあります。なので、既存品との違いは何なのか明確にして広く前広に協議することが大切です。

開発目的

　その開発は何のためにするのか？ということです。例としては以下のようなものを想定しています。

• コストダウンのため、
• A社の参入障壁になっている品質案件で、他社を凌駕し、新規に参入するため、
• B社向けで、他社に劣っている〇△の品質で、他社を凌駕し、シェアーアップを測る。

開発コンセプト

　　目標を達成するためのより具体的な方法、また、開発を進めるにあたっての全体の考え方、という意味で開発コンセプトといった言葉を用いています。

　例えば梱包容器のコスト削減で言えば以下のようになります。

• 容器仕様見直しによる50%以上のコストダウン、
• 品質やハンドリング性能は前機種同等以上、
• 前機種と使用上互換性がある事

現状整理

　一般に技術ばらしとも呼ばれているようですが、お客様の要望事項を実現するためには色々な
要素があり、それを整理するのが現状整理です。
　例えば、コストダウンが目的であれば、既存品のコスト分析（現状整理）を行い、効果が大き
いと思われる項目についてコストダウンの施策や技術課題（要素技術）をまとめ目標に落とし込みます。
　お客様の要求事項が性能の改善である場合は、その技術要素を整理することになります。例えば、ガラスの輸送中のずれを防止するのであれば、ガラスの保持機構、衝撃吸収、除振機能などの対策が
考えられるが、現状の技術を整理し、効果が大きいと思われるものについて対策方針、技術課題
（要素技術）をまとめ目標に落とし込みます。

要素技術

　設計コンセプトを具現化するために必要な個々の具体的な技術的アイデア。技術的検討課題です。

　例えば梱包容器のコスト低減で言えば

　といった具合です。

　　この例は改善に近いので、新しい開発というよりは仕様の見直しに近いですが、新規の技術を検討する必要がある場合にはアイデアを思いつく必要があります。

品質展開

要求事項から開発目標、設計仕様への落とし込み

単純にお客様の要望事項を一つの特性で表すことが出来る程、単純でない場合もあります。そんな場合は要求品質内容と工学的な関連をまとて二次元で表した品質表にして考える必要があります。

要求機能展開、QFDと呼ばれる手法が有名ですので良ければ参照してください。

部品を生産しているような場合は、お客様で使われる状態での特性で考える必要があります。例えば、ガラスの梱包容器であれば、お客様から見れば必ずガラスが乗っかって梱包された状態です。社内であれば、空容器で使う場合も、ガラスが乗った場合もあります。

ガラスが乗った状態で使われる場合は、ガラスの積載の状態も特性に大きく影響します。

当たり前のようですが、慣れてくると、梱包容器だけの比較で特性を考えようと、途中を飛ばすような事があり、抜け、もれ、が発生する場合があるので注意が必要です。

お客様の要望は、ガラスが積載された状態での要求事項ですので、容器単体としての要求事項だけで考えるのではなく、製品として必要な要求事項から部品に必要な要求事項を考えないと漏れが出てくる。という事です。

目標の数値化について

これも、難しい物はいっぱいあります。具体的に言えば梱包容器の作業性です。これを、具体的な数値目標に落とすと非常に難しい。実際に作業者に聞いても、問題視する人としない人と大きく分かれますので、お客様の多くの意見を聞いて、優先順位を決めておく事が必要です。

仮に、一人作業で1分以内で作業が出来る事。と決めても、作業に関する特性なので適切ではないです。一人作業で一分以内で作業できるために、どうするかを考えることになりますが、実際は色々難しいです。

こんな場合は比較対象を決めて、同等以上としておいた方が現実的です。比較対象としては、他社の容器となります。作業性が優れているか、いないか、何人かで実際に扱ってみて比較し、改善が必要であれば、その改善を開発目標として運用していました。（他社品は何とかして手に入れましょう。）

お客様に聞くのが合理的なような気もしますが、作業者によって意見が違っていたり。他社品が多く流れている所であれば、他社の容器に慣れているので、他の容器は作業性が悪く感じる。お客様によっては、他社と同じ構造にしろと無理を言ってくるお客様もいます。当然、逆のパターンで、自社の方が使いやすいと言ってくださるお客様もいます。

お客様の声ではなくて、自分たちで実際に使ってみる。また、設計者が使ってみると、甘えが出るので、社内の第3者の評価を仰ぐといった事も必要と思います。

そのうえで、設計者がこれで良いと思ったら、具体的に早くお客様に評価してもらう事が大切になります。

要求事項の優先順位

　お客様の要求事項そのものに対する優先度は、コンセプトを決める際に絞り込む事になります。たとえば、△△性能の改善要請があるが、今回は盛り込まない等です。当然設計開発の部門 だけでは決められません。コンセプトは関連部署と協議し要求事項の優先順位を決める事が大切 になります。

　その上でお客様の要求事項を、一旦、開発目標と設計仕様に落とし込みを行います。設計仕様は 制約事項なので守らなくてはならないものです。設計を進める上で、お客様に変更をお願いする 事はあり得ますが優先順位を付ける対象にはなりません。

　開発項目は、現状整理したうえで必要な対策、開発目標を定めたものです。一番効果が 得られると思われる項目から優先して進める事が大切になります。 　また設計開発者は機能向上を優先しがちで特に初期の頃はコスト意識が薄くなりがちです。 コストダウン設計に限らず、コスト目標は開発目標に入れ、初期の段階からしっかりフォロー して行く事が大切になります。

まとめ

　狩野モデルとは

当たり前品質とは？

テレビをつけたけど画面が出ない。車に乗ったけどエンジンがかからないとかそういった事です。使う上での最低条件、必要条件とも言えるでしょう。

一元的品質とは

テレビや車のカタログに出ているスペックをイメージしてもらえれば良いでしょう。価格なども一元的品質と言えます。

魅力的品質とは？

新技術と言い換えてもいいでしょう。今までにない価値を生み出すわけです。一元的品質でも圧倒的に他社を凌駕していれば魅力的品質になるともいえるでしょう。

各品質の対処方法

魅力的品質については自組織の強みを考慮しながら、いくつかの項目に焦点を絞って競合組織を凌駕する水準を狙えばよいでしょう。いかに重点を絞ってリソースを集中しブレークスルーをはかるかが大切となります。

当たり前品質は、競合組織を凌駕しても喜んでもらえませんが、悪くなるとそっぽを向かれます。競合組織を下回らない水準を狙いとした上ですべての物を確実に実施する必要があります。

魅力的品質を実現するためには、顧客の潜在ニーズを把握する事と、ニーズを満たす上で不可欠なボルトネック技術を予想し、解決する事の二つが大切になります

ISO9000の知識　中條武志著　日本経済新聞社　より

第一優先は当たり前品質

当たり前品質は必要条件ですから取りこぼしは許されません。使っていただく上での制約事項と言っても良いかもしれません。

この当たり前品質は、満たすことが出来ないとクレームに直結します。

なので、設計開発者としては営業任せにしては絶対にいけません。実際にクレームが発生しても誰も責任を取ってくれません。

営業任せにしてはいけない理由は、当たり前な品質は、お客様も何が問題になるのか分かりません。

なので、実績のある既存品との違いを明確にして、お客様とどういった問題が考えられるか技術的な協議を行う必要が絶対に有ります。

技術的な議論になるのでやはり営業に任せられません。

他社との競争になる一元的品質

他社との比較で評価されます。他社より劣っていれば、どこかの部分では他社に勝っていないと買ってはもらえません。

他社に勝っている要因は商品だけでなく、短納期だったり、接客の態度であったり、製品の品質以外の要因でも比較されます。

魅力的品質は他社との差別化

魅力的品質は潜在ニーズを把握して、お客様と新しい未来を作っていく形になります。引用図書、ISO9000の知識にあるように、潜在ニーズの把握とボルトネック技術を予想し解決することが大切なのは確かにその通りです。

しかしながら、言うのは簡単で、実際には非常に難しく、お客様がどこまで魅力的と感じてもらえるか人によっても違ってくると思います。

上の図に示したように製品の品質以外のサービス、対応力など、いわゆる自社の強みは何なのか、よく考え、総合力で差別化を計って行く事が大切になると思います。

つまり、物理的充足度が低くてもお客様の満足につながる左上の領域を目指すことも大切だと思います。

まとめ

お客様のライン(使われ方）をよく知る。

社内向けの開発

• 工程担当者とラインを見ながら必要事項の洗い出し。
• ラインが複数に及ぶ場合は、全ラインに詳しい人に確認。

　社内の場合、機密保持の観点で詳細まで確認できないということは基本無いはずであすが、相手にとっては時間を取らせることになる事になります。

　常日頃から、製造ラインのメンバーとコネクションを持ち、1対１でフリートーク出来る関係性を作っておくのが大切になります。

お客様向けの開発

• 他部署メンバー確認事項を具体的に依頼
• 装置メーカーと色々なルートで接触する。

　設計/開発の部門のメンバーであれば見せてもらえなくても、クレーム対応で品質保証のメンバーや製造の舞台のメンバーが先方のラインに入る機会は意外とあるものです。

　その時に、事前に気になっていたポイントを説明し確認してもらうのは有効です。

　お客様によっては特に量産前の開発段階では装置メーカーを直接紹介していただいたり、場合によっては3社で打ち合わせを行うこともあります。

お客様と議論を通じて要求事項/制約事項を洗い出す

商品の機能/性能（スペック）を説明する。

　社内の場合にはアイデアを温めている段階でも1対1のフリートークは可能ですが、お客様の場合には、やはりハードルは一つ上がります。

　私の場合には、デザインレビューが終わり、試作品を作成し、社内的に本格検討に進む際にお客様にアナウンスするのが普通でした。お客様からの要請で開発する場合には、アイデアの段階で紹介することもありました。

　お客様との関係、あるいは社内の考え方でお客様ともアイデアの段階で協議できるのなら、早い方が絶対に良いです。

　資料はカタログをイメージしていますが、商品の事をよく理解いただくのが目的になります。商品によって、必要な資料を準備すれば良いと思います。

お客様の確認が必要な項目を確認する。

　一般に商品の説明には性能やスペックが記載されたカタログをイメージするでしょうが、それとは別に、設計を進める上で確認をしなければいけない項目です。

　私が担当していた梱包容器で言えば以下のような形になります。

　梱包容器はフォークリフトで運ぶので、運べるようにするためにはフォークリフトの諸性能を知っておく必要があります。これを考えるにはどの様な使われ方をするのかよく知っておくことが大切になります。

他社品/既存品と開発品との違いを明確にする。

他社品でしか実績が無い場合

　他社品でしかお客様で使用された事しかない場合に、新しく参入する場合には他社品との違いを明確にする必要があります。

　他社品は市場に出ていない場合は入手は基本的に困難ですが、色々なルートで情報を入手しましょう。

　また、お客様に設計上確認が必要だと納得していただければ、部分的に情報を開示してもらうことも可能です。

　何よりも実績が一番、実績のあるものと、新規の物との違いは何か、違いがあるとどういった影響が出るか？を考え、お客様と議論することが大切です。

自社品での実績がある場合

　当然、自社品と開発品の違いを説明し、どういった影響があるかお客様と議論することになります。

お客様のライン仕様が決まっていない場合の対応

• 当方から、逆に提案し、それをもとにライン設計をしてもらう。（フォローが必要）
• お客様のスケジュールを把握し、ポイント、ポイントで確認を行う。

定期的に要求事項を確認する。

• 要求事項は定期的に確認する必要があります。
• そのためには、設計上確認が必要な項目と他社品と自社品の違いをフォーマット化し、情報として蓄積できるようにすることが大切です。
• 営業など他部署に確認してもらうにしてもフォーマット化が必要です。

お客様の要望事項を洗い出す方法

お客様の要求事項の例

　お客様の要求事例の例を表1に記載します。

　扱う商品によって事情は異なると思いますが、

赤字で記載した使用工程からの要請事項（制約事項）は、確認漏れがあると量産後に問題が顕在化する場合があります。そうなると、量産NGになることもあり、インパクトが非常に大きくなります。

使用工程からの要請事項（制約事項）はインパクトが大きいにも関わらず、お客様から開示が無いと把握するのが難しくなります。

要求事項を把握するのは何故難しいのか？

お客様自身が要求事項をよく理解していない。

　お客様って誰？で記載したように、ご担当の方だけがお客様ではありません。関連部署から情報を入手し要望事項を取りまとめる必要があります。

　基本、設計者がお客様と話が出来るのは、お客様の窓口の方なので、窓口の方の顔をつぶさず、他の部署からの情報を入手してもらうのは基本営業にお願いすることになります。営業との連携も大切だと思います。

お客様はすべてを語らない。（暗黙の要求事項）

　お客様は基本、貴方の商品に関しては良く分かりません。なので、商品に関しては十分説明して、どう言った要望があるのか、制約事項があるのか、議論しながら引き出す必要があります。

知らない内にライン変更があり要求事項が変わる

　お客様のご担当者の方次第になりますが、通常、メーカーに連絡しないといけないと思ったことは連絡していただけます。前述したように商品の説明/議論を通して、お客様にこれは連絡しないといけないな。というポイントをよく理解してもらうことが大切と思っています。

通常ラインは見せてくれない

　お客様により、様々ですが、基本、ラインは機密上の問題で見せてもらえません。

新ラインの場合は実際に制約事項が決まっていない。

　開発/製作の納期の点で、お客様のラインの詳細が決まらない内に、色々決めて行く必要が出てきます。

どうすれば良いか

次の記事に対応方法を記載しました、よければ参照ください。

お客様視点、お客様に寄り添って要望事項/制約条件を洗い出すのはどうすれば良いのか？

お客様の要求事項を洗い出すのはどうすれば良いのか？お客様のライン(使われ方）をよく知る。お客様と議論を通じて要求事項を洗い出す。お客様のライン仕様が決まっていない時は、先に提案し誘導する。定期的に要求事項を確認する。お客様のライン(使われ方...

rakuda0218blog.com

2021.01.03

まとめ

　なお、この記事は私が経験した　B to B　（お客様が個人ではなく企業）の場合を想定して記載していますのでご了解願います。

お客様って誰ですか？

　「顧客満足ってどうやるの？社内を動かす実践的ノウハウ」佐藤　知恭監修　CS実践研究会　編　日本経済新聞社、P38からのお客様って誰？の記載があったので引用します。

　この本では、「お客様は誰か」の議論は効果絶大と記載されています。理由は驚くほど様々な議論が出てお客様に対する高い認識を共有できるようになると書かれています。

　私自身、議論したことはないので効果が絶大かどうかは分かりませんが、お客様は誰かを考えるのは大切だと思っています。

　私は薄い大きなガラスを輸送する梱包容器の開発を長年担当して来ました。一般的に、そのラインの設計の担当者が窓口になるのですが、その後ろには、製造部署や品質保証部署など、サービスの良し悪いを判断出来る（せざるを得ない）部署があります。

　本来、お客様の窓口の方が各部署の代表として折衝してもらうといいのですが、必ずしもそうはいきません。窓口以外部署ともチャンネルを持ち、品質の良し悪しの話が出来る事が大切と感じています。

　そうなってくると、やはり営業に技術的な事もある程度理解してもらって、折衝してもらうことが大切になります。また現実的には各社の社内事情で各部署の力関係やキーとなる部署も異なるので、その辺りも営業には探ってもらうことが大切です。

　対外的なお客様ではなく、社内(後工程）がお客様の場合もやはり複数の部署とコミュニケージョンをとって行く事が必要になります。

お客様視点、目線で考えるってどうするの？

そもそも、お客様の誰に話を聞くのか？も大切ですが、話を聞くだけでは不十分です。何故なら、お客様も、実際に何が必要で、何を要望したら良いのか分かっていないことが多いからです。

お客様から話を聞くだけでなく、開発品に関しては具体的に現状品との違いを明確にして議論することも大切になります。

別途記事にしていますので良ければ参照してください

お客様の要望事項を洗い出すのは何故難しいのでしょうか？その原因を考えます。

お客様の要求事項の例　お客様の要求事例の例を表1に記載します。　扱う商品によって事情は異なると思いますが、赤字で記載した使用工程からの要請事項（制約事項）は、確認漏れがあると量産後に問題が顕在化する場合があります。そうなると、量産NGになる...

rakuda0218blog.com

2021.01.02

まとめ

問題意識を持つ

　問題意識を持つのが最初になります。自発的に意識した場合は良いですが、強制的に意識しなければならない場合もあります。

どちらもアイデアが出るまで問題意識を持つ事が最初です。問題意識を持つ事で見る目が変わり、ヒラメキにつながる情報を多く脳内に蓄積して行く事になります。

脳の焦点化でも説明されていますが、脳は、見たいと思った物しか見てくれていません。（NLPの基本がわかる本、山崎啓支、日本能率協会マネージメントセンター、P24より）

ヒラメキは何もない所から降ってくるわけではありません。日頃から関心を持って、物事を見ていると、自然と「観察力」や「洞察力」を鍛えている事に繋がり、いざというときに回路がつながりやすくなります。

ヒラメキを検証する。

ヒラメキは上記のように、脳内のネットワークで最適と思われる回答として出てきたものです。自信をもってまずは実際に試してみて検証してみる事が大切です。

単なる思い付きであれば、実行に移す前に問題点が明確になります。行けそうだ！と思ったら実行に移すのが大切です。

新しいものはヒラメキが無いと先には進めません。実際に進めて行くと新たなアイデアが浮かぶことも多々あります。実際に進めようとすると、その前に問題点が発覚するケースもあります。

ヒラメキは大切にしましょう。

潜在意識を活用する。

　潜在意識は寝ている間も活動しているとのことです。

NLPの基本がわかる本　山崎　啓史　日本能率協会マネジメントセンター　P85より

睡眠は、体を休めるだけでなく、不要な情報は忘れ、必要な情報を整理する作用があるそうです。（思考の生理学、外山滋比古著、筑摩書房より）そういった効果もあるのかもしれません。

リラックスしている時の方が、アイデアが出やすいとも言われています。潜在意識と意識の境目が曖昧になるからだそうです。（これも何かの本で読んだんですが題名は忘れてしまいました。）

体を動かす。コーヒーを飲む。気分転換を図るのはやはり大切という事になります。

前提/機能を疑え

　改善のイメージに近くなりますが、前提を疑う、そのものの機能を考え、代替の方法は無いか、止められないか？具体的には、そもそも○○が必要なのか？○○の機能は？同じ機能を持たせるのなら××で良いのでは？結局〇△で代用できるのでは？等です。

技術動向/業界情報/類似業界情報

　当たり前の話ですが、世の中の技術動向、業界情報は大切です。会社に勤務していると自然と入ってくる情報もありますが、改めて調べる必要が出てきます。

　私の場合、自分が担当している技術が、他の業界でどう使われているのか？を調べるとヒントが得られることが多かったです。

アイデアだし/ブレストは有効？

　念のためにブレストについて説明するとブレインストーミング、複数の参加者で自由にアイデアを出す手法で、皆さんも経験されていると思います。

　個人的にはアイデア出しにはブレストは不向きと思っています。それよりも普段の同僚（上司もOK）との会話の中で、思いつくまま意見交換を行い（二人ブレスト？）を日常会話として実施する方が有効と感じています。

　いかがでしょうか？

　何か不具合があった時の対策会議、品質問題の対策会議等では複数のメンバーで議論することは有効と考えています。

　その方法においても具体的には後々紹介していきたいと思います。

まとめ