電気通信大学 西康晴氏に聞く、テスト技術の未来：［Special Interview］

ソフトウェア開発におけるテストの重要性が年々高まってきている。しかし、開発現場の状況はいまだ多くの混乱に満ちているといってもいい。極端にいえば、開発工数の9割にも達するといわれるテスト工程が直面する危機的な状況について電気通信大学の西康晴氏に聞いた。（編集局）

ソフトウェアが抱える課題はどこに潜むのか

――ソフトウェアを取り巻く現状について、どうお考えですか？

　ひと言でいうなら、未曾有の品質危機にあると思います。

　わが国が作る製品の品質は、1980年代の初頭に一度アメリカを追い抜いたのですよね。それ以来、バブル崩壊を経験した現在でも、自分たちの品質は世界一なのだと思い込んでいる日本人が多い。自動車ですとか、家電製品については、確かにそれは当てはまると思います。しかし、ソフトウェアに関していうなら、残念ながら品質が良いとはいえません。例えば、メガバンクにおける情報システムの混乱、携帯電話のバグ、航空管制システムのトラブル……。現在、いろいろな企業でシステムの統合が行われていますが、失敗している例も多いようです。それは、私たちが思い描いている、日本製品の品質は高いというイメージからはとてもかけ離れたものです。

　また、それに加えて、乳製品の集団食中毒や原子力発電所の事故隠しなどが相次ぎ、世の中全体がリスクに対して敏感となり、ソフトウェアの不具合に対しても社会的な責任が問われるという風潮になっています。私が驚くのは、電車に乗っていて、隣にいる小中学生などが「バグる」という言葉を普通に使うことです。ずっと専門用語だと思っていましたが、もう一般的な用語なのですね。それは裏返せば、世の中がソフトウェアにはバグがあって当然と思っているからなのでしょう。

――なぜ、品質が下がってしまったのでしょうか？

　1つは、ソフトウェアに求められる機能や複雑さが格段に高まったことが挙げられます。組み込みソフトウェアなどに顕著ですが、携帯電話を例にしても、インターネット接続機能が付いたり、デジタルカメラが入ったり、非常に複雑になっています。

　企業の情報システムでは、もちろん機能の複雑化などいろいろな要求はありますが、それよりも大きいのは、ビジネスのスピードがけた違いに速くなっていることです。同じ複雑度であっても、単位時間当たりに作り込む複雑度が上がっているので、結果としていままでのやり方では立ち行かなくなっているのです。

　一方、情報システムに対するROI に関しては、一昔前よりかなり厳しく評価されるようになってきています。うまく導入できたときの投資と利益とのバランスを見るというのは進んでいると思います。ところが、不具合が発生したり、うまく導入できなかったときのダメージに対しては、そういう評価が難しいこともあって、あまり考えられていません。日本の企業というのは、物事を始める前にリスクのことをいうと、始める前からそんなことをいってどうするんだ、そこをなんとかするのが君たちの仕事じゃないかというのですよね。

――ソフトウェアテストについては、どうでしょうか？

　テストがソフトウェア開発全体の工数の中で占める割合は、少なくても3割、多い場合は9割にも達しています。まさにボトルネックですよね。原因はいくつかあって、1つは、作らなければならないものの複雑さが上流の開発技術よりも速く進歩しているために、テストが始まる時点ですでに多くのバグが含まれているのです。つまり、上流で「品質の作り込み」ができていないのですね。それはもしかしたら、時間をかければ技術的には可能だけれども、ビジネスがそれを許さないという状況なのだと思います。それから、テストに要求される難易度や複雑度に対して、テスト技術者のスキルが向上していない、さらに技術者そのものが増えていないという状況もあります。

――テスト自体の時間も増えているわけですね。

　例えば、ソフトウェアハウスのような企業がソフトウェアを開発しますよね。そこで、頑張ってテストをする。その時間は、開発全体の3割とか5割かかるわけです。その後、それを購入したベンダが検収のためにまたテストするケースが多くあります。さらに、そのシステムを導入したユーザー企業が、検収やほかのシステムとの組み合わせなどのためにまたテストを行うのです。缶ジュースを買うときに、だれも中に砂が入っているとは思いませんよね。しかし、ソフトウェアの場合には、砂がまったく入っていないということを現実的な高い確率で証明することは誰にもできないので、購入した方もテストせざるを得ないのです。極めて無駄なテストが繰り返し行われているわけです。

