CADを使わない設計者、出世できない解析者：MONOistゼミ レポート（5）（2/3 ページ）
設計者がCADを使わない!? 解析専任者は出世できない!? ショッキングな話題が次々と飛び出したパネルディスカッションの内容をお届け。
解析専任者を一生続けると、出世できない！
アイティメディアさんに提案しますよ。『本当の設計者のためのPowerPoint＆Excelゼミナール』を企画してみては？ かなり集客できると思いますが。
（場内、笑い）
大規模な会社の話に行くと、またPowerPoint＆Excelな話に行ってしまいますし、ここで議論するのは、あくまで中規模の会社が対象としておきましょうか。（そういう会社においては）設計者の方が解析している、あるいは解析専任者がいる（あるいは解析専任の部署がある）ところがあると思いますが、彼らの役割分担についてはどう考えたらいいでしょうか？
CAEは奥が深い世界。それを設計者が完全にマスターするのは、さすがに無理です。だとすると、設計と解析の2つの部署――いや、もっと複数かもしれませんが――部署間で連携を取り、いい設計をしていく体制づくりが大切になってくるかと思います。
例えばわたしも、日々いろいろなお客さまとお付き合いしていて、結構大変だなと思うのが、設計部隊と解析部隊との関係があまり良くないところが多いことです。同じ解析部隊の中でも、構造、衝突、流体と分野が違う同士で仲がよろしくありません。それぞれの人たちは、自分たちが中心だと思っているからなのか……。会社内部よりも外部の人たちとの方が、絆（きずな）が強かったり……。
ですから、そのような状況下でも協調設計せざるを得ないシステムづくりでもしてしまわないといけないのではと。人間関係、もしくは組織関係を含めようとしたら、決してうまくいきませんから。日本は本来、『和を以（もっ）て貴（とうと）しとなす』という国だったはずなのに、いまはそうではなくなってきているのですね。欧米大手の自動車メーカーや航空メーカーでは、自動的に部門間が協調設計するように仕向けるようなシステム化が非常に進んでいます。日本は、そのようなシステム管理をあまり積極的に取り組んでおらず、部門単位のエゴ……個性といいますか……、そういったものが強くなってしまいました。
また、日本の大手自動車メーカーさんは、IT部門の力がすっかり弱くなりました。（製造業における）IT部門は管理的業務がメインになり、建設的なことをやっていないケースが増えてきているのです。本当はIT部門と経営者たちがともに、『どういうシステムを構築すれば、良い製品ができるのか？』ということを考えるべきなのに。（モノづくりにおけるIT構築については）トップダウンで決めないと。いまのような各部門のボトムアップの改善ばかりでは、日本製造業は非常に危ないのです。
組織が大きくても小さくても、解析シミュレーション（CAE）については、ある程度専任体制が必要です。どうやれば組織がうまく機能するか、次のような3つのポイントがあります。この3つをうまく組み合わさないと、解析シミュレーションの専任体制はうまく機能しません。
- 人・モノ・金に責任を持てるマネジメント：製品技術が分かり、CAEを評価できる管理職の確保
- 社内要員の育成：CAE要員の役割の明確化、現場との協力関係の確保、将来への処遇の道筋の確保
- 外部活用：何もかもを社内のCAE要員に任せるのには無理がある。社内機能と外部委託業務を併用する
図にすると、このような組織になります。
これは、わたしの20年以上の業界経験の中で悟った理想的な組織の例です。図の真ん中がCAE担当で、チームの大きさは会社の規模によります。例えば、先ほどのような中規模サプライヤでは、設計部の中に数名のCAEチームを持っているでしょう。この人たちをいかに機能させるかになります。
今日の中小規模のサプライヤは、新入社員が入ると、まずCAE担当にします。2年ぐらいたち、非常に高度な技術が身に付くと、『もうちょっと広く、設計を経験した方がいい』とCAE専任担当からだいたい外されるんですね。そうすると、また一から出直し。じゃあ、その人たちがその先何年か仕事をしていくに当たり、処遇ベースやジョブローテーションはどう計画するか……。実は、これがほとんどありません。
最も重要なのは、『人・モノ・金に責任を持てるマネジメント』です。わたしがいままで接してきた会社で（マネージャとして）成功していたのは、設計現場からきた人でした。CAE専任者では、自分の得意な範囲ばかりになってしまいます。製品の設計とCAEの両方分かる人が、作業の優先順位の決定や、将来の処遇パスの確保、内部とのケンカの仲裁などをやらなければいけません。そして、少人数な組織では、そのようなことのすべてを管理者が遂行することは難しいので、外部（の組織や仕組み）をうまく活用すればいいのです。
それって、もっと平たくいうと、解析専任者は偉くなれないということですか？
偉くなれないですね。わたしの知る限りですが、解析専任者を何十年も続けた人で役員になった人はいません。日産の山下 光彦副社長は、かつて衝突解析の専任者として活躍しましたが、5年ほど経験した後に違う部署に転属していますし。
ずっと解析専任者だったらマズイ……と。
一生続けるとしたら、フェローがせいぜいいいところでしょうね。
何だか………………それはぐっとくるものが、……言葉にできない。
スカラのオーバーフローはどうにかならないの
以前、（当時の業務で）PCクラスタを自分で組み立てたことがあります。その当時、PCクラスタは相当繊細なものだと思いました。動作タイミング調整や、OSやアプリなどの負荷分散の考慮……など。その運用やメンテナンスに関して、専任者は必要なのでしょうか。
PCクラスタは、皆さんもご存じかと思いますが、スパコンと比べて、信頼性が1〜2桁（けた）ぐらい違ってきます。PCクラスタを導入するときは、たまに障害が表れることを前提としたシステム構築および運用を考えることが必要です。その一方で、障害が起きても自動的にシステムをリロードし、必要なジョブを継続させるような仕組みにお金を掛けるお客さまもいます。 また、PCクラスタの運用関連をアウトソースするケースもあります。要は、『たまに発生する数回の障害に対して、いくらコストを掛けようか』と考えることも運用を検討する際は必要だと思います。
MSC加藤さんの講演のスライドの中で、スカラコンピュータで内積計算を行うと、キャッシュがオーバーフローしてしまい、ガーッと落ちる……という話（『設計のねじれプロセスを正しCAEの浮島を築く』をご覧ください）がありましたが、何か反論はありませんか？
会場に、当社のPCクラスタやVPシリーズの設計に携わった専門家が来ています。彼に聞いてみましょう。
（来場者席から回答）「ベクトルに比べたら、スカラはどうしても性能が落ちてしまうことは否めません。その原因は、スカラとベクトルでメモリアクセスのアーキテクチャが異なるためです。スカラは大規模なアクセスでキャッシュがあふれてしまうのに対し、ベクトルアクセスはキャッシュを使用せずに大規模なアクセスが効率良く行える構造になっています。しかし、いまのスカラは、例えばプリフェッチ機構など、昔になかったさまざまな技術が開発され、だんだん改善されてきています」
単純にCPUの数が増えていくと、Nastranのライセンスのカウントはどうなるのですか？
いろいろパターンはあると思いますが、1つは、ライセンス数が増えていけば、だんだん単価が安くなっていくパターンがあると思います。もう1つは、並列化ライセンスを格安にしようという動き。かつては、2プロセッサで並列するから、金額も2倍になる、なんて時代もありました。いまと比べれば、だいぶ少ないプロセッサ数の並列だったから成り立ったのです。それが、いまみたいにコア数が8、16、32個という状態では、例えば『32コアだから、32倍の金額を払いなさいよ』となれば誰も買ってくれませんよね。いまは昔と比べ価格の決め方も変わってきて、だいぶ健全になりました。
何だか……、昔は極悪だったみたいじゃないですか。
わたしが（この業界に）入る前はね（笑）」
Copyright © ITmedia, Inc. All Rights Reserved.