MBSE導入に取り組み始めたものの「何から始めればいいの?」「本当に意味があるの?」と戸惑っていませんか?ここでは、執筆者が現場で経験したリアルなつまずきと、そこからどう乗り越えたかをお伝えします。

目次

最初の一歩で止まってしまう理由

MBSE導入が始まっても、途中で検討が止まってしまうケースは意外に多いです。

「モデルベース」ときくと、「効率化」や「手戻り削減」といった期待が膨らむ一方で、現場としては「何からはじめればいいのか」「どこまでやればいいのか」という戸惑いの方が大きいのではないでしょうか。

私自身、かつてMBSEを推進していた際、まさに戸惑いの渦中にいました。

経営層からは「MBSEで開発を変える」と強い期待が寄せられました。特に自動車業界では「100年に一度の変革期」と言われ、SDV(Software Defined Vehicle)にMBSEを適用することで、競争優位を築けるのではと見られていたのです。

そのため、ツールや教育にも高額な投資が行われ、「絶対に成功させなければならない」という雰囲気が現場に強いプレッシャーとなってのしかかりました。

しかし現場の実感は全く違いました。

「モデルを作った先に何があるのか?」
「どこまで作り込めば効果が出るのか?」

誰も明確な答えを持っていませんでした。

私自身、「これで本当に手戻りが減るのか?」「今やっている作業と何が変わるのか?」と自問する日々でした。

そのうち、「意味あるの?」「やる必要ある?」という声も上がり、検討は徐々に停滞していきました。推進者である自分自身が「これでいい」と言えない状態でした。

こうした状況は決して珍しくありません。

MBSE導入が最初の一歩で止まるのは、「効果が見えにくい」「ゴールが描けない」「周囲の理解が追いつかない」といった複数の要因が絡み合っているケースが多いです。

結局のところ、「描いた先に何があるのか」が見えないまま手を動かしてしまうことが多いのではないでしょうか。
私もそうでしたし、多くの現場で同じ壁にぶつかっているのを見てきました。

描いたままで終わるわけ

モデルを描くことが目的になってはいけない」——MBSEに取り組むと、よく言われます。でも、最初から明確な目的を持ってモデルを描き始められるケースは、実はそう多くありません。

私自身、「このモデルって何のために描いてるんだっけ?」と迷いながら手を動かしていた時期がありました。けれど、描くうちに気づいたのは、要求仕様に潜む曖昧さです。図にしようとした瞬間、前提の食い違いや暗黙の了解が表面化し、文章では見逃されていた曖昧さが可視化されたのです。

しかし、その曖昧さは、現場の柔軟性や調整力で支えていた部分でもあります。モデル化によりそれが消えると、かえって開発が進みにくく感じ、「使いにくい」といった反応が生まれます。これが心理的な壁になり、結果として“描いただけ“で止まる状況につながります。

また、モデルによって浮かび上がった課題の大きさです。矛盾や問題点が見えても、判断基準や議論の文化がないままでは、その先に進めません。「これは扱いきれない」と感じて、モデルの活用が中断されてしまう——そんなケースも少なくありません。

加えて、モデル作成自体が評価対象となっていたり、ツール導入が先行し、運用や理解が追いついていない現実もあります。目的が曖昧なまま描かれたモデルは、やがて“置き物”になってしまいます。

とはいえ、描いたことが無駄では思いません。あぶりだされた課題は、重要な論点への入り口です。大切なのは、そこで止まらず、それをどう使える形にしていくか。

MBSEの本質は「使うこと」にあります。でも最初は「描くことが目的」でも構わないと思います。大切なのは、そこから何が見え、それをどう次に繋げるか。その積み重ねこそが、“使えるモデル” への第一歩だと考えています。

使われるモデルにするため

あるとき、思わず口にしました。

「このモデルって、なんで描いてるんだっけ?」

似たようなダイアグラムがいくつも並び、それぞれに意味があるはずなのに、分からなくなっていました。周囲のメンバーも答えられず、議論はうやむやに終わりました。

けれど、その問いは心に残りました。昔、あるコンサルタントの方から言われた「プロセスがあるからモデルが成り立つ」という言葉を思い出し私はプロセス全体に目を向けるようになりました。開発の流れを棚卸ししながら、問い直しました。

  • レビューでは何を見ているのか?
  • どの場面で、どんな判断が求められているのか?

気づいたのは、モデルが“正しい”だけでは足りず、使われる場面と結びついていなければ意味がないということでした。
レビューや検討会議の中で実際に使われ、意志決定を支える形になって初めて価値が生まれるのです。

一方でモデルを通してプロセスの曖昧さが可視化されることもありました。

「レビューって、何をどう確認していたんだっけ?」
「誰が何をもって“良し”とするの?」

構造が見えるからこそ、曖昧な運用が浮き彫りになり、レビュー自体を再検討せざるを得ないこともありました。レビューの観点がモデル基準で考えられていないという根本的な課題にも直面しました。

戸惑いもありましたが、今思えばそうした“引っかかり”が大事だったのだと思います。

モデルは「どう作るか」ではなく、「どう使ってもらうか」から逆算して考える必要があります。

  • レビューのどの場面で、どの観点でモデルが使えるか
  • これまでExcelや口頭で済ませていた確認を、どうモデルに置き換えられるか
  • 手戻りや誤解を防ぐ粒度や表現とは?

MBSEはプロセスを整える道具であると同時に、整っていない現状を映す“鏡”にもなります。それをどう受け止めるかも導入の一つの壁だと感じました。

既存のやり方に「差し込む」

私は「すべてをモデルにする」ことを目指したのではなく、既存のやり方にどう“差し込むか”を考えながら進めてきました。一例として「要件管理」を挙げます。

要件一覧はExcelで整理され、明確だと思っていました。仕様書として展開されると文章表現に幅が出て、受け取り方に差が生じました。

  • どの範囲を想定するのか
  • 柔軟性をどこまで許すのか
  • 安全性や認証はどう扱うのか

そこで間に「モデル」を差し込み、要件を「対象」「手段」「条件」等と構造化しました。
こうすることで、レビューでも具体的な議論が可能になりました。

モデルはExcelやWordを置き換えるものではなく、その間にそっと差し込むことで解釈のズレを防ぎます。既存のやり方を壊すのではなく、頭の中に隠れていた違いを引き出してくれる──それこそが「モデルが使われてこそ価値を持つ」という実感です。

無理なく前に進むための工夫

MBSEを進めようとすると、「今のやり方を変えたくない」という現状維持の空気や、モデルが更新されず止まってしまう運用面の課題、会社特有の文化や構造に起因する状況など、さまざまな“進みにくさ”が現れてきます。

こうした課題には共通するものもあれば、その会社ならではの事情から生まれるものもあります。一つを乗り越えても、次の課題が見えてくる――そんな連続の中で、現場の負担が大きくなってしまうことも少なくありません。

だからこそ大切なのは、“社内だけで抱え込まず”、使えるリソースを無理なく活用しながら少しずつ前に進むことです。

MBSEは、壁を越えながら少しずつ根づかせていくものだからこそ、外部の力もうまく活用しながら進めていくことが効果的だと考えています。

完璧な形を一気に作ろうとせず、続けながら少しずつ浸透させる取り組みとして進めることが、結果的に定着への近道となります。

MBSEは“一気に完成させる”ものではなく、“続けながら根付かせていく”ものです。私たちはその道のりを、導入から定着まで伴走します。

MBSEを“組織の力”に変えたいとお考えの方は、ぜひお気軽にご相談ください。