目次

複雑化する製品開発において、設計・検証・改良のサイクルを効率化する手法として注目されているのが「モデルベース開発（MBD）」です。特に自動車業界をはじめとする製造業では、従来の開発手法と比べて、開発期間の短縮や不具合の早期発見、コスト削減など多くのメリットをもたらすことから導入が進んでいます。一方で、シミュレーションと現実のギャップ、初期導入の難しさ、人材育成の課題なども存在します。

本記事では、モデルベース開発の定義や目的、従来の開発手法との違い、導入によるメリット・デメリット、さらには車載領域での活用事例や導入成功のためのポイントまでをわかりやすく解説します。MBDの導入を検討している企業の方は、ぜひ参考にしてください。

H2. モデルベース開発とは？定義や目的をわかりやすく解説

製造業における開発手法は、技術の進歩とともに大きく変化しています。特に自動車業界では、システムの複雑化や開発期間の短縮要求に対応するために、新しい開発アプローチが求められています。

そこで注目されているのが、コンピューター上でのシミュレーションを活用したモデルベース開発です。従来の紙ベースの仕様書に代わり、実行可能なモデルを中核とした開発手法により、効率的かつ高品質な製品開発が可能になります。

H3. モデルベース開発（MBD）とは？

モデルベース開発（MBD：Model Based Development）とは、設計工程でコンピューター上に作成する「モデル」を用いて、シミュレーション検証を行いながら開発を進める手法です。

従来の開発では紙の仕様書を基に設計していましたが、MBDではコンピューター上で動作するモデルが「実行可能な仕様書」となります。この手法により、実機製作前の段階で機能や性能を検証でき、開発プロセス全体の効率化を実現できます。

広義のモデルベース開発は、製品の形状をシミュレーションする3D-CAEも含まれますが、この記事では狭義の制御系開発におけるモデルベース開発について説明します。

H3. モデルベース開発のモデルとは？

モデルベース開発におけるモデルとは、開発対象となるシステムや制御機能をコンピューター上で数式やブロック図により表現したものです。このモデルは単なる設計図ではなく、実際に動作させることができる「動く仕様書」としての機能を持ちます。

たとえば、自動車開発では、エンジン制御システムやブレーキシステムの挙動をモデル化し、シミュレーション環境で動作確認を行います。モデルは視覚的に理解しやすく、関係者間での情報共有も効率的に行えます。

H3. モデルベース開発の目的

モデルベース開発の主な目的は、開発期間の短縮と品質向上の同時実現です。従来の開発では実機完成後に初めて総合的な検証が可能でしたが、MBDでは設計段階からシミュレーションによる検証を行えます。これにより、開発後期での大幅な設計変更や手戻りを防げます。

また、コンピューター上での検証により、実機では困難な極限状態でのテストも安全に実施できます。さらに、モデルの再利用により、類似製品の開発効率も大幅に向上します。

H3. モデルベース開発の特徴

モデルベース開発の最大の特徴は、実機を用いずにコンピューター上でシステム全体の挙動を検証できることです。モデルは実際の物理現象を数学的に表現するため、現実に近い精度での検証が可能になります。

また、MATLAB/Simulinkなどの専用ツールを使用することで、モデルから自動的にプログラムコードを生成できます。これにより、手作業によるコーディングエラーを削減し、開発品質の向上を図れます。さらに、モデルは視覚的で理解しやすく、開発チーム間のコミュニケーション促進にも貢献します。

H3. モデルベース開発の必要性

現代の製造業では、製品の高機能化や複雑化が急速に進んでおり、従来の開発手法では対応が困難になっています。特に自動車業界では、電動化や自動運転技術の導入により、システムの複雑さが飛躍的に増大しています。このような状況下で、試作を繰り返す従来の開発手法では、時間とコストが膨大になってしまいます。

MBDは、こうした課題を解決する有効な手段として位置づけられており、今後の製品開発において必要不可欠な技術となっています。また、市場競争の激化により短期間での製品投入が求められる中、MBDによる開発効率化は企業の競争力向上に直結します。

