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

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

技術情報の整理

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

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

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

設計/開発に必要な情報

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

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

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

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

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

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

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

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

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

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

分類は最低限に

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　まとめ

デザインレビュー

デザインレビューの目的

技術的な何故を開発メンバーで協議しておく事が必要で、それが一番大きな目的です。

　実務上はデザインレビューの結果を開発計画にまとめる事。開発計画を関連部署に説明し、合意を得て開発を進める事になります。

　　関連部署に説明し、レビューを行い、進め方の合意を得るのをデザインレビューと呼ぶ方も多いと思いますが、その場合は、製造なり、品質保証なり、営業の観点の議論になり、技術的な深いレビューは出来ません。

　なので、まえもって、設計/開発のメンバーで徹底的に、その設計の根拠、技術的な内容を深く議論することが大切になります。

参加メンバー

開発メンバ（少人数、最低2人、決裁者の出席は必須）で詳細なレビューを行う。

　参加メンバーを絞り、少数で有効な議論をするのが大切です。他部署メンバーとプロト機／予察評価を共同で実施したような場合は当然、他部門のメンバーも参加してもらう必要があります。

デザインレビュー内容

要求項目から要素技術/開発目標の進捗状況

• 要素技術の進捗状況確認。
• 開発目標の達成状況(達成/未達）
• 問題点の特定と修正。

過去の不具合対策が反映されているか

　この場合、設計上のレビューですので、具体的に物理、化学的な事が原因で発生した不具合について、確実に対策が盛り込まれているかレビューすることになります。

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

未然防止/予防対策に必要な過去のトラブルの上位概念化。一般化。でもどうすれば良い？そのコツ、秘策を紹介します。

一般化、上位概念化一般化、上位概念化の例たとえば、失敗学実践編　濱口哲也・平山貴之　日科技連で紹介されている上記の看護師さんの配薬ミスについて考えます。失敗学実践編　濱口哲也・平山貴之　日科技連　を参考に作成未然防止とは過去に発生した不具合...

rakuda0218blog.com

2021.02.05

他社特許の抵触有無、特許戦略の明確化

• 製品開発の場合は必須
• プロセス開発の場合は侵害検証の可能性は少ないので必須ではない。

マージン評価

●材料加工の場合

　例えば、研磨の場合には加工圧力やスラリー濃度、PAD寿命、研削の場合は砥石の押し込量、砥石寿命等、量産時に管理幅を設定する必要がある項目のマージン評価結果、

　また、特性がそのパラメーターに感度があるのは何故か？その原因まで深堀することが大切です。何故なら、パラメーターの感度は状況が変われば変わることは良くある話で、その時に深堀が出来ていないと、何を、どう考えればよいのか、手が出なくなるためです。

●組み立て加工品の場合

　過負荷評価（シミュレーション）やプロト機での評価（振動試験　etc）

量産性評価（品質/コスト/納期）

• 開発コンセプトに基づいて量産性の評価を行う。
• 他部署と協議をするための原案を作成する。
• 本格的な検証は他部署を巻き込んだ量産設計の所で検証していくことになる。

　組み立て加工の場合、既存の製品と部品/技術の共有化が図れているかのチェックが必要。コストだけでなく、納期(デリバリー）に大きく影響します。

リスク評価

　ISO上は、リスク評価を各ステージで実施するように要求されています。ただ、デザインレビューの段階で細かなFEMAなどを実施しても、その後、細かな所は変わっていくのであまり意味が有りません。制約事項、あるいは市場から退場をせざる負えないノックアウト要因があるのなら開発の前提条件、制約事項、要望事項として洗い出しておくべきで、リスク評価とは異なります。

　デザインレビューの段階では、その設計そのものが、重大クレームや、制約事項に対して適切かのレビューを行う事が大切となります。

一方、量産前にはFTAとFMEAを組み合わせたような詳細なリスク評価は絶対に必要です。

その段階では、量産化を見据えた管理方法の検討段に入っているので、具体的に、管理方法にリスク評価の結果が反映できるので、非常に有効です。

デザインレビューで心がけるべき大切な事、6選

　開発の目的を達成できると自信が持てる。行けそうだと思えることが大切です。

　そうでなければ、人の意見に左右され、議論になりません。自信が持てなければ調査、実験に戻りましょう。

本格検証は、このデザインの検証になりますのでこのデザインレビューで骨組みはほぼ決まります。その為、設計の問題点を想定範囲を広く、感度良く気が付けるようにしておく事が大切です。

私は、下記の６点が必要と感じています。

また、デザインレビューは、改まって実施するのは一回で良いでしょうが、同僚や、上司とは非公式な打ち合わせはタイミングをみてどんどん実施する事も大切な事と思っています。

設計・開発フロー

　デザインレビュー（D.R）、設計検証、設計審査等、色々な言い方がありますが、本ブログでは上記のフロー図のように定義致します。

デザインレビュー：試作品/プロトラインのステージに進むためにレビューを行う。

　　設計審査：量産に移行するにあたって総合的な審査を行う。

自信を得る事。

個人的な考えですが、調査/予察実験の目的は、開発目的が達成できるとの自信を得る事です。自信は事実を積み上げて行く事でしか得られません。

・なぜ自信を持つことが大切か？

　自信を持つというより、量産で問題なく出来るといったイメージを持てるが大切です。また、自信は調査や実験を通してでしか得られません。そうでなければ人の意見に左右されることになります。

　完成形がイメージ出来ていれば、現状と完成形を対比して、何が違うのか？足りないのはなにか？を考えて行く事になります。

　例えば、色々な問題点を指摘された際に、自信があれば、それは〇×なので試作品で確認しましょう。とか、その問題点に関しては○○ではないですか？と議論が出来ます。

　自信を持って議論が出来なければ、素直に調査/実験に戻るべきと思っています。

完成形の詳細が具体的に見せられること。

試作品やパイロットラインに進むには、製造や営業など、関係部署の了解をもらう必要が有ります。その為、完成形が具体的に分かるように基本設計をまとめ上げる事が大切です。

関係部署の人から、後で、思っていたのと違う。そういった物だとは思わなかった。等と言われては、その時点でやらなければならないことが増えます。

余計な仕事を増やさないためにも、詳細に、完成形が具体的に見える形で紹介しましょう。

良く走りながら考える。と言いますが、経験上、走りながら考えるは上手く行きません。

自分で完成形をイメージし、絵を見せる事です。実際には検証してみないと分からないので、そこは走る必要があるのですがそれでいいんです。具体的な絵が無いと相手もあやふやなので、後々揉めることになります。

具体的な絵が相手に伝われば、その時点で議論が出来ますが、あやふやまままでは、議論もぼやけます。

逆の言い方をすると、具体的な絵が描けていないと自信は持てないはずです。

実際には検証してみないと分からないわけですから、自信を持つとは具体的な絵が描けているとも言えます。

ある意味、その通りなのですが、後々、問題が顕在化した場合、影響が大きく、問題も起きくなります。本質的な問題は先送りして良い事は何もありません。

揉めそうなことは先に揉めておく事が大切で、そのためには、出来るだけ、具体的な姿で議論する必要があるという事を特に強調しておきたいです。

少なくとも、思っていた通りに行かない場合には、自分が想定していたのと何が違ったのか？と考えるだけ、傷は少なくて済みます。

また、先に説明しておけば、周りの納得が得られやすかったものを、上手く行かなくなってから、これこれだから大丈夫、と説明しても言い訳のように聞こえてきます。

関係者を巻き込み、開発を進めて行くためには、やはり、自信を持つ事。具体的な絵姿を見せる事の方が大切だと個人的には思っています。

問題を先送りしない

私の経験上、本格検証まで進んで、結局上手く行かず、中止に追い込まれた経験は何個かありますが、それは、やはりその前の、デザインレビューの時にも、完成形を明確にイメージ出来ていなかった。自信がなかったと言うのが有ります。

開発は、次のステージに進む関所のようなものが何回かあります。デザインレビューはその代表です。そこで問題を先送りしない。という事が、当たり前ですが大切だと思います。

この手の話になると、時間が大切。走りながら考える事が大切。という方もいらっしゃいますが、走りながら考えて済む話なら走りながら考えれば良いと思いますが、完成形に自信が持てない物は「急がば回れ」が結局近道だと思っています。

トップ方針などで話がどんどん進んでしまうような場合は要注意となります。

デザインレビュー

インプット情報のレビュー

インプット情報は以下の4点

1. お客様の要求事項
2. 開発目標
3. 設計仕様
4. 開発コンセプト

調査/予察に進む前にデザインレビューの決裁者にインプット情報は決裁をもらっておくことは大切です。

お客様の要求事項は、開発部門と営業など客先対応部門、社内開発の場合はお客様となる製造との事前擦り合わせは必須です。しかし、それ以外の3点は、改めて関係部署と開発計画書の形ですり合わせをするので、まずは、設計/開発部門でしっかり協議し、決裁をもらう事が大切です。

要素技術の検証

まずは、要素技術の検証が必要です。下の図を見てください。開発目標を達成するために、必要な技術として洗い出したのが要素技術です。

要素技術が進まないと開発目標は達成できません。

よって、要素技術の検証を調査（シミュレーション）やプロト機を使った試験を通して開発目標が達成できるかどうか検証することになります。

試作機、プロトラインの仕様まとめ（基本設計）

要素技術で目途が得られたら、実際の試作機、あるいはプロトラインの仕様をまとめることになります。デザインレビューの際の内容は、下記の様になるので、それを意識してまとめる必要が有ります。

まとめ