- 156 -

業務系ソフトウェア人材の

組込みソフトウェア開発への乗り換え

本報告書作成に向けた調査活動の開始当初、調査チームは一つの仮説を持っていた。つまり、業務系

ソフトウェア開発を行う企業が組込みソフトウェア開発へ参入する事例が今後増えるのではないか、と

いう仮説である。

この仮説の検証結果は、第６章のコラムで述べることとして、ここではソフトウェア・エンジニアリ

ングの観点から、業務系ソフトウェア人材の組込みソフトウェア開発への乗り換えの可能性について触

れたい。

一口に組込みソフトウェアといっても、プラットフォーム（ハードウェア）寄りのソフトウェアやア

プリケーション寄りのソフトウェア、あるいはその中間的なものまで様々であることはすでに述べた。

以前は組込みソフトウェアの規模も複雑性も小さく、何でもできる職人的技術者が開発する傾向が強か

ったが、今後はソフトウェアのレイヤー（どちら寄りか）によって異なる種類の技術者が開発に当たる

分業化の傾向が強まると考えられる。

こうした中、アプリケーションの開発に業務系の Java プログラマを当てる事例が出始めている。こ

の場合、実際の開発言語はJava とは限らず、C/C++の場合もあるが、いずれにせよこのレイヤーの開

発ではリアルタイム制御など専門性の高いプログラム設計能力は求められず、業務系と同じように、（A

の場合は処理Pを実施、Bの場合は処理Qを実施、といった具合に）ロジックに基づいてプログラミン

グできればよい。ただし、業務系以上に効率的なメモリ消費のための工夫などは求められる。

また、アーキテクトの仕事に関しても、業務系で培ったノウハウを組込み系に応用するといったこと

が行われる。たとえば、従来はメモリや性能上の制約から組込み系開発では適用が進まなかったオブジ

ェクト指向分析・設計手法を組込み系開発に取り入れる事例も増え、また、業務系ではいち早く普及し

たUML（後述）のようなモデリング手法（分析・設計情報を図式化する手法）についても、普及の兆し

が見られている。これらの手法を組込み系開発に導入するに当たっては、業務系でのこれらの手法の適

用経験が豊富なアーキテクトに主導的な役割を求める場合もある。もちろん、組込み系に特徴的に見ら

れる設計手法やソフトウェア設計上の制約などは十分に考慮の上、導入に当たっての工夫をしなければ

ならないことは言うまでもない。

このように、業務系人材の組込み系開発への転用は現実のものとなりつつある。ただしそれは組込み

ソフトウェアのすべてのレイヤーで同じように起こっていることではない。アプリケーションが製品の

付加価値部分を少なからず担うようになる中、その生産性を高められるように、また、ただでさえ不足

しがちなソフトウェア人材を効率よく調達できるように、このレイヤーにおいては業務系ソフトウェア

開発の技術やノウハウの転用が進んでいる。それとともに、アーキテクトは業務系のソフトウェア分析・

設計手法を積極的に取り入れ始めている。

（元 東軟信息学院 客員教授 細谷竜一）

- 157 -

5.7.4 モデルベース開発

制御システムの開発に当たって現実世界の制御対象（例：エンジン、電気ポット、など）とそれ

が置かれる環境をモデル化してシミュレーションによって制御システムによる制御アルゴリズムの

振る舞いを検証しながら開発する手法をモデルベース開発（MBD）と呼ぶ。実際の制御対象を用意せ

ずコンピュータ上でのシミュレーションによって開発を進められるだけでなく、シミュレータに入

力した制御アルゴリズムからC言語のソースコードを生成できるため、開発生産性を上げ、コスト

を下げるとともに制御システムの信頼性を上げることができる。こうした特徴により、近年注目さ

れている。モデル化とシミュレーションのツールとして一般にMATLAB Simulinkが利用される。

特に組込みシステム開発の上流工程においてシミュレーションによってプロトタイプを設計・検

証するときに後述のモデルチェッキングとともに用いられる。これによって実機を対象とした本格

的な設計工程に入る前に基本的な仕様定義と検証を済ますことができるのである41。

（モデルベース開発の関連分野として）モデルとして表されるシステムやソフトウェアの設計あ