H2. モデルベース開発のメリット

モデルベース開発を導入することで、企業は多くの具体的な効果を得られます。経済産業省が公表している実際に導入した企業へのアンケートやヒアリング調査では、開発効率の向上だけでなく、組織全体の業務改善につながる効果も確認されています。

モデルベース開発の主なメリットとしては、以下が挙げられます。

  • 開発コストを削減できる
  • 開発期間を短期化できる
  • 不具合を減少できる
  • 製品（サービス）の質を向上できる
  • コミュニケーションを活性化できる
  • 企画提案力を向上できる

これらのメリットを詳しく見ていくことで、モデルベース開発導入の価値を具体的に理解できるでしょう。

参考：経済産業省│MBD／CAE等の導入・活用の手引き・事例集（概要版）

H3. 開発コストを削減できる

モデルベース開発により、試作製作や検証にかかる費用を大幅に削減できます。従来の開発では実機での検証が必要でしたが、シミュレーションによる検証に置き換えることで物理的な試作回数を減らせます。特に自動車分野では、高速走行や急ハンドル、急ブレーキ、衝突試験などの危険な走行試験項目を仮想空間で実施でき、試作実機を作らずに済むため、開発コストの削減に大きく貢献します。

実際の導入事例では、製品によって異なりますが、中には1製品で年間1千万円弱のコスト削減効果を実現した企業もあります。また、解析を外注することによる開発期間短縮も、間接的なコスト削減効果をもたらしています。

H3. 開発期間を短期化できる

シミュレーションによる検証により、開発期間の大幅な短縮が可能です。従来の手法では試作品完成後に初めて性能評価ができましたが、モデルベース開発では設計段階から並行して検証を進められるフロントローディング（試験の前倒し化）により、問題の早期発見と解決が実現できます。実際の導入企業では、トライ時間を40％削減した事例もあります。

さらに、開発効率の向上が働き方改善にもつながっています。このような時間短縮効果により、市場投入スピードの向上も期待できます。

H3. 不具合を減少できる

モデルベース開発は、設計工程でシミュレーションを行うことにより、高精度な設計を不具合を発生させることなく進めることができます。

また、不備が発生しうる箇所の予測精度も向上します。シミュレーション技術により、極限状態や故障状態での挙動も安全に確認できるため、従来の検証方法では見つけられなかった潜在的な不具合も発見できます。

H3. 製品（サービス）の質を向上できる

シミュレーションによる業務効率化により、製品やサービスの品質向上に大きな効果をもたらします。コンピューター上での詳細な検証により、設計品質そのものが向上します。

また、現実での実験が困難な解析も可能になるため、これまで検証できなかった領域での品質確認も実現できます。複数の設計案を短時間で比較検討できることから、最適な設計選択も可能になり、結果として製品全体の性能向上につながります。

H3. コミュニケーションを活性化できる

多くの企業で挙げられたモデルベース開発の副次効果として、コミュニケーションの活性化があります。従来の文字ベースの仕様書とは異なり、モデルは直感的にイメージしやすい解析結果を提供するため、関係者間での理解が深まります。

技術的な内容を視覚的に表現できることで、異なる部門間での情報共有も円滑になります。また、設計意図や動作原理を明確に伝えられるため、開発チーム全体での認識統一も図りやすくなります。

H3. 企画提案力を向上できる

モデルベース開発の習得により、企業の企画提案力が大幅に向上します。特に自動車業界では、自動車メーカーと同じ土俵に立って提案するための必須の技術として位置づけられています。シミュレーション結果を用いた具体的な性能予測や改善提案により、顧客に対してより説得力のある提案が可能になります。

また、設計段階での詳細な検証結果を示すことで、提案内容の信頼性も高められます。これにより、競合他社との差別化も図れます。

H2. モデルベース開発のデメリット

モデルベース開発には多くのメリットがある一方で、導入や運用において解決すべき課題として、以下が挙げられます。

  • シミュレーションと現実の結果の齟齬が課題
  • 費用対効果の算出が課題
  • 人材の確保・育成が課題

