松岡正人(まつおか まさと)

 マイクロソフト モバイル&エンベデッドデバイス本部エグゼクティブプロダクトマネージャ。

 この数年,様々なニュースで「組み込みソフトウエア」という言葉を目にするようになりました。これまでも人々の生活を支えるためのソフトウエアとして開発され,使われ続けていましたが,メディアに注目されることもなく,とても地味な存在でした。このところの盛り上がりは,いったいどうしたことでしょうか。

 組み込みソフトウエアは,確実にユーザーの意図することを実現し,誤動作の許されない環境で鍛えられてきました。あえて言えば,与えられた仕事を寡黙にこなす昔ながらの日本の技術者と似ているかもしれません。そして日本製品全般に対する海外市場での認識は,そのまま組み込みソフトウエアの品質の高さを示す指標だったと言えるでしょう。

 しかし,今メディアで目にするのは,高いと言われ続けてきた「組み込みソフトウエア」の信頼性や品質の低下という問題です。これはあらゆる分野において顕在化しており,携帯電話や家電のみならず,自動車や航空管制システムなど多くの分野でソフトウエアの品質に基づく様々な問題が発生しています。

 少し前までは,ソフトウエア品質の問題と言うと,たいていパソコンのソフトウエアが対象でした。それがこの数年では,きわめて身近なところで使われている機器に組み込まれたソフトウエアの,つまり組み込んだ製品そのものの品質問題として大きく取り上げられ始めたのです。

 その理由はいくつか挙げることができるでしょう。一つには,開発規模の拡大という問題があります。開発規模の拡大とは,開発するソフトウエアのコード量が増えていることを意味します。では,なぜコード量が増えると品質が低下するのでしょうか。

 情報処理推進機構(IPA)がまとめた「経済産業省2006年版組込みソフトウエア産業実態調査報告書」によると,組み込み製品の出荷後に発生した品質問題の原因の半数以上が,ソフトウエアの不具合によるものだとしています(図1)。また,経営層は,昨今の様々な製品の品質に起因するトラブルについては経営課題としてとらえていることがこのレポートからみてとれます。

図1●製品出荷後の設計品質問題の主な原因──「経済産業省2006年版組込みソフトウエア産業実態調査報告書」から
図1●製品出荷後の設計品質問題の主な原因──「経済産業省2006年版組込みソフトウエア産業実態調査報告書」から

 また,開発者の数が不足しており,その結果外部の開発会社への委託や人材派遣,場合によっては海外の開発会社に委託するオフショアなども増えつつあることも最近の傾向だと言えるでしょう。

 開発規模の拡大に適応するため,このような対応で開発を行うことが増えています。大きなプロジェクトになればなるほど,自社だけでの開発は困難になるからです。そして,ここにも問題が潜んでいます。

 一つは,品質上の問題が見えにくくなってしまうという点です。外部の人と仕事をする場合に,言葉や文章だけで伝えきれない部分をどのようにうまく伝えて理解してもらうかが大きな課題となります。誤解が生じやすく,ひどい場合には手戻りが多発して開発効率が大きく下がってしまう可能性があるということです。もちろん,そのような開発プロジェクトでは,プロジェクト・マネジャのマネージメント能力が問われることになります。

 もう一つは,開発中の製品の情報が競合に漏れてしまう可能性があることです。例えば,携帯電話の新製品がどれくらいの頻度で発売されるかを考えてみてください。おそらく年に1回は同じメーカーから新製品が発売されており,派生機種を含めればもっと多いでしょう。

 機器仕様を固めながら製品開発を進める*1中で,競合の製品が想定していたものよりも優れているのであれば,より消費者に受け入れられる製品を作るために,製品の仕様を変更する場合もあるでしょう。消費者向けの製品では,このような手間とそれに伴うコストを考慮しながら,最終的な決断をしなければならないのが一般的です。さらに変更にあわせて,開発や保守の体制も柔軟に対応させる必要があります。

 もちろん,ソフトウエアで解決できる仕様変更・追加であれば,製品を出荷した後でもソフトウエアを更新することで解決できる場合もあります。現在,携帯電話はこの方法でネットを通じて不具合の修正を行っています。ただし,自動車では販売店などに持ち込んで更新してもらうのが普通でしょう。

 実は,この更新そのものにも問題が潜んでいます。更新の頻度が高ければ,手間がかかるなど顧客満足度を下げる要因になり,製品の販売が思うように伸びない可能性があります。あるいは,電話の交換機やネットワーク・ルーター,スーパーのPOSレジのように,通信インフラや業務端末として使われる機器では,更新に伴う機会損失についても十分考慮しなければなりません。

 つまり,組み込みソフトウエアは,一般生活とビジネスの必需品として機器の中で信頼され使い続けられるものでなければなりません。生活するうえでの依存度も高くなっていることから,機器の障害が発生すると,テレビで大きなニュースとして取り上げられ,新聞紙面を賑わすわけです。例えば,この数年に起こった不具合関連のニュースとしては,以下のようなものがあります。