指数関数的に増加するソフトウェアテストの負荷

――企業の情報システムにはどんな問題があるのでしょうか？

　オープン化とともに、ハードウェアやソフトウェアの組み合わせがどんどん増えています。ユーザー企業は、なるべくコストを下げるために、同じ動きをするであろうものなら、なるべく安いものを使いたがりますから、組み合わせもさらに増えるのです。また、先ほどからいっています組み込みソフトウェアの製品がオフィスにも入り込んできています。例えばコピー機などは、実は高機能なコンピュータだったりするのですね。それと、オフィスのサーバやクライアントマシンが混在する、非常に複雑なネットワークになってきているのです。

――早急な対応が必要というわけですね。

　そのとおりだと思います。通信系などでは、破たん寸前だったり、すでに破たんしたという製品の話もあります。撤退した企業のエンジニアに聞くと、開発チームとして撤退したことは忸怩（じくじ）たる思いだが、しかし、もしもあのまま続けていたら取り返しのつかない不具合を出していたかもしれなかったそうです。それを考えるなら、不具合が出る前に撤退しておいた方がビジネス的判断としては正しかったということでした。

IT投資を最大化するために企業が直面する課題

――品質を高めるためには、どのような対応が必要なのでしょうか？

　情報システムを導入している企業には大きく2つのタイプがあると思います。1つは、情報システムによって業務やサービスに新しい価値を生み出そうとしている企業。いい換えれば、情報システムをよく理解している企業です。

　こうした企業の多くはERPに頼っていません。ERPを導入するというのは、ある種、業界標準のやり方に自分たちの会社のやり方を合わすということになりますからね。つまり、自分たちの強み、付加価値を損なうことになるのです。

　もう1つのタイプは、あまり差別化などは意識せずに情報システムを導入しているという企業です。このような企業は、汎用パッケージですとか、ERPですとか、情報システムについてはあまりこだわることなく、ほかの部分で差別化しようとしています。

　前者のタイプの企業では、投資に見合うように情報システムの価値を戦略的に高めていかなければなりません。そのためには絶対的な必要条件があります。それは、作ったものがちゃんと動くということです。ところが、現状はどうでしょうか。運用にすごくコストがかかっていたり、起こるはずのないバグが発生して、結局は原因不明のまま、なんとなくシステムが動いていたりというケースが多いのですね。

　それは、情報システムに投資したコストのうち、少なくない部分が後ろ向きのコストに消えていることを意味しています。つまり、ROIを落としているのですね。品質を上げるというのは、どちらかというと守りのようなイメージがあると思います。しかし、守りをきちんとしておかなければ、攻めには転じられません。そこが1つのポイントだと思います。もともと攻めようと思って投資している部分が攻め切れていない。そこを補強してやることによって、攻めが万全になります。

　一方、後者のタイプの企業は、汎用のパッケージやコンポーネントなどを導入することによって、一見、品質の良いシステムが構築できます。確かに実際にできるのですが、問題はパッケージやミドルウェアの品質にその企業のシステムの品質が依存してしまうということなのです。

　一番分かりやすい例を挙げましょう。OSにセキュリティホールが発見され、パッチがリリースされたとします。そして、そのパッチによってアプリケーションに不具合が発生するようになったとしましょう。この場合、よほど影響力のあるケースは別ですが、一般的にはそのアプリケーションの責任になってしまいます。アプリケーションにバグがなくても、汎用のパッケージやコンポーネントを使うことで、自社の情報システムのリスクをほかの企業に握られてしまうことになるのです。そのためにも、業界単位などでユーザーグループをつくり、自分たちが使っている標準的なパッケージやミドルウェア、OSなどについて、どういうところでバグが出るとか、使い悪さを情報共有したり、流通させるようにすべきだと思います。

ソフトウェアテストの未来へ解決すべきさまざまなテーマ

――現在、どのような研究テーマに取り組んでいらっしゃるのでしょうか？

　1つは、ソフトウェアテスト分野全体のプレゼンスを高めるための活動を行っています。開発の中でこれほどテストが重要となっているのに、ソフトウェアテストを単なる「検算」と思っている人がとても多いのですね。普通、学校では、足し算や掛け算は教えても、検算には力を入れません。検算にすごく時間がかかったので、勉強が終わりませんでしたといったらすごく怒りますよね。最初から間違いなくやればいいじゃないかと……。ソフトウェアについていえば、残念ながら日本とはそういう国なのです。まず開発側は非常に多くのテストが必要となることを認識して開発すべきですし、ユーザー企業も、それを十分理解して発注すべきだと思います。同時に、ユーザー企業がきちんと検収して高い品質のシステムを運用できるようにするにはどうすべきか、という点にも取り組んでいます。