こられ各課題の詳細と対策を把握することで、モデルベース開発導入時のリスクを最小限に抑えられるでしょう。

H3. シミュレーションと現実の結果の差異が課題

モデルベース開発において最も重要な課題が、シミュレーション結果と実際の現実との間に生じる差異です。この問題の主な原因として、照合データの不足が挙げられます。解析結果の検証を繰り返し、シミュレーションの精度を高めていくとともに、現実でのふるまいをどこまでシミュレーションで表現するかの取捨選択を行う必要もあります。

また、ソフトウェアの機能不足も考えられ、特に自社製品が特殊な工程を含む場合、この問題が生じる可能性は高まります。対策として、解析だけでなく解析結果の照合も作業工程に組み込んでシステム化することが重要になります。

H3. 費用対効果の算出が課題

モデルベース開発の導入効果を数値化することは、経営判断において重要な要素となりますが、その算出方法が課題となっています。短期的には、モデルベース開発環境の立ち上げに伴う初期投資が発生します。特に物理現象のモデル化に必要な評価作業や、実測とシミュレーション結果の差異検証などに相当な開発費が必要となるため、導入初期は投資が先行する状況になります。

ヒアリング調査では、各社において共通する方法として、製品の製造工程においてモデルベース開発によってどの程度のコストを削減できるか予測し、「製品数×省略できるコスト」で算出しているとの声が多く聞かれました。

しかし、この算出方法では初期投資の回収期間や品質向上、開発期間の短縮といった間接的な効果さらには長期的な競争力向上などを正確に評価することが困難な場合もあり、より精緻な評価手法の確立が求められています。

H3. 人材の確保・育成が課題

モデルベース開発を活用するためには、ある程度のプログラミングの知識が求められるため、コンピューターの知見をもった人材の確保が重要となります。新卒採用であれば、MATLAB/Simulinkのような1Dモデルの知識やCAD/CAMを学んでいる学生などが対象として挙げられています。

人材育成においては、マニュアル整備やOJTでの教育が主流となっていますが、解析は現実の結果との照合が重要になるため、現場と連携できる社内体制の整備も必要です。専門性の高い技術であることから、人材育成には時間と費用がかかることを認識しておく必要があります。

H2. モデルベース開発と従来の開発の違い

製造業における開発手法は、技術革新とともに大きく変化しています。従来の紙ベースの開発手法から、コンピューター上でのシミュレーションを活用した開発手法への転換が進んでおり、その違いを理解することが導入成功の第一歩となります。

H3. モデルベース開発と従来の開発の違い

従来の開発手法では、自動車のコンセプトから紙ベースの仕様書をもとに各担当者が作業を進め、試作機を作成して組み立てた後、統合テストで仕様書通りに正常に稼働するかを検証していました。テストを繰り返してエラーをつぶす作業が必要で、手戻りが頻繁に発生していました。

一方、モデルベース開発では、PC上で「動く」車両を設計し、走行シミュレーションを実行できます。オフィスで車両評価まで行えるため、実機製作前の段階で設計検証が可能になり、大幅な効率化を実現できます。

H3.MBDによるsuriawase1.0からsuriawase2.0へ

日本の製造業は長年にわたり、試作品を作成し、それを巧みに合わせこむことで高品質な製品を生み出してきました。この「すり合わせ開発」と呼ばれる手法は、日本の製造業の大きな強みとなっています。

しかし、すり合わせ開発を実現するためには、巧みな技を持つ技術者と十分なすり合わせ時間が必要でした。現在、世界との競争が激化する中で、開発量の増大、高スキル技術者の不足、開発期間の短縮要求といった課題に直面しており、このままでは日本の製造業が培ってきた強みが失われてしまう危険性があります。

そこで注目されているのがモデルベース開発の活用です。モデルベース開発を導入することで、日本が得意とするすり合わせ開発をバーチャル空間で実現し、日本品質を保ちながらリソースと開発期間の課題をクリアしようという取り組みが進められています。この新しいアプローチがSURIAWASE2.0です。

