組込みソフトウェア品質の向上とテストツールの関わり

世の中は日々進歩していると言われますが、果たして組込みソフトウェア開発の現場はどうでしょうか。ハードやソフトを構成する技術は確かに進化していますし、組込み分野で作られる製品は、日進月歩で新しいモノが続々と世の中に登場しています。
お馴染みの携帯電話を例にあげてみましょう。世の中にアナログ方式の携帯電話が現れたころの付加機能といえば、せいぜい短縮ダイヤルくらいだったと思います。アナログからデジタル方式になると、電話帳や、スケジュール帳、それにショートメール、電卓などと徐々に通話以外の機能が増えました。それが今や、ゲームや音楽が楽しめ、ラジオが聴けてTVも見られ、カメラやGPSまで搭載と、まさに、詰めこめられるものは何でも詰め込んでいるといった感すらあります。

この携帯電話（第3世代）のソフトウェアの規模を取り上げ、開発規模の増加について考えてみましょう。ある電機メーカの技術レポートによると、ファームウェアで3Mステップ程度、全体では10Mステップ以上にも及ぶそうです。これがどれくらいの規模かOSと比べてみましょう。
WindowsXPが35Mステップ、Windows95が15Mステップ程度（※1）だそうです。Windowsの場合、大規模で複雑なソフトウェアの品質を確保するために、開発者と同数の品質保証担当がテストを実施しているとのことです。ちなみにWindowsNTの開発においてコードボリューム4Mステップに対して、400人の開発者とほぼ同数!の品質検査担当者がいたそうです。
最新のVistaになると、その規模は50Mステップを超えるといわれ、約4000人の開発者とほぼ同数の品質検査担当者がいるという、国家的プロジェクトと呼べるほどの膨大なリソースが投入されています。これに対して、同じように大規模複雑化している携帯電話をはじめ、組込み製品の品質はどの程度の技術者で行なわれているのかを見てみましょう。

ここでは分かりやすくするために、システムレベルやハードウェアを含めずに「ソフトウェア」に関わる工数のみで比較します。開発工程をソフトウェア実装・単体テスト、ソフトウェア詳細設計、ソフトウェアアーキテクチャ、ソフトウェア要求定義とすれば全体の28%となり、テスト工程をソフトウェア総合テストとソフトウェア結合・結合テストとすれば全体の17%となります。人数比に換算すると、約3:2となります。

この人数比は適正なのでしょうか。先のエンジニアの比率からすれば、この数字だと矛盾することに気づきませんか？実はこのデータからは、本来必要な人員より少ない人数で、テスト工程を回しているのではないか？という仮説が導かれるのです。
この仮説が正しいとなると、十分な品質を確保しようとするなら、テストに関わるエンジニアに大きな負担がのしかかるとともに、それなりにコストがかかっているであろうことが予想されます。この予想の裏付けを得るために、データを更に見てみたところ、どうやら的外れでもなさそうなのです。

品質が経営課題となっているのは、市場不具合による利益損失やブランド価値の低下による逸失利益の発生、採算性の低下など様々な理由をあげることができるでしょう。事業責任者からの「品質を上げよ」という要求と、開発現場の危機意識が合わさって、多くの組織で真剣な取り組みが行なわれているのです。

一口に「設計品質の向上」と言っても、取り得るアプローチは多岐に渡ります。例えば開発プロセスそのものの見直しや、開発標準の策定といった組織レベルのものから、OJTや独学といった個人レベルのものまで、といったようにです。
「ツールの導入」という手段により設計品質を確保しようとすることは、代表的なアプローチの一つと言って良いでしょう。このことは、ツールを購入した動機を見ても分かります。

ツールといっても多くの種類のものが存在します。ソフトウェア品質、特にテストツールに関しても実に様々です（表1参照）。

テストツールはどのようなものと捉えれば良いのでしょう。テストツールとはテストを円滑にするための道具です。また、テストを実施するための物理的環境であり、ハードウェア/ソフトウェアの両方を指すものです。