　また、テストを効率的に行うためには非常にコストがかかります。そのコストを早い段階で理解してもらうことも重要です。開発の後半で、しかもコストがかさんだ段階になって、テストツールの稟議を出しても通らないですよね。

　2つ目は開発側の問題です。SCMなどでよく使われる理論に、TOC（Theory of Constraint：制約理論）というのがあります。要は、ボトルネックを見つけ出し、そのボトルネックを最も効率的に動かせるように全体を再配置するというものです。ソフトウェア開発の場合、3割から9割もテストしているということはテストがボトルネックなのですね。そうであるなら、すでに開発の段階からテストをやりやすいように設計すべきです。そうすれば、トータルとして大きくコストを下げられるのです。

　3つ目はテスト技術者そのものです。実はテストとは検算であると思っている人が技術者自身にもとても多いのです。技術的な観点、プロジェクトマネジメント的な観点、ユーザー的な観点、ビジネス的な観点、これらがすべて分かっていないと本当によいテストはできないのに、そこまで意義のある仕事だと思っているテスト技術者というのは意外に少ない。企業側も、まずテストに配属して、そこでスキルが付いたら開発やSEにステップアップさせるといった考えのところが多いのです。この3つのテーマをまとめて底上げしていきたいと考えています。

――技術的には、どのようなテーマがあるのでしょうか？

　分かりやすくいうなら、百発百中のテストを目指しています。そのためには、バグのある個所だけをテストしてやればよいわけです。実際にはそうはいきませんから、それに近づくための研究をやっています。

　1つは、バグのナレッジマネジメント。バグの気持ちになる研究といってもよいかもしれません。どういうバグがどういう状況でどういう場所に入り込みやすいのかといったことを分析して、開発側とテスト側で情報を共有できるナレッジマネジメントを考えています。

　2つ目は、開発とテストを同時に始める、もしくはなるべく早い段階でテストを始めるというものです。例えば、要求分析で出てきた要件を基にテストを設計したり、アーキテクチャ設計で採用されたデザインパターンからバグの入り込みやすいテスト項目を狙っていきます。開発と同じように、テストも非常に粗いところから始めて粒度を細かくしていくわけです。グレーボックステストと呼んでいますが、コンカレント開発と呼んでもよいかもしれません。

　こうしたテストの工数を減らすための非常に重要な方法は自動化をすることです。そのためには、すでに開発の段階で自動テストツールを使ってテストをできるように設計する必要があります。それは別に変わった考え方ではなくて、例えば半導体では、動作をチェックするための端子のようなものが設計の段階から必ず組み込まれています。また、この自動テストツールをいかに効率的に活用するかというのも研究のテーマとなっています。

――最後に、西先生にとってソフトウェア工学の魅力とは？

　私は、もともとコンサルタントをしていました。しかし、コンサルティングでは1社1社の品質を上げることはできても、ソフトウェア業界全体の品質向上、あるいは日本の産業競争力の向上は遠い道のりです。ソフトウェアという観点から大学から産業全体にどんどん提言しつつ、産業全体に役立つような研究を進めたいと考えています。私は、パソコンを使って自分でプログラミングしたりして、幼いころからずっとソフトウェアが好きでした。そんな日本のソフトウェア産業に世界一になってほしいのですね。自分の研究によって、日本の競争力が高まり、みんなが少しでも幸せになれればよいなと思っています。

著者プロフィール

西 康晴

• 電気通信大学 電気通信学部 システム工学科 講師（工学博士）
• 2001年、某社にてソフトウェアテストに関するコンサルティング部門を設立
• 2003年4月、現職
• ソフトウェアテスト技術者交流会（TEF：Testing Engineer's Forum）を主宰

http://blues.se.uec.ac.jp/swtest/

• ソフトウェアテストシンポジウム（JaSST）共同実行委員長
• 組込みソフトウェア管理者・技術者育成研究会（SESSAME）世話人

http://www.sessame.jp/

• ソフトウェアテストに関する論文や著書を多数執筆、翻訳『ソフトウェアテスト293の鉄則』（共訳）『基本から学ぶソフトウェアテスト』（共訳）