今日、システム構築の世界では明らかに1つのトレンドがある。それは、今までより安価なコストで、より短い納期で、より高い品質のシステムを作りあげることが求められているということだ。どのようにすればこの難題をクリアすることができるのだろうか。

　2007年7月25日、東京・青山ダイヤモンドホールにおいて、＠IT情報マネジメント編集部主催による「ソフトウェアテスト・ミーティング 〜システム構築における新たな常識『品質コントロール』」が開催された。求められる品質を担保するための最大の砦であるテスト工程、そのあり方をさまざまな角度から考えるこのセミナーに、この分野に高い問題意識を持つ参加者が多数来場した。

　基調講演に登壇したのは、東海大学大学院 組込み技術研究科 助教授（工学博士）の山浦恒夫氏である。同氏は、過去に日立ソフトエンジニアリング（以下、日立ソフト）にエンジニアとして勤務した経験を持つ。今回は、日立ソフトの品質管理手法を中心に、「残存バグ率0.02％を実現する品質コントロール法」と題して、ソフトウェアの品質を高めるためのプロセスを紹介した。

東海大学大学院　組込み技術研究科　助教授(工学博士)の山浦恒夫氏

　日立ソフトには、開発フェイズごとの摘出バグのパーセンテージを調査した統計データがある。それによると、机上デバッグから品質保証チームによるテストまで5つのチェック段階があり、そこで合計99.98％のバグが摘出され、顧客サイトでバグが発見されるのはたったの0.02％だという。

　これを実現するために行われているのが、「プログラマはテスト項目を設計し、テスト項目を作成し、実行する」「ソフトウェア製品のライフサイクルを通じて、バグの統計データを収集する」「プロジェクトマネージャは、バグの統計データを分析し、プロジェクトを管理する」「設計部と独立した品質保証チームが製品をテストする」という4つの方法だ。講演ではそれぞれその詳細な内容が紹介された。

　また第2部では、日本とアメリカ・インドのソフトウェア品質の考え方の違いについても言及。山浦氏は、日本の品質保証は彼の地では適用できないという。その理由として「日本は品質、彼らは納期を最重要視するソフトウェア開発での優先順位の違い」「全体主義の日本人と個人が優先するアメリカ・インド人の国民気質の違い」などを挙げ、彼らと協業するなら、テスト項目の設計を含めて品質保証してもらうか、プロトタイピングによる開発だけ依頼し、それを動く仕様書として、日本で設計・開発するのがよいとの考え方を披露した。

　エンピレックスは、Web、音声アプリケーション、そしてVoIPネットワークの統合テストならびに管理ソリューションを提供する米国のテストツールベンダだ。

　同社の提供する製品の中に、エンタープライズWebアプリケーションの性能と拡張性を正確にテストできる負荷テストツール「e-Load」があり、同ツールは国内シェアNo.1を誇っている。

　同社には、日々顧客よりさまざまな性能検証依頼が寄せられる。この日のセッションでは、エンピレックス 副社長 山岡英明氏が登場し、そうした実際の事例の中からWeb負荷テストで陥りやすい落とし穴がいくつか紹介された。

エンピレックス 副社長 山岡英明氏

　まずは、性能問題が開発プロジェクトに重大な影響を与えるケースだ。ある大手企業では1年半かけてクライアント／サーバ型システムをWeb化するプロジェクトを立ち上げたが、システムリリース4カ月前になって性能問題が表面化した。エンピレックスが調査したところ、この大手企業の予想どおりサーバのサイジングに根本的な問題があった。全体アーキテクチャの見直しが必要となり、結果的にこのシステムのカットオーバーは予定より6カ月も遅れることになってしまったという。

　続いては、負荷テストのケース設定に起因する問題だ。あるシステムで1分間に2000ページを処理可能であることという性能目標値が設定された。そこで同時100ユーザーでこの負荷テストを行い、さしたる問題もなかったため、予定どおりリリースされた。しかし、妙な画面が出現するアプリケーションエラーが多発。エンピレックスの調査で500ユーザーでこの現象が確実に再現されることが判明した。さらなる原因究明で、アプリケーションのメモリ使用に大きなボトルネックがあることがわかった。

　3つめのケースは、性能が機能要件として認識されないために起こった問題だった。このシステムは、同時100ユーザーでデータベースアクセスが可能であることが性能目標値とされた。それを確認するべくエンピレックスが検証を求められたのだが、なんと100ユーザーどころか同時3ユーザーでデータベース内に待ち行列が発生し、タイムアウトを起こしてしまう。応答時間は設計段階で明確に設定されていた。しかし、開発チームはそれを非機能要件と認識しており、まったく気にかけていなかったのである。

　山岡氏はこうした事例を挙げながら、性能障害の原因は一般的に考えているより重症で、それを修正するのに多大なコストがかかることを強調した。同社自身、「e-Load」の性能問題に直面したことがあり、それを修正するのにシステム構成の再検討が必要で、2年の月日と数億円のコストが必要だったという。

　では、これを回避するためにはどうすればいいのか。効果的に負荷テストを行うための施策として、山岡氏は以下の2点を掲げた。

　1つめは、負荷テストを単なるテストと考えず、十分な時間を確保することだ。スクリプト作成から不具合修正まで一連のプロセスをこなすには、最低でも2週間は必要だという。

　もう1つは、ボトルネックを発見して対処するスキルを身につけることだ。

　「今日は、分業体制が進むあまり、全体を俯瞰して問題を切り分けられる開発者が少なくなっている。ここはまさにテストエンジニアが活躍できる分野。当社は製品ばかりではなくトレーニングやセミナーにも力を入れている。ぜひ積極的に活用していただきたい」（山岡氏）。

本セッションで取り上げた製品の詳細な資料をダウンロードしていただけます。 以下の画像をクリックしてください。 お問い合わせ先：eTestJapan@empirix.com

　システム構築において、単体テストが重要な意味を持っていることはもはやいうまでもない。Parasoft Japan 代表取締役社長 野田勝彦氏はまず、Boehmの問題の発見が修正が遅くなればそれだけコストが高くつくという「1:10:100の法則」を引いて、そのことを明らかにした。2006年の経済産業省の調査によると、組込みソフトウェア業界における不具合発生、その発見は、システム実装・単体テスト工程が最も高かったようだ。最近は、フロントエンドのみならず、業務ロジックまでもJavaで構築されるなどすべてがオープン系というアーキテクチャも増え、さらなるセキュリティ確保や無停止稼働要求など、システムがますますミッションクリティカル化しており、今まで以上に単体テストを厳密に実施する必要性が高まっている。

Parasoft Japan 代表取締役社長 野田勝彦氏

　しかし、単体テスト工程は非常に細かく量の多い作業で、その実際の内容については個人の経験、スキル、モチベーション、性格などといったものに依存しがちだ。これを一体どのようにコントロールするか。野田氏はこれはどう“見える化”するかにかかっていると強調した。

　この「見える化」を実現するには、情報を集約し、可視化するインフラが必要だが、機械的に計測可能で可視化しやすい情報と、機械的な計測が難しく可視化しづらい情報があることを示唆し、機械的に計測可能な情報は、標準のフレームワークを利用することにより利用可能なツールの選択肢が増えることに着目したいと述べた。また、可視化しづらい情報は人手を介さずに情報収集することは難しいが、ツールに任せられるところはツールにまかせ、本当に必要な部分にのみ人的リソースを注力することが望ましいとも述べた。Parasoftも、深夜の自動テストを実現するためのJtestやC++test、メトリクスの収集と蓄積を実現するGRSなど、「見える化」を実現するツール群を提供しており、既存の構成管理システムにチェックインすれば、深夜テスト、メトリクス収集が自動化される運用モデルが好評を得ているという。

　野田氏はこのセッションで今話題の静的フロー解析も紹介した。一般に、テストとはプログラムが仕様どおり振る舞うかどうかを検証するもので、仕様にないケースは見落とされがちである。これを防ぐためにシステムの仕様や操作方法をまったく知らない人によるモンキーテストやスモークテストが推奨されているが、実際にはリソースの確保が難しい。そこで実効性を持ったソリューションとして脚光を浴びているのがこの静的フロー解析だ。プログラムを実行することなくプログラムフローとデータの流れを解析し、問題を検出するこのテスト手法は、すべての分岐の組み合わせを検証、データの流れを解析することにより、特定の分岐の組み合わせのみに発生する問題を検出できるという。理論的には、不定・不良データへのアクセス、リソースやメモリの開放処理の問題、例外処理やエラー処理の漏れなどが検出可能と考えられており、静的フロー解析機能を持ったParasoftバグ探偵は、オープンソース製品の品質向上にも貢献しているという。

　ツールを導入したからといってただちに改善効果が得られるわけではない。新しい試みを取り入れた際には、逆に一時的な生産性や品質の低下が生じ、本来の効果が発揮されるまでには時間がかかる。また、業務上の問題にはさまざまな要因が関わっており、これを解決するには各要因に対してバランスよく取り組む必要があり、ツール導入はその1つにすぎないという。野田氏は、「改善対象範囲を少しずつ計画的に広げ、短期目標をクリアして達成感を得ながら長期目標に至る、段階的かつ継続的な改善こそが道すじだ」と、講演を結んだ。

本セッションで取り上げた製品の詳細な資料をダウンロードしていただけます。 以下の画像をクリックしてください。 お問い合わせ先：parasoft-info@techmatrix.co.jp

　このセッションは、クイズでスタートした。システム構築のプロセスに関するメトリクスがいくつか示されて、それは何が起こっていることによって生じているものかを当てるのだ。作業に関するもの。作業の進捗に関するもの。ビルドテストに関するもの。初めはただの線と面の図形にしか見えないものが、マイクロソフト デベロッパー＆プラットフォーム統括本部 岩出智行氏からどう見るかという解説を受けることによって、しだいにそのメトリクスの示す意味が読み取れるようになってくる。解読できるようになっていくのだ。

マイクロソフト デベロッパー＆プラットフォーム統括本部 岩出智行氏

　“測定されていないものは改善できない”といったW.Edwards Demingの言葉を引いて、岩出氏はメトリクスを取ることの重要さを語り、具体的にそのために必要な4つのステップを解説した。

　まず、Step1は測ること。ここでのポイントは、組織で共有できるメトリクスの雛型を用意して、プロジェクトごとに単一のデータリポジトリでメトリクスデータを管理することだ。また、データ収集は可能な限り頻繁に行い、その情報をメンバーはもちろん、ステークホルダーに開示することも重要だという。

　Step2は、バラつきを理解すること。メトリクスデータにはバラつきが生じる。その原因には日にちやロットが変わっても現象に変化がない共通原因と何か特別な事情のために生じた特殊原因の2種類があり、共通原因からくるバラつきを特殊原因であるかのようにとらえたりしないことが大切だ。

　Step3は、複数の次元で測ること。例えば、ソフトウェア品質を調査するのに現時点の状況をスナップショット的に見てもよくわからないが、そこに時間軸を加えて時系列でとらえていくと、ソフトウェアの品質状況が上向きなのか下向きなのかが見えてくるというわけだ。

　最後のStep4は、Step3までの活動で把握できた問題点を具体的にカイゼンすること。例えば、あるシステム構築でライフサイクルを調査した結果、統合テスト工程にボトルネックがあることが判明した。実際に、作業進捗メトリクスを作成してみると、リードタイムの遅れが見てとれる。そこから共通原因によるバラつきと思われるものを探り、それを減らしていく。

　このようなメトリクスを取得するためには、Step0の活動として、メトリクスのベースをデザインする必要があるが、Visual Studio Team Systemには、ソフトウェア開発ライフサイクル上のさまざまな活動の管理単位であるワークアイテムというものがあり、これによりプロセス全体の流れと個々の作業手順を定義することができるという。この統合開発環境ではまた、ビルドやチェックインの機能を使ったメトリクスの記録が可能だ。

　「まずは測ることから始めてほしい。すべてはそこから始まる」

　セッションの結論として、岩出氏はこう強調した。開発作業に支障をきたしそうな気がしてつい気持ちが後ろ向きになるが、Visual Studio Team Systemなどツールをうまく活用すればそこはクリアすることができ、実際に測ってみるとわかることが数多くあり、案外楽しめるものだという。また、メトリクスは、それを取ることによってカイゼンの方向性が明らかになる。ただし、メトリクスにはバラつきがあることを理解しておく必要はある。さらに、カイゼンの効果は使用するメトリクスによって左右されるため、メトリクスをどうデザインするかは非常に重要で、メトリクス自体も定期的にカイゼンを図っていくことが必要だ、と力説した。

◆ Visual Studio Team System

　誰しも高品質ソフトウェアの開発をめざしている。そのための重要な砦としてテストプロセスが存在することもわかっている。しかし、開発の最前線では、組織や多忙さやコミュニケーションなどの問題が山積していてなかなかうまく実践できていないというのが現実だ。

　日本アイ・ビー・エムでは、こうした問題を解決するためのテストプロセスとして、Agileを推奨している。今日、Agileは業界の主流となったと同社は見ており、2006年に発行された「Agile Journal」の中から、“回答者の35％が、現在Agileプロジェクトまたはパイロットが進行中であると答え、アジャイル・プロセスは自社にそぐわないと考える回答者はわずか12％だった、調査対象企業（そのうち3分の1は従業員数1万人以上）の88％がAgileプロセスを使用中または評価中である”という記事を紹介している。

　Agileにはチームのコラボレーションやソフトウェアの技術的作業にフォーカスを当てており、理論より実践を重視するという特徴がある。ドキュメントがない、作業方法に決まりがない、予測できない、拡張不可であるといった指摘を受けているが、日本アイ・ビー・エム ソフトウェア事業 ラショナル事業部 テクニカル・セールス テクニカル・セールス・スペシャリスト 小野塚荘一氏は、「それらはすべて誤解。Agileでも必要な文書化は行い、作業方法の特定は求められている。ジャスト・イン・タイム型の計画を立てて、予測もできる。EclipseはAgileプロジェクトであることからも、拡張可能であることは明らかだ」と弁明する。

日本アイ・ビー・エム ソフトウェア事業 ラショナル事業部 テクニカル・セールス テクニカル・セールス・スペシャリスト 小野塚荘一氏

　ただし、具体的に選択する手法は適材適所であるべきで、チームのサイズが小規模であったり、地理的分散が少なく、アプリケーションがそれほど複雑ではない、コンプライアンス、ガバナンス要件が低いといった場合にはXPやScrumなどが向いており、その逆の場合にはRational Unified Processが向いていると小野塚氏は語る。

　一方、IBM Rational ClearQuestは、テストチームと開発チームとの連携を可能にする開発ライフサイクルにおけるハブの役割を果たす。テスト、障害、プロジェクトでの変更を集約する単一のプロジェクトビューを持っており、これにより現時点のプロジェクト全体の状況が可視化可能になるとともに、テストプロセスと開発プロセスの間でプロジェクトの成果物を関連づけたり、監査を行うことができる。また、ライフサイクルトレーサビリティー機能を有し、プロジェクト進捗におけるすべての情報を、1つの情報源から一元的に参照することができる。さらにテスト管理では、テストケースの作成やテスト環境の定義が行えるとともに、作業項目の重みづけ、テスト実行、分析、レポートの出力といった機能を提供する。IBM Rational ClearQuest MultiSiteという製品ではレプリケーション機能と同期化機能を有しているため、地理的に分散したチームであっても密接に協調してテストプロセスを進めることができるようだ。

　このほか同社は、中央集中のビルドとリリース管理を行えるRational Build Forgeや、わかりやすい手順書を簡単に作成できるRational Manual Tester V7、回帰テストを自動化するRational Function Tester、負荷テストのためのRational performance Tester、SOAテスト・ソリューションであるRational Tester for SOA Quality、Rational Performance Tester for SOA Qualityなど、一連のテストツール製品をラインナップしており、小野塚氏はセッションの最後にそれぞれの機能概要を解説するとともに、ソフトウェア品質を向上させるには、なによりも適切なプロセスの選択と効果的なテストの実施が重要だと訴えた。

◆ 日本IBM Rationalソフトウェアに関する情報