なぜ2.0と呼ぶのかというと、従来の「すり合わせ開発」を第一世代の1.0と位置づけ、モデルベース開発を活用した新たな取り組みを第二世代の2.0と名付けたことに由来します。経済産業省も、自動車産業におけるバーチャルシミュレーションを活用したモデルベース開発により、このSURIAWASE2.0を深化させる方針を示しており、サプライチェーン全体でのMBD活用による効率的な開発体制の構築が期待されています。

H2. 車載・自動車におけるモデルベース開発の具体例

自動車業界では、モデルベース開発がさまざまな領域で実際に導入され、具体的な成果を上げています。自動車/自動運転分野、パワートレイン分野、シャシー分野、その他の分野で幅広く活用されており、エンジンやトランスミッションといった基本的なパワートレインから、最新の電動化技術、燃費改善、熱管理、運動性能、振動制御まで、多岐にわたる開発領域でMBDによる効率的な開発が進められています。

これらの具体的な適用例を通じて、モデルベース開発がどのように実践されているかを理解することで、導入検討の参考になるでしょう

H3. エンジンのモデルベース開発の例

エンジン開発においてモデルベース開発は、燃焼特性や制御システムの最適化に活用されています。従来の実機テストでは時間とコストがかかる燃焼解析を、コンピューター上のモデルで効率的に実施できます。エンジンの電子的タイミング制御など、複雑な制御アルゴリズムの開発では、シミュレーションにより多数の運転条件下での性能を検証可能です。

実際の開発現場では、エンジン回転数や負荷条件を変化させたモデルベースキャリブレーションにより、最適な制御パラメータを短期間で決定できるようになっています。

H3. トランスミッションのモデルベース開発の例

トランスミッション開発では、シフト制御の最適化にモデルベース開発が効果的に使われています。AT（オートマチックトランスミッション）、MT（マニュアルトランスミッション）、CVT（無段変速機）など、各種トランスミッションの制御ロジックをモデル化することで、実機製作前の段階で制御性能を評価できます。

変速タイミングや変速ショックの軽減、燃費向上のための最適制御など、複雑な制御要求に対してシミュレーションベースでの検証が可能になります。開発現場では、車両モデルと組み合わせた統合検証により、実車に近い条件での評価を実現しています。

H3. 電動化のモデルベース開発の例

電動化技術においてモデルベース開発は、HEV（ハイブリッド車）やBEV（電気自動車）の制御システム開発に広く活用されています。高圧電池の管理システムや、エンジンとモーターの協調制御、エネルギーマネジメントシステムなど、電動化特有の複雑な制御をモデル化して検証を行います。

特にエネルギー効率の最適化では、バッテリーの充放電特性やモーター効率をモデル化し、さまざまな走行パターンでのエネルギー消費を予測することで、実機テスト前に制御戦略を決定できます。電動化システムの安全性確保においても、モデルベースでの故障モード解析が重要な役割を果たしています。

H3. 燃費のモデルベース開発の例

燃費改善のためのモデルベース開発では、エンジン効率、トランスミッション効率、車両の空気抵抗など、燃費に影響するすべての要素をモデル化して総合的に最適化を図ります。実際の開発現場では、さまざまな走行パターンでの燃料消費をシミュレーションし、最適な制御マップを作成しています。

パワートレイン全体の統合制御により、エンジン、トランスミッション、補機類の協調動作を最適化することで、実機での検証前に大幅な燃費改善効果を予測できます。モデルベースキャリブレーションにより、従来の実車テストでは困難だった細かな制御パラメータの調整も効率的に実施されています。

H3. 熱のモデルベース開発の例

自動車の熱管理システムにおいてモデルベース開発は、エンジン冷却、車室内空調、電動化システムの温度管理など、幅広い分野で活用されています。エンジンの燃焼熱や摩擦熱、電動システムでの発熱をモデル化し、冷却システムの性能や制御戦略を最適化します。

