無料ブログはココログ

Twitter

  • Twitter

« 2005年2月 | トップページ | 2005年4月 »

2005年3月

2005年3月21日 (月)

なぜ使えない(9)

今回はCAEとプレゼンテーション力の関係を述べる。

CAEの結果画像はプレゼン時には非常に強力である。

応力図、アニメーションなどをプレゼンテーションで見せると、間違いなく現実にそのようなことが起きると思わせてしまう。

しかし、近頃はみる方もだいぶこのようなプレゼンテーションにもなれてきて、突っ込んだ質問、つまりプレゼンの図と実際の現象が一致しているのかが問われてくる。

そこでうまく説明が付けることができるかが解析者の能力が問われてくる。

設計開発の問題に関する部分であるなら、十分納得させるまで答えなくてはならない。

しかし、本質的でない部分の質問も出ることが多い。

例えば、コーナ部で非常に応力が集中しているとか、注目していない領域の応力がおかしいなどである。

これに対してメッシュの分割の大きさが云々という説明を始めても解析に詳しくない方たちは通じず、その場を何とか収めたとしても、結局正確には出ないのか、と思われてしまう。

それでは、使えないと思われてみ仕方あるまい。

そこであえて、応力図やアニメーションを極力出さないようにすることをお勧めしたい。

設計者が必要な情報、つまり設計案を解析結果で比較したグラフや表を中心に見せるべきである。

図は、解析手順を示すところでモデルの絵を出す程度で十分であることが多い。

後はもし要求されたら出せばよいのである。

2005年3月13日 (日)

なぜ使えない(8)

しばらく、メーカーの中での解析専任部署の技術者や受託解析会社の技術者に関する話を述べたい。

前回、これらの解析先任者には特にコミニュケーション力とプレゼンテーション力が必要だと述べた。

技術的には非常に優秀で、知識もある解析技術者というのは少なくないのだが、このコミニュケーション力とプレゼンテーション力がないために、評価が低くくなっている方も多いように思える。

まずは解析技術者のコミニュケーション力について述べる。

解析者の業務上一番重要なコミニュケーションをとならければならない相手は、当然解析の依頼者である。

解析の依頼者からは、解析の依頼内容を聞き、解析に必要な図面、物性値などのデータをできるだけもらわなければならない。

解析に必要なデータは結構多く、解析のために依頼者が探すのが、結構面倒臭いとされてしまう経験をお持ちの方も多いと思う。

また、解析に本当に必要なデータはなかなか送られずに、少し的外れなデータが送られてくる場合も結構ある。

これらを解決するためには、依頼者ときちんとコミニュケーションをとることが重要である。

また、後で述べるが、実は解析者は解析する前に解析結果を予想しておかなければならない。

解析を行う前に、結果を予想するためには、物理法則を理解して理論的に考えることも重要だが、実際にどのようなことが起きているのか、依頼者や依頼部署の関係者から聞き出すことも重要である。

依頼者は、設計、開発のプロではあるが、解析関係のことは素人の方が多いので、解析にとっては重要な事項なこと(たとえば現象や過去の事例など)を伝えてくれない場合が多い。

そのようなことをうまく聞き出し、シミュレーションに反映にさせると、非常に質の高い解析ができる。

そこで、どのようにコミニュケーション力を高めるか、が問題になるが、わたしも述べられるほどコミニュケーション力はないので、世の中に出ているビジネス書などを参考にしてほしい。

ただ、コミニュケーション力を意識して仕事されると、少しづつ良い方に向かうであろう。

また、メーカーの解析部門であれば、できるだけ設計開発部門の近い場所にいるのが良い。
遠いところでメールや電話でやり取りするより、直接現物を見ながら話をした方が良いに決まっている。

だがどうも、最近の傾向ではCAE部門は設計開発部門からはなされる方向に見える。。。

2005年3月 6日 (日)

なぜ使えない(7)


いまだにCAEをCADの導入と同様に考えて、オペレーションさえできれば何とかなると思っている方が結構多い。

CADであれば、2次元でも3次元でも形状ができれば、とりあえずそれをアウトプットとして、周りを納得させられることができる。

しかし、CAEはモデルを作って解析結果をただ出すだけでは、その結果の妥当性がない限り、周りを納得させることはできない。

また周囲は、ベンダーや講演会、学会でのデータやプレゼンを鵜呑みにして、CAEですべての試験結果が完璧に「予言」できると思っている場合が多いから、厄介だ。

少しでもおかしいところがあると、今度は逆にシミュレーションは信用できない、CAEは使えない、ということになり、信用回復に時間がかかる。

しかし、今まで述べてきたように、CAEは一筋縄ではいかないので、周りを納得させるための結果を得られるようになるには、それなりの経験が必要で、時間がかかる。

ただ、もう一度基本に立ち返ると、設計開発者が持っている課題点に対して、何かしらの解決案を出すことができれば、CAEは役に立ったといえる。

設計開発者自ら解析を行う場合は、解決案の部分に焦点を絞ってCAEを行うので、課題解決を意識することはそれほど難しくないと思う。

よって、設計開発者自ら解析を行う場合の課題点は、忙しい中ソフトのオペレーションをマスターできるかということと、解析結果をうまく解釈できるか、ということになる。

これについては、また機会があれば述べたいと思うが、設計開発者が「気合い」を入れることができれば、解決できる場合が多いはずである。

ところが、解析専任者がこの解決案を意識して解析を行うというのは、なかなか難しい。

それを意識できないと、例えば最終報告が解析のテクニック的な部分の説明が多くなり、依頼した設計者などがよく理解できないこととなり、本論と関係ないところが議論になるなどして、解析者の墓穴を掘ってしまうことも良く見受けられる。

私も気をつけているのだが、いまだにやってしまうこともある。

これを防ぐには、技術力は当然だが、
・プレゼンテーション力
・コミュニケーション力
も大変重要である。

これらについてはまた次回。

« 2005年2月 | トップページ | 2005年4月 »

2015年6月
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        

最近のトラックバック

ウェブページ