コンピュータが設計するから、設計者は要らない!?：ピタゴラスイッチの計算書を作ろう（6）（2/3 ページ）

設計計算書とフロントローディングとシミュレーション

　銀二叔父さんは、もの憂げなまなざしを遠くへ向けながら、ゆっくりと話を続けました。

銀二「シミュレーションというのは、もともと、運動方程式を解析的に解いて運動を把握することが難しいので数値計算で近似的に解を求めるというものだ」

草太「“解析的”？」

銀二「解析解を求めるというのは、微分、積分を駆使して、数式として解を求めるということだ。解が数式で表現されるから、式に含まれるパラメータが運動にどう影響するか、俯瞰（ふかん）的に理解することができる。だから本当は解析解が欲しいんだ」

「しかし現実の機械の構造は複雑だし条件も多種多様だ。だから解析解が求められるなんてことはまずない。そこで、本来連続系である微分積分の演算を離散値化して数値計算できるようにしたんだ。コンピュータが発達した現在では、CG技術を利用してシミュレーションモデルを“数式”ではなく、“絵”で作成できるようになった」

草太「僕たちが作ったモデルがシミュレーションモデルってこと？」

銀二「そうだよ。昔は、数式をコンピュータに1行1行入力していたんだ。ボールが落下するシミュレーションも、昔はニュートンの運動方程式をキーボードで入力していた。いまはPCの画面上でボールの絵を描けば、それでモデルが作成されたことになる」

草太「便利だからいいじゃない」

銀二「確かに便利になったけど、モデルを作ったのはシミュレーションソフトであって、操作をした人間じゃない。技術者の矜持（きょうじ）という点では、なんとも情けないと思わないかい？」

草太「そういわれれば、確かにそう思うけど、そんなに重たく考えなくても解析ツールとしてとらえればいいんじゃないの？」

銀二「設計ツールとしてのシミュレーションという考え方には文句はないけど、力学の基本も理解していない者から『シミュレーション結果が“イイ感じ”だったので、私の設計も“イイ感じ”にできました！』 っていわれると、思わず『ウソつけっ！』っていいたくなる」

草太「自分がソフトに使われてしまうのではなく、シミュレーションの結果が本当に正しいのか、自分で検証できる程度の力学や解析力があればいいんだけどね」

銀二「私がいいたいのは正しくそこだよ。シミュレーションをすれば評価されるのではなく、シミュレーションの結果を正しく判断できる者が評価されるべきなんだね。例えば、薄い板の両持ち梁（ばり）の上にボールを落としたとする。板の中央と端では跳ね上がるボールの高さは違うだろ？」

　銀二叔父さんは、自分がシミュレーションした例を見せながら説明を続けます。

草太「真ん中で高く跳ね上がって、端ではあまり跳ねないよね」

銀二「一般にシミュレーションで使われる物体は剛体として扱われている。しかしこの場合は、板を剛体としたモデルにすると、板の落下位置によって跳ね上がり高さが異なるという結果は出てこない」

　薄い板は断面係数が小さいので、硬い金属であっても弾性的挙動をします。中央と端ではその弾性の大きさが異なるので、跳ね上がるボールの高さも異なるのは経験上誰でも分かることです。だから、正しい跳ね上がり高さを知りたければ、板を弾性体として計算する必要が出てきます。

草太「それじゃあ、剛体の板をばねで接続して、疑似的に弾性体を作り出せばいいのか」

銀二「そうだな。そのとき、ばねの定数をどのような値に設定すればよいか？ そのためには、力学や材料力学の知識が必要となる。しかし、何も考えない人は剛体のままシミュレーションをして結果が出たと喜ぶ。それだけならいいが、それが重大な設計ミスにつながるってことだってあり得る」

草太「でも技術が進歩すれば、コンパクトデジカメのように、誰でも簡単に正しいシミュレーションができるようになるのでは？」

銀二「シミュレーションに依存して、自分で考え、自分で判断することを放棄することが一番危険なんだ。シミュレーション結果の是非を判断するためには、自分で設計計算をすることが重要で、そのためには物理や数学の基礎を理解していることが不可欠だ」

「まず設計計算書で、基本的な設計思想や設計計算の考え方を整理しておき、電卓やExcelを使っておおよその答えを出しておく。そしてExcelでは複雑で困難な計算を、シミュレーションソフトがカバーする。つまり設計計算書とシミュレーションが補完する関係が望ましいんだよ」

　最近「フロントローディング」といって設計段階からコストや品質をクリアして、開発期間短縮を目指した設計開発手法が注目されています。ITが発達したことにより、設計が固まらないうちに3次元のモックアップモデルが誰でも見られるようになりました。

