この連載記事の目次へ

機器メーカーは,プロジェクト管理などの管理手法の導入を試行錯誤しながら進めている。一般的な管理手法を組み込み分野に適用するためにはどのような工夫が必要なのか。各種の手法の根本にある原理・原則に立ち返りながら解説する。

この記事は,「日経エレクトロニクス」と「日経バイト」が刊行した別冊『組み込みソフトウエア2006---品質管理と開発技法の実践的改革A to Z』の掲載記事を抜粋したものです。別冊の詳細はこちらをご覧下さい

 組み込みソフトウエアの特徴の1つは,非常に分野が広いことである。各種のコミュニティを通じて,色々な分野の組み込みソフトウエア技術者と開発手法や開発プロセスなどについて話していると,言葉すら合わないことが多い。

 開発手法や開発プロセスは,何らかの原理や原則の上に立っている。分野に合わせて細分化した手法やプロセス,ツールに関する情報は世の中にたくさん出回っている。しかし,自身の手掛けている組み込みソフトウエアに,それらの手法やツールが本当に適合するものかどうかは,なかなか分からない。現在の組み込みソフトウエア開発において最も重要なのは,原理・原則を深く探求していくことではないだろうか。

 物事には,必ず本質がある。組み込みソフトウエアのような歴史の浅い領域では,本質を追求することの重要性が高い。ソフトウエアが一品一様になるのは仕方がないことである。つまり「これさえやっておけば絶対に大丈夫」というものはあり得ない。何か問題があったときに,「本質的な問題は何なのか」という自問自答を繰り返して原理・原則を知り,その上で自分なりの工夫を加えることが大事になるはずだ。

根本原因はプロジェクトの混乱

 組み込みソフトウエアの問題として「品質」を挙げる人が多い。それをよくよく聞いてみると,「開発の終わりがなかなか見えない」とか「どのプロジェクトでもレスキュー部隊の投入が必要になる」といった状況にあるという。当社でも,品質が問題視されたプロジェクトを分析したことがある。どの工程にどれだけの工数をかけたのかを見ると,ピークが3つあることが分かった(図1)。機能設計とプログラミング,機能およびシステムのテスト,という3工程に多くの工数を掛けていた。

機能テストやシステム・テストで作業が爆発
図1 機能テストやシステム・テストで作業が爆発
品質が問題視されたプロジェクトにおける,それぞれの工程に投入した工数を相対比較したものである。機能設計の工程から混乱したまま進んだプロジェクトは,最後の機能テストやシステム・テストの工程における多量の不具合発生という結果を生んだ。

 このプロジェクトは,次のような状況に陥っていた。機能設計に入った途端に,機能がどんどん膨らんで複雑になり,予定していた納期までに作業を終えられない。ようやく構造設計に入ったとしても,この時点で既に大幅に遅れている。このため,本来重要な構造設計がおろそかなままプログラミングを始めてしまう。さらに,品質確保のために重要な単体テストや結合テストにも時間を掛けずに機能テストに移る。この段階で大量の不具合が見つかって作業量が「爆発」し,プロジェクトが終わらなくなっていたのである。つまり,問題は品質として現れるが,その根本原因はプロジェクトの混乱にあると考えられる。

量がソフト開発を難しくする

 ソフトウエア開発の難しさはどこにあるのだろうか。製品の複雑さを表す指標として,ハードウエアの世界でよく使われるのは部品点数だ。数百点で双眼鏡,1万点超で自動車,10万点超で航空機が作れると言われている。自動車や航空機は,そう簡単に開発できるものではない。ソフトウエアについて考えてみると,ソース・コードが1万行や10万行といったソフトウエアを当たり前のように開発している。少し乱暴な表現ではあるが,ソース・コード1行を1部品として考えると大変な作業のように思える。これは,ソース・コードの1行1行が単純なものであるからこそ作れるのである。

 ハードウエアは,部品1つが難しく,それが組み合わさってさらに難しくなる。一方のソフトウエアは,ソース・コードの1行は簡単だが,その行数が非常に多いことに難しさがある。場合によっては,ソース・コードが100万行を超えることもある。この量を制御する管理技術が必要になる。

 組み込みであろうと,ソフトウエアであることには変わりはない。難しさの1つは,メモリ容量や性能といった物理的な制約条件が多いこと。問題が発生した際に,こうした制約のせいで採り得る選択肢が少なくなってしまうのである。その中で解決策を探るところに技術をつぎ込む--これが組み込みソフトウエア開発の本来の姿のはずだ。しかし,現在は量の問題という,それ以前のところで混乱している状況にある。

 組み込みソフトウエア独特の難しさには,ハードウエアと並行で開発するという点もある。ハードウエアとソフトウエアの間での調整が多いために複雑さが増してしまう。さらに,ハードウエア技術者に対してソフトウエアの状況を適宜明確に説明できなければならないという課題もある。ソフトウエアの課題に向けた解決策として単に管理手法を導入すればよいわけではない。問題の本質的な原因に目を向けた管理が重要になる注1)

注1)
「管理」には「management」と「control」の2つの意味がある。「management」が「首尾よく行う」という意味なのに対し,「control」は「統制する」「支配する」といった意味である。日本語の「管理」には「この通りにやらなくてはいけない」という意味が含まれていると考えがちだが,ソフトウエアの分野では「管理」を「management」の意味で使っている。ここでも同様の意味で「管理」を使う。

(第2回につづく)

(福井 信二=オムロン インダストリアルオートメーションビジネスカンパニー コントロール機器統轄事業部 技術部 技術開発グループ 技術専門職)