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

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

変動費と固定費

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

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

変動費

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

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

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

また、製品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であっても、こちらから開示した情報だけでなく、相手から入手した情報にも縛りが入ります。いわゆる情報コンタミの問題も発生します。

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

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

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

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

まとめ

マスタースケジュール

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

要素技術は開発内でプロト機や予備試験を通じて開発目標がクリヤーできそうだ。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を明確に、更に数値で明確に！！が大切になります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

ノウハウとは？

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

契約の必要性について －オプション契約－ | 特許業務法人 三枝国際特許事務所[大阪・東京] 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品を分析、強度評価を行い、その結果をシミュレーションに反映させ、寿命をシミュレーションし、管理基準の見行いました。

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

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

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

まとめ

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

設計・開発工程の効率化

量産、事業を前提とした設計・開発（イメージとしては事業部研、事業に直結した設計・開発）の場合、私が入社した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）インターフェイス

　例えば隔週の進捗会議の開催、等、この会議ですべてのアクションを決めて行く。スケジュールを都度調整するのも大変なので定例会議をお勧めします。

　各部門の考えを集約し、開発計画書にまとめ上げるのは非常に大変です。私も色々失敗して来ました。上手く交渉しまとめ上げていくにはどうすれば良いのか、次回、お話したいと思います。

７、制約条件

お金や人材など無尽蔵にあるわけではありません。本格検証を進める上での制約条件、前提条件を洗い出して初めに確認しておきます。

８、主要マイルストーン/スケジュール

要素技術を量産レベルで問題ないか検証して行くのが本格検証ですので、量産化するまでのマスタースケジュールを作成し、開発計画書にまとめて各部門と協議することになります。

したがって、マスタースケジュールは全体を見渡して、マイルストーンを明確にし、主要な課題を示したスケジュール表となります。

具体的には以下のようなイメージです。

まとめ

本格検証を進めるには各部署の協力が不可欠であり、初めにしっかり検証の進め方、開発体制などの進め方をしっかり「すり合わせ」をして方向性を合わせる事が非常に大切になります。