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

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

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

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

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

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

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

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

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

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

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

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