特集 組込みソフトウェア品質の向上とテストツールの関わり 〜組込み開発の実体分析と テストツール導入のポイント〜 本特集では、株式会社豆蔵のシニアコンサルタント大西建児氏にご寄稿いただき、組込みソフト開発業界全体の課題意識と、 ソフト品質の向上を目的としたテスト体制、 テストツール導入のポイントについて解説いたします。 （ ガイオ・テクノロジー） はじめに 世の中は日々進歩していると言われます 4M ステップに対して、 400 人の開発者と めずに 「 ソフトウェア」に関わる工数のみ ほぼ同数！の品質検査担当者がいたそう で比較します。 開発工程をソフトウェア実 です。 装 ・単体テスト、ソフトウェア詳細設計、ソ が、果たして組込みソフトウェア開発の現 最新のVista になると、その規模は50M 場はどうでしょうか。ハードやソフトを構成 ステップを超えるといわれ、 約 4000 人の 求定義とすれば全体の 28% となり、テスト する技術は確かに進化していますし、 組 開発者とほぼ同数の品質検査担当者がい 工程をソフトウェア総合テストとソフトウェア 込み分野で作られる製品は、日進月歩で るという、国家的プロジェクトと呼べるほど 結合 ・結合テストとすれば全体の17%とな 新しいモノが続々と世の中に登場していま の膨大なリソースが投入されています。 す。 お馴染みの携帯電話を例にあげてみま これに対して、同じように大規模複雑化 フトウェアアーキテクチャ、 ソフトウェア要 ります。人数比に換算すると、約 3:2 とな ります。 している携帯電話をはじめ、 組込み製品 しょう。世の中にアナログ方式の携帯電話 の品質はどの程度の技術者で行なわれて が現れたころの付加機能といえば、 せい いるのかを見てみましょう。 ぜい短縮ダイヤルくらいだったと思いま す。 アナログからデジタル方式になると、 電話帳や、スケジュール帳、それにショー 組込み開発の実態と トメール、 電卓などと徐々に通話以外の 抱え持つ悩み 機能が増えました。それが今や、ゲーム や音楽が楽しめ、ラジオが聴けてTVも見 本稿では、世の中の動きを大 られ、 カメラや GPS まで搭載と、まさに、 枠で掴むために、 経済産業省 詰めこめられるものは何でも詰め込んでい の外郭団体である情報処理推 るといった感すらあります。 進機構 （ IPA）がまとめた調査 この携帯電話 （ 第 3 世代）のソフトウェ 結果 （ ※ 2）を参照します。 アの規模を取り上げ、開発規模の増加に 右下の図 1 からソフトウェアエ ついて考えてみましょう。 ある電機メーカ ンジニアが 50.2% を占めている の技術レポートによると、ファームウェアで のに対して、テストエンジニアと 3M ステップ程度、全体では10Mステップ QA スペシャリストは、両者を合 以上にも及ぶそうです。これがどれくらい わせて15.9% ということが分かり の規模か OS と比べてみましょう。 ます。ここからは、開発者と品 Windows XPが35Mステップ、Windows 質に関わるエンジニアの人数比 95 が15M ステップ程度 （ ※ 1）だそうで が約 3:1 という関係が見えてき す。 Windows の場合、 大規模で複雑な ます。 ソフトウェアの品質を確保するために、 開 少し角度を変えて工数で見て 発者と同数の品質保証担当がテストを実 みましょう。（ 図２参照）ここでは 施しているとのことです。 ちなみにWin- 分かりやすくするために、 シス dows NTの開発においてコードボリューム テムレベルやハードウェアを含 2 GAIO CLUB 2006 Vol.2 図１ 職種ごとの人数比率 図２ 工程ごとの投入人数比率 この人数比は適正なのでしょうか。先の エンジニアの比率からすれば、 この数字 のから、 OJT や独学といった個人レベル 費の削減すら狙っていることが分かりま のものまで、 といったようにです。 す。つまり、一般的なツール購入の理由 だと矛盾することに気づきませんか？実は 「 ツールの導入」という手段により設計品 は、 QCD 全ての要因を満足させることな このデータからは、本来必要な人員より少 質を確保しようとすることは、 代表的なア のです。これは少々欲張りのように見える ない人数で、テスト工程を回しているので プローチの一つと言って良いでしょう。 こ のですが、ツールを導入したからといって はないか？という仮説が導かれるのです。 のことは、ツールを購入した動機を見ても 簡単に効果が出せるわけではありません。 分かります。 なぜ簡単ではないのか？この疑問を考え この仮説が正しいとなると、十分な品質 を確保しようとするなら、テストに関わるエ 図５では、ツールを購入した第 1の理由 ンジニアに大きな負担がのしかかるととも が品 質 確 保 であり、 同 じくらいにスケ に、 それなりにコストがかかっているであ ジュールの短縮を望んでおり、 また開発 るために、 以降はツールに的を絞った形 で話を展開します。 ろうことが予想されます。この予想の裏付 けを得るために、データを更に見てみたと ころ、 どうやら的外れでもなさそうなので す。 この認識は、 プロジェクト責任者による プロジェクトの評価結果のデータ （ 図３参 照）から得ました。これによると、機能や 製品品質、 出荷後の不具合は大方計画 を満たしていることが分かります。しかし、 開発期間や開発費用が計画通りに収まっ ているプロジェクトが半分にも満たないこと も分かります。以上のことから、テストに関 図３ プロジェクトの評価 わる人員は計画通りにしか割り当てられな いながら、実際のテスト工数は、予定より もうんとかけることで、何とか品質を確保し ているという、組込みソフトウェア開発での 実態が見えてくるのです。 では、 どうして開発期間や開発費用を 見積もりから超過させてでも、品質へ投資 しようという力が働くのでしょうか。 大きな 要因として、 ソフトウェア品質の確保が経 営課題となっていることがあげられます。 事業責任者が回答したデータによると、 組込みソフトウェア開発に課せられている 課題で最たるものは 「 設計品質の向上」 だったのです。（ 図４参照）その次が 「 開 図４ 組込みソフトウェア開発に課せられている課題 発期間の短縮」になっています。 品質が経営課題となっているのは、 市 場不具合による利益損失やブランド価値 の低下による逸失利益の発生、採算性の 低下など様々な理由をあげることができる でしょう。事業責任者からの 「 品質を上げ よ」という要求と、開発現場の危機意識が 合わさって、 多くの組織で真剣な取り組 みが行なわれているのです。 一口に 「 設計品質の向上」と言っても、 取り得るアプローチは多岐に渡ります。例 えば開発プロセスそのものの見直しや、 開発標準の策定といった組織レベルのも 図５ ツールを購入した理由 GAIO CLUB 2006 Vol.2 3 ツール導入のポイント ツールといっても多くの種類のものが存在しま す。 ソフトウェア品質、 特にテストツールに関 しても実に様々です。 （ 表１参照） テストツールはどのようなものと捉えれば良い テストツールの概要が分かったところで、次に 二つ目にツールの 「 機能不足」があげられ 本題である 「 なぜツール導入効果が簡単に出 ます。実際に導入してみると、実際にやりたい ないのか？」ということを説明します。私のこれ ことができないとか、使用方法に制限があり使 までの経験や、コンサル活動でヒアリングをした えないケースが該当します。 内容を通して知りえたツールを使いこなせない 三つ目は、テスト手法や技法に対する「 スキ 理由の幾つかと、それを少し整理したものが表 ル不足」や 「 理解不足」です。 テストツール を使う技術者自身に問題があるということです ２です。 のでしょう。 テストツールとはテストを円滑にす ここにある様に、 ツールを使う上での課題は るための道具です。また、テストを実施するた 大きく３つに分けられます。一つはツールを使う めの物理的環境であり、 ハードウェア／ソフト 目的が無いとか、 分かっていないというツール ウェアの両方を指すものです。 の 「 利用目的」がはっきりしていないということ それから、テスト計画／設計／実施／管理 ジェクトのためのインフラともいえます。 テスト ツールの種類とテストプロセスを、 図６に簡単 にマッピングしてみましたが、ここからもツール がインフラであることが分かるでしょう。 と表現するのが妥当でしょう。 こういった要因から、ツールを入れたとしても 簡単にはその効果が得られないのです。 ツールはテストを円滑にするための道具であ です。 全てのテストプロセスで用いるため、テストプロ から、「 使えない」のではなく「 使い切れない」 例えばメディアでの情報や、 ツールベンダの ると言いましたが、道具だからこそ、それに振 セールストークにのっかり、 トップダウンでツー り回されないようにしなくてはなりません。 その ルを導入してしまうと、 開発現場における利用 ためにはツールの導入時にこそ、必要性を投 目的がはっきりとしなくなるなんてことは、よくあ 資対効果を含めて十分に検討しなくてはなりま ることでしょう。 せん。 本稿では、 投資対効果をあげるためにツー 分類 概要 テスト設計ツール テスト設計や テスト・ データの作成を支援するツール ル導入時に注意すべきポイントについてツール GUIテストツール GUIやW e bブラウザの 操作を記 録し，テストスクリプトで操 作を再生することで，テストの 自動化を支援するツー ル。 を自作する場合と、 市販品を買う場合で、そ 性 能テストツー ル テスト対象の システム に負 荷を与えることにより，パ フォーマンス関 連の テストを可能にするツール。GUIテストツールと連携 する製品 も多い。また，CP U負荷 やリソース利用状況 の測定機能 を提供するものもある。 れぞれ３つずつ紹介することにします。 テスト管理ツール テスト計画，設計 ，実施 という一連のアクティビティ管理を支援するツール 。テスト設計ツールや不具合分析ツール などと連携したり， 一 つの製 品にパッケージングしているものもある。 単 体テストツー ル 開 発 者による単 体テストの 実施 を支援するための，フレームワークやライブラリを備えたツール 。xUnit 系のツール もこの カテゴリであ る。 テスト評価ツール カバレッジの計測 やメトリクスの 収集を通して，テスト実 施の効 果を測定 し，評価 を支 援するツール 。 静 的 解 析ツール プログラム を実行 せずに，コードを解析 してコードの 品質 レベルをチェックするツール。 動 的 解 析ツール プログラム を実行 している状 態で，メモリー使用状況の監視やランタイム・エラーのチェックなどを行うツール 。 不具合分析 ツール 不 具 合のライフサイクル全 般を一元管理するツール。テストによって発生する不具合報告 の 作成 や対処内容 ，修正確認などの情 報 を収集 し，分析用の可視化 データを提供する。 構 成 管 理ツール テスト対象システムの 構成管理 を支 援するツール 。 計測器 アナライザ ，LANモニター，オシロスコープ，デジタルハイ 主 にテスト実施結果 の判定を支援するために用いられる機器。プロトコル・ コーダ，電流 /電圧計 ，温度計 などテスト項 目により幅広い機材が用いられる。 そのほか特定目的 に用いられるツール 例 ：人間 の手による操作をマニュピレータなどで自動入力可能 とするもの。外部接点入力 を模 擬するための SW （ スイッチ）ボックスと いった主にハードウエアで構成 されるテスト用ツー ル。テスト結 果を記録するための画 面キ ャプチャリングするもの 。キ ー ボー ドの入 力 を記 録す るアプリケーション，テスト・ドライバ やスタブを逐次実行 させるシェルスクリプト。 表１ テストツールの種類 （ 「 ステップアップのためのソフトウェアテスト実践ガイド」より引用 ※３） ツールを自作する場合 「 ポイント１：リソース、コストは作る前に 明らかにし確保しておく」 市販品なら価格はだいたい分かりますし、 オープンソースならコストはダウンロードするだ けだと、かかりません。ですが自作する場合、 特に少数 （ 時には 1 人）の開発者で作成する テスト管理 ツール テスト評価 ツール 構 成 管 理ツール 不 具 合 分 析ツール GUIテストツール 性 能テストツール 単 体テストツール 動的解析ツール 実施 管理 テスト管理ツール 計画 なら往々にしてスケジューリングがいい加減にな り、 どれくらい工数をかけるべきか予め決めて ないことがあるでしょう。 その結果、 テストをし ているのかツールをいじっているのか分からなく なるというくらい、想定外に手間をかけざるを得 ないことが発生してしまいます。 設計 テスト設計 ツール 静 的 解 析ツール これでは明らかにコストのかけ過ぎなのです が、開発現場では意外とこういった負の工数に 無頓着だったりします。 こういった状況だと、 図６ テストプロセスとツール ツールの完成度が低く思ったよりも使われな 課題 の分類 目 視のほうがテスト実施 が速く済む 利用目的 ツールを買う予算が無 い 利用目的 自動化する時 間がない 利用目的 効率的 な使い方が分か らない スキル不 足 ツールにどのようなものがあるか 知 らない スキル不 足 そ、あらかじめどれくらい工数 （ コスト）をかけ ツールを使 いこなせるテスト技術者 がいない スキル不 足 て良いのかを、 作る前にはっきりさせておき、 メトリクスが取 れても意 味がわからない スキル不 足 テストの記 録をとっても振り返らないから、取 るだけム ダ スキル不 足 以前自動化 したことがあるが、結局使われていない スキル＆理解不足 ツールを使 っても工数が削減できるかどうか 分からない スキル＆理解不足 ＤＢのデータをそのままツールに落とせない 機能不足 アーキテクチャとの整合性が取 れてない 機能不足 フラッシュ，Shockwaveなど） Webの テストで使えない（ 機能不足 テストツール がバ グば か りで使えない 機能不足 テストツール の使い勝手 がよくない 機能不足 テストスクリプトのメンテナンス工 数が掛か りすぎる 機能 &理解不足 以 前テストを自 動 化しても楽にならなかった 機能 &理解不足 表２ ツールを使いこなせない理由 4 かったり、 バグが多くなったり、 保守性が悪く 課 題の 内容 GAIO CLUB 2006 Vol.2 再利用できないものになってしまったりといった 弊害が発生しやすくなります。 自作だからこ 適切なリソースを確保しておくことが大事なので す。 「 ポイント２：使い捨てか再利用するかの 方針を先に決めておく」 作る前から再利用が前提であるのなら、 この 点であまり問題にはならないでしょう。 しかし、 最初は使い捨てするつもりが、 現場での受け が良いために、 そのまま使い続けられる様に なってしまうと、問題が起きてしまうことがありま 「ポイント２：サポート体制の充実度や ユーザコミュニティの有無を調べておく」 するはずです。 または、 問題がユーザからレ ポートされたなら即修正した上で、 パッチをリ す。いざ次のバージョンになってから再利用す 評価版でインストールの流れを把握していた リースしたりその内容をユーザコミュニティに通 るために直そうとすると、ハードコーディングな としても、 製品版のツールを実際にインストー 知したりといった努力を、日々行なっていること 箇所の見直しや、 構造がいい加減だったりす ルしたり、 他の類似ツールからスクリプトや でしょう。 こういったことはツールベンダの大小 ると、 作った本人が手を入れるときでさえ、思 データをインポート しようとすると、想定外の問 ではなく、ツールをユーザとともに良いものにし いのほか苦労することになります。 ですから、 題に出くわすことは別段珍しくありません。この たいかどうか、 といった作り手としての姿勢によ 一度使い捨てを前提に作り出したのなら、 もし 様な時は、 どうしてもツールベンダのテクニカ ることなのだと思います。 そのツールを今後使い続けることになれば、リ ル／カスタマサポートに頼らざるを得ません。 ファクタリングや、 一から作り直すくらいの覚悟 ですがベンダによっては日本語サポートが貧弱 をしておかなければなりません。 （ 無いことも）だったりサポートが有償 （ 思いの さいごに ほか高額なことも含め）だったり、 対応した技 「 ポイント３：メンテナンスを誰がいつ、ど う、 やるかを決めておく」 術者のスキルが低く、適切なサポートが得られ ないことが有りえます。 自作のツールは大抵少人数 （ 多くは 1 人）で 外資のツールベンダで日本語サポートは充 作られることが多いため保守のためのドキュメン 実してなくとも、インターネット上のコミュニティ トがなかったり、 ソース内のコメントが貧弱だっ が活発であることはあります。そういった場合、 たりします。作った本人のみしか使わない使い 英語の壁を乗り越えられるなら問題を低減する 捨てのツールならそれでも構わないのかもしれ ことができます。 ませんが、 大人数で使ったり再利用するツー 信頼できるテクニカルサポートをツールベンダ ルであるならば、製品と同様に保守体制を作る から受けられるかどうかは、お試し版の評価時 べきです。こういったことは開発メンバの問題と に、幾つか質問を出してみることで確認するこ いうより、プロジェクトマネジメント面で考慮すべ とができるでしょう。 また、 ユーザの生の声が きことなのですが、 自作ツールのメンテナンス どれくらいツールベンダでの製品開発に反映さ が必要になるかどうかは、なかなかプロジェクト れているか、ベンダの営業部門に尋ねてみる マネージャやリーダだと気づかないことも多いで とよいでしょう。 ユーザの顔を向いているツー しょう。ですから、ツールの保守体制は開発側 ルベンダなら、製品ロードマップに対して、ど でまず検討した上で、 プロジェクトマネジメント のようにユーザの声が反映されているかを、 側と協議した方がスムーズになるでしょう。 しっかり説明してくれるはずです。 ここまでで、 ツールを導入するためのポイント を幾つか紹介してきました。最後に組織面での ポイントについてお話しします。ツールを上手く 使いこなすためには何よりも、管理層 ・技術者 層双方で 「 品質向上」に向けてベクトルを合わ せることが重要です。 目先にかかってしまうコストだけから判断して、 「 ツールは高すぎる」という話しをよく聞きます。 この様な話しを聞く度に 「 投資対効果をきちん と分析した上で、本当に高いのかどうか真剣に 考えていないことの方が多いのでは？」と私は 感じざるを得ません。 ツールを使いこなすこと で、 品質を確保した上で開発者の生産性を高 め、 かつ開発組織全体の競争力が増すように なっていかないと、グローバルな組込み開発の 競争には生き残れないといっても過言ではな い、 今そういった状況であることを是非知って おいて欲しいと思います。 「 ポイント３：不具合情報をオープンにし ているかどうか確認しておく」 ツールの不具合が発生する度に、 ツールベ 市販のツールを買う場合 最後は少しばかり大きな話になってしまいまし たが、 ともあれ 「 道具」としてテストツールを上 手く使いこなすにはどうすればよいのか、といっ ンダへ問い合わせることは、結構ユーザにとっ たことを検討するきっかけに本稿がなれば幸い てはストレスがかかることです。 新しいツール です。 だったりメジャーバージョンアップ直後だと、そ 「ポイント１：お試し版で導入前検証す る」 実際の開発環境でお試し版を入れて、 ツー の頻度が多いことだってあるでしょう。 「 だった ［ 参考文献］ ら、 （ 不具合があることを）最初から言ってお ※ 1 日経コンピュータ 2006 9/4 号 ニュース いて欲しいよな」というユーザの怒りや憤りの ＆トレンドより ※ 2 経済産業省 2006 年版組込みソフトウェ ルの動作だけでなく開発環境の従来の動きが 声を聞くことは、 ツールベンダにとっても本意 問題ないことを確認することをおすすめします。 ではないはずです。ですから心有るツールベ ア産業実態調査報告書(平成 18 年 6 月) ツールによってはインストールに手間取ったり、 ンダなら、 不具合情報をオープンにして、 い ※ 3 ステップアップのためのソフトウェアテスト 想定外の制約条件 （ OS や DB のバージョンに つの修正バージョンで対応できるかを明らかに 実践ガイド， 日経 BP よって上手くいったりいかなかったり）があった り、 別のアプリケーションの動作に問題が起き たりするなどといった問題を、 未然に防ぐこと ができるからです。 また、 カタログを見ただけでは分からない実 際の使い勝手を確認したり、 従来の開発プロ 【 執筆者】 大西建児 （ おおにしけんじ） 株式会社 豆蔵 シニアコンサルタント セスにどれくらい影響があるか （ テストツールを ・略歴 ：国内電機メーカー、外資系通信機器ベンダーにてQA 活動やテストを行なった経験を活か し、テストをはじめソフトウェア品質改善全般のコンサルティング活動に従事。NPO 法人ソフトウェア 導入する場合は、多かれ少なかれ開発プロセ スの見直しが発生します）を想定することは、 テスト技術振興協会(ASTER)の理事や JSTQB （ Japan Software Testing Qualifications Board）技術 委員などとして、 テスト手法や技術の普及、 発展に取り組む。 スムーズなツール導入のためには非常に意味 ・執筆活動 ：「 ステップアップのためのソフトウエアテスト実践ガイド」著 （ 日経 BP，2004 年） 、「 基 があることです。 本から学ぶテストプロセス管理」監訳 （ 日経 BP， 2004 年） 、「 ソフトウェアテスト２９３の鉄則」（ 共 訳 - 訳者代表， 日経 BP， 2003 年） 、「 ソフトウェアテストPress, 特集記事， 技術評論社」 等 GAIO CLUB 2006 Vol.2 5
© Copyright 2026 Paperzz
