コードジンのヘッダーが入ります
現在のソフトウェア開発おいて、オフショア化は避けられない課題だ。IBMにおいても開発リーダーは米国に居て、開発はインド、テストは欧州で行うなど分散開発が進んでいる。
日本IBMの小野塚氏はグローバル分散開発を成功させるための要因を次のように整理する。その第一は、作業の曖昧さの排除だ。プロセスの定義、役割の明確化、作業の開始基準と完了基準の決定などを行う。また、ツールにより立ち上げたコミュニティーの活用などによるコミュニケーション、さらにプロジェクト・リポジトリに情報を集めて構成管理、変更管理を行うことによるリスク管理も重要だ。その結果、作業の標準化とガバナンスが可能になる。
そして分散開発において、製品(アプリケーション)品質を見える化するためのポイントがテスティング環境の確立だ。重要なのは開発の各フェーズでテストを確実に実施することであり、機能テストだけでなく、負荷テストやセキュリティ検査などの非機能テストも、なるべく早い段階から行うことが望ましい。そして単体テスト、システムテストの結果は「障害データベース」に蓄積していく。
一方、テストを実施すれば、非常に多くのテストログやテスト結果が生成される。対するプロジェクト管理者や製品販売者レベルにおける関心はそのすべてではなく、必要に応じて集約したデータにある。小野塚氏は「どのレベルでまとめるかの判断ができれば、テストの目的も明らかになり、結果として必要なテストの内容も導き出すことができる」と分析する。
分散開発における各サイト内には、開発者、テスト担当者、リリースマネージャー、本番環境の運営担当者などが点在することになる。小野塚氏は「各作業において個々の経験に依存しないことがポイント」と指摘する。そこで特に依存度が高くなりがちなビルド作業を自動化し、同時に単体テスト、可能であればシステムテストまで自動化する。
開発チームが作業で用いた一連のビルドプロセスの自動化やテストの自動化セットは、本番環境への移行、本番環境での実行管理での再利用は容易だ。そこで小野塚氏は「可能な限り、再利用を前提とした自動化がポイント」と提言する。
では、自動化はどう実現するのか。ここで日本IBMの小野塚氏は、IBMの持つテストツールを三つ紹介した。「IBM Rational Performance Tester」は、Web、SAP、Cirix、Siebelに対応した負荷テストツールだ。たとえばWebアプリケーションを多重化して一気に負荷をかけ、応答が遅いページのCPUやメモリなどのリソースの状況を見て、ボトルネックを発見する。
二点目の「Rational Functional Tester」は、マウス、キーボードの操作を記録して、自動的に再生するツールだ。さまざまなパターンの単純操作の繰り返しが可能で、Web、Java、.NETアプリケーションに対する回帰テストを自動化することができる。入力に対する出力が動的に変化するデータについても、パターン・マッチングによりチェック可能だ。
最後の「IBM Rational AppScan」は、Webアプリケーションのセキュリティ検査を行うツールだ。SQLインジェクションやクロスサイトスクリプティングなど、設定ミスや既知のぜい弱性をターゲットにしたハッカーの視点による「ブラックボックステスト」を自動的に行う。発見した問題点の指摘だけでなく、修正方法も提示する。
またIBMでは、分散開発のインフラとなるツールも提供している。まずRational ClearCaseは、ソースコード変更の記録と変更後のビルド、リリース作業を自動化する。Rational Build Forgeは、ビルドとその理由を関連づけ、一連のビルド作業を自動化する。そして現状確認と可視化、メンバーの連携をサポートし、リリースごとの障害情報を提供するのがRational ClearQuestだ。
小野塚氏は「自動化できるところは積極的に自動化ツールを活用することによって品質が上がる。早い段階から反復的に実行できることが重要」とまとめ、セッションを締めくくった。