組み込み機器向けソフトウエアの規模が指数関数的に増えている。ソフトウエア規模の増大に対応すべく,先進的なソフトウエア開発方法論を取り入れる先進企業が現れている。「ケータイ」「デジタル家電」「クルマ」などの先進事例を取り上げながら,上流設計から下流のテスト・検証工程に至るまで,組み込みソフトウエア開発の現状を浮き彫りにした,パネル討論会「ソフトウエアものづくり論」を4回に分けてレポートする。本記事は,その最終回である。


ソフト危機を克服するために,開発手法はどうあるべきだと考えていらっしゃいますか。上流工程と下流工程,どちらに改善の余地がありそうですか。

パネリスト
杉村 領一 氏
エスティーモ副社長 (前,パナソニック モバイルコミュニケーションズ 技術部門 モバイルシステム開発センター 所長)

小泉 忍 氏
日立製作所 モノづくり技術事業部 組込みシステム改革戦略センタ 主管技師

村山 浩之 氏
デンソー 電子機器事業グループ 電子PF開発室 室長

モデレータ:浅見直樹(ITpro発行人)

本記事は,2006年11月17日に,組み込み機器の展示会「ET2006」の会場において開催されたパネル討論会「ソフトウエアものづくり論」の内容をまとめたものである。

杉村氏:やはり上流工程が大事ですね。年間で携帯電話機を10機種開発するとします。その10機種に横断の共通アーキテクチャをいかに決めるか。これを決めるためには,どの機種にどのような機能が組み込まれていて,そのどの部分を共通化するのが最適かを考える必要がある。ここをきっちりやっておかないと,無駄が生じる。この作業は,現場主導というよりトップダウンにやらなければならない。優秀な人材ほど,現場の仕事で重要な役割を果たしているわけですが,そういう逸材にこそ,こうしたアーキテクチャ設計をやってもらいたい。私たちの経験では,上流工程の設計に力を入れたことで,下流工程におけるバグ密度が1年間で半減しました。それくらい,上流工程にメスを入れることは効果的なのです。

 アーキテクチャの重要性をひしひしと感じています。これから先もイノベーションは継続します。携帯電話には,新しい機能がどんどん追加される。ネットワーク経由で,アプリケーションをダウンロードするといった使い方も出てくるだろう。こんな時代に備えて,ソフトウエアのアーキテクチャをきれいに整えておきたい。後から機能を追加したり削除しても,システムが破綻を来さないような構造を最初から作り込んでおくべきだろう。日本型のものづくりの現場では,ボトムアップな開発がほとんどです。

 「とりあえず走ってしまえ」と開発に着手するのではなく,「基本設計」あるいは「思想」に基づいたトップダウンな発想が必要になる。ところが,トップダウンなアプローチだけでは日本の現場は動かない。アーキテクトを採用しただけでは,現場との溝が埋まらない。ボトムアップとトップダウンのアプローチをいかに並列に組み合わせるか,このプロジェクト・マネジメントが大切なのです。

小泉氏:上流工程を押さえることで,かなり多くの問題が解決します。やはり,上流の設計技法を工夫することが大事だと思っています。上流工程において検証すれば,下流のテストを簡略化できるかといえば,必ずしもそういいきれないこともある。どのレベルまでテストすればよいのか,このあたりの基準が明確になっていない。上流工程における検証と,下流工程におけるテストの関係を明確にするのは,ソフトウエア工学の大切な研究課題だと認識しています。

 日立製作所では,新たに「モデル・ベース開発」に取り組み始めました。特にデジタル家電では,製品仕様をきちんとモデル化し,それを上流で検証する必要性が高まっている。あるいは,テスト項目を自動的に生成して信頼性を高めることも重要になってきた。自動車業界でもモデル・ベース開発が進められてきたが,その波がようやくデジタル家電にも押し寄せてきた。モデル・ベース開発により,開発の抽象度を高めたことから,開発工数を下げる効果は見られつつある。ただ,設計の論理レベルと実装の論理レベルにギャップが生まれかねない。そこをきっちりとテストすることが大事になる。

 ここで,テスト工程をいかに効率化するかが悩ましい問題となっている(図7)。例えば製品テストは,ソフトの規模以上に爆発する。大まかにいえば,ソフトの規模や機能が2倍になったと仮定すれば,テスト・ケースはその組み合わせの数だけ増えるので,ざっくり4倍に増えてしまう。しかも,製品サイクルが短くなる中,どうしても開発エンジニアは製品出荷を急ぎたくなる。テストがおろそかになりかねない。テストおよび検証工程について,どういった戦略をとるかが急務の課題である。実は,テスト選任の技術者は,あまりいない。テスト技術者をいかに育成するかも大切なポイントとなる。モデル・ベースの開発に移行するのを機に,上流でテスト・検証するのが効果的だと考えている。

図7●テスト・検証の重要性が高まる
出所:日立製作所

