モデルベース開発に価値はあるのか？
無理なモデルベース開発の押し付けは「百害あって一利なし」
「モデルベース開発って本当に良いものなの？」
「モデルベース開発を目指すべきなのかな？」
と聞かれることが結構あります。
また「あえてモデルベース開発をせずに、今までどおりに仕事していたらよいのでは？」という意見も聞くことがあります。
私の考えとしては、モデルベース開発は良いものだと思いますが、なんでもかんでもモデルベース開発を目指す必要はないとも思っています。合うものもあれば、合わないものもあるからです。「もの」と言ったのは「対象」として合わない「もの（物）」、「実施者」として合わない「もの（者）」など、さまざまな理由で合う合わないがあるからです。
合わない「もの」が「人」の場合には、その人の努力が足りないなどと言われることもありますが、私は一概にそうとも言えないと思っています。現状のやり方（モデルベース開発以外の方法）の方が、その人にとっては効率的で品質が良いものを作れる場合もあるからです。いわゆる「匠」の場合ですね。そういった「匠」に対して無理にモデルベース開発を押し付けるのはナンセンスだと私は思います。そんなことをしても決して良い結果、効率化も高品質化もできないと思うからです。それぞれの人が今出せる最大のパフォーマンスを維持できるようにする方が会社にとって最善のことだと思っています。もしもモデルベース開発が本当に唯一無二の手法であれば、どんな「巨匠」であってもいつかは受け入れてくれることでしょう。それは言葉ではなく行動や結果で見せるとよいでしょうね。「巨匠」の作品を超える成果（高効率と高品質）を出せばよいのです。それができないうちは「巨匠」たちにモデルベース開発が良い、モデルベース開発に切り替えるべきなど言える理由がないのです。無理にモデルベース開発をさせても「百害あって一利なし」だと私は思っています。
また、「匠」以外に対しても同じことが言えます。強制的にモデルベース開発を推進するのではなく、今の仕事を一生懸命に試行錯誤した結果、実はその改善こそがモデルベース開発でしたという方が理想的です。モデルベース開発という枠をはめるのではなく、自分の仕事と向き合って改善した結果がモデルベース開発という枠組みに入っていたというのが理想的だと思うのです。
他人のやっているモデルベース開発を参考にすることはとても価値があります。その人が苦労して乗り越えたことを真似ることで失敗せずにクリアできる場合もあるからです。シンプルな対象であればかなり効果的な方法だと思います。しかし、みなさんが対象している開発は、きっとかなり複雑なものだと思いますから、単純に同じ適用の仕方は通用しないと思います。一見すると同じように適用できているように見えますが、「あまり効果が感じられない」「返って手間が増えたような気がする」などという嬉しくないボヤキが微かに聞こえてきます。無理に他人のやったモデルベース開発の枠に自分たちのやっていたことを押し込んだ弊害が出てしまったのだと思います。自分たちの開発に合うようにアレンジしなければメリットよりもデメリットの方が多い場合が結構あります。できれば自分たちの課題を整理し、モデルベース開発のメリットとデメリットを照らし合わせて、課題解決にマッチするかどうかを判断した上で、自分たちの開発へとモデルベース開発を適用するとよいでしょう。自分たちの課題とモデルベース開発のメリットがマッチしていなければ、当たり前ですがまったく改善することはないのです。
私とモデルベース開発
私自身の経験をお話ししたいと思います。私がモデルベース開発をはじめてしたのは、私自身が開発でやっていたことがモデルベース開発であると自分で認識する前のことです。要するに自分のやっているスタイルがモデルベース開発だと知らずにモデルベース開発をしていたということです。
当時すでにモデルベース開発なるものは世の中にあったので単純に私のアンテナ（情報収集能力）が低かっただけなんですけどね、、、、、
当時の私の置かれている状況は、開発対象の機械が容易に使える状況になかった上に、開発期間があまり長くなかったこともあって、早めに制御対象がどんな動きをするかを知って、前倒しできることはできるだけ前倒しで検討をしたかったという経緯があります。そのため実物がない状況でも制御対象の検討をするために、制御対象のプラントモデルをMATLAB/Simulinkというツールで作ってみたのです。
当時はプラントモデルを作るために必要な情報はあまりありませんでした。図面から読み取れる情報や、機器のスペック表から読み取れる部分的な情報、一般的な特性傾向などを使って機器の特性を推定したりしました。それでモデルを作ってみて、プラントのデータ、と言っても過去に計測できていたザックリとしたポイント、ポイントのデータと照合してみて、それなりの傾向が合っているかを確認し、推定した計算ロジックやパラメータの再検討を繰り返し、結構苦労したことを記憶しています。こう書くと計測データに無理に絵合わせをしたように誤解されるかもしれませんが、ズレが大きかったところは「なぜ」ずれが大きく生じたのか？を検討して、考慮しなければならない特性が抜けていたとか、バラツキというか環境要因によって大きく変化するパラメータがあったとか、気付きのポイントを明確にすること、そしてそれらが変化しても安定的に制御対象が期待する動きをするように制御できるように創意工夫をしたのです。したがって「よくわからないけど何かしらのパラメータをいじったら実際と一致した。なんで一致したかわからないけど、、、」みたいな絵合わせをしたわけではないのです。当たり前ですが、よくわからないのにシミュレーション結果を合わせても、適切に制御なんてできませんよね。
作ったモデルをシミュレーションすることで、いろいろな課題も見えてきました。ここでは具体的に書くことはできませんが、あれも改善しないとならないし、これも誤検出してしまうかもしれないなど、いろいろなことが見えてきたことを思い出します。
理屈を考えてモデルを作ったからこそ、作ったモデルから理屈を逆推定して、推定原因を解決する方法が思いつけるのだと思います。そして解決策をモデル化して、うまく解決できそうか？シミュレーションして確認するのです。
もう一度言いますが、この時点でモデルベース開発という言葉を私は知りませんでした。ただ、普通に仕事をしていただけなのです。それが偶々モデルベース開発という枠組みの中にあっただけだったのです。
さまざまなモデルベース開発
モデルベース開発と言ってもさまざまな適用方法がありますし、人によって解釈が違っていたります。解釈が違うと解釈が違う人と話をしていて話の内容の理解が変わってしまうので、あまり嬉しいことではありませんが、正味なところ各人がそれぞれの目的を期待通りに達成できているのならば「モデルベース開発の定義などどうでもよいかも」と若干思うこともありますが、他の人と話していて「あ〜この人はこういう定義でモデルベース開発と言っているのだな」と相手の話を理解するためにも、さまざまなモデルベース開発の解釈について知っておく価値があるかもしれません。
私が考える「モデルベース開発」とは
モデルベース開発は、開発、特に設計行為においてモデル化（抽象化）という概念を使って論理的に設計・開発することだと思っています。設計対象（制御対象）の設計目標の挙動や状態へ設計（コントロール）するために重要な特徴量は何かを試行錯誤しながら見つけ、１つであれば入力との関係、複数あればさらに特徴量間の関係を明らかにすることがモデル化だと思うのです。こうしたちゃんと中身を理解したモデル化を行なっておけば、そのモデルを使って期待する挙動をさせるためには、どのような設計をすればよいか見通しがよく検討ができると思うからです。
私のモデルベース開発の解釈は上記のとおりですが、その他の解釈についてもご紹介したいと思います。
これまでに「モデルベース開発」であると聞いたことがある解釈３選
シミュレーション、オートコード、自動検証の３つのどれかをしていることをモデルベース開発と言っていることを聞いたことがあります。もっとユニークな定義の人もいましたが、今回はこれまでに聞いたベスト３に限定して述べたいと思います。それぞれはとても価値のあることだと思いますが、モデルベース開発のモデル化による副次的なご利益であって、それ自体だけをモデルベース開発というのは、ちょっと違うような気がします。モデルベース開発は、開発、特に設計行為においてモデル化（抽象化）という概念を使って論理的に設計をすることだと思うからです。モデル化によって様々なご利益を得られるようになるのですが、この根本を無視してモデル化だけして副次的なメリットばかりに目を向けると後段で説明するGIGO「ゴミを入れてもゴミしか出てこない」ことになると思うからです。
とは言え、シミュレーション、オートコード、自動検証は価値のあることなので、それぞれについてもう少し見ていきましょう。
シミュレーション
制御対象や制御器をモデル化することによって、シミュレーションすることができるようにもなります。モデルを使ってシミュレーションをすることで実際にモノがない状態でも制御の評価をコンピュータ上で可能になったり、現実世界で実施しにくい条件（劣悪な環境条件や危険な条件など）でも安全かつ容易に評価をすることができるようになります。
世の中にはシミュレーションすることをモデルベース開発と言っている人もいますが、それではモデルベース開発という言葉が生まれる以前からシミュレーションという言葉やCAE(Computer Aided Engineering)という言葉がありましたから、あえてモデルベース開発という必要はなく「開発でシミュレーションした」とか「開発でCAEを活用した」と言えば済む話です。モデルベース開発ではモデル化に意義があるのであって、シミュレーションはモデル化したことによる副次的なご利益だと私は思います。
オートコード
MATLAB/Simulinkなどのモデル化ツールで作成した制御モデルから自動でECU(Electronic Control Unit)への組み込み用Cコードを生成することを言います。MATLAB/Simulinkで制御部分をモデル化することで、シミュレーションによって入出力のテストが容易にできるようになることや、プラントモデルがあれば制御の有効性評価をバーチャルで行えるメリットがあります。制御機能をシミュレーションによって十分に評価してから組み込み用コードを生成するので実物でテストをしてからの不具合をかなり減らすことができます。オートコード自体に価値はありますが、これもまたモデル化したことの副次的なご利益であって、オートコード自体をしていればモデルベース開発という認識は適切とは言えないでしょうね。
自動検査
モデル化されていると網羅的な検証をコンピュータに任せることも可能になります。まぁ網羅検証用のツールが必要にはなりますが、モデル化しているとかなり簡単に検証ができるようになってきています。また、カバレッジ（網羅率）を測定することでテストが十分になされているかも確認することができます。さらに、コンピュータによってテストができるようになったことで同じ入力を与えてリグレッションテストをすることで変更差分の影響を定量的に評価できるようにもなってきています。制御をモデル化することによってテストの前倒し化（フロントローディング）や、コンピュータを使った自動化を進めるのに一役買っていると言えるでしょう。これもオートコードと同様に自動検査自体はとても価値があることなのですが、これもまたモデル化したことの副次的なご利益であって、自動検査をモデルを使ってやっているからと言ってモデルベース開発という認識は適切とは言えないでしょう。もう少し噛み砕いて言うと、自動化をするためにモデル化することはモデルベース開発と言う（カテゴライズする）のは少し違うということです。自動検証自体や自動検証をするためにモデル化するということは何ら問題はありません。それは自動検証を目的としたものであってモデルベース開発ではないと言っているだけです。あえて言うならばモデルベーステストというなら適切な言い方かもしれませんね。
ゴミを入れてもゴミしか出てこない（GIGO）
GIGO(Garbage In, Garbage Out)をいう言葉があります。これはゴミを入れてもゴミしか出てこないという意味で、モデルベース開発において気をつけないといけないことの１つであると思います。
インプットである要求仕様が不十分であったり、不適切であったりすると、当たり前のことですが最終的に作られるソフトもよろしくないということです。いくらモデルベース開発で自動検証をしようとも、網羅検証をしようともダメなのが正しく作られるだけですね。それは望ましくないことであり、あまりにも残念なことだと私は思います。
だからこそ最上流のインプットである要求仕様の適切さが重要とされ、要求開発が注目されてきているのです。自動車業界でMBDを推進する組織であるJMAABでも要求開発を重要視して活動されていました。これまでに大きく2回ほど要求開発をテーマに活動が立ち上がって、共に数年間活動されている実績があります。
モデルベース開発は、上流での成果物が下流のインプットとなるため、上流での失敗が下流での作業のやり直しを増やしてしまう場合があります。下流側で見つけられるものならば、その時点で上流へとフィードバックしてさらに下流への流出を防止することができるでしょうが、視点が異なる要素の場合、下流では見つけることができず、ダメなものがドンドン下流に流されてしまうことになります。例えば、要求開発で市場要求を不適切に捉えたり、要求から設定した仕様が不適切であったりすると、その要求仕様をインプットとして機能設計を行う側としては気付きようがありません。たとえ不適切かもしれませんが、それが正しいという前提で、その仕様を満足させる具体的なシステムの機能を設計するのですから気づきようがないのです。
また、機能設計で作られた機能からソフトを作るソフト設計段階においても同様のことが言えます。その機能のインプットとアウトプットになるようにソフトを作るわけですから、当然ながら依頼された機能自体は正しいという前提でソフトを設計します。そして依頼された機能の振る舞いのとおりに動くようにソフトの検証も行われるからです。
そもそもの要求が不適切であると、モデルベース開発のプロセスがいかに優れたものであっても、その不適切なものを正しく作っていってしまうという残念なことが起きるのです。まさにゴミを入れても、ゴミしか出ないことになるのです。
まとめ
残念ながらモデルベース開発自体はよいものを作ることはできません。作るのは開発者や設計者なのです。もしかしたら近い将来はAIが作るかもしれませんが、もうしばらくの間はやはり良い製品を生み出すのは人間だと思います。その人間が目的を達成するために何をしたらよいのか？最適なのか？効率的なのか？よく考えた結果、やったことがたまたまモデルベース開発だったならば、素晴らしいモデルベース開発になることでしょう。
しかし、どこかの誰かのやったモデルベース開発をちゃんと理解せずに、なぞっただけではあなたの目的を達成できるとは限らないのです。モデルベース開発をしようとする気持ちの方向は同じであっても具体的な施策はその人によって、そして設計対象によって、あなたやあなたの所属する組織の置かれている状況やリソース、過去からの経緯などによって変わるのです。ですから、誰かがやって成果を出したモデルベース開発を参考にすることはよいことではありますが、自分の目的、なすべきことをよく考えて、それをどのようにすれば改善できるのか？それをモデルベース開発在りきという考えではなく、まっさらな考えで検討をするとよいでしょう。そうしないとモデルベース開発っぽいことをしているだけで、何も効果を産まないことを続けることになってしまうかもしれません。
この記事が気に入ったらサポートをしてみませんか？