モデル駆動開発

SESSAMEで一緒のにしさんがブログでソフトウェアの自動生成を話題にしているので、今回は自動コード生成、モデル駆動開発について考えてみたい。

ソフトウェアの自動生成といっても設計行為がいらないわけではない。実際にはUMLなどでモデルを作ってそのモデルからコードを自動に生成するという話だ。ようするにソフトウェアシステムの抽象度を一段上げようという世の中の傾向のことである。

ソフトウェアをアセンブラで書いていた時代からC言語などの高級言語で書くように時代はシフトしたので、次は言語で記述せずにモデルを記述して、モデルからC言語、C言語からアセンブラといった変換の部分をツールにやらせようという考え方だ。

その背景には、10万行を超える高級言語で書いた組込みソフトウェアは絡まり合い、収拾が付かなくなり、不具合が起こっても問題の原因を追及しきれないことが多いことにある。

手続き型の言語に慣れてしまった組込みソフトエンジニアはC++などのオブジェクト指向言語を使うことに尻込みし、また、オブジェクト指向言語を使っても従来の手続き型の言語でも試行錯誤的プログラミングをやってしまう。

そういう状況を見ていると、いっそモデルしか書けないようにして、モデルからコードへの変換のアーキテクチャの中にアーキテクトのノウハウを隠蔽してしまった方が品質が上がるんじゃないかと思うこともある。

でも、何年かまたは何十年かして、もしそういう時代がきたとしても必ずモデルからコードへの変換がどうなっているのか、今使っているモデル変換のアーキテクチャを変化させる必要がないのかを常に考る技術者が必要になる。今でもC言語とCPU、アセンブラに精通し、Cからアセンブラへ変換するコンパイラを開発しなければいけない人たちが必要なのと同じだ。

ちなみに、組込みソフトエンジニアでハードウェア寄りのソフトを書いている人たちは今でもCPUやグラフィックコントローラなどのデータブックをぼろぼろになるまで読み込む。多くのソフトエンジニアのソフトウェア記述の抽象度を上げても、誰かが抽象度の上がったモデルと下層レイヤのソフトウェアやハードウェアとの橋渡しをしなければいけない。

ソフトウェアプラットフォームがPCの場合は、モデルからコードへの変換のアーキテクチャは一般化しやすいだろうが、組込みの場合、変換アーキテクチャを一般化し、変換アーキテクチャの寿命を長持ちさせようとすると犠牲にしなければいけないことが生じる。

組込みシステムの場合、市場要求が千差万別で機能だけでなく性能要件やコストの要件などもあり、制約も多いからトレードオフが頻繁に発生する。コスト要求からくるメモリやCPUパフォーマンスの制限をクリアするためのトレードオフは手続き言語のレベルなら何とかなることが多い。でも、モデル変換のアーキテクチャの中にトレードオフのパターンが隠蔽されていると最適なすり合わせができない。

モデル変換のルール・アーキテクチャにその製品や製品群特有のすり合わせ要素を注入することは可能だが、トレードオフのポイントが頻繁に変わるような商品だった場合、モデルベースの開発はうまみがなくなってしまう。

モデル変換のルール・アーキテクチャを変えない、プラットフォームを変えないことに固執すると、ソフトウェアの開発効率は上がるが、トレードオフバランスの調整やすり合わせによるまねされにくい強みを作り上げるというアドバンテージは減る。プラットフォームが共通になり、数少ないモデル変換アーキテクチャが組込みソフト開発の世界にも普及するようになると、組込みもアプリケーションソフトだけで勝負することになる。これでは他社がまねしにくいソフトウェアのコアコンピタンスを作り上げることが難しい。

プラットフォームの共通化、フレームワークの共通化は、PC+Windows の現状を見れば分かるように、エンドユーザとアプリケーションソフトウェア開発者にはメリットが大きい。でも、そのメリットとは裏腹にPCのハードウェアメーカは辛いだろう。ユーザはPCを買うときにSONYでも東芝でもNECでもDELLでもどのメーカのパソコンを選んでも使い勝手にさほど変わりがない。変わりがないというよりは変えられないのだ。ここまでプラットフォームや共通クラスライブラリが普及してしまうとハードメーカは独自の特徴を出すことができない。

組込みシステムに対するモデル駆動開発のポイントはトレードオフやすり合わせの必要がないGUIなどのアプリケーションソフトに絞って実施することではないだろうか。組込みソフトウェア開発では開発環境の選択であっても常にトレードオフのことを考え、顧客満足を最大にするポイントを探り続ける必要がある。

P.S.

にしさんのブログのコメントに自動車エンジニアさんが、【MATLAB/Simulink/Stateflow】を使った自動コード生成の実態を書いている。MATLAB/Simlink についてはこのブログでも『MATLABのビジネスから見る知的生産性とは』に記事を書いているが、自動車エンジニアさんの記述によると自動車の世界ではMATLAB/Simlinkを使ったモデルベース開発/自動コード生成は実用段階まで進んでおり、実際の車のソフトにも自動コード生成で作られたソフトウェアが実装されているそうだ。日経エレなどの雑誌の記事では読んだことがあるが、現場の生の声でその実態を聞くとリアリティがある。

モデルベース開発によってコードを自動生成する行為が商品の価値を押し下げる可能性がなく※1、実際の商品の動きからモデルやチューニングパラメータを類推されないのなら、モデルベース開発に移行した方がいいというのは理解できる。

※1 パフォーマンスを低下させたり余計にメモリを食ったり、自動コード生成を実現させるためにCPUのランクを上げてコストアップになったりすることが顧客満足を低くする可能性のこと）

また、高級言語でプログラミングするエンジニアの割合が減って、モデル駆動開発するのが常識になったなら、高級言語ですり合わせ開発してまねされにくいソフトウェア資産を作ることより、開発の効率化や品質向上のメリットの方が大きくなる時代もくるだろう。やっぱりトレードオフのバランスポイントが大事になる。

ただ、一つ気になるのはMATLAB/Simlinkのように、モデルベース開発のツールが一社独占になってしまうことのリスクだ。万が一何かの理由でつぶれてしまったり、IBMやMicrosoftなどの巨人に飲み込まれていきなりツールや保守の価格を10倍ぐらいにされても、その条件を飲まざるを得なくなる。

ソフトウェアは複製コストがほとんどかからないので何万台も何十万台も製品を作って売るメーカーなら開発ツールが少々高くてもエンドユーザーへの負担は少ない。逆にメーカーは高価なCPUを使ったり、メモリ部品を余計に追加したりして材料費が10円でも20円でも高くなることを嫌う。原材料費のアップはエンドユーザーまで行くと数倍の負担になってしまうからだ。

一般的な会社においては開発ツールの価格の高さに加えて、開発ツールのセカンドソースも考えておかないといけないところが辛い。競争相手が次々現れたとしてもコンパイラやRTOSもバグがないかとか信頼性は高いかとか考えないといけないのと同じように、アーキテクチャ変換ツールの信頼性について心配しなければいけない。

やっぱり自動車業界のように業界内での示し合わせができないと普及するのに時間がかかると思うなあ。