2004/01DVDレコーダー。設定が初期化されてしまうなど
2004/04携帯電話。操作不能または強制再起動となる
2004/07デジタルカメラ。オートフォ-カス(AF)動作異常
2005/08ADSLモデムルータ。発信できないなど
2005/10自動車。エンジン停止や警告灯の表示異常など
2006/07エレベータ。開閉装置の誤作動
2006/09電話中継系呼制御サーバー。ひかり電話の混雑

 これらは,検索エンジンを使って,「ソフトウエア 不具合 ニュース」のキーワードで検索したものです。簡単に多くの記事を見つけることができます。現在の日本の産業を支え,ひとたび不具合が発生すれば事業への悪影響を与えかねない脆弱性をもはらむもの,それが「組み込みソフトウエア」なのです。

組み込み開発の定義

 では,組み込みソフトウエアを開発することはどのようなことなのでしょう。身の回りの製品をもとに少し考えてみましょう。

 我々の身近には,パソコンと同じハードウエアを使いながら組み込み機器と呼ばれるものがいくつかあります。例えば,駅の券売機やPOSレジ,ATMなどです。これらは,特定の用途のためだけに作られており,定められた使い方以外はできないように構成されているのが一般的です。ただし,プログラムやインタフェースを更新・拡張することで,新しい機能やサービスを追加することができます。

 業務アプリケーションも同様に,例えば給与計算のプログラムはそれだけしかしません。しかし,給与計算のプログラムが動作するパソコンは,OSに給与計算以外のプログラム(アプリケーション)が付属しており,ゲームをしたり,インターネットにアクセスしたり,音楽を聴いたり,絵を描いたりできます。これに対して,ATMは,あらかじめ用意されたATMのプログラムだけが使えるようになっており,マインスイーパーをATMの画面で楽しむことはできないというわけです。

 ITエンジニアにとって身近なものでは,ラックマウント型のアプライアンス・サーバーなどはATMと同様に,組み込み機器の一種だと言えます。もちろん,プリンタやモニターなどはまさに典型的な組み込み機器です。マウスもそうです。

 ソフトウエアの規模がどうであれ,ソフトウエアを組み込んだ機器を開発することが,組み込み開発であり,同時に,使い方が制限されているものがこれまでの組み込み開発の定義だったといえます。パソコンのようにユーザーがどんな目的で使うかを想定しきれないものとは違い,あらかじめユースケースが詳細に定義された機器なので,開発の範囲が定義しやすいと言えます。

 なお,日本で言う組み込み開発は,開発対象と開発ホストが異なるクロス開発*2が一般的だという点が特徴です。ホストは,現在はほとんどがパソコンです。かつてはUNIXワークステーションや専用の開発端末などもありました。私自身は汎用機上でアセンブラを使った開発の経験もあります。

 ただし,汎用のOSを搭載した機器が増えるにつれて,組み込み開発の定義もあいまいになり始めています。この点については,今後の連載の中で述べたいと思います。