特に電動車両では、バッテリーやインバーターの熱管理が性能と安全性に直結するため、温度予測モデルによる制御システムの事前検証が不可欠です。実際の開発では、外気温度や走行条件の変化に対応した熱管理制御を、シミュレーションにより効率的に開発しています。

H3. 運動性能のモデルベース開発の例

車両の運動性能開発では、操縦安定性、乗り心地、制動性能などの向上にモデルベース開発が活用されています。サスペンション特性、ステアリング特性、ブレーキ制御などをモデル化し、さまざまな走行条件での車両挙動を予測します。

シャシー統合制御システムでは、複数の制御システムが協調して車両の運動性能を最適化するため、モデルベースでの統合検証が重要になります。実際の開発現場では、車両モデルを使用してタイヤ特性やシャシー剛性の影響を解析し、目標とする運動性能を実現するための設計パラメータを効率的に決定しています。

H3. 車両振動のモデルベース開発の例

車両振動の制御においてモデルベース開発は、乗り心地向上とNVH（騒音・振動・ハーシュネス）性能の改善に重要な役割を果たしています。エンジン振動、路面からの振動、風切り音など、さまざまな振動源をモデル化し、車体構造や制振システムの設計に活用されています。

アクティブサスペンションやエンジンマウントの制御では、振動伝達特性をモデル化して最適な制御アルゴリズムを開発します。実際の開発現場では、モデルベースでの振動解析により、実車テスト前に振動レベルの予測と対策効果の検証を行い、開発期間の短縮と品質向上を同時に実現しています。

H3. モデルベース開発手法のシステム検証への適用の例

ADASシステムの検証にモデルベース開発手法を適用した一例として超音波センサのモデル化の事例を紹介します。ここでは従来の実車評価では困難だった多様なユースケースの検証を効率化するため、音波シミュレーション結果を分析してセンサモデルを構築します。

このモデルは受波強度の時間波形を忠実に再現し、ポール、壁、縁石などの対象物種別に対応した物標検出を可能にしています。MILS（Model In the Loop Simulation）環境での自動ブレーキ機能評価では、車速条件や対象物を変更した停止距離評価を実施し、実車構築前の早期段階での課題解決を実現しました。

H2. モデルベース開発の工程「開発の流れとシミュレーション手法」

モデルベース開発では、開発段階に応じてさまざまなシミュレーション手法が用いられます。設計初期段階から実機テストまで、各工程で最適な検証環境を構築することで、効率的な開発プロセスを実現できます。

ここでは、代表的な5つの手法の特徴と適用場面、そしてシステム検証にモデルベース開発手法を適用した事例を紹介します。

H3. MILS

MILS（Model In the Loop Simulation）とは、制御対象の制御装置をモデル化し、制御対象モデルと組み合わせてシミュレーションを実施する手法です。制御処理をコンピューター上でシミュレーションさせて動作検証を行うことで、仕様検討、設計、要求分析、基本設計といった開発序盤の設計段階で仕様の精度を高めます。

コンピューター上で制御システムの動作検証を行うため、試作機で検証する際に発生する物理的な破損の心配はありません。極端な条件設定や大胆な設計変更をした場合の動作検証が可能で、設計段階で仕様の不備を見つけることができるため、後工程での手戻りによる開発工数増加を防止できます。

H3. SILS

SILS（Software In the Loop Simulation）とは、制御対象をモデル化し、実際のECUソフトウェアと組み合わせてシミュレーションを実施する手法です。MILSで検証したモデルから生成された実装コードを、制御対象モデルと接続して動作検証を行うことで、実装レベルでの制御性能を確認できます。

MILSとHILSの中間的な位置づけにあり、実装コードの動作を制御対象モデルで検証することで、コード生成時の問題や実装固有の課題を早期に発見できます。実際のECUハードウェアを使用しないため、HILSよりも環境構築が容易で、デバッグ作業も効率的に行えます。ソフトウェア開発段階での品質向上と、HILSでの検証前の事前確認として重要な役割を果たします。

H3. HILS

