| 組み込みソフトウェアテスト特集 組み込みソフトウェアテストが抱える課題とは？ 品質管理・テストツールの有効性 |
効率的に品質を確保するため、テストをどう効果的に実践するか？ これが、組み込みソフトウェア開発における最大の関心事であることは間違いないだろう。各産業で世界最高水準の組み込み機器が開発されているが、その背後では、肥大化の一途をたどるソフトウェアに対する綱渡り的な品質確保が行われ、そのため開発現場は疲弊し、ビジネス上も看過できないほどのロスを生んでいる。
今回は、組み込みソフトウェアの品質保証やテスト技法に造詣（ぞうけい）が深く、業界を上げての啓蒙（けいもう）活動や知識体系の策定作業にもかかわる、豆蔵の大西建児氏、NECエレクトロニクスの吉澤智美氏、日立製作所の加藤大受氏のお三方にテストを巡る現状の問題点から改善提言、ツール活用のポイント、テストエンジニアへのエールまで幅広く語り合っていただいた。
| 出席者プロフィール | ||
■大西建児氏 |
豆蔵 ES事業部 シニアコンサルタント 大手電機メーカー、外資系通信機器機メーカーでソフトウェアテストや品質保証を中心に担当し、現在は豆蔵で組み込み機器メーカーやSIerに対し、テストや品質改善に関するコンサルテーションを行う。ASTERの副理事長であり、ASTERが2008年1月に主催する「JaSST 2008 東京」の共同実行委員長も務める。また、「SQuBOK」策定部会のメンバでもある。 |
|
■吉澤智美氏 |
NECエレクトロニクス マイクロコンピュータ事業本部 マイコンソフトウェア事業部 チームマネージャー NECエレクトロニクスに入社して以来、コンパイラなど自社製マイコン向け開発ツールの開発に従事。ツール自体の品質管理やそれを活用するユーザーのソフトウェア開発を支援。日科技連の高品質ソフトウェア技術交流会への参加など社外活動も積極的に行い、現在、ASTERの理事を務めるほか、SESSAMEにも個人会員として参加。 |
|
■加藤大受氏 |
日立製作所 ソフトウェア事業部 ネットワークソフトウェア本部 Entier事業推進室 技師 外資系・国内のパッケージベンダで品質保証を担当。現在は日立製作所で組み込みRDBMS「Entier」のエバンジェリストを務め、個人でもオープンソースRDBMS「Firebird」のユーザー会を主導するなど開発・テスト領域で幅広く活躍する。IPA/SEC（組み込み事業領域）に設置されたソフトウェアテスト技術準備委員会のメンバも務めた。 |
|
| 肥大化しブラックボックス化する組み込みソフトウェア |
── ご自身の仕事とのかかわりから、組み込み分野における品質保証やテストの現状をどのように感じていますか？
| 豆蔵 ES事業部 シニアコンサルタント 大西建児氏 |
■大西 業界全体では体力のある企業ばかりではないので、QA（Quality Assurance）チームを立ち上げていないところも多いですね。それとセットメーカーは部品を集めて製品を作りますが、部品のサプラヤによって実力差がはっきりと出るのが、組み込みソフトウェアでしょう。自動車産業でいえば、少数の大手メーカーなら品質はしっかりしていますが、町工場から発展して、ときの流れでソフトウェア開発まで手掛けるようになったサプライヤだと、品質も何もあったものではない……、ということはよく聞く話ですね。
■加藤 組み込みRDBMSを推進している立場からすると、組み込み系は、部品を組み合わせてソフトウェアを作るノウハウを持っていない企業が多い気がします。ソフトウェアの規模が急に大きくなり、これ以上自分たちだけで一から十まで作れないという状況になってきています。そのため、最近ではエンタープライズ系のように製品ベンダからミドルウェアを買ってくる企業が増えているようです。しかし、買ってきたミドルウェアの品質をどのようにして担保するのか、それで悩んでいる企業がここ1年で明らかに増えてきたと感じています。
従来、コンポーネントを使うといっても、TCP/IPスタックのように限られた領域だったのが、最近ではデータ管理なら“データ管理をミドルウェアに全部任せましょう”というような流れになっており、これまで自社開発によりホワイトボックスだったものがブラックボックス化してしまいテストの方法や品質の考え方が大きく変化してきている。特にプラットフォームがバラバラな組み込み系の場合、ミドルウェア製品といっても、特定の顧客向けにビルドし直したりするので、調達側も供給側も品質をとらえにくいようですね。
■吉澤 自社で機器からソフトウェアまで開発している企業が存在する一方で、機器は自分たちで開発するけど、ソフトウェアはほかで安く作らせるという企業もあって、それを受託する側は（コスト制約などで）少し辛いものがあるような気がします。一方、委託する側はどうかといえば、加藤さんが言うような“ソフトウェアを買ってくるのと同じ問題”を抱えているようです。
最近、「コードが肥大化したのでコンパイラの最適化でなんとかしたい」という話をよく聞くのですが、中身を見てみると不要なコードがいっぱい入っているんですね。けれど「誰が作ったものか……。どう保守してよいのか分からないので怖くて削れない」という状況のようです。結局、人で見切れるコード量には限度があり、その枠を超えてしまったものだから、開発が混乱し、テストの方法も分からないので「大変だ大変だ」となっているのでしょう。
■加藤 わたしは、エンタープライズ系から入ってきたので余計に感じるのかもしれませんが、「何でそんなに大きいの？」というぐらい組み込み系はコード量が多いですよね。オープンソースRDBMS「PostgreSQL 8.0」でコード量は80万行ぐらいなのに、組み込みソフトウェアは普通に100万行を超えていたりする。それは人で見切れないですよ。過去の資産を利用したり、なるべくソフトウェアで機能を実現する傾向が強まっていることもコードの肥大化に影響しているのでしょうが、要らないコードを削るコストさえないのが現状のようです。
| 設計が悪ければ品質は高まらないの大原則 |
── では問題の本質はどこにあるのでしょうか？
■大西 日科技連が先ほど（2007年9月上旬）開いた「ソフトウェア品質シンポジウム」の基調講演で、トヨタ自動車の重松崇（常務役員）さんが話していたことが印象的でした。「トヨタ生産方式をソフトウェア開発にも生かせないのか」という質問に対し、「ソフトウェアは生産ではなく設計によるものなので生産のための方式は適用できない。それよりもソフトウェア産業が培ってきた開発手法を勉強している」という内容の答えだったのですが、これは本質を突いています。“コードは生産するものではなく、設計するもの”なんですよね。
■加藤 昔は、設計にもっと時間をかけていませんでしたか？ 日本企業は欧米企業と比べて設計の時間が短い気がします。それと、「みんなで努力すればうまくいく」という生産の考え方をソフトウェア開発に当てはめ、みんなで苦労しているようにしか見えないところも……。設計自体が悪いと、いくらテストしても品質は上がらないので、できる人に十倍コードを書かせた方が品質は絶対よくなります。技量によって作業量を変えないといけないのに、どうも日本企業の場合は作業を均等に割り振っているように見えます。
■吉澤 平等に仕事を割り振っても、結局はできる人が一番ヒイコラと苦労することになるのが実態でしょうね。
■加藤 それで嫌になると外資に転職するというパターンですね（笑）。
■大西 キチンと設計されないまま納期優先で開発が進むと、テスト自体の設計も十分に練られないままテストを実施しなければなりません。こうなると、テスト件数が爆発します。典型例として、携帯電話の分野ではもう完全な“人海戦術テスト”が多いと聞きます。本来、キチンと設計すべきところができていないと、どうやってもテスト件数は爆発してしまいます。
■加藤 設計する人に実装能力がないケースも目立ちますね。アルゴリズムを書いたことのない人が設計をやっていたりする。実装が分かっていて設計するのと、分からないで設計するのでは、中身が全然変わってきます。
■大西 それは日本の悲しいところで、ソフトウェア工学やコンピュータ科学などソフトウェア開発に本来必要な基礎知識を持たない人が、日本ほど実際の開発に携わっている国は世界にないのかもしれません。
それと、なぜこんなにコードレビューしないの？ という思いはありますよね。ツールをうまく活用すればそんなに難しい話ではないはず。コード規約違反などは、人が根掘り葉掘りやるより、ツールでやれば簡単なんです。ツールのコストなんて人の工数に比べたら安いもの。それなのにあまり使われていない……。
結局、コードの品質が悪いからテストで苦労する。なるべくしてなる結果なのです。そして、本来掛けなくてもよい多大なコストを品質確保に当てている。それは、IPAの「組込みソフトウェア産業実態調査」でも明らかで、納期と品質は予定通りなのに、予算が超過しているプロジェクトが非常に多い。いくら品質を確保できても、利益が出なかったら徐々に競争力は奪われてしまいます。
■加藤 このような課題を抱えたまま何とかなっているのは、安くテストを実施してくれるところを見付ける努力をしているのと、それをビジネスにする企業が現れたことでしょうね。アルバイトを集めて人海戦術テストをやる会社とか……。
■吉澤 5年前には、テストを請け負う会社はこれほどなかったですよね。これに頼ってばかりいると、テスト件数の爆発は全然防げないですよね。
| 上流工程にテスト設計を盛り込んで効率化 |
── 上流から品質を作り込むという考えは以前からあり、さまざまな手法も提唱されていますが？
■吉澤 設計に状態遷移図などを使う企業は昔からありましたが、そうした手法でも追い付かないぐらいコードが爆発しているんだと思います。
■加藤 状態遷移図もUML図も書いているんでしょうが、その設計自体が正しいかどうかの実装前の検証がエンタープライズ系に比べて不十分な気がします。ハードが絡んで後回しになる面もあるのでしょうが。
■大西 組み込み系は、エンタープライズ系のようにアプリケーションの基盤をキチッと固め、その上で開発し、進化させるという文化でないことが多いことも影響しているでしょうね。例えば、内蔵ソフトウェアがギガバイトに迫るほど大きく、複雑になっている携帯電話ですら、アプリケーションの基盤は脆弱（ぜいじゃく）です。その上で、取りあえず動けばいいと、パーツをブロックのようにカチャカチャと組み合わせている。それと、組み込み系の嫌らしいところは、メモリ制約で複数のアプリケーションが無理繰りにリソースを共有していること。その品質を確保するのが難しいのは、ある意味で当たり前の話なんです。
── 組み込みソフトウェア開発では通常、全行程の50％以上をテストに割かれるといわれます。それを削減するにはどうすればよいのでしょうか？
| NECエレクトロニクス マイクロコンピュータ事業本部 マイコンソフトウェア事業部 チームマネージャー 吉澤智美氏 |
■吉澤 どのプロジェクトでも始めからテスト工程を50％以上と見積もっているわけではなく、結果的にそうなっているようです。ASTERでは、上流工程にテスト設計を組み込み、テストを効率化すべきと提唱しています。ただ、多くのプロジェクトでは、それを実践できる技術者がおらず、いたとしても時間の余裕がないというのが現実でしょう。
■大西 テストに問題を抱えている企業で共通していえるのは、“戦略の不在”です。製品を出すことによるビジネスゴールと直結したプロジェクト戦略を立てれば、製品によってQCD（品質：Quality、コスト：Cost、納期：Delivery）バランスは違ってきます、極端なことを言えば、品質を重視しないプロジェクトもあり得るわけです。ただ、それはプロジェクト当初に決めておかないと結局、後ろのテスト工程になって右往左往することになります。
もう1つ言えることは、現場の人があまりテスト技法を知らない、ということ。現場の人をその気にさせるには、ちょっとした工夫でいいので、「ほら、こんなに楽になるでしょう」と説得できる成功体験をさせてあげることですよ。
■加藤 あと、実装のリーダーがプロジェクトマネージャになるケースが多いのですが、テストのことをよく分かっているQAリーダー経験者がマネージャをやると、プロジェクトはかなり楽になりますよ。“テストのしやすさまで考え設計”してくれると、テスト工程は全然違ってきます。QAリーダー経験のあるマネージャならその辺が理解できるはずですから。
また、組み込みソフトウェアの開発に携わる人ならさんざん苦労していると思いますが、プロジェクトを始める前に過去のプロジェクトがなぜ失敗したのかをちゃんと見直してほしいですね。そうすれば、テスト設計の位置付けも変わってくるはずです。
| 関連リンク：“Excelでテストケースを管理”が行き詰まったなら…… | |
| 優秀なエンジニアを投入し、ツールをフル活用する |
── テストの効率化にツールの活用は有効なのでしょうか？
■大西 ツールに移行していくのは自然な流れだと思います。人海戦術テストで行っていることの多くは、ツールで自動化できます。これまで自動化が進まなかったのは、チェックポイントが複数にまたがっていて、1つ1つの検証は自動化できても、それらを同期させて検証することが困難だったからです。しかし、近年のロボット技術や画像認識技術の進化で、そのハードルも徐々にですが下がってきています。
■加藤 確かに、携帯電話の実機テストもロボットシステムでできるようになって、かなり楽になりましたね。数年前、ある金融機関のオンラインバンキングシステムのテストで、140機種もの携帯電話端末で動作を検証し、1つ1つ表示画面をデジカメで撮影して納品するという気が遠くなる作業を手掛けた経験がありますが、ロボットを使えたらどんなに楽だったか……。
■大西 人が寝ている間も指示通り働いてくれるわけですから助かりますよね。
| 日立製作所 ソフトウェア事業部 ネットワークソフトウェア本部 Entier事業推進室 技師 加藤大受氏 |
■加藤 テスト自動化ツールも使い方次第では効果が高いですよね。わたし自身のエンタープライズ系での経験で言えば、全テスト工程の10％ぐらいは自動化できるはず。その分、人でしか行えないテストに時間をかけられるので品質が向上します。自動化ツールを入れると、人が帰った後も含め24時間の枠でテスト作業の割り振りを考えられるのが大きいと思います。
ただ、“ツールを使いこなせるテストエンジニアが1人いること”が前提条件です。ツールによってクセがあるので、何を自動化できて、何が自動化できないかを理解した上で運用することがとても大切です。
■大西 それは感じますね。ツールを導入してハッピーになりたかったら、それなりのエンジニアをアサインしてください、と。
■吉澤 静的解析ツールでも同じですね。わたしは“お世話係”という呼び方をしているんですけど、やはりツールのクセを熟知したエンジニアが1人いると効果が全然違ってきます。最近の静的解析ツールはインターフェイスもよくできているし、単純にメッセージを出力するだけなら簡単なのですが、そのメッセージを読み取り、自分たちのドメインに照らし合わせてアクションの要不要を判断し、ルールをチューニングできるお世話係が必要です。
静的解析ツールを使ったからといって即バグが減るわけではないのですが、誰もが分かるコードになるのでレビューがしやすくなるなど、品質のボトムアップができます。ソフトウェア開発を外部に委託している企業では、成果物の検収で静的解析ツールを使うケースも増えていますし、自動車業界の「MISRA C」ように業界標準のコーディング作法を取り入れている業界もあるので、そうなると静的解析ツールは絶対欠かせないテストツールになりますね。
| 関連リンク：短納期、低コストのプレッシャーに負けたくない！ | |
| 暗中模索ながらテストを重視し始める |
── 全般的にテストの重要性は認識されてきたのでしょうか？
■大西 プログラミング技法や開発環境の研究、トレーニングへの力の入れようと比べると、テスト技法への投資はまだまだですね。それでも業界全体として、品質による問題で大変損をしていることは確かで、だからこそ、経営者が問題意識を持ち、メディア的にも注目を集めているわけです。
■吉澤 10年前、テスト技法に関する書籍は数冊しかなかったのに、いまでは山のように出ていますよね。ソフトウェアテスト技術者交流会のメーリングリストでも最近、「テストを担当することになりました。どう進めてよいのか分からないので、教えてください」みたいなあいさつをして新規登録する人がとても増えています。それから、企業もテストを重視し始めているように感じます。ただし、何をどうやったらよいのかまでは分かっていない。“ボトムアップで何とかしよう”というような感じでいる企業が多いようです。
■大西 ただ、“いまほどテストエンジニアを目指すのに適した環境が整っていたことは過去にはない”ですよね。わたしも策定作業に加わりましたが、ソフトウェア品質の知識体系「SQuBOK」のガイドがまとまり、ASTERが主催するシンポジウム「JaSST」もテストをキーワードにしたエンジニアの情報交換の場として定着してきましたし、回を重ねるごとに内容も充実しています。「JSTQB（JapanSoftware Testing Qualifications Board）」のテスト技術者資格も認知度が上がっています。
■加藤 ただ、テスト技法を勉強する手段や知識体系は増えたのに、書籍や雑誌を買ったり、Web記事を読んだりするのは、残念なことに若い世代じゃないんですよね。
■大西 そうですね。セミナーなどで若い参加者に「勉強している？」と聞くんですが、「してない」という答えが多いです。会社にもあまり投資してもらっていないし、自己投資もあまりしていないという状況のようです。
■吉澤 もっと本やWebを読んで勉強してもらいたいですね。まずは、キーワードを頭に入れるところから始めるとよいです。知識と経験が身に付いてくれば徐々にそれらがつながっていくはずです。組み込み系では今後ますます、実力のあるテストエンジニアが求められてくるはずですから、自己投資する魅力は十分にあると思います。
| 関連リンク： | |
|
|||||||||||
|
|