　その仮想モデルを見て、営業は、もっとこういう曲線にした方がお客にアピールできるといったり、生産技術者はこんな形状では物は作れない、など本格的な設計に入る前にあれこれ注文することができます。場合によっては生産ラインの設計も同時に着手する場合もあります。

　ただし、設計の骨格がしっかりしていて、みんなの要求を受け入れても設計パラメータの値を少々変更すれば、設計品質をそれほど落とさずに対応できるならば問題ありません。しかし「作ってみなけりゃ品質なんて分かるかい」という設計陣の下では、開発前に会議を開いて、事前にあれこれ要求しても意味がありません。

草太「設計計算書があれば、お客や営業の要求に対応できるか計算すればすぐ分かるんじゃないの？」

銀二「そうなんだ、お前のいうとおりなんだ。しかし、実際には設計計算書が作られている製品というのはあまりないんだよ。取りあえず試作品を作って、仕様をクリアできるか現物で確認しようっていう場合がほとんどなんだ。そういう“もの作り”では、設計計算書はあまり重要視されない。会社によって違うだろうけど、設計計算ではなく図面を描くことが機械設計だと思っている会社が非常に多いんだ」

草太「確かに図面がなければ物は作れないからね」

銀二「納期は決まっている。だから、とにかくどんなふうになるか現物を見たい。その結果、検討もそこそこに図面を引いて試作品を組み上げる。性能が出なければカットアンドトライで何とかしようってことになる。で、何とか作り上げるんだけど、なぜうまくいったか分からない。迷路に迷っているうちに何だか知らないけど出口に到達したって感じだな」

草太「ふーん。設計ってもっと合理的にされているものだと思ってた」

銀二「合理的な設計をする会社もあるけど、そういう会社は少ないな。似たような製品だからすぐ作れるのではと思っても、すぐには作れず、何度も同じ過ちを繰り返しながら、バタバタして作り上げる。多くの会社でこの繰り返しをしているようだね」

草太「そういえば、昔は設計でだいたいの形状や構成を確保して、『生産工程で品質を作り上げる』というのがものづくりの主流だったけど、最近は『設計で品質を確保する』というフロントローディングが開発の主流だと先生がいってたよ。だけど、いまの話では実際にはそうでもないんだね」

真のフロントローディングとは

銀二「会社にもよるし、業界にもよるな。そもそもフロントローディングの語源はなんだと思う？」

草太「“前にロードする”、つまり負荷を前に掛けるってことだよね」

銀二「さっきおまえがいったように、昔は「品質は生産工程で作り込む」だったんだ。ということは製品品質を作り込むクライマックスは開発設計の最後にあったわけだ。だから開発の最後で工数や改善費などの負荷が掛かっていた。しかし、それでは仕事の手離れが悪くなり、開発期間がどんどん延びてしまい、費用はかさむし、開発期間もなかなか短縮できない、という問題が起きてきた」

「そこで、品質を作り上げるために要する時間や費用などの負荷を設計段階に掛けて、早い時期に品質を作り上げ、開発費低減と開発期間短縮を狙ったのがフロントローディングってわけだ」

草太「なるほどね。しかし設計段階の検討を充実させようっていったって、“もの”がなければ検討できない開発手法では、設計検討の前倒しもできないと思うけどな」

銀二「まったくそのとおりだ。品質を作り込むために、取りあえず試作品を作って、その試作品をベースに改善していくもの作りの手法では、しょせん試作品から離れた設計はできない。人間は実例や実物をいったん見てしまうと、その影響を受けてしまって、新しい発想ができなくなる。『開発期間を短縮しろ』っていわれれば、せっかく作った試作品をベースに改善したくなるのは人情というものだ」

草太「類似製品の試作品を設計するにしても、そのベースに“類似製品についての設計計算書”がないよね。だから類似製品の見よう見まねで作らなければならない。で、結局、毎度毎度一から作り始めるのと同じ経路をたどって、なかなか開発期間は短縮しないんだ」

銀二「上からは、『前作ったのと同じように設計すればいいんだよ。一度経験してるから、今回は半分の期間でできるだろう？』といわれるが、その前回がどうしてうまくいったか分からないから、結局、土日に出勤してつじつまを合わせることになる」

草太「ふーん。現場の設計って結構大変なんだね。どうりで理数系の学校出てても、メーカーに就職したがらない人が増えるわけだ」

　そんな草太の言葉に、銀二叔父さんはつい苦笑いしてしまいました。