現在の組み込み開発

 組み込み開発なるものはいつから始まったのでしょうか。現在の開発スタイルはいつごろからのものなのでしょうか。

 私が初めて出会ったコンピュータは,1976年からNECが販売していたTK80というマイコンボードでした。高校の物理の先生が秋葉原で中古で買ってきて,使わせてくれたのが最初です。米Intelの8080互換のμPD8080という8ビット・マイコンが搭載されていました。当初は,機械語*3しかサポートされていませんでした。のちにBASIC言語を装備したことで,機械語がわからなくてもプログラムが作れることから,多くのユーザーに受け入れられました。

 その後,μPD8080を使ったプリンタのファームウエア*4の開発をしたことがあります。プログラムはアセンブラで書いていたと記憶しています。初めてICE*5を使ったのもこのころだったと思います。

 しかし,当時のICEには欠点があって,プログラムをデバッグ・モードで動作させると,動作周期が微妙にずれてしまい,不具合がハードウエアなどの処理タイミングに依存するような場合は,発見するのが困難でした。また,対応可能なプログラムのサイズも,数Kバイトから数十Kバイトでした。

 やがて,16ビット・マイコンが登場し,プログラムのサイズが大きくなります。しかし,本格的に肥大化するのはもっとずっと先,ここ数年のことになります。

 プログラム・サイズの変化は,二つの理由によるものです。一つは,CPUの高速化。もう一つは,機器に求められる機能の高度化です。

 例えば,複雑なソフトウエアを組み込まなくても電子ジャーや洗濯機などはハードウエアだけで,電子回路や電気回路だけで求められる機能,例えば,お米を炊くとか,洗濯や脱水といった仕事をこなすことができました。しかし,ビデオレコーダが登場すると,タイマー録画の機能など,徐々にプログラムを必要とし始めます。それは,組み込み開発の歴史そのものだと言えるでしょう。

 携帯電話も,当初は数人で開発できるくらいのプログラム・サイズでしたが,iモードに代表されるように,様々な機能を付加し続けたことで,現在では数十Mバイトもの規模のプログラム(およびデータ)が開発対象です。

 一般には,コードの行数で言うと100万行を超える規模の開発が携帯電話という小さな組み込み機器で行われていて,数百人規模で開発していると言われています。私が20年あまり前に経験した小規模な組み込みソフトウエア開発など,全く比較になりません。言い換えると,以前は個人の技量でできていたことが,現在では組織的に開発を推し進める仕組みがないと,最終的な製品ができあがらないことを意味します。高層ビルを建てるのと,犬小屋を建てるのに必要なスキルが全く違うのと同じです。

 わずか30年あまりの組み込み開発の歴史の中で,大きな変化が起こったのはつい最近のことだと言えなくもありません。この流れの中で開発環境も大きく進化しています。これについては,今後の連載で紹介したいと思います。

 余談ですが,最近読んだ本で,中世のヨーロッパでペストが大流行したときに,当時の一般的なキリスト教の医者は,静脈を切り裂いて悪い(と思われる)血を流すことで体の中が清めるというほとんど迷信に近い医療行為を行っていたために,数多の人々が死んでいったというくだりがありました。これと犬小屋の話は「経験と知識が不足している」という点において同じ問題を抱えています。

 ITエンジニアが組み込み開発プロジェクトにかかわる場合にも同じことが言えます。また,汎用機での開発経験も業務系の知識もないエンジニアが,基幹システムの開発を汎用機で行う場合にも同じことが言えるでしょう。自分がこれから取り組むプロジェクトについて,技術的な背景,業務における制約などいろいろと理解しておくことが重要なのです。

 次回は,ITエンジニアの皆さんに理解していただきたい,組み込み開発の技術上の違いについてもう少し掘り下げてお話ししたいと思います。