HILS（Hardware In the Loop Simulation）とは、制御装置であるECUと制御対象を模擬したHILS装置で構成した、ECUソフトウェアを評価する環境です。ECUの接続先を実機（センサーやアクチュエータ）に代わりHILS装置に接続し、HILS装置をプラントモデルで制御することで制御対象の動きをシミュレーションできます。

実機（センサー、アクチュエータ）がない環境でもECUソフトウェアの試験を行う環境を提供し、MILSでは検証できないECU回路やIO信号ノイズ等による影響を含めた実機に近い環境でECUをテストします。実機が完成する前にHILSでECUをテストできるため、テストの遅延を防止でき、実機ではテストが難しい極限状態や故障状態での検証も安全かつ実機に近い環境で実施可能です。

H3. RCP

RCP（Rapid Control Prototyping）とは、汎用の制御対象（ハードウェア）に制御モデルをつなぎ、制御設計の最適化を行う方法です。

MILSによる制御対象モデルが想定した通りに作られているかを検証したい場合や、実機プラントが複雑でモデル化が困難な場合などに用いられます。制御モデルを汎用の制御装置（ECU）に搭載し、実機プラント（制御対象）につなげることによって、通信によって発生する遅延を取り入れながら制御モデルの動作検証を行うことが可能となります。

モデルを用いたシミュレーションだけでは確認が難しい項目についてチェックが行えることから、必要となる機能を早期の段階で見極められるようになります。

H3. ACG

ACG（Automatic Code Generation）とは、モデルからコードを自動生成することで、ソフトウェア作成工程にて用いられる手法です。MILSで検証されたモデルからECUに搭載可能なコードを生成し、製品への実装やSILSへの検証に使用することが出来ます。人手に頼らずコードを自動作成できることが大きなメリットですが、モデルの記述によってはこちらの意図しないコードが自動生成されてしまうこともあり、細部を調整しながら活用する必要があります。

設計段階でモデルを用いた検証を十分に行った後、そのモデルから直接実装コードを生成することで、手作業によるコーディングエラーを削減し、開発品質の向上を図れます。モデルとコードの一貫性も確保され、設計意図が正確に実装に反映されるため、保守性の向上にもつながります。

H2. モデルベース開発を導入するときの成功と失敗のポイント

モデルベース開発の導入は多くのメリットをもたらしますが、適切な計画と実行がなければ期待した効果を得られません。成功企業と失敗企業の事例を分析すると、明確な成功要因と失敗パターンが見えてきます。

以下では、MBD導入を成功に導くための重要ポイントと、避けるべき失敗要因について解説します。

H3. 導入を成功させるポイント

MBD導入を成功させるためには、戦略的なアプローチが不可欠です。単純にツールを導入するだけでなく、組織全体での取り組みとして位置づけることが重要になります。

成功している企業では、明確な目標設定と段階的な導入計画を策定し、経営層から現場まで一貫した方針で進めています。また、技術面だけでなく人材育成や組織変革にも十分なリソースを配分し、長期的な視点で取り組んでいることが特徴的です。

H4. 明確な導入目的と範囲を設定する

モデルベース開発導入の目的は企業によって異なります。作成したアルゴリズムや制御をシミュレーションによって仮想検証し品質を向上させる目的、オートコードを活用してCソースコード作成の実装工数削減と品質安定を得る目的、モデルによる上流設計の実現と抽象表現による機能把握や設計意図の共有を得る目的などがあります。

導入目的が違えば、同じ状況でも失敗だったり成功だったりします。何を求めたいのか、そのためにツールをどう使うかといった目的や目標がないと上手く適用できません。

まずは自社の課題と期待効果を明確にし、段階的な導入範囲を設定することが成功の第一歩となります。

H4. トップダウンとボトムアップを連携する

MBD導入には、経営層からの強力なサポートと現場の理解・協力の両方が必要です。マネジメントの役割は、経営に貢献できるように指針を提示することと、現場に対して働きやすい環境を提供して力を引き出すことです。

戦略を描く力として、経営方針に則った在りたい姿を定義し、プロセス・人材・技術の縦軸と時間の横軸のフレームワークを使って具体的な計画を立てる必要があります。