テストツールの概要が分かったところで、次に本題である「なぜツール導入効果が簡単に出ないのか？」ということを説明します。私のこれまでの経験や、コンサル活動でヒアリングをした内容を通して知りえたツールを使いこなせない理由の幾つかと、それを少し整理したものが表2です。

ここにある様に、ツールを使う上での課題は大きく3つに分けられます。一つはツールを使う目的が無いとか、分かっていないというツールの「利用目的」がはっきりしていないということです。例えばメディアでの情報や、ツールベンダのセールストークにのっかり、トップダウンでツールを導入してしまうと、開発現場における利用目的がはっきりとしなくなるなんてことは、よくあることでしょう。

2つ目にツールの「機能不足」があげられます。実際に導入してみると、実際にやりたいことができないとか、使用方法に制限があり使えないケースが該当します。

3つ目は、テスト手法や技法に対する「スキル不足」や「理解不足」です。テストツールを使う技術者自身に問題があるということですから、「使えない」のではなく「使い切れない」と表現するのが妥当でしょう。

こういった要因から、ツールを入れたとしても簡単にはその効果が得られないのです。ツールはテストを円滑にするための道具であると言いましたが、道具だからこそ、それに振り回されないようにしなくてはなりません。そのためにはツールの導入時にこそ、必要性を投資対効果を含めて十分に検討しなくてはなりません。
本稿では、投資対効果をあげるためにツール導入時に注意すべきポイントについてツールを自作する場合と、市販品を買う場合で、それぞれ3つずつ紹介することにします。

市販品なら価格はだいたい分かりますし、オープンソースならコストはダウンロードするだけだと、かかりません。ですが自作する場合、特に少数（時には1人）の開発者で作成するなら往々にしてスケジューリングがいい加減になり、どれくらい工数をかけるべきか予め決めてないことがあるでしょう。その結果、テストをしているのかツールをいじっているのか分からなくなるというくらい、想定外に手間をかけざるを得ないことが発生してしまいます。
これでは明らかにコストのかけ過ぎなのですが、開発現場では意外とこういった負の工数に無頓着だったりします。こういった状況だと、ツールの完成度が低く思ったよりも使われなかったり、バグが多くなったり、保守性が悪く再利用できないものになってしまったりといった弊害が発生しやすくなります。自作だからこそ、あらかじめどれくらい工数（コスト）をかけて良いのかを、作る前にはっきりさせておき、適切なリソースを確保しておくことが大事なのです。

作る前から再利用が前提であるのなら、この点であまり問題にはならないでしょう。しかし、最初は使い捨てするつもりが、現場での受けが良いために、そのまま使い続けられる様になってしまうと、問題が起きてしまうことがあります。いざ次のバージョンになってから再利用するために直そうとすると、ハードコーディングな箇所の見直しや、構造がいい加減だったりすると、作った本人が手を入れるときでさえ、思いのほか苦労することになります。ですから、一度使い捨てを前提に作り出したのなら、もしそのツールを今後使い続けることになれば、リファクタリングや、一から作り直すくらいの覚悟をしておかなければなりません。

自作のツールは大抵少人数（多くは1人）で作られることが多いため保守のためのドキュメントがなかったり、ソース内のコメントが貧弱だったりします。作った本人のみしか使わない使い捨てのツールならそれでも構わないのかもしれませんが、大人数で使ったり再利用するツールであるならば、製品と同様に保守体制を作るべきです。こういったことは開発メンバの問題というより、プロジェクトマネジメント面で考慮すべきことなのですが、自作ツールのメンテナンスが必要になるかどうかは、なかなかプロジェクトマネージャやリーダだと気づかないことも多いでしょう。ですから、ツールの保守体制は開発側でまず検討した上で、プロジェクトマネジメント側と協議した方がスムーズになるでしょう。

