開発期間を従来の半分にしたIHIのCAE実践――ロケットエンジン設計から生まれた「TDM」：CAEイベントリポート（4/5 ページ）

リスク管理を同時に実施

　一方、この手法では設計と同時にリスク管理も実施する。はじめの設計モデルづくりおよび設計解の集合の導出は、あくまでモデルが正しいという前提で進めるが、モデルを作成しようとした時に、“どうしても自信がない”という箇所が出てくる。そういった不安を「技術リスク」と認識して、リスク管理を進めていく。

　通常リスクは、発生可能性と影響度の積で定義される。だがこれから作ろうとする製品のリスクの発生可能性を示すことは不可能だ。そこでIHIでは、発生可能性を技術理解度に置き換えた（図9）。

図9：リスクを技術理解度を根拠として定義し直す（出典：IHI）

　技術理解度はさらに、現象の理解度、環境条件の理解度、実証度の積で表される。現象の理解度は物理モデルの理解度とし、メカニズムや支配的パラメータを把握してモデル化が可能なレベルかどうかで4段階に分ける。環境条件の理解度は境界条件の理解度として、データや根拠に基づいているかにより3段階に分ける。実証度は実測データの有無により3段階に分ける。「これらは発生可能性よりははるかに定量化しやすいと考えられる」（呉氏）。

　一方、影響度の定量化も難しいため、リスクが現実化した時の後戻り時間に置き換えるという。自分の解析が間違っていた場合に、それを修正するのに掛かる時間を1日、1週間、1年などで定義する。このようにしてリスクの大きさを定量化し、要素試験が必要かどうかなどの判断につなげていく。

　最後に問題となるのが、要素試験をした時、本当にリスクが現実になってしまったケースだ。つまり数学モデルが間違っていたが、設計は進んでいるという状態だ。IHIでは「予想外れ問題」と呼んでいる。IHIでは本当に心配な箇所については、外れてしまった時のバックアッププランをあらかじめシステム中に仕込んでおくという考え方を取っている。

　新型ロケットエンジンの開発では、世界初となる液化天然ガスを用いたエンジンの長秒時燃焼試験に成功した。上記の手法によって、世界初にもかかわらず、従来の半分以下の期間での開発に成功し、試験で重大な不適合も起きなかったとのことだ。