2005年5月31日、飯田橋の東京カンファレンスセンターで、「＠ITソフトウェアテスト・ミーティング〜情報システムの品質最適化への挑戦〜」（アイティメディア主催）が開催された。当日の朝は雨という悪条件にもかかわらず、開始時間前から多くの受講者が詰めかけ、最後のパネルディスカッションにいたるまで会場はほぼ満員状態だった。

　「品質」は、今日のシステム開発においてもっとも注目されているキーワードだ。次々に台頭する新技術、システム要件の多様化などが絡みあい、開発プロジェクト自体が困難をきわめている。こうした中、かつてのような「高品質＝バグがない」という公式は、もはや成り立たなくなってきた。

　そこで改めて問われているのが、「高品質なシステムとは何か」という問題だ。本セミナーでは、ソフトウェア工学の識者やテストツールベンダを中心に、あらゆる角度から「高品質なシステム」を検証し、具現化するための方法論を披露した。

◆ テストがダメなプロジェクトは開発もダメ

「品質」は、今日のシステム開発においてもっとも注目されているキーワードだ

　そもそも品質とはソフトウェアに限らず、あらゆる業種・業態に共通のテーマだといえる。特に最近は、自動車や食品、交通機関などで発生した品質事故のニュースが盛んに報道されている。ソフトウェア分野に目を向けると、携帯電話やカーナビなど組み込み系ソフトの不具合により、製品回収が発生するケースも少なくない。エンタープライズ系のソフトでいえば、信頼性が求められる金融機関のシステムに不具合が発生するなど、「かつてはあり得なかった」事態が起こっている。その分、顧客や一般消費者も「品質」について厳しい目を向けるようになってきた。

　ソフトウェア品質ならびにテストに詳しい電気通信大学・電気通信学部　システム工学科講師の西康晴氏は、本セミナーの基調講演で「品質に対する認識が高まったおかげで、最近はテストプロセスの参考書や先進事例が手軽に参照できるようになった。これに伴い、開発工程におけるテストの位置づけやテスト技術、ツールの役割も劇的に進化している」と述べた。

　かつてソフトウェアテストといえば、「開発終了後、短期間でできるだけ多くのバグを出せばよい」という認識で実施されていた。というのも、開発工数全体では要件定義や実装にかかわる作業が中心となり、「しっかりとしたテストを実施するには、どうしても時間が足りなかった」からだ。しかし西氏はこうした状況を否定し、「そもそもテストがうまくいっていないプロジェクトは、開発もうまくいっていない」と断言する。

　「テストでバグを見つけるのは当然のこと。そのうえで、さらにユーザビリティやセキュリティ、保守運用性などもチェックしなければ、今日のエンタープライズシステムの要件を満たせるはずがない。つまりテストは開発の“後工程作業”ではなく、要求仕様書を書く段階から意識すべき事柄といえる」（西氏）。

　具体的にどうすべきか。西氏は「多忙な開発現場では、テストにリソースを割くのは難しいだろう」と認めながらも、2つの方策を示した。

◆ 上流工程からテストを意識する

　まず取り組むべきは、テストプロセスそのものを洗練させること。テストにおいて必ず問題になるのが、「いつまでテストを繰り返せばいいか」という点だ。これが見えないと、行き当たりばったりに単体テストを繰り返すはめになる。当然テストプロセスは確立されず、プロジェクトごとに同じ問題に突き当たり、その繰り返しとなるわけだ。

　先進的な例では、テストプロセスそのものを独立させ、開発プロセスと同じように分析・実施・レビューを繰り返し、次のプロジェクトに再利用するケースがあるという。こうしてノウハウを蓄積しておけば、どこを検証してどこを次フェイズに回すかという判断も下しやすい。リスクの発生を最小限に抑えられるというメリットもある。こうしておけば、単体テストをしっかりやるだけでテスト作業の効率が飛躍的に向上するという。つまり、開発とテストで工程を分けるのではなく、常に一体化してプロセスを整備する必要があるということだ。