特に重要なのは、開発工程に応じたリソース配分の見直しです。従来は、後工程での検証・修正作業に人員を集中配置していましたが、MBD導入により前工程でのシミュレーション検証が充実すると、設計段階での工数は増加するものの、後工程での不具合対応が大幅に削減されます。この変化に対応するため、設計フェーズへの人員配置を強化するなど、全体最適の観点から開発リソースを再編成する必要があります。
一方で現場では、設計視点が上流へシフトし、検証視点の再検討が求められます。トップダウンによる推進と現場の負担軽減を両立させることで、組織全体での変革を実現できます。

H4. ツールと人材育成に投資する

モデルベース開発には専用のソフトウェアや装置等が必要で、従来の開発手法と比較すると高額であることがほとんどです。しかし、適切なツール選定と十分な人材育成投資を行うことで、長期的な効果を得られます。

モデルベース開発は従来の開発に比べてツールの利用率が高く、設計者自身がシミュレーションを行う必要があるため、設計者はツールなどを使いこなすための習熟に時間がかかります。新しいツールやプロセスの習得が必要となり、エンジニアのスキル向上が不可欠です。

また、マネジメント層こそデジタルに対するリスキリングが求められており、デジタル技術について十分に理解し効果的に活用するためのスキルが必要になります。

H3. 導入時に注意すべき失敗ポイント

MBD導入の失敗には共通するパターンがあります。多くの企業が陥りがちな問題点を理解し、事前に対策を講じることで失敗リスクを大幅に軽減できます。失敗する企業では、目的の不明確さ、組織間の連携不足、技術的な準備不足などの問題が複合的に発生しています。

これらの失敗要因を具体的に分析し、どのような対策が必要かを明確にしておくことが重要です。

H4. 導入目的を曖昧にしない

多くのメリットを享受できるため非常に魅力的に映る開発手法ですが、日本国内においてMBDが経営に対して貢献できている企業は少ないのが現状です。その理由の多くは、MBDに対する誤った解釈にあります。シミュレーションツールを導入すれば即時効果が現れると信じている企業が多く見られます。

ツールはあくまで手段（How）であり、なぜやるのか（Why）、何をやるのか（What）、誰のためにやるのか（Who）を考えないと上手く適用できません。　

オートコード自動生成から着手する場合、オートコードのデバッグに時間を取られ、期待するCコードの品質を満たせず失敗するリスクも高くなります。MBDのメリットが現場で見えなくなってしまう状況を避けるため、導入目的を明確に設定することが不可欠です。

H4. 部門間のコミュニケーションを怠らない

MBD導入では、組織全体での協力体制が重要になります。部門間の協力が重要となるため、組織文化の変革が求められることが多い傾向があります。

たとえば、MBDのリソースを技術開発として確保できていたとしても、商品企画に繋がらない事例は多く見られます。縦割りの組織により、技術開発と商品企画が繋がらず、製品開発の着手タイミングになっても企画が不十分で手戻りや遅延する問題をよく耳にします。

この問題は、マネジメントの問題でもあり、現場の問題でもあります。開発全体を俯瞰して開発工程をどのように繋いで開発を効率化するかを描けていないことが問題の本質です。関係者のベクトルを統一するためには、目的を正しく共有・理解することが不可欠です。

H4. モデリングのルールや表記法を標準化する

MBDでは設計段階でモデルを作成しシミュレーションを行う必要があり、従来の開発工程に比べると工数が増大してしまいます。設計者の視点が上流設計にシフトしていく中で、最初はどうしても細部に視点が落ちてしまいがちです。

コードアタマから、モデルアタマへの視点変更が求められており、ツールに使われる側から、ツールを使う側への思考のシフトが必要です。

If文とSwitchとStateflowの使い分けや、折線を直線にするためのブロック配置、Go-From多用による接続線減退期など、記述黎明期から構造検討アーキテクト期まで段階的な成熟が必要になります。基準の書き方を統一し、ガイドラインの背景を理解して最適なアーキテクチャを検討できる体制を整えることが重要です。