実際の開発環境でお試し版を入れて、ツールの動作だけでなく開発環境の従来の動きが問題ないことを確認することをおすすめします。ツールによってはインストールに手間取ったり、想定外の制約条件（OSやDBのバージョンによって上手くいったりいかなかったり）があったり、別のアプリケーションの動作に問題が起きたりするなどといった問題を、未然に防ぐことができるからです。
また、カタログを見ただけでは分からない実際の使い勝手を確認したり、従来の開発プロセスにどれくらい影響があるか（テストツールを導入する場合は、多かれ少なかれ開発プロセスの見直しが発生します）を想定することは、スムーズなツール導入のためには非常に意味があることです。

評価版でインストールの流れを把握していたとしても、製品版のツールを実際にインストールしたり、他の類似ツールからスクリプトやデータをインポートしようとすると、想定外の問題に出くわすことは別段珍しくありません。この様な時は、どうしてもツールベンダのテクニカル/カスタマサポートに頼らざるを得ません。ですがベンダによっては日本語サポートが貧弱（無いことも）だったりサポートが有償（思いのほか高額なことも含め）だったり、対応した技術者のスキルが低く、適切なサポートが得られないことが有りえます。
外資のツールベンダで日本語サポートは充実してなくとも、インターネット上のコミュニティが活発であることはあります。そういった場合、英語の壁を乗り越えられるなら問題を低減することができます。
信頼できるテクニカルサポートをツールベンダから受けられるかどうかは、お試し版の評価時に、幾つか質問を出してみることで確認することができるでしょう。また、ユーザの生の声がどれくらいツールベンダでの製品開発に反映されているか、ベンダの営業部門に尋ねてみるとよいでしょう。ユーザの顔を向いているツールベンダなら、製品ロードマップに対して、どのようにユーザの声が反映されているかを、しっかり説明してくれるはずです。

ツールの不具合が発生する度に、ツールベンダへ問い合わせることは、結構ユーザにとってはストレスがかかることです。新しいツールだったりメジャーバージョンアップ直後だと、その頻度が多いことだってあるでしょう。「だったら、（不具合があることを）最初から言っておいて欲しいよな」というユーザの怒りや憤りの声を聞くことは、ツールベンダにとっても本意ではないはずです。ですから心有るツールベンダなら、不具合情報をオープンにして、いつの修正バージョンで対応できるかを明らかにするはずです。または、問題がユーザからレポートされたなら即修正した上で、パッチをリリースしたりその内容をユーザコミュニティに通知したりといった努力を、日々行なっていることでしょう。こういったことはツールベンダの大小ではなく、ツールをユーザとともに良いものにしたいかどうか、といった作り手としての姿勢によることなのだと思います。

ここまでで、ツールを導入するためのポイントを幾つか紹介してきました。最後に組織面でのポイントについてお話しします。ツールを上手く使いこなすためには何よりも、管理層・技術者層双方で「品質向上」に向けてベクトルを合わせることが重要です。
目先にかかってしまうコストだけから判断して、「ツールは高すぎる」という話しをよく聞きます。この様な話しを聞く度に「投資対効果をきちんと分析した上で、本当に高いのかどうか真剣に考えていないことの方が多いのでは？」と私は感じざるを得ません。ツールを使いこなすことで、品質を確保した上で開発者の生産性を高め、かつ開発組織全体の競争力が増すようになっていかないと、グローバルな組込み開発の競争には生き残れないといっても過言ではない、今そういった状況であることを是非知っておいて欲しいと思います。
最後は少しばかり大きな話になってしまいましたが、ともあれ「道具」としてテストツールを上手く使いこなすにはどうすればよいのか、といったことを検討するきっかけに本稿がなれば幸いです。

［参考文献］
※1 日経コンピュータ 2006 9/4号 ニュース＆トレンドより
※2 経済産業省 2006 年版組込みソフトウェア産業実態調査報告書（平成18年6月）
※3 ステップアップのためのソフトウェアテスト実践ガイド、日経BP