Loading
|
|
|
Loading
|
| ＠IT > 開発が変わる：アプリケーションの品質がITプロジェクトの鍵を握る |
 |
アプリケーション開発における評価指標の1つとして、Quality（品質）、Cost（費用）、Delivery（納期）が広く使われてきた。評価の基準や達成目標が比較的明確な「費用」「納期」に比べ、「品質」の評価には常にある種のあいまいさが残り、往々にして、作業工数や人員不足などを理由に不十分なテストを実施しただけで納期に間に合わせることもあった。しかし、アプリケーションの品質は最終的にビジネスに大きな影響を及ぼす。今まで、アプリケーション品質向上のためにさまざまな試みが行われてきたが、重要なことは、品質はプロセス全体で包括的に管理されるべきだということ。重大なビジネスリスクを引き起こす危険性は、アプリケーションの機能面と同様に性能面にも秘められており、これらの問題を本番稼動前に、どれだけ正確かつ早期に発見、修正できるかが、提供するサービスの品質の鍵を握るのである。
アプリケーション開発プロジェクトの評価指標の1つである「QCD」（Quality：品質、Cost：コスト、Delivery：納期）｡これまで、これら3つの評価指標が等分に機能してきたかというと、必ずしもそうではなかった。プロジェクト管理において最も重要視されてきたのは、費用と納期だった。“これこれの予算で、いついつまでに間に合わせること”が、大命題だったのである。そのため、アプリケーション開発の世界においては、生産性の向上を支援するものは次から次へと誕生してきた。開発言語しかり、統合開発環境しかり、IT業界を挙げていかに早く効率よく作るかを模索してきたといえる。そのように作ることができれば、時間が稼げるだけでなく、工数の削減により人件費などのコストも抑制できるからだ。 では、品質はまったく問題にはならなかったのか、というと、決してそういうわけではない。動かないアプリケーションを歓迎するユーザーなどいるはずはなく、それどころか彼らからは高いレベルの要望が出されるのが常だった。しかし、さまざまな開発生産性向上の支援策が施されているにもかかわらず、曖昧かつ変化する要求、複雑に絡み合う進捗管理、ますます短期化する開発期間などの理由により、アプリケーションは期日までにどうにか仕上げるというのが精一杯のところだった。品質については十分な検証期間が取られていないため、ユーザーが満足できるレベルにはほど遠い、というのが実情だったのだ。
アプリケーションの品質は、納期やコストと同等、あるいはそれ以上に重視されなければならない。なぜなら、品質の低さが最終的にビジネスに悪影響を及ぼしてしまうからだ。例えば、ある条件下で間違った計算結果を返す不具合だったとしよう。それが金銭に関わるアプリケーション、あるいは人命に関わるアプリケーションであったりすれば、提供する企業や組織は社会的信用を大きく損なうことになる。あらゆる場面でITシステムが社会インフラになりつつある今日、アプリケーションの品質は社会問題に直結しかねないのである。 IT業界もこうした環境の変化にまったく無関心というわけではなく、開発をめぐる状況は徐々に変化を見せつつある。テストファースト、テスト駆動型開発などと呼ばれるプログラムの開発手法はその代表例だろう。コードの記述に入る前にテストケースを書き、その後にプログラム本体の記述に着手する。完成したらテストを行い、パスするまで修正を繰り返す。不具合は「すべてのテストにパスしない」という形で発生するため、運用段階で発見される不具合を修正するよりもはるかに容易だ。 ただ、テストファーストで開発すればアプリケーションの品質問題がすべて解決するかというと、それほど単純ではない。ここに興味深いデータがある。アプリケーション開発において、不具合の出所を調査したところ、その70％は要件および設計フェーズで発生しているとのことだ。一方、アプリケーションの不具合のうち、その60％がユーザーによる受け入れテストで発見され、さらに、本稼動後に発見されるものも20％あるという。 テストファーストでは、コーディング前にあらかじめテストを書いておくため、不具合は、コーディングの段階で修正される。つまり、プログラマは、自分のミスを自分で発見できる。しかし、テストファーストを採用したとしても、上流工程で埋め込まれた不具合まではコーディング段階で修正することは、実際には非常に困難であり、ユーザーによる受け入れテストの段階で初めて認識されるケースが多いということである。アプリケーションの品質を不具合の割合で測るとすれば、このアプリケーションの品質には問題があることになってしまう。 この事実が示唆することは明らかだ。アプリケーションの品質管理は要件、設計、コーディング、テストなどの段階ごとに行うのみでなく、統合的に行われるべきなのである（図1）。特に、開発プロセスに入る以前の要件管理からスタートすることが重要だ。要件の種別、内容、重要度、優先順位、変更可能頻度などを整理し、テスト要件と結びつける。これに基づき、テスト戦略が策定され、何をどのように実現すべきかを把握したうえで、テスト計画が立てられ、実際にテスト（手動および自動）が実行される。テストの結果、発見された不具合を分析し、開発部署にフィードバックする。さらに、不具合をリアルタイムで管理し、発生から収束までを時系列で追っていく。つまり、アプリケーションは要件管理、テスト計画管理、テスト実行管理、不具合管理といった統合的な品質管理の枠組みの中で品質の向上を考えて初めてユーザーの満足を得られるレベルに到達できるということなのだ。
この統合的な品質管理は、コストを抑制するという意味でも重要な取り組みである。一般に、不具合の修正コストは、運用段階では開発初期段階に比べて100倍かかるという。また、ある研究では、要求段階のコストを1とすると、設計段階で5倍、コーディング段階で10倍、テスト段階で20倍、納入時点で直すと200倍かかるとしている。数字に若干違いはあるものの、不具合をできるだけ早い時点で修正すればするほど、そのコストを抑えられるというのは、アプリケーション開発における真理のようだ。要件定義の段階で修正できれば要件定義書を書き換えるぐらいの作業で済む。 しかし、これが受け入れテスト段階まで進んでしまうと、当該部分のコーディングを見直し、その変更による他のプログラムへの影響度合いを調査し、テストプロセスを1からやり直す、といった具合に、作業は膨大なものになってしまう。また、結果として、予定の納期どおりに完成させられないという事態にもなりかねない。統合的な品質管理を行って、考え得るかぎり早期に不具合の芽をつぶしながら進行することが、アプリケーション開発においては何よりも肝要なのである。そのためには、テストプロセスを標準化し、各段階におけるテストを常に見える状態、すなわち可視化する必要がある。そのうえで、アプリケーションの品質を評価するための管理指標を設定し、それに基づいて、配備・導入・本稼動への移行可否判定（Go/No-Go）をすることになる。 また、アプリケーションの品質保証に際しては、機能面と同様、性能（パフォーマンス）面の検証が必須である。品質の最後の鍵を握る性能の検証は、アプリケーションによっては、機能以上に優先順位を上げるべきテーマといえる。性能の問題は、本稼動後に顕在化することが多く、この場合、修正にかかる費用が膨大になる。また、原因究明に十分な時間が取れず、その場しのぎの対処療法を行ったがために、問題をさらに大きくしてしまった例もある。アプリケーションの性能を的確に見極めずに、性能不足を看過（かんか）するということは、ビジネスが完全に停止してしまうということをも意味している。社内に広く告知し、満を持してオープンさせた新システムに対して予想を超えたアクセスが集中し、サーバが処理不能になる。それは大きな失望、怒りを招く事態だ。それが対外的に公開する戦略的システムであれば、さらに状況は悪くなる。アプリケーションの性能は常に最適化して維持しなければならない。それには、予想される性能上の課題を本稼動前に確実に検証し、起こる可能性のあるリスクをできるかぎり少なくする必要がある。 このように開発工程全体を見ながら、品質保証とリスクコントロールを手助けするものがないか、調べてみた。
ヒューレット・パッカードの展開するHP Softwareには、アプリケーションの品質と性能を検証し、総合的な品質の向上と維持を実現するための、問題解決策があるという。 まずは品質についてだが、同社はHP Quality Centerという統合品質管理ソリューションを用意している。構成製品の1つであるHP TestDirector softwareには、要件とテストを関連付けて管理する「要件管理」と、テスト戦略やテスト計画の立案を支援する「テスト計画」、手動および自動テストの実行管理を行う「テスト実行」、不具合の管理と追跡を行う「不具合管理」といったテスト管理に必須の機能が搭載されている。また、それぞれを連携させることで、テストプロセスの可視化と標準化が実現できるようになっている（図2）。
HP TestDirector softwareにより、品質に関するプロセスの標準化が行えるとともに、テスト資産の一元管理、管理プロセスの可視化と自動化が実現する。つまり、品質管理プロセスの最適化が現実のものになるというわけだ。また、テストに関するさまざまなデータを一元的に見ることのできるダッシュボードを利用すれば、品質管理プロジェクトの状態を、開発現場、管理者、顧客といった利害関係者の間でリアルタイムに共有し、意思決定に利用することも可能だ。 さらに、品質管理の最前線で利用される自動機能テストツールとしては、HP Functional Testing softwareがある。機能テストを自動実行することにより、夜間および休日といったプログラマの活動時間以外の時間を最大限に利用でき、人為的なミスを排除した品質の高いテストが可能になる。同一アプリケーションを異なるプラットフォームやOS、異なるWebブラウザなどといったさまざまな環境でテストする場合、これらを同時並行で実施でき、大幅な効率化が実現する。また、アプリケーションの変更やバージョンアップ、OSのサービスパック適用時に行う回帰テストでは、すべてのテストを繰り返し実施することで、テストカバレージの向上とテスト時間の短縮に劇的な効果が期待できる。 性能を最適化するためのソリューションには、HP Performance Centerがある。その中核をなすのは、エンタープライズ環境における負荷テストツールとして、もはや業界標準といえる地位を獲得しているHP LoadRunner softwareだ。コンピュータによって生成される仮想ユーザーが重要なビジネスプロセスに対する大規模なアクセスをエミュレートし、アプリケーションやシステムに負荷がかかったときの振る舞いをテストし、パフォーマンス・ボトルネックの特定と原因の分析を行う。これにより、システム障害によって起こりうるビジネスリスクを、本稼動前に削減することができる。HP LoadRunner softwareは、さまざまな仮想ユーザーを容易に生成できる直感的でわかりやすいGUI、幅広い環境のサポート、広範囲におよぶ分析機能など、数々の特長を有している。 もちろん、これらの標準化・自動化ツールが、いつも万能薬として働くというわけではない。ときには時間を割いても手動で行った方がいい作業もあることだろう。しかし、少しでも効率的に品質や性能を向上できるなら、ツールを利用した方が賢明なのではないだろうか。それにより新たに確保できた時間を、より本質的な思考や判断に割くことが可能になるからだ。 ◆ ビジネスの観点で考えれば、これからのアプリケーション開発は品質および性能の最適化を抜きにして考えることはできない。それが最大にして唯一のリスクヘッジポイントだからである。開発は変わる。品質の視点で根底から変わっていく。ITシステムの活用の仕方がビジネス成功への切り札となる状況の中で、いかにしてITのビジネス価値を最大化するか。アプリケーションの品質がITプロジェクトの鍵を握る。そんな時代がやってきた。
提供：日本ヒューレット・パッカード株式会社 企画：アイティメディア 営業局 制作：＠IT編集部 掲載内容有効期限：2007年5月14日 |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