村山氏:では,自動車業界においてソフトウエア開発の方法論として,どのような点に留意しているのか(図8)。基本的には,ソフトウエアを部品化し,それを組み合わせることを重視し,モデル・ベース開発の手法を積極的に採用してきました。特に,時間軸(異なる世代への適用)および空間軸(異なる車種への適用)のいずれの視点からも,ソフトウエア部品を再利用することを重視しています。

図8●クルマのソフト開発手法の変遷
出所:デンソー
[画像のクリックで拡大表示]

 単純に,上流工程で工夫を施したからといって,下流工程を簡略かできるというふうには考えていません。ウォーターフォール型の開発手法という意味で「上流」「下流」という言葉が使われているわけですが,私はV字型の開発では左右の形状が対称型のセットで考えるべきだと思っています。

「C」や「D」よりも「Q」が大事

小泉氏:ハードウエアと違い,ソフトウエアは必ずしもきれいに部品化できないことが多い。うまく設計したつもりでも,そのソフトウエア部品を組み合わせた結果として,「メモリーリーク」や「バッファ・オーバーフロー」といった現象が起こりかねない。やはりテストが大切なんです。実装後のテストをいかに効率よく進めるか,これが開発工程の肝になる。

杉村氏:アーキテクチャや開発体制と並んで,開発の「プロセス(手順)」も大事な課題です(図9)。いかに品質を保ち,いかに納期を守り,そして低コストに抑えるか。私の経験では,「QCD」のうち,特にクオリティを高めることを最優先しないと現場は疲弊してしまう。「納期も守れた」「コスト内に納めることができた」としても,品質へのこだわりを忘れてしまっては,現場を活性化できない。信頼性の確保を最重要課題と考えています。

図9●組み込みに適した開発手法とは何か
出所:パナソニック モバイルコミュニケーションズ
[画像のクリックで拡大表示]

 例えば,現場教育では,「べからず集」を活用しています。現場に蓄積された知恵をみんなで共有するための仕組み作りに取り組んでいる。ソフトウエア開発の現場は忙しく,なかなか勉強してくれない。そこで,ちょっと空いた時間にでも学習できる仕組みをWebで実現するなど,工夫を施している。

 バグの統計的な分析にも力を入れています。携帯電話機の機種ごとに,どの工程でどれくらいのバグが検出されたかというデータをすべて記録しています。この記録を積み上げていくことにより,経験的にそれぞれの工程におけるバグの発生件数を予見するわけです。まだ経験則の域を超えていませんが,過去のバグ統計と照らし合わせながら,現在のソフトウエア開発の状況を診断しています。予見される件数に比べて,実際に検出されたバグの件数が異常に多い場合も,逆に少なすぎる場合も,現在の設計・製造過程に問題がないかを再度見直すようにしています。

 プロセスの改善には時間がかかります。マネジメント・サイドは,効果が出るまで辛抱強く待たなければならない。一歩一歩進んでいることを現場が実感できるように,現場に効果をフィードバックしていくことが大事だと認識している。それぞれの現場は,それぞれの事情を抱えている。それを加味したうえで,現場自身が自らカルチャーを変えようとしないと,プロセスはなかなか変わらない。

ソフトの面白さを若者に伝えたい

学生の間で,理工系離れが進んでいます。テクノロジー・イノベーションの重要さと面白さを若い人たちにも伝えていく必要がありますね。

村山氏:「人」の話は,非常に重たく,最も大きな課題の一つですね。社内で最近,ソフトウエアに限らず,ものづくりのモチベーションを高めるにはどうすべきかという活動を始めたところです。なかなか思うように行かないのが実態でして...。特にソフトウエアについては,「時間いくら」で評価されることに根深い問題がある。一口でソフトウエア技術者といっても,実はいろいろな職種があります。例えば,コーティングとモデリングは全く異質の仕事です。コーディングでは分析する力が問われます。逆に,モデリングでは「概念化」あるいは「抽象化」の能力が必要になります。こういう業種の違いを本質的に理解し,技術者のスキルと成果を正しく評価する---こういう基本的なことからきちんとやりたいですね。

小泉氏:今の若い人は,製品そのものを使いこなすことには長けている。表面的な理解さえできてしまえば,その中身がどうなっているのか,どういう仕組みで動作しているのかには,あまり関心がないようですね。製造業が何をやっているのか,なぜモノが動くのか,そういうことを若手に教えていく必要があると思う。例えば,大学における組み込みソフトウエアのカリキュラムなどを強化するような動きがあってしかるべきでしょう。

杉村氏:ソフトウエアは面白いですよ。製造工程がないわけですから。一瞬にしてコピーが100万個も出来てしまう。それが世界中を飛び回るわけです。こういう喜びを多くの人に感じ取ってもらいたいですね。

 日本の開発現場が最も悩む点は何か。それは「自分の役割と専門」がはっきりしないことです。自分はプログラマなのか,テスターなのか,それともマネージャなのか。日本のソフトウエア開発現場は,このあたりが実にあいまいです。海外では,スキルが分化・専門化しており,各人が何をすればよいかを明確にしている。日本でも,スキルの分化を進め,グローバルに通じる人材を育成したい。言葉の壁があるのは確かですが,世界を目指す人材が日本からどんどん出てきてほしいですね。