日経ものづくり/体質改善3D設計 第9回 標準化とモジュール化2 ~仕様/諸元の因果関係で整理する~

技術ディビジョン・コンサルタント 大泉 圭一

 

設計の標準化とモジュール化の取り組みでは両者を明確に分けること、そしてこれらを設計プロセスの「機能設計」と「形状設計」それぞれに対して適用することが、筆者らの手法の特徴である。今回から2回にわたって、標準化とモジュール化を実現するための実行手順(実際の作業の流れ)を取り上げる。実行 手順を、標準化とモジュール化、機能設計と形状設計という4つのキーワードで整理すると、下図のようになる。今回はまず、機能設計における標準化の作 業~と、同モジュール化の作業を説明する。機能設計は、主に設計対象が形状に落とし込まれる前の段階のため、仕様や設計諸元といった概念的な情報だ けが存在している。従って、純粋に機能や性能を実現するための設計手順やロジックに焦点を当てており、特定の仕様を前提とした形状や派生機種などは考慮しない。

 

 

■機能設計を対象とする標準化 設計検討項目の整理

 

機能設計の標準化でまず実施すべき作業は、機能設計で検討している項目を洗い出す(抽出する)ことだ。これによって、現状の設計検討に対する形式知化がど の程度図られており、設計者の中でどの程度共有されているかを確認する。さらに、設計作業を通してどの程度チ亜種チが発生しており、標準化による効果をど れくらい期待できるかを計る狙いもある。
まずは、設計者が日々行っている作業手順の聞き取りを行い、リストの作成から始める。設計検討項目として取り上げる単位(粒度)は細かくすればいくらでも 細かくなるので、初めから細かすぎないように注意する。時間にゆとりがない場合は、非常に粗い粒度で始めても構わない。 各検討項目に対して、以下のような情報を確認する。
•検討内容
•設計検討書などの資料名(存在しなければ「なし」と明記)
•検討作業の媒体名(表計算ソフト、CAD、ソルバーなど)
•検討頻度(例えば、毎回/新規性の高いときのみ/適当など)
•検討に含まれる諸元の多さ
•検討資料の汎用化度
•亜種の発生状況(影響の大小、背景)

これらの中で検討資料の汎用化度や亜種の発生状況については、設計者の主観で判断して構わない。あまり厳密に考えずに作業を進めてほしい。
設計検討書などの資料が存在せず、担当できる設計者が限定されている設計作業があれば、その作業は形式知化されておらず、属人的になっていることを示す。 聞き取り調査の中では、実は設計のやり方を理解しておらず、他の技術者の見よう見まねで設計を行っているような状況も見えてくる。

 

■機能設計を対象とする標準化 仕様/設計諸元の整理

 

設計検討項目のリスト化が完了したら、設計検討項目ごとに、顧客が指定する仕様や設計者が決める設計諸元などを抽出する。具体的には次のような情報である。
•設計検討項目名
•(上記の設計検討項目に含まれる)仕様/設計諸元名
•(上記の設計諸元における)インプット情報
•検討頻度
•(平均的な)検討工数/期間
•(平均的な)繰り返し検討回数
最も重要で、かつ手間がかかるのは、インプット情報を正確に整理することだ。インプット情報となるのは仕様か先行する設計諸元であるが、インプットは1つであることは少なく、大抵は複数の仕様や設計諸元であることが多い。それらを漏れなく抽出する。
しかし、ここでもあまり神経質になる必要はない。この後の作業〔諸元DSM(Design Structure Matrix)の作成、表計算ソフトによる設計計算ツールの作成など〕を進めていくと、漏れがあればおのずと見つかるからだ。作業の中で頻繁に手戻りが発 生するのも効率的ではないが、80点ぐらいを目指して作業をしてほしい。
仕様や諸元を整理する粒度も、あまり細かくする必要はない。例えば、エアシリンダの検討をする場合、その諸元としてはボア径やシリンダストローク、シリン ダロッドの材質などが考えられる。大規模な装置では、これらすべてを諸元として分析対象に入れては切りがなくなる。そのような場合は、仕様/諸元名として 「シリンダ仕様」などのように記述し、含まれるすべての諸元を集約して分析対象とする。

 

■機能設計を対象とする標準化 機能設計手順の定義

 

仕様/諸元のリストが完成したら、続いて機能設計の手順を定義する。手順の良しあしが設計効率に大きく影響することはもちろん、機能設計の標準化には適切な手順が必要だからだ。機能設計の標準化では、ムダな繰り返しや試行錯誤の解消も目指す。
筆者は以前、サーボモータを用いて負荷軸を回転させる装置において、機能設計の標準化を支援したことがある。主な検討項目としては、どのサーボモータを使 用するか、減速にどのようなギア列を用いるか、それとも市販の減速機を用いるか、加減速時のトルクと回転数を両立させるためにダブルクラッチを用いるか、 などだった。
これらの検討は過去の設計実績に基づいて行えば、図面を描かずに表計算ソフトを用いて行える。実現可能な組み合わせは非常に多く、その中からベストと思われる1つを選ぶためには繰り返し検討が必要だった。
しかし、このような繰り返し検討は本質的な試行錯誤が必要な検討ではなく、多くの実現可能なパターンの中から適切だと思われるものを選択しているにすぎな い。機能設計の標準化の目的は、このような作業を軽減し、設計者に依存した亜種を検討結果に基づいて解消することである。
具体的な作業について説明しよう。機能設計の手順を定義するために、筆者らは諸元DSMを用いる。
DSMは分析対象の要素間の因果関係や相関関係を分析するときに用いる手法だ。

 

上図のマトリックスの一番上の行と左端の列には、作業でリスト化した仕様と設計諸元が同じ順序で並んでいる。同図では、「設計検討諸元1」から始ま り、「同28」で終わっている。諸元DSMは、諸元の表示順番(番号)で検討手順を表現する。右側の領域には所々に「節点」と呼ぶマークが付けられてお り、これらのマークが因果関係を示している。手順で整理したインプット情報は、ここに表示される。上図の例では、「設計検討諸元15」は、「同5」と 「同7」をインプットとして決定される諸元であることを示している。
対角線は同じ要素を交差させた部分であり、”自分自身”はインプットにならないため、節点は対角線上には存在しない。ほとんどの節点が対角線の左下にある が、対角線の右上に表示されているものもある。右上にある節点は、自分よりも番号の大きい要素からインプットされていることを意味しており、例えば同図で は「設計検討諸元9」のインプット情報として「同14」がある。 自分よりも後の作業結果をインプットするということは、フィードバックを前提としていることから望ましくない設計手順である。諸元DSMにおいて対角線の 右上に節点があるかどうかを確認することで、フィードバックを解消する手順を見いだせるわけだ。
手戻りとなるフィードバックを解消するために諸元の順序を変えることは、場合によっては、その諸元を先行するステージに押し込むことになる。
そこで、機能設計の標準化があらためて必要になる。設計ロジックを明確にして亜種を解消し、できれば機能設計の自動化を図る。設計ロジックが形式知化されれば、設計を自動化しなくとも対応可能な設計者を増やしてボトルネックを解消するといった対応も可能になる。

 

(続きは、下記よりPDFをダウンロードしてご覧ください)

 

出典:PDFを含む掲載記事は、日経BP社『日経ものづくり』 2010年12月号 p102~107「体質改善3次元設計」より、日経BP社の了承の下、掲載しております。

パブリシティ・イベント