| ||
|
これまでの組み込みソフトウェア開発では，個人や企業の知識あるいは経験に依存してきた部分が少なからずあった。例えば，構造化分析や構造化設計などの技法をカスタマイズし，開発対象に特化した独自の方法を確立していた。勘と経験，人間関係に基づいた世界だった。
こうした状況になったのには，二つの理由があった。一つは，「要求仕様やハードウェア仕様が頻繁に変わる」「メモリーやCPU性能などのリソースに制約が多い」といった状況下での開発では，チーム内の暗黙知と密接なコミュニケーション，あるいは職人的な技術に頼らざるを得なかったことである。そうしないと所望の納期とコストを満たせなかった。もう一つは，日本企業が持つ品質への強いこだわりである。組み込みシステムを構成するハードウェアやソフトウェアが最適となるように擦り合わせる開発がごく普通に行われてきた。汎用性のある方法論に昇華しづらい世界がそこにあった。
オブジェクト指向の導入が一法
しかし勘と経験，人間関係に依存した開発は限界を迎えている。本コラムで何度も触れたように，組み込みソフトウェアは大規模化や複雑化，短納期化が進み，開発プロジェクト自体も大きくなっている。社内だけでは手に余る案件が出てきた。結果として，外部委託やオフショア開発に頼ることになる。個人や企業のローカル・ルールや“方言”を，社外の技術者に対して説明しなければならない。もはや「あうん」の呼吸は通用しない。
以前のように，開発対象となる組み込みシステムが小規模で，開発期間に余裕があるのなら，じっくり意思を擦り合わせることも可能だった。大人数で大規模，さらに納期が厳しいとなると，従来型の開発はもはや非現実的である。そもそも共通認識レベルが低い状態でのコミュニケーションは伝達効率が悪いし，会議や打ち合わせの長時間化や言葉の行き違いによる手戻りにつながる。コスト超過や納期遅れといった事態を招きかねない。
では，どうすればよいのか。一つの解が，組み込みソフトウェアにおける標準的な開発方法論の確立である。標準となる技法が存在すれば，技術者のあいだで共通認識を形成できる。プロジェクトの前に教育や訓練を実施し，いざ開始となったらロケット・スタートを切ることも可能になる。
開発方法論を確立する一つのアプローチとして，かねてから注目されているのがオブジェクト指向技術である。オブジェクト指向の考え方を取り入れることには利点が多い。例えば，人間が理解しやすい現実的な「モノ」を単位としてプログラムが分割されるので，管理がしやすくなる。プログラムをうまく分割すれば，再利用可能な部品として活用し，開発期間の短縮が図れるし，保守性の向上も見込める。
ソースコードを自動生成するMDA（Model Driven Architecture）への展開も考えられる。MDAとは，システムに対する要求を分析して作製した図（例えば，UML：Unified Modeling Languageの図）から，ソースコードを自動的に生成する開発手法である。UMLなどの図はシステムの構造や振る舞いを表現するが，これは製品のプラットフォーム（ハードウェア）が変わってもそのまま使い回せることが多い。つまり図（モデル）自体を再利用できる。プラットフォームを変更する場合は，変換ルールの切り替えだけで対応可能である。ハードウェア変更に伴うソフトウェアへの影響を抑えられる。
ちなみにUMLには，組み込みソフトウェア開発への導入を前提としたeUML（Embedded UML）が提案されているし，各種の開発支援ツールが存在する。オブジェクト指向技術を使って組み込みソフトウェアを開発する環境自体は整備されつつある。
本格普及に二つの壁
しかし，オブジェクト指向技術が開発現場にしっかり根付いているかというと，程遠いのが現状である。
図1[拡大表示] に，組み込みソフトウェア開発で用いられるプログラミング言語のランキングを示した。圧倒的に使われているのがC言語。オブジェクト指向開発言語のC++とJavaは合計で18.6％にとどまる。開発ツールの使用状況からも，オブジェクト指向の本格普及への道のりが遠いことが分かる（図2[拡大表示] ）。分析・設計ツールの使用率は19％に過ぎない。このなかには非オブジェクト指向系も含まれている可能性があるので，オブジェクト指向の分析・設計ツールを使っている現場はさらに少ないと思われる。
筆者の実感に照らすと，システムの要件定義だけをUMLでドキュメント化し，設計や実装は従来の構造化設計でC言語を用いてコーディングを行っているというのが，現場の状況だろう。オブジェクト指向の本格普及には，もうしばらく時間がかかりそうだ。
では，導入によるメリットが明確な上に，環境も整いつつあるオブジェクト指向技術が，どうして普及しないのだろうか。理由は大きく二つある。第1に，「鶏が先か卵が先か」になるが，オブジェクト指向のスキルを持った人材が開発現場に少ないことが挙げられる。これは先の調査データでも明らかである。OJTによる教育を行おうにも，教えることができる人材が限られる。第2はコストと時間である。オブジェクト指向の開発技法を導入するには，教育や訓練，対応ツールの購入などに，相応のコストと時間がかかる。目前の開発案件に追われる現場では，本格導入に踏み切りづらい。
しかし手をこまねいていても仕方がない。開発現場にどのような技術スキルが必要なのかを分析し，不足なら適切な教育や訓練を実施するなどのスキームを何とかして構築しなければならない。
擦り合わせと組み合わせの融合を目指す
こうした観点に立って，情報処理推進機構ソフトウェア・エンジニアリング・センターは，組み込みソフトウェア開発に関する技術スキルを分析する方法「組込みスキル標準（以下ETSS）」を2005年5月に公開した。ETSSを使えば，組み込み製品の開発を手がける組織や技術者が持っているスキルの項目や習熟の度合いが把握できる。スキルが不足しているなら，それを補うための教育や訓練を選択する際の指標としてETSSを使うことも可能だ。さらに今後，スキルと教育カリキュラムを関連付ける予定である。
このほか，設計段階の品質を高めるために，設計の標準化や設計検証の自動化などについての検討を2005年度から始める。さまざまな開発対象や開発局面で起こり得る問題に対して，どのようなモデリング手法を，どのように利用するのが有効かなどについて提案していく。
最後に指摘したいのは，オブジェクト指向技術が有効だからといって，組み込みシステムを“極度”に部品化することは，得策ではないという点である。部品化が行き過ぎると，わが国が強みとしてもっている，擦り合わせ型開発による高品質の製品という良さを弱めかねないからだ。
良質な製品を実現するには，「組み合わせ型」と「擦り合わせ型」をうまく組み合わせて開発することが不可欠である。前者は大規模化・複雑化・短納期化などの課題を解決するために用い，後者は製品の差異化を図るために利用するといった考え方である。擦り合わせ開発と組み合わせ開発をバランスよく取り入れたところに，組み込みソフトウェア業界が求める開発技法は存在する。