るいは制御アルゴリズムが所定の条件を満たす振る舞いをするかどうかを厳密に検証することをモ

デルチェッキングと呼ぶ。Promela はソフトウェア仕様記述言語であり、これによって記述したモ

デルをSPINツールを使って検証することができる。

後述のUMLの関連技術体系であるMDA（Model Driven Architecture）は、組込みシステム開発で

いうモデルベース開発とは用語は似ているものの直接は関連しない。

5.7.5 UML

UML（Unified Modeling Language／統一モデリング言語）は業界標準のソフトウェア設計表記法

であり、13種類の図法からなる。

もともと業務システム開発向けでの利用が多いものだが、オブジェクト指向プログラミング言語

の普及に伴い、組込みシステム開発での適用事例も増えつつある。

オブジェクト指向ソフトウェア設計や、C++やJavaによるプログラム設計を図式化できることに

最大の特徴があるが（クラス図など）、ユーザによるシステムの使い方を図示するユースケース図、

構造化設計で使われるフローチャートに似たアクティビティ図、組込みソフトウェア開発で多用さ

れる状態遷移図（UMLではステートマシン図と呼ぶ）やタイミングチャート（UMLではタイミング図）

なども含まれ、適用範囲は広い。

個人向けに UMTP（UML based Modeling Technologies Promotion）による日中共通のモデリング

技能認定試験やOCUP（OMG-Certified UML Professional）などの技術者資格制度があり、UMLの仕

様の知識や、モデリング（設計や仕様を模型化すること）の技能レベルを客観的に証明することが

できる。

UMLによって描いた図からソースコードを自動生成したり、設計の妥当性を検証したりといった、

ツールによるある程度の自動処理が可能である。

41 併せて第６章解説「自動車産業で注目されているモデルベース開発手法」も参照されたい。

- 158 -

図表5-24 UMLによる表記例（ステートマシン図）

図表5-25 UMLによる表記例（タイミング図）

UMLを組込みシステム開発に応用しやすくするいくつかの動きがある（図表5-26）。現在のところ

規模の大きな組込みシステム開発であってもUMLの利用は10%に満たないが（図表5-27）、その導入

- 159 -

のポイントは情報共有、設計品質、そしてドキュメンテーションの向上に見出すことができる（図

表 5-28）。ソフトウェア・エンジニアリングの視点で開発プロセス全体にわたって利用できる表記

法として現状で唯一のデファクト標準であり、徐々に普及していくことが見込まれる。

図表5-26 UMLの組込みシステム開発への応用に向けた取り組み

UML2 2004 年ごろから使われ始めた UML の最新版で、ステートマシン図（状態遷移図に相当）の強

化や、タイミング図（タイミングチャートに相当）の導入が行われたほか、シーケンス図（シ

ステム要素間の呼び出しの順序関係のパターンを表す図）などでも時間制約が表現しやすくな

り、組込みシステム開発での利用がしやすくなった。 また、ソフトウェア開発をモデルベー

スで進め、中・下流工程を半自動化するための技術体系である MDA（Model Driven

Architecture）をサポートしている。

リアルタイムUML ブルース・ダグラス著の同名の書籍で、リアルタイムシステムの基礎とともに組込みシステム

開発でのUMLの各図法の使い方や分析方法を詳しく解説している。Bruce Powel Douglass（著）、

渡辺博之、オージス総研 （訳）『リアルタイムUML：―オブジェクト指向による組込みシステ

ム開発入門』 翔泳社, 2001年。

eUML Embedded UML 2002年。ハード／ソフトを区別しないシステム全体の記述を施行している。UML

の拡張版ではなく、UML を利用した組込みシステムの買いはプロセスとしてまとめられてい

る。成果は書籍として出版（渡辺ほか『組み込み UML：eUML によるオブジェクト指向組み込

みシステム開発』翔泳社, 2002年。

UML for SoCフォーラ

ム

キャッツ株式会社、日本ラショナルソフトウェア株式 会社、富士通株式会社が設立したフォ

ーラムで、UMLをSoC（System on a Chip） 設計で適用する際のUMLの拡張仕様（UML Profile

for SoC）を策定した。これに より、SoCの上流設計工程において、デバイスに要求される機

能を UML を用いて記 述することが出来るため、SoC におけるハードウェア設計とソフトウェ

