品質リスクを評価する方法
前回のコラムでは、品質リスクの高低をパラメータにして、テストのやり方を変えていくことで、ソフトウェアのビジネス価値を判断するために必要な情報量と、その情報を得るために必要なコストや時間との間でバランスを取ることが可能になることまで解説しました。今回は、まず品質リスクの高低をつける方法について見ていきたいと思います。
品質リスクは、ソフトウェア要求の分析フェーズにおいて、ソフトウェアが想定どおりに動かないことがビジネスにどの程度の影響を及ぼすのかを評価して算出します。
品質リスクは、以下の式で表し、評価することが可能です。
|
品質リスク＝ソフトウェアの問題によって引き起こされる損害×問題が発生する確率 |
「問題により引き起こされる損害」に関しては、よりビジネスに近い要求に対して評価を行います。具体的には、以下のような要因に対して損害の度合いを評価します。
- 不具合が出た機能の使用頻度
- イメージの悪化による（不具合が出た機能による）業務の喪失
- 財政的、経済的、社会的損失または責任の可能性
- 民事上または刑事上の法的拘束
- ライセンスの喪失
- 妥当な次善策の欠如
- 故障の判明による否定的な評判
※ISTQB Advanced Levelシラバスより引用(http://jstqb.jp/syllabus.html)
一方、問題が発生する確率は、システムへの要求に対する技術的なリスクと解釈して評価を行います。評価は、以下のような要因に基づいて実施します。
- 技術およびチームの複雑性
- 開発者の個人的な問題およびトレーニングの問題
- チーム内の衝突
- 供給者側との契約の問題
- 開発組織の地理的な分散
- 新しいアプローチ
- ツールや技術に慣れていない
- 管理または技術的なリーダーシップの劣悪性
- 時間、リソース、管理のプレッシャー
- 初期品質保証の欠如（レビュー、ソフトウェア構成管理）
- 仕様変更多発
- 前のテスト・レベルでの低品質
- インタフェースと統合の問題
※ISTQB Advanced Levelシラバスより引用(http://jstqb.jp/syllabus.html)
問題の発生確率に対するリスクは、システム要求で評価した後にビジネス要求へ積み上げていきます。そして、システム要求で評価した問題が発生する確率を積み上げていくうえでは、トレーサビリティが重要な役割を担うことになります。
大切なのは「正確さの追求」ではなく「比較を可能にする」こと
ソフトウェアに品質リスクがあるということは、そのソフトウェアの機能を利用する際に問題が起きる可能性があることを意味しますが、問題発生の確率は不確かなものです。そのため、上記の式はリスクの重大さを理解するうえでは役立ちますが、問題発生の不確実性に対処するのには役立ちません。つまり、ソフトウェアの品質リスクは計算することは可能であっても、そのリスクが顕在化するかどうはあくまでも不確実な予測でしかないということです。
その意味で、品質リスク評価の目的は、個々のリスクの正確な分析を行うというよりも、それぞれの深刻さを比較し優先順位をつけることにあります。したがって、品質リスクの評価結果には利用者サイドの合意が不可欠であり、リスク評価ミーティングは必ず開発側と利用側が一緒に行わなければなりません。またそうすることで、ソフトウェアのビジネス価値の適切な評価につながるのです。さらに、リスク評価に関する合意形成というプロセスを開発工程に組み入れて、開発側と利用者側の双方で品質リスクを共有することは、利用者側と開発側の意識のギャップを埋める役割も果たすのです。
「リスクベースドテスト」導入の2つの障壁
前回、今回と説明している品質リスクをベースにしてテストを進めていくことを「リスクベースドテスト」と呼びます。
このアプローチは、欧米ではかなり一般的になっていますが、基本的な考え方は、「テストは、ビジネス価値を判断するための情報源である」という、本連載でこれまで述べてきたことそのものです。
このアプローチ、つまり、リスクベースドテストを適用する際の障壁は大きく2つあります。
1つは、前述した「リスク評価に対する合意形成」です。例えば、この合意形成のプロセスが利用者側と開発側との（開発に関する）料金交渉の側面を持ってしまうと、それぞれの思うところを正直に言い出しにくい状況に陥ってしまうのです。
またもう1つは、「評価内容の定期的な見直し」です。リスクは不確実で変動性が高いものであるゆえに、それに対する見直しは欠かせません。開発当初に大きなリスクだと思っていたことも、開発過程で技術上の課題が解決さることで、些細なリスクへと変容することも間々あります。その逆に、利用者側の要件変更によって、問題発生の確率が高まっていく個所もあるはずです。
このような変化をリアルタイムに反映した最新のリスク評価をベースにテストの配分や量を見直していかなければ、現実とのかい離が激しいリスク評価をベースにテストを進めなければならなくなります。その結果として、開発側も利用者側もリスク分析の必要性を感じなくなってしまうのです。
とはいえ、上述した2つの壁を乗り越えることができれば、リスクベースドテストは驚くほど簡単に導入することが可能になるのです。
品質リスクで評価するビジネス価値の実現度
利用者側は、品質リスクを指標にすることで開発中のソフトウェアがビジネス価値をどこまで実現しているかを判断することが可能になります。ということで、本稿の最後にそのための具体的な方法について触れておきましょう。
通常、開発終了の是非を決める際には、テスト密度（コード行数に対するテスト実行数）と欠陥密度（コード行数に対する欠陥数）、および信頼度成長曲線（欠陥の検出傾向）といった3つの指標を用いた品質評価が行われます。それに対し、リスクをベースに品質の判断を下す場合には、これらとは異なる指標が用いられます。
具体的には、テスト密度や欠陥密度の代わりに、リスクとして識別された項目に対するテストの「合格度合い」、「欠陥の検出数」が指標になるのです。また、傾向値としては、リスクの度合いを点数づけし、テストが合格するごとにその点数がマイナスされていく傾向を指標化したものが用いられます。そして、これらの指標に基づきながら、リスクが許容範囲まで軽減されたことを確認し、開発終了の是非を判断することになるのです。
以上、前回から2回にわたり、ソフトウェアのビジネス価値を判断するための効率的なテスト手法として、品質リスクの考え方を用いたアプローチを説明しました。このアプローチの採用によって利用者側は、投資と時間とのバランスを取りながら、ソフトウェアのビジネス価値を判断することが可能になります。なお、次回からは、ソフトウェア開発のトレンドであるALM（アプリケーションライフサイクルマネジメント）について、その考え方や効果について解説していきたいと考えます。
※ これは2011年にCIOオンラインにて「【HP特別連載コラム】探求！ビジネス成長とIT革新
シリーズ3：ビジネス成果をもたらすソフトウェアを開発するために（6）」として連載したものを転載したものです。