車載ソフトウェアのモデルベース開発（MBD）は、まず企画からスタートします。次にユースケースを洗い出し、細かくモデルを作っていきます。モデルを作成した後は、モデルからのオートコード（自動コード作成）によるテストを実施します。オートコードにより、実際のコーディングはほぼ不要になります。

また、ユースケースからモデルに落とし込む段階において、シミュレーションで動かしてテストできるため、仕様ミスなどがないかの確認ができます。いわゆるアジャイル的（※編注：短期間のサイクルで改善を繰り返すこと）な開発手法とも言えます。

自動車は通常、数年単位で開発しますが、重大な手戻りが生じた場合は開発期間が半年から1年ほど延びてしまうこともしばしばです。市場に出回ってから仕様ミスが発覚した場合には、リコール対応のための作業も費用も膨大なものとなり、社会的信頼やブランド価値も大きなダメージを受けてしまいます。

こうした事態を防ぐためにも、モデルベース開発（MBD）はもはや導入が必須と言えるわけです。

車載ソフトウェアの開発においては、従来は実車を動かしてテストを都度行っていましたが、モデルベース開発（MBD）では細かなモデルごとにシミュレーションで動かしてテストできるため、後工程でのテストが少なくなる傾向があります。こうしたことが「手戻り」の防止にもつながっています。

ADAS（先進運転支援システム）では、自動で追い越しをしてくれる機能があります。従来の開発手法では、隣の車線に車がいないかをカメラやセンサーで確認し、隣の車線に移ったら少し速度を上げて再度カメラやセンサーで確認してから元の車線に戻る、といった自動追い越しのアシスト機能を、実車を使ってテストしていました。

しかし、毎回実車を動かすわけにもいかないため、結果的に検証が必要な点を下流に持ち越してしまい、後から問題が発覚することで手戻りが増えがちでした。

モデルベース開発（MBD）ではシミュレーションで「自車が時速△キロで走行しており、△メートル後方に時速△キロの車がいる」といった細かな想定を行い、実車を使わずに膨大なテストを完了することができます。

そのため課題を下流に持ち越さず、手戻りを圧倒的に減らすことができるわけです。

もちろん自動運転ソフトウェアの開発においても、モデルベース開発（MBD）は必須です。

システムが人間に代わって運転操作を行う自動運転では、無限にあるようなユースケースでの検証が必要になります。上流工程でそれらのユースケースをシミュレーションでテストするプロセスを踏まなければ、下流の工程で致命的な問題が発覚する可能性が高まります。

現在、自動運転ソフトウェアの開発を、大手自動車メーカーや大手サプライヤー、大手IT系企業、ベンチャー企業などが競い合うように進めています。そうした中では開発にはスピード感が求められ、手戻りはできる限り避けたいところです。

前述のとおり、自動運転システムなどを含む車載ソフトウェアの開発現場にとって、手戻りは命取りです。そのため、今すぐにでも開発手法をモデルベース開発（MBD）に移行した方がいいものの、既存の開発環境からの移行は簡単ではなく、モデルベース開発（MBD）に関する専門知識も求められます。

日立ソリューションズはそのような課題を解決し、モデルベース開発（MBD）へのスムーズな移行をサポートすることで、手戻りが起きるリスクをいち早く最小化することに貢献しています。

日立ソリューションズはクルマの各部品の開発にも手広く携わっており、その知見をもとに、顧客と伴走しながら課題を素早く抽出し、必要であれば実際に手を動かすエンジニアリング面まで、全面的なワンストップサポートを提供します。

先進モビリティの開発において、高い安全性を担保しながら、コスト削減やブランド価値の毀損を防止するためには、モデルベース開発（MBD）の導入が必須です。しかし、現場ではモデルベース開発（MBD）の導入がそこまで進んでいない現状もあります。それは一体なぜなのでしょうか。

次の記事ではなぜ企業がモデルベース開発（MBD）に躊躇してしまうのかについて、説明していきます。