　そこで重要になるのが、いかにテストを設計するかだ。テスト設計の方法論としては、「TPI」（Test Process Improvement）というテストプロセスのモデルなどを参考にしてもよい。また、ソフトウェアの品質を定量的に把握する「信頼度成長曲線」のモデルを利用し、テストプロセスを改善していくのも有効だ。方法論については、書籍やWebサイトを通じて簡単に入手できる。

　こうした取り組みを経て、初めてテストツールを活用する意義が出てくる。上記に挙げたテストプロセスのモデルの中には、テストツールの分類のほか、どの工程でどのようなツールを利用すべきかも規定されている。だが「何を重点に検証したいか」が見えないままツールを導入しても意味はない。むしろ、最優先で検証すべき箇所を見逃す事態を招くこともある。

　西氏は「ツールがあればテストが進むわけではない。テスト計画をきちんと設計し、ツールにできること、できないことを切り分けることで初めてツールの効果が出る」と述べる。「最近はインターネットを通じてフリーのテストツールも手に入れられるようになっているので、まずはそこから試してみるのも一手。ツールの価値を見きわめることが重要」（西氏）。

　そして西氏はもう1つ、高品質なソフトウェア開発のキーファクターとして「人材」を挙げる。ツールの専門家やテストマネージャなどはもちろんだが、「それより重要なのは、仕様にあらわれないユーザビリティやパフォーマンス、セキュリティ、保守運用性を初期段階から考え、設計に落とし込んでいく人材。いま注目されている“ITアーキテクト”は、まさにこうした役割を担う職種なのではないか」（西氏）。これまでITアーキテクトといえば、要件定義など上流工程と開発現場の橋渡しをする役割と捉えられてきたが、西氏は品質という観点から同職種の重要性を訴える。「実際に、インフラからアプリケーション層まで含めて全体最適化を図るとすれば、上流工程から品質やテストに関しても考えが及ぶはず。システムの品質が大きく取り上げられているいま、ITアーキテクトに寄せられる期待は大きい」とし、講演を締めくくった。

◆ 開発担当者とテスト担当者は同一にすべきか

　この講演を受け、本セミナーの最後を飾ったパネルディスカッションでは、テストツールベンダやSI企業の識者が集まり、「ソフトウェア品質向上のコツ」というテーマで活発な議論が展開された。モデレータは、アイティメディア ＠IT発行人の新野淳一氏、パネリストは以下のとおり。

• エンピレックス エンタープライズ・ソリューション・グループ 副社長 山岡英明氏
  
  
• テクマトリックス 技術本部 第一技術部 プロダクトソリューショングループ グループリーダー 西田啓一氏
  
  
• マーキュリー・インタラクティブ・ジャパン 小�ｱ將弘氏
  
  
• マイクロソフト 岩出智行氏
  
  
• 日本アイ・ビー・エム 小野塚荘一氏

　本パネルディスカッションでは、「高品質なソフトウェア」を、「バグがないだけでなく、機能、性能、ユーザビリティ、運用性に優れていること」と定義。この前提を踏まえたうえで、モデレータの新野氏が「ソフトウェア品質向上の取り組みとして、人材とプロセスの確立という2つのテーマが明らかになった。この問題と共に、仕様書の中で『品質』を表すことが可能か否かを考えたい」と口火を切った。

パネルディスカッションでは、テストツールベンダやSI企業の識者が集まった

　まず「ソフトウェアテストの専門家」に該当する人材として、山岡氏と小野塚氏はITアーキテクトの重要性を訴求。前述の西氏と同じように、ITアーキテクトを「システムの機能を最大限に引き出すために、テストプロセスそのものを設計する人物」と位置づける。つまりシステム全体の最適化だけでなく、開発プロセス自体も「品質」という観点から最適化する人物が必要ということだ。

