icon-sns-youtube icon-sns-facebook icon-sns-twitter icon-sns-instagram icon-sns-line icon-sns-tiktok icon-sns-etc
SEARCH

機械設計 連載「B to B向け機械設計のポイント」

2026.02.13

第4回 基本設計/基礎開発の段階で大切なポイント

  • facebook
  • twitter
  • LINE

技術力向上カウンセリングオフィス 布施 裕児

ふせ ゆうじ:代表 1989 年4 月、旭硝子(現・AGC)入社、パソコン用ハードディスク向けガラス基板の加工技術開発、営業などに従事した後、液晶用のガラスを扱う事業部に異動となり、液晶用ガラスの梱包容器/梱包材料の設計開発を17 年以上担当。途中、1 年半ほど知財部兼務となり、特許戦略構築、出願推進活動も経験。2023 年4 月、同社を早期退職。現在は中小企業の技術支援や組織改革支援、セミナー講師として活動中。(一社)製造業総合支援 副代表。資格:上級心理カウンセラー[(一社)日本能力開発推進協会]。

はじめに

 図1 に今回提案する一般的な設計開発のフローを示す。顧客の要望事項を開発目標、設計目標に落とし込んだら具体的に基本設計/基礎開発を行うことになる。デザインレビューは量産検証のステージに進んでよいかどうかの設計審査の意味で使用しており、デザインレビューまでを基本設計/基礎開発の期間としている。
図1 一般的な設計開発のフロー

図1 一般的な設計開発のフロー

 基本設計/基礎開発では具体的に調査や予察実験、シミュレーションを行い、結果をレビューし、PDCAを短期間で回していくことになる。その際、基本設計/基礎開発はどういった体制が望ましいのか、他部署の協力体制はどう考えていけばよいのかについて紹介する。

 また、要素技術開発、基本設計以外に量産性の検討、評価も大切になる。品質(Q)、コスト(C)、納期(D)の検討で大切と思うところを紹介していく。

基本設計/基礎開発の体制について 

 図1 のように各工程を段階的に完了させていくシステムではなく、製品開発と並行して工程設計、サポート体制の構築を同時進行的に行い、最初から生産性を確保する開発を行うコンカレント・エンジニアリング・システムが推奨されている1)。 

 開発する商品は筆者が取り扱っていたような、構造体に簡単なメカ機構があるだけの単純なものであれば、担当一人で対応できるとしても、いわゆる工場に据え付けられる製造装置のような、メカから電気制御、ソフトウェアまで要素技術として組み込まれる商品のように、何名かの担当者が関係するものまでいろいろなケースがあると思うが、筆者はデザインレビューまでは極力、設計開発の精鋭メンバーでマイルストーンを明確にしたマスタースケジュールをベースにPDCAを早く回し、量産設計までの期間を極力短くすることに注力した方がよいと考えている。 

 実際に試作品を製作し、量産性を本格的に検証していく量産検証の段階では、必然的に顧客も含めたいろいろな部署と共同で完成させることになる。結局、量産検証はコンカレントなプロジェクト活動として行わざるを得ないが、そのときはやはり設計開発部隊が中心となっていろいろな協議を重ねることになる。設計開発を担当したメンバーがしっかり基礎検討し、「これでいこう」と本人が思える状態でなければ、試作に進んでも結局、顧客を含む関係部署としっかり協議はできない。 

 筆者が思う、設計開発部署が「これでいこう」と思える状態とは、具体的な量産の姿がイメージできていることである。図面ができている状態ではない。いわゆるQCDをはじめとする量産性など、さまざまな状態で各部署と議論する中で「こう考えている」と具体的に言える状態である。 

 工程の設計開発者がいる場合は、当然商品の設計開発者と工程の設計開発者が一緒になってデザインレビューまで進めるべきである。しかし、潤沢なメンバーがいない場合、やはり商品の設計開発者が、量産性に対する社内/社外の顧客の要望事項をしっかり聞き取り商品設計に反映させることが必要になる。 

 答えを一緒に考えるにしても、どこまで現実味があるかよくわからないものを検討する余裕は通常、ほかの部署にはないはずであるし、そのような検討を行うのが設計開発の部署ともいえる。 

 基本設計/基礎開発結果をまとめた開発計画書を商品の企画書と考えれば、やはり設計開発部署が責任を持ってまとめて関係部署と協議するのがよいとご理解いただけるのではないだろうか?

基本設計/基礎開発時の他部署との関係 

 基本設計/基礎開発の段階では設計開発部隊のメンバーで早くPDCAを回し、開発期間を短くすることに注力すべきと述べた。しかしながら、図1 に示したように、顧客の要望事項や制約条件を洗い出すのに他部署の協力は必要不可欠である。また、設計開発のコンセプトを考える際に、要望事項に優先順位をつけ、今回の開発には要望を盛り込むか盛り込まないかを設計開発だけで決めるわけにもいかない。 

 設計開発のコンセプトを決め、要望事項を絞り込むのは本来、すべての関係者の了解が前提となるものである。しかし、関係者といっても興味や関心は一様ではない。一般に、実際に設計開発が終了し量産移管した際に受け取る部署が興味や関心は一番高いし、優先順位も判断しやすい立場にある。その部門と共同でコンセプトを作成し、必要に応じてほかの部門の意見も聞きながら要望事項を絞り込むのが大切になる。
33 件
〈 1 / 2 〉

関連記事