MBDやシミュレータを立ち上げることは、メーカーの本質的な仕事なのか？

モデルベース開発やシミュレータ環境を
メーカー自身が苦労しながら立ち上げているケースを見かけます。

現場としては「やらなければ前に進まない」ため必死に取り組んでいるのですが、
少し俯瞰して見ると、そこに違和感を覚えることがあります。

それは、その苦労は本質的なのか？ という点です。

本来、メーカーが注力すべきなのは、魅力ある製品をどう作るか、
そして今の時代に合った開発プロセスをどう設計するかです。

モデルベース開発、HILSやシミュレータは、そのための「手段」に過ぎません。
にもかかわらず、立ち上げそのものが目的化してしまっている現場も少なくありません。

HILSの立ち上げは「非競争領域」ではないか

例えばHILSを例にして説明します。
HILSやシミュレータの構成は、多少の差はあれど、基本的にはどのメーカーでも似通っています。
使用するツールも限られており、ベンダ依存も強い領域です。

つまり、HILSを立ち上げたからといって、
それ自体が製品競争力になることはほとんどありません。差が出るのは、

どんなテストを設計しているか
何を品質として定義しているか
どこまで自動化し、どこを人が判断するか

といった“中身”の部分です。

立ち上げ作業そのものは、言ってしまえば非競争領域です。
にもかかわらず、多くの時間と人材がそこに投入されています。

習得しても資産になりにくい技術

HILSの特徴として、

一度立ち上げると5〜10年は同じものを使う
次の更新時にはツール世代が変わっている
担当者が異動・退職していることも多い

という現実があります。

つまり、HILSの立ち上げ技術は「一度覚えたらずっと使える技術」ではありません。
むしろ、次に必要になったときには再学習が必要になる技術です。

そのような技術を、メーカー側で必死に内製・維持し続けることが、
本当に合理的なのかは再考の余地があります。

小さな部署ほど内製は破綻しやすい

規模が大きい組織や会社では内製しても問題ないと思いますが、
小さな組織や数名〜十数名規模の部署では、HILS専任者を置くことは現実的ではありません。

兼務で対応する
異動でノウハウが分断される
数年後には「誰も全体を分かっていない」状態になる

結果として、「内製したはずなのにブラックボックス化したHILS」が
出来上がってしまうケースも珍しくありません。

内製＝ノウハウが残る、とは限らないのが実情です。

本来注力すべきは製品価値と開発プロセス

メーカーにとって本当に重要なのは、

どんな制御・機能を実現したいのか
どんな開発プロセスなら品質とスピードを両立できるのか
モデルベース開発をどう自社文化として根付かせるのか

といった部分です。

HILSやシミュレータは、それを支えるためのインフラに過ぎません。

インフラ構築に過度なエネルギーを使うことで、
本来注力すべき設計やプロセス設計がおろそかになるのは、本末転倒と言えます。

外部委託という合理的な分業

HILSやシミュレータの立ち上げは、それを専門に行っている外部に任せる、
という選択肢は十分に合理的です。

外注＝丸投げではありません。

設計思想はメーカーが持つ
要求・判断基準はメーカーが定義する
立ち上げ・構築は専門家が担う

この分業によって、メーカーは本来の強みである製品開発やプロセス設計に集中できます。

「外注するとブラックボックスになる？」

ブラックボックス化の原因は、内製か外注かではなく、
設計思想や判断基準が言語化されていないことにあります。
適切なレビューや説明を行えば、外注でも十分に理解可能な状態は作れます。

また、残すべきものは、配線やツール操作ではなく、テスト戦略や品質の考え方です。
企画段階で、残すものをあらかじめ定義しておけば、外注化しても問題ないです。

逆に企画段階で、曖昧にスタートするよりは、外部の支援を受けながら、
進めた方が資産が残りやすいです。

おわりに

シミュレータを立ち上げること自体が目的になった瞬間、モデルベース開発は歪み始めます。
何を作りたいのか。どんな開発プロセスを実現したいのか。

内製の場合の学習コスト、手戻り、属人化リスク、数年後の再立ち上げコストまで含めて考えると、
外注の方がトータルで安くなるケースは少なくありません。
そこに集中するために、外部を使うという選択肢があっても良いはずです。

モデルベース開発を“手段”として正しく使うために、
分業のあり方を一度立ち止まって考えてみる価値はあるのではないでしょうか。