　マイクロソフトの岩出氏によると、実はマイクロソフトには、製品開発に際しまさにこうした役割を担うチームが存在するそうだ。「当社は約10年前にMicrosoft Solutions Frameworkという開発プロセスを確立している。これはイテレーション型開発モデルであり、それぞれのイテレーションの中で『開発』や『テスト』など6つの役割（ロール）に分かれたメンバーがそれぞれ協力し合って製品を開発していく」（岩出氏）という。同社の場合、開発とテストの担当チームがそれぞれ独立した形を取っている。これは「開発に求められる視点とテストに求められる視点は異なる」という見解のためだ。同一にすると、どうしてもテスト作業に甘さが出る。むしろ第三者の視点で品質を検証するのが望ましいという。

　一方、「テスト実行する担当者自身が、開発者として優れた資質を持つ必要がある」と主張するのが西田氏。いいソフトウェア＝いいコードを判断できる目がなければ、テストの質そのものも向上しないからだ。ただしテストの専門家に必要なスキルセットとして「顧客の目からシステムの品質を判断できる実績」（西田氏）を挙げ、開発担当者とテストの専門家とは別のスキルがあると述べている。いずれにしろ、優れた開発技術を持つことは必要だが、それだけではなく「顧客の視点に立って品質を評価できる人材」が必要とされているようだ。

◆ プロジェクトがテストに振り回される？

　とはいえ、実際の開発現場にとってみれば、「テストの重要性は認識していても、時間が足りず、本格的な取り組みができない」というのが実情だろう。開発期間の短期化は年々激しくなっており、XP（eXtreme Programming）やRUP（Rational Unified Process）などイテレーション開発が主流となる中で、下手をするとテスト自体がオーバーヘッドになってプロジェクトの進ちょくを妨げることにもなりかねない。実際、小野塚氏はこうしたリスクを認めた上で、「イテレーションの中にテストプロセスを組み込み、開発プロセス全体を設計する必要がある」と述べる。

　ここで重要な役割を果たすのがテストツールだ。小�ｱ氏は「アプリケーションリスクマネジメントという方法論がある。リスクの高いものから順にテストプロセスを設計し、自動化できるところはツールに任せることで、テストのオーバーヘッドを軽減できる」と主張。また「優秀なテスト担当者にツールは敵（かな）わない」（山岡氏）としながらも、限られた期間のプロジェクトにおいて、テストツールが果たす役割が大きいことを説明した。

　ツールのメリットとしては、テストのカバレッジが広がることが挙げられる。山岡氏の言葉を借りれば、「いかに優れたテスト担当者でも、テスト消化率の観点からいえばツールには勝てない」ということだ。ただし、ツールの効果が出るのは優秀なテスト担当者がいればこそ。そもそものテスト計画がズレていては、いかにカバレッジが広いツールといえど、見当違いの分野を検証しているだけになる。こうした事態を避け、プロジェクトがテストに振り回されないように全体を調整するのもテスト専門家に求められる役割だ。

◆ 仕様書の中で「品質」を表現できるのか

　もう1つ、現場の開発担当者が疑問視するのが「仕様策定の段階からテストを意識する」ということだろう。ソフトウェアの仕様とは、開発を進める中でも随時変わっていくもの。初期段階からパフォーマンスやユーザビリティ、セキュリティ、保守性などを確定するのは難しい。パネリストも「ある程度、仕様が変更するのは仕方がない」と口をそろえる。「RUPではリスクの高いものから順に決めると定義しているが、実際には非常に困難」（小野塚氏）。

　ただし「優秀なエンジニアであれば、ある程度先を読むことはできる」（西田氏）という見解や「仕様書の中から、品質に関する項目を抜き出してテストケースを実施できる」（小�ｱ氏）という意見もあり、開発の初期段階からテストを意識してプロジェクトを進めることは必ずしも不可能ではないようだ。むしろ「プロジェクトや開発プロセス自体の品質が低いと、仕様書における品質も確保できない」（小野塚氏）ということから、まずは優れたアーキテクトやテスト担当者をプロジェクトに投入し、開発プロセスそのものの質を向上させるのが必要だといえる。そうすることで、おのずと「仕様書からのテスト設計」も可能になっていくだろう。