「バグはあることを前提に」と話す，マイクロウェアの星氏
| 【国内記事】 | 2001.06.27 |
6月27日から3日間東京ビッグサイトにおいて，デジタルテレビなどをはじめとしてさまざまな機器に採用される，「組込みシステム」の開発に関する「第4回組み込みシステム開発技術専門セミナー」が開催されている。同期間に，「データストレージEXPO」「ソフトウェア開発環境展（SODEC）」「組込みシステム開発技術展（ESEC）」も併せて開催されている。初日となった27日，マイクロウェア・システムズの星光行企画室長が，「開発製品に応じた組み込み用OSの選択基準」をテーマにセッションを行い，OSの選択で製品開発時間に大きな差がでることや，アプリケーションに最適なOSの選択をするための指針などを示した。
星氏はこれからの組み込み型製品でのOSの選択基準について，「製品ライフサイクルが短くなり，タイムトゥーマーケットが叫ばれる現在，目的の製品をいかに早く商品化できるかが何より重要。性能よりも短期開発を重視すべき。そして，開発期間を大きく左右するのがOSの選択」と話す。
同氏は，製品の開発期間が増大している原因を挙げる。より複雑なアプリケーションが増えてきていることでプログラムが長く複雑化し，デバッグに時間がかかることやプロジェクト管理が難しくなっていることがあるという。さらに，さまざまなミドルウェアやプロトコルの登場などによる工業標準規格に開発が追いつかないこと，技術者不足なども問題になっているという。
これらの問題をクリアするか，あるいは最初から発生しないようにするために，同氏はOSの選択が重要だとしている。
OSを選択する場合の1つの分類方法として，星氏はプロセスモデルとスレッドモデルを挙げた。
プロセスモデルはさらに，OS-9やWindows CE（V3.x），LynxなどのリアルタイムOSと，UNIXやLinux，Windows 95/98/Me，WindowsNT/2000，Windows CE（V2.x）などの非リアルタイムOSに分かれる。
一方，スレッドモデルには，リアルタイムOSであるiTRONやVxWorks，pSOSなどがある。
同氏は，プロセスモデルではカーネルやプロセスなどのアプリケーションが独立して存在しており，プログラム中でローカル変数が基本になるとする。スレッドモデルは，カーネルやドライバ，タスクがなどが1つの大きなオブジェクトで動作するもので，グローバル変数が基本になるという。
このため，プロセスモデルで，ある1つのプログラム実行時にエラーが発生した場合，エラーとなったプロセスのみがダウンするが，スレッドモデルではシステム全体がダウンしてしまう可能性が高いという。
星氏は，小型で高速なシステムを構築したい場合はスレッドモデルのOSもいいが，スケーラブルな展開をする製品や大規模で複雑なシステムを構築できるプロセスモデルを採用すべきとしている。
同氏は，異なるOSを利用して同じ機能のプログラムを開発した実例も紹介した。A社のOSの場合，A4紙5枚で計335行であったのに対し，B社では同19枚で計1386行にもなったとしている。
開発手法はRADで
また，同氏は，ハードウェアおよびソフトウェアに分かれる開発手法に関して，RAD（Rapid Application Development）を実現するのが望ましいとする。
従来型開発では，ソフトウェアのテストやデバッグをするために，ハードウェアが出来上がるのを待たなくてはならず，無駄な時間が発生したという。さらに，障害が発生した時に原因がソフトウェア側かハードウェア側かを切り分ける手間が掛かる。
一方，RAD開発手法では，ソフトウェアを「リファレンスボード」に乗せ，ハードウェアとは分離してソフトウェアのテストを行うという。これにより，ハードウェアを設計，開発している間にソフトウェアのテストおよびバグ取りができ，ハードウェアが出来上がると同時に最終テストに移れる。ソフトウェアとハードウェアの開発を同時進行で行えるため，プロジェクトの進捗状況を大幅に改善できるという。
RADを実現するためには，各種のAPIが細部まで定義され，疎結合のシステム設計ができていることや，ドライバとアプリケーションが完全に分離していること，ソフトウェアが部品として再利用できるようになっていることなどが要求されるとしている。
バグはあるものと考えよ
同氏はまた，プロジェクト全体の思想を，バグがないことを前提とする「Fault avoidance」から，バグは発生するものと考える「Fault tolerance」に転換するべきとも話している。プログラムが長くなると，デバッグに時間が掛かる上，バグを完全になくすることが困難であり，統計的にバグ回避の限界点が存在するという。同氏は，プログラムが16000ラインを超えた時点で，エラー密度（1000ライン当たりのエラー数）は0.5を超え，これをバグ回避の限界点と呼ぶ。つまり，16000ラインを超えたプログラムは，最終化したとしても完全にバグなしにすることは難しいわけだ。
同氏は，携帯電話のプログラムの不具合が発覚して，製品回収騒動が起こった件に関して，「なぜ，バグがあることを前提とした商品開発をしないのか分からない。ネットワークを持っているのだから，バグ修正版を携帯電話のユーザーがダウンロードできるような仕組みにすれば済むことだ」と話した。
関連リンク
[怒賀新也 ，ITmedia]