ア設計が 協調しながら機能の実装を両者間で柔軟に調整するコ・デザインにも有効と思われ

る。

- 160 -

図表5-27 普及途上のUML

資料：経済産業省 2007年『2007年版組込みソフトウェア産業実態調査報告書』

図表5-28 モデリング手法の導入効果

資料：経済産業省 2007年『2007年版組込みソフトウェア産業実態調査報告書』

UMLを策定している業界団体であるOMG（Object Management Group）は、モデルに基づくソフト

ウェア開発手法とツール技術体系としてMDA（Model Driven Architecture）を提唱している。

MDAは、一言で言えば、UMLで基本設計レベルの図を描けば、それに基づいて詳細設計の図やソー

スコードまでを（半）自動生成するなどして、開発生産性を向上するとともに、上流工程において

作成したモデルの再利用性を引き出すことでその資産価値を高めるというコンセプトである（図表

5-29）。

基本設計レベルのモデルはPIM（Platform-Independent Model／プラットフォーム非依存モデル）

と呼び、特定のハードウェアやソフトウェアプラットフォームに依存しないため、様々なプラット

フォーム上での同時展開や、将来の異なるプラットフォームへの移植に適している。その特性から、

- 161 -

組込みソフトウェア開発分野で大規模な適用事例が知られている。

特定のプラットフォーム向けにPIMを詳細化したモデルをPSM（Platform-Specific Model／プラ

ットフォーム特化モデル）と呼ぶ。モデルコンパイラと呼ばれる専門のツールあるいはそれに相当

する機能を使ってPIM及びターゲット・プラットフォーム情報に基づいて自動生成することができ

る。

UML は人間同士のコミュニケーションを助ける表記法としての側面と、ツールに対してソフトウ

ェア設計を入力し、ソースコードを自動生成するといった自動化の側面との両方がある。MDA は特

に後者に重きをおいたUML等の標準の応用である。

そのため、OMGでは単にUMLの表記法だけでなく、UMLで描いた図をデータとしてツール間で交換

するフォーマットや、モデルの変換ルールの記述方法など様々な関連標準を整備している。これに

基づくツールもいくつか発売されているが、まだ相互運用性は低く、発展途上の技術体系である。

図表5-29 MDAによる設計とコーディングの自動化

5.7.6 ソフトウェア・プロダクトライン

製品には、しばしば製品ラインアップというものがあり、同じ用途であるが少しずつ違う仕様の

一連の製品（プロダクトファミリ）や、ある用途の製品とそれに関連する周辺用途の製品からなる

製品群（プロダクトライン）のことを指している42。

製品ラインアップに含まれる製品は、ばらばらに開発されるわけではなく、共通のアーキテクチ

ャや部品群をまず開発し、周辺製品との関連性や接続性を周到に設計した上で開発されることが一

般的である。

ソフトウェア･プロダクトラインとは、製品ラインアップと同様の考え方に基づいて開発される一

42 プロダクトファミリとプロダクトラインの用語の使い分けは厳密ではなく、両者をまとめてプロダクトラインという場合もある。

- 162 -

連のソフトウェアのことである。

製品ラインアップ内の個々の製品毎に、ばらばらにソフトウェアを作るのではなく、共通の仕様

モデル（フィーチャ・モデルという）、ソフトウェア・アーキテクチャやソフトウェア･コンポーネ

ント群を設計した上で、効率的に個々のソフトウェアを「生産」しようというのが、その背景にあ

る考え方である。

今のところ、「ソフトウェア・プロダクトライン開発ツール」というような単独のツールは存在し

ない。むしろ、既存のソフトウェアツールやエンジニアリングの考え方を組み合わせた実践手法（プ

ラクティス）としての色彩が濃い。また、共通のソフトウェア資産からいかに効率的に多くのソフ

トウェアを生産するかがポイントとなるため、マーケティングや製品開発計画の段階でも製品ライ

ンアップあるいはソフトウェア・プロダクトラインを意識することが重要であり、単なる技術論で

はなく、ビジネスとの協調が求められる。

そのため、ユーザ主導で仕様が決まるカスタム業務システムよりも、メーカー主導で製品ライン

アップと仕様を決められる場合が多い組込みソフトウェア開発での方が適用しやすい考え方である

と言われる。

ソフトウェア･プロダクトラインの技術的ポイントを述べるとすれば、

① 仕様のモデル化（フィーチャ・モデリングなど）

② 対象製品領域内で再利用可能な（設計モデル、ソフトウェア・コンポーネントやフ

レームワークなどの）ソフトウェア資産の構築（コア資産開発）

③ DSL（Domain-Specific Language）を使って直接的に仕様を記述し、処理できるドメ

イン特化のプログラミングをするか、特定仕様からソフトウェア資産の組み合わせ

をツールによって（半）自動的に決定し、ソースコードを生成する（プロダクト開

発）

ということになる（図表5-30）。①と②はともにドメイン･エンジニアリングという技術領域に含ま

れる。こうしたことと併せ、ソフトウェア・プロダクトラインの開発では、従来の開発方法に比べ、

3～50倍の生産性が得られるとされる43,44。

対比するとすれば、こうしたことはLSI設計などでは当たり前のように行われていることである

が、ソフトウェアの世界ではいまだ発展途上にある方法論であるといえる。

43 Software Product Linesホームページによる。http://www.softwareproductlines.com 44 なお、上記②と③には前出のMDAと似た部分があるが、MDAとソフトウェア・プロダクトラインはそれぞれに異なる源流を持っており、融合していない。MDAはUMLを策定している米国の標準化団体OMGが推進している技術体系であるのに対し、ソフトウェア・プロダクトラインは米カーネギー・メロン大学ソフトウェア・エンジニアリング研究所（SEI）などが提唱している。

- 163 -

図表5-30 ソフトウェア・プロダクトライン

- 164 -

図表 モデルベース開発におけるECU開発プロセス

制御仕様設計（ソフトウェア設計）

制御仕様設計（機構設計）

実装工程（自動コード生成）

要求仕様分析（システム分析）

機能検証（ECU検証）

制御仕様検証

適合（車両確認）

要求仕様検証

機能検証（ECUソフトウェア検証）

スパイラル・アップしながら進行

出所）各種資料より安田作成。

自動車産業で注目されているモデルベース開発手法 近年、自動車の開発手法そのものの見直しが行われている。従来、自動車の開発では、従来から数多

くの実車プロトタイプが作成され、それを用いた試行テストが数十回繰り返されることを通じて詳細に

実際の動的振る舞いをチェックし、品質熟成を向上させていくという作業が行われてきた。ただし、近

年、自動車に多数のマイコンが搭載されることで、そのテスト項目は飛躍的に増大しているという。そ

れに伴い、実機テストの回数を増大させることは、費用の観点から限界がある。また、テストの網羅性

の観点からも問題がある。

こうした問題を是正する手

段の一つとしてモデルベース

開 発 （ Model-Based

Development：MBD）が進

展している。MBDとは「一連

の開発プロセスの各工程にお

いてモデルを用いて開発を行

なうこと」であり、実装したい

機能をブロック図や線図を用

いて表現したり、あるいはシミ

ュレーションによってコント

ローラであるECUと制御対象

であるセンサーやアクチュエ

ータの動作を予め確認したりする開発手法である。モデルを用いることで制御仕様が可視化できるよう

になるため、コードの自動生成、検証の自動化などを志向することができ、テストシナリオ（パターン）

の再利用も可能となる。MBDの開発プロセスは、要求仕様工程、制御仕様工程、実装工程、機能検証工

程、適合工程からなり、図表のように描くことができる。MBDの目的は開発効率の向上、コスト低減、

品質の向上を実現することにある。曖昧な情報によるミス･コミュニケーションを抑制し、シミュレーシ

ョンを用いた迅速な設計・評価の実施、設計結果の資産化が可能になる。また、コードの自動生成、検

証工程の自動化なども志向されており､ヒューマンエラーの減少、手戻り作業の抑制、検証作業の短縮化

などが期待されている。これら一連の工程を効率よく遂行するためには適切なツールチェーンを構築す

る必要がある。よく利用される開発ツールとしてはモデル設計ツール、ラピッドプロトタイピングツー

ル、自動コード生成ソフトウェア（Auto Code Generator）、HILS（Hardware In the Loop

Simulation）システムといったものがある。

（東京富士大学 准教授 安田賢憲）