ツールの効果的活用で機能品質高め─テスト工程のあり方を見つめ直す

IT投資バランスの最適化を目指す

2013年1月29日(火)中村陽一郎

リスト

2012年7月、シリコンバレーの視察に出かけた。システム開発を支援するテストツールの最新動向を調査するのが主な目的である。その一環でIT投資を最適化するために役立つツールの状況もヒアリングした。本稿では、現地で得た情報をもとに「IT投資バランスの最適化」と「システム品質の向上」という2つの視点でレポートする。

より戦略的な情報システムへの投資割合の増加や、IT投資全体の抑制が声高に求められるようになって久しい。企業のIT部門はこれまで何年にもわたって理想的なIT投資のバランスを実現するために努力を続けてきたことだろう。しかし、現在も多くの企業では、既存システムの維持と運用に対するIT投資と、業務革新や新サービス創出などに対するIT投資の配分は「7対3」といわれている。理想とする「5対5」を実現する企業は少ないのが現状だ。

理想的なIT投資にならない理由はいくつか考えられる。中でも根深い課題の1つが、システム開発や運用、情報（データ）管理といった日々のIT活動がブラックボックス化している点が挙げられる。

多くの企業は営業活動の効率化や改善を目的に、SFA（営業支援）システムやCRM（顧客関係管理）システムなどを導入し、顧客への提案活動の進ちょくやクロスセル/アップセルに結びつくような顧客情報などを可視化してきた。ERPパッケージを導入して日々の財務活動を可視化し、収益改善に役立てる努力もしてきた。

しかし、こうした業務の実態を可視化するためのITの整備や運用はブラックボックスと化している。そんな例は決して珍しくない。

当然のことながら、SFAやCRMシステムといった切り口で個別にKPIを設定し、システムへの投資が適切かどうかを判断する企業は多くある。だが、個々のシステムではなく、IT投資の全体像を俯瞰し、かつ複眼的な視点でKPIを設定している企業は必ずしも多くない。IT投資を最適化するためには、こうした視点が不可欠となる。

開発から運用、安全性まで
全体を俯瞰して貢献度を把握

例えば米HPは2011年、ITの成果/評価の可視化を支援する「IT Perfor-mance Suite（以下、ITPS）」を発表した。これは、アプリケーション･ライフサイクル管理、システム運用、情報（データ）管理、情報セキュリティの4分野に関わるソフトウェア群と、KPIダッシュボード、コンサルティングサービスを包括した構成になっている。

その中で、IT投資を最適化するのに役立つのが「IT Executive Scorecard」だ（図1）。HPおよび他社のさまざまな管理ソフトウェア群から、IT活動を可視化するのに役立つ情報を収集し、企業のCIO（最高情報責任者）やPMO（プロジェクト管理オフィス）、IT運用責任者などの役割に応じたKPIダッシュボードを提供する。

図1　HP の「IT Executive Scorecard」の画面例

例えばシステム開発なら、成功したテストや、自動化したテストの割合をKPIとして設定し、実行状況をダッシュボードで把握できる。システム運用ならSLA（サービスレベルアグリーメント）の順守率や、致命的なエラーからの平均復旧時間（MTTR）をKPIとして設定し、達成率ををつぶさに確認する。IT活動全体を俯瞰した場合、どの項目を改善すれば理想的なIT投資バランスに近づくのかが判断しやすくなる。

進ちょくのズレや人海戦術など
システムテストの課題の現状

一方、システムの品質に目を向けると、要件を満たさないシステムが開発されるケースが目立つ。事業部門が満足しないシステムは少なくないようだ。日経コンピュータが実施したシステム開発プロジェクトに関する調査※1では、「品質」「コスト」「納期」のうち成功/達成率がもっとも低かったのが「品質」だった。システム開発においては、いかに機能品質を高めるかが重要なテーマとなっている。

※ 1　出典「日経コンピュータ 2008年12月1日号」

機能品質を損なう要因は、テスト工程を軽視し、テストを単純な作業だとみなしていることが考えられる。一般的な開発工程は、全工程時間の約5割をテストに費やすと言われ、保守の改修プロジェクトや、ミッションクリティカルなシステムの場合、8〜9割がテストというケースもある。

しかし、どんなテストを実施すべきかを十分検討した上で取り組むケースは意外と少ない。これまでの経験と勘を頼りにテスト項目を決めたり、経験の浅いエンジニアにおいては“行き当たりばったり”でテストを実施したりしているのが現状であると言わざるを得ない。残念ながら、テスト工程を上流工程の遅延を相殺するバッファと考えているプロジェクトマネジャーが少なからず存在するのも事実である。

これは、テスト工程を単なる作業と捉え、テストは実施しさえすればよしと捉えられていることに問題がある。ソフトウェアテストを体系的に学ぶための国際資格「ISTQB」のシラバス（学習事項）では、テストとは何かという問いに対し、以下のように記している。

テストの活動は、テスト実施の前後にも存在する。例えば、計画、コントロール、テスト条件の選択、テストケースの設計と実行、実行結果のチェック、テスト完了基準の検証、テストプロセスやテスト対象システムに関する報告、テストのまとめや終了作業（テストフェーズが完了した後）がある。テストにはドキュメント（ソースコードを含む）レビューや、静的解析を実施することも含む。※2

※2　出典「ISTQB テスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2011.J02」（作成：InternationalSoftware Testing Qualifications Board、（翻訳：Japan Software Testing QualificationsBoard）

つまり、テスト活動とは単に実行フェーズだけではなく、テストの準備作業や検証作業なども含めているのだ。

要求分析、要件定義、設計、実装、開発の各工程において、テストを見据えた詳細な分析を行うことが品質の保障につながる。テスト工程になって慌てて実施するテスト内容を決め、ただ消化するだけでは品質が損なわれて当然である。ただし実際の開発現場では、上流工程で詳細な要件まで定義するのは困難であることが多く、テスト分析を上流で行っているケースは少ない。

前工程の遅れによるテスト工程の短期化も問題である。要件を決める工程、システムを設計する工程、連携するシステムの開発遅延など、さまざまな工程が遅れるケースは少なくない。こうした進ちょくの遅延が少しずつ積み重なることでスケジュールを圧迫し、テストに割く時間が削られてしまうのだ。テスト期間の短期化は品質の低下に直結する。遅れを取り戻そうと人海戦術でテストを実施すればコスト超過を招く。コミュニケーション不足による手戻りの発生も懸念され、プロジェクトそのものが失敗に終わるケースもある。