NHKの報道によると、我々が「組み込み系開発」と呼んでいるコンピュータに直接制御されている機器のバグは、製品全体の16%に、何らかの形で存在しているとの事です。
http://www3.nhk.or.jp/news/2006/06/26/d20060625000126.html

シンドラーエレベーターの件でNHKは早期から「プログラムミスの可能性」を報じていましたし、報道ステーション等でも、事故を起こした機種とは別の機種に「制御プログラムのミス」が存在する事を報じていました。


私自身は、家電業界の組み込み系開発の現場を離れて５年にもなりますので、最近の事情を良くは知りませんが、おそらく、汎用的な開発言語や開発ツールの恩恵から、最も遠い所にあるという現状は変わっていないと思います。

実際、珍しい事に、私はUNIX用のアプリケーションの開発とマイコンを使った組み込み制御の開発の両方を近い時期に経験しています。そして、前者では簡単にメモリの解放漏れやテスト時に通過したコードの割合を計測するツールを導入したのに対して、後者では、業者が直接売り込みに来たにも拘わらずそれらの導入を見送ったのを、私は覚えています。

なぜなら、そういったツールを使うと、処理速度が３分の１くらいになってしまうので、タイミングやハードウェアのコストが重視される組み込み開発には向かなかったからなのです。

おかげで、色々と細工をしてそういった問題を自力で発見し、解決するスキルが身に付きましたけどね。 （そして、そう言ったスキル程、貧弱な環境での開発を経験しているシニアな人たちからヒントを貰う場合が多いのです。）ただしそういう事自体は、開発の本筋とは違いますので、できるだけやらないに越した事はないです。

更に言えば、開発ツールの導入が遅れている現場ほど、組み込み開発である事とは無関係な、「ソースのバージョン管理ツール」の様なツールの導入にも消極的な場合が多いのです。

当然、開発の進捗が「見えない化」し、モジュールの詳細仕様の情報が完全に個人の頭の中に隠蔽されてしまい、開発プロセスの導入もおぼつかなくなってしまいます。ですから、開発そのものに支障が生じない限りにおいては、ツールを活用するべきだと思います。

勿論、そうする事で現場の意識が変わり、その開発にとって必要な特殊なツールの導入も進むでしょう。

組み込み開発が楽しくなるか、辛くなるかは、その点に掛かっているとも言えます。「見えない化」されたもの、もしくは自分一人の頭の中を常に占領してしまっているものを、不安を引きずりながら開発するのは大変ですからね。

「仮に製品に問題が発生しても、大事に至らないように動作する基準を設けるなど早急な取り組みが必要だ」とのコメントで記事は結ばれていますが、果たしてそういった基準が適用されている事を検証する手段はあるのだろうか？　また、基準そのものがうまく作れるのだろうか？と、心配な事は多い訳です。

おそらく、16%もの製品で発覚したバグの多くは、かなり人間臭いミスによるものでしょうし、それらをツールの導入で解決できるとしても、やりかたはケースバイケースになるでしょうからね。

何よりも恐ろしいのは、バグそのものの原因となるヒューマンエラーの量と、そのバグが引き起こす問題の深刻度は、まったく比例関係にはならないという事です。それが深刻な現象であろうと、些細な現象であろうと、かかわっているヒューマンエラーの質や量に差がある訳ではありません。

よって、ハードウェア的な工夫を別にすれば、「深刻なバグだけを防止する」という事はできないわけで、開発者としてはソフトウェア全体の品質を上げる為に努力するしかないわけです。