ソフトウェア開発は時間との戦い

前回のコラムの中で、ソフトウェアの利用者側は、開発プロジェクトにおけるテストの計画／設計がしっかりできているかどうかに留意すべきであると述べました。また併せて、ソフトウェアに対する要求を適切に分類し階層化しておくことと、要求とテストとを紐づけておくことが、開発プロジェクトを成功に導くポイントであるとも指摘しました。

繰り返すようですが、上に掲げた点は重要です。というのも、テストを通じて開発中のソフトウェアがビジネス要求を満しているか否かを確認できるようにしておくことは、ソフトウェアのビジネス価値を判断するうえで非常に有効だからです。

もっとも、ビジネス上の価値判断が正確に下せるようなテストを計画／設計したとしても、計画したすべてのテストを実行する時間が取れないケースも間々あります。

とりわけ、変化の激しい現代のソフトウェア開発では、工期の短縮が大きな命題となっており、適切なタイミングで必要とされるソフトウェアを供給することが強く求められています。またそれが、クラウド導入の活発化やアジャイルな開発プロセスに対するニーズの高まりにつながっているのです。まさに、今日のソフトウェア開発は時間との戦いだと言えるでしょう。

それゆえに、テストにも開発と同様の俊敏性が求められ、利用者側がビジネス価値を判断するための有意義な情報をより短期間に受け取れるようでなければなりません。

そこで必要とされるのは、テスト量の調整だけではありません。ソフトウェアに対するビジネス上の価値判断を下すために何を優先的に検証するかの順位づけも必須となります。

またそれを行うには、ソフトウェアのビジネス価値を判断するために必要とされる情報量と、その情報を得るためにかかるコストや時間とのバランスを取ることが求められます。

そして、このバランスを見定める方法として、「品質リスク」という考え方があるのです。

「品質リスク」の考え方

リスクとは一般的に「悪い結果になってしまう可能性」を指します。ソフトウェア開発におけるリスク――すなわち、「悪い結果になってしまう可能性」には、いくつかの種類があります。

その1つは、プロジェクトの予算や納期を順守できないリスクです。これはプロジェクトのマネジメントがうまく機能しないことに起因するリスクであることから、「プロジェクト・リスク」と呼ばれます。

また、もう1つのリスクは、開発したソフトウェアを利用する際に、利用者の想定通りにソフトウェアが機能しないというリスクです。

これはまさに、本連載の第1回で言及した「価値あるソフトウェア」が開発できないというリスクであり、これを「品質リスク」と呼びます。言い換えれば、ソフトウェア開発を進める中で、この品質リスクをうまくマネージ（管理）していくことが、「価値あるソフトウェア」を開発することに直結するというわけです。

品質リスク管理の3つの方法

品質リスクを管理する方法は、通常のリスク・マネジメントと同様にいくつかあります。

方法の1つは、リスクを完全に回避することです。これは要するに、「品質リスクが高いものは開発しない」という方法です。この方法を採用することで、当然、品質リスクはゼロになりますが、ソフトウェアの開発で得られるリターンもゼロになります。

次に考えられる方法は、リスクの移転、あるいは分散化です。具体的には、リスクが顕在化したときに被る損失を他者と分担できるようにしておくことです。その一般的な例としては損失の補てん分を保険にかけるという方法が挙げられます。また、新規性が高く研究色の強いソフトウェアを開発する場合、想定どおりのものが作れないおそれが強くあります。そのようなケースにおいて、品質リスク上の損失を開発ベンダーと利用者とで分担し合う契約をあらかじめ結んでおくといったことも一例として考えられます。

さらに、もう1つの方法として考えられるのがリスクの低減です。この方法はすなわち、ソフトウェアの開発時に、品質リスクの低減に向けたさまざまな工夫を凝らすというものです。

そうした工夫の一例として、開発の初期段階において品質リスクを内包した機能を試作し、設計上の課題を早期に解決するという手法が挙げられます。とはいえ、品質リスクを内包したすべての機能に対してこの手法を適用するのはコスト的に見合わない場合がほとんどです。したがって、品質リスクの高低を評価し、品質リスクが高いところに対して優先的に対処する必要が生じます。それがすなわち、「品質リスクの考え方を用いて、ビジネス価値判断のための優先順位づけを行う」ということなのです。

投資や時間とのバランスを取るパラメータ

テストやレビューは、品質リスクが低減したかどうかを確認する手段として重要になります。

品質リスクをベースにしたテストのアプローチでは、品質リスクの高い機能を洗い出し、それらのテスト／レビューの優先度を高くして、それぞれの品質リスクが低減していることを早期に、また確実に確認できるようにします。

その具体的なやり方としては、例えば、品質リスクが高い機能に対しては、テストやレビューの実施順を早めたり、テスト・ケースを増やしたり、自動化を推進してテストを何度も行ったりといった方法が考えられます。

ただし、それだけではテスト量が増えることはあっても、減ることはありません。そこで、品質リスクの低い機能についてはテストを単純化したり、実施順を後回しにしてテストを1回で済ませたりして、全体のテスト量を調整します。

このように、品質リスクの高低をパラメータにして、テストのやり方を変えていくことで、ソフトウェアのビジネス価値を判断するために必要な情報量と、その情報を得るために必要なコストや時間との間でバランスを取ることが可能になります。

以上、今回はソフトウェアのビジネス価値を判断するためのテストの効率的な手法として、品質リスクの考え方を用いるアプローチについて説明しました。このアプローチでは、ソフトウェアの利用者がテストの情報を頼りに品質リスクが低減されたかどうかを確認することになりますが、今回はその説明まで話が及びませんでした。そこで、次回も引き続き品質リスクを取り上げ、利用者がビジネス上の価値判断を下す際に留意すべきポイントや着目すべき点について解説する予定です。

※　これは2011年にCIOオンラインにて「【HP特別連載コラム】探求！ビジネス成長とIT革新

　シリーズ3：ビジネス成果をもたらすソフトウェアを開発するために（5）」として連載したものを転載したものです。