この連載記事の目次へ

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

 それでは,組み込みソフトウエア開発は「モノづくり」になっているのだろうか。筆者は,現状ではそうなっていないと考える。まず残念ながら,品質や生産性が非常に低い現場が多い。また組み込みソフトウエア開発の現場では,要求仕様を固められないなど,個々の工程をきちんと確立できていないことが多い。ソフトウエアのテストに至っては,やり方すら全く分からない,というケースも見受けられる。

 まず必要なのは,分析や設計,実装,テストといった個々の工程能力を向上することである。しかし組み込みソフトウエアを競争力の源泉として欧米やインド,中国と戦っていくには,個々の工程能力の向上だけではおぼつかない。日本のモノづくりの強みであるすり合わせ開発や工程融合を組み込みソフトウエア開発に適用すべきである(図2)

組み込みソフトウエア開発をモノづくりに

図2 組み込みソフトウエア開発をモノづくりに
日本の製造業には,すり合わせ型開発や複数の工程の融合などを通じて高い競争力を達成している組織が多い。こうした素養を組み込みソフトウエアの開発にも生かしていく必要があるだろう。

 すり合わせ開発に必要な能力は,大きく3つある。1つは,顧客価値創造・誘導能力だ。すり合わせ開発を行ってはじめて実現できるような高い品質や性能を,顧客に欲しいと思わせ続ける能力である。2つめは,アーキテクチャ構築・推移能力である。部品間のすり合わせを的確に行いつつ,コストを低減させ保守性を向上できるようなアーキテクチャを構築し,市場や事業の状況に合わせて,臨機応変にすり合わせ構造と組み合わせ構造のバランスを素早く変化させなくてはならない。3つめは,すり合わせ検証能力である。自社製品だけでなく他社からの調達品についてもすり合わせが必要な部分を素早く見極め,またうまくすり合ったかどうかをきちんと評価することが必要となる。

 特に,携帯電話機とデジタル・カメラなど複数の製品群をすり合わせて融合させようとするとき,ソフトウエアではテスト・ケースが爆発することがある。組み合わせ型の製品アーキテクチャでは,100個の機能同士を足しても,それぞれのテスト・ケースがキレイに分かれているため,足し算した200個のオーダーのテスト・ケースで済む。一方,下手なすり合わせ型では,それぞれの機能が相互に依存関係を持ってしまうため,テスト・ケースの数が掛け算になってしまう。100個のテスト・ケースで済んだソフトウエア・コンポーネント同士を融合させると,全体としてのテスト・ケースが1万のオーダーになってしまうのだ。

 しかし,きちんとアーキテクチャ設計を行えば,すり合わせが必要な機能や依存関係を明らかにすることができるため,それほどテスト・ケースは増加しない。すり合わせ開発では,テスト・ケースが増えないようにアーキテクチャを設計する必要があるのだ。それには,テスト工程と設計工程の密な連携が必要である。

工程間の連携が足りない

 残念ながら組み込みソフトウエア開発では,ハードウエアのモノづくりのように,工程間の密な連携やコミュニケーションができているとはいえない。分析工程や設計工程,実装工程,テスト工程という製品の開発プロセスにおいて,分析工程と設計工程,実装工程の間は比較的,情報交換がなされているものの,設計工程の情報をテスト工程でも積極的に活用し,テスト作業を効率化するという工夫ができている組織は多くない。

 同様に,テスト工程で見つかった不具合を詳細に分析し,設計にきちんとフィードバックしている組織も少ない。不具合分析の結果からレビューのためのチェック・リストを拡充するという作業は多くの組織で手掛けるようになったものの,上手にパターン化できていないため,分厚くなりすぎて実用的でなかったり,抽象的な観点の羅列に終始している組織も散見される。

 組み込みソフトウエア開発をモノづくりのレベルに引き上げるために重要なのは,こうして複数の工程を上手に融合させ,上流で品質を作り込みながら,下流の生産性を引き上げていくことなのだ。

「既にやっている」という組織の多くは「癒着」

 既にこうした工程間の連携や融合を実践していると主張する組織もあるかもしれないが,その多くは融合ではなく,工程同士の癒着である。ここでいう癒着とは,それぞれの工程をどのように区切ればいいのか把握できていない状態である。

 癒着は,すべての工程を同じエンジニアが担当している場合に発生しやすい。確かに工程間の情報のやり取りは密に行われるが,各工程で何をすべきかが明確にならず,泥縄式の開発になり品質が安定しない傾向がある。癒着型の開発体制の場合,例えばオフショア開発をしようとした際に実装工程の切り出しができず,仕様作成やコミュニケーションに工数や費用がかかるという本末転倒の事態に陥っていることが少なくない。もしくは開発委託先に的確な指示ができず,非常に品質の低いソフトウエアが納品される結果になる。

 工程の融合というのは,こうした癒着とは異なり,個々の工程を確立した上で,工程同士の連携や協調に必要な要素を洗い出し,そこを起点に密なコミュニケーションを取るという高度な開発プロセスである。単に,少人数が全ての工程を担当すれば実現できるわけではない。

(第3回につづく)