これもHPソフトウェアの何かのサイトで2012年5月に公開された（っぽい）のであるが、どこでどんなふうに公開されたかが記憶に無いです。もしかしたら未公開かもしれないです。これともう一回分残っているのを昨日偶然見つけましたので楽しみにしてください。（そこからの続きは、希望があれば書きおろしするかもしれないです。）

ーーーー

皆さんこんにちは。前回の虎の巻の連載記事を執筆したのがなんと去年の11月なので、半年ぶりになります。ご無沙汰してしまいすいません。今回のテストマネジメント虎の巻は、テストの投資効果についての続きです。前回は欠陥の件数を予測し、その修正にかかるコストから、投資効果を考える話をしました。今回は欠陥の修正コストから見た投資効果以外の投資効果について述べていきます。

前回のおさらい

前回、投資効果を考えるためには、テストがソフトウェア開発にとってどのような価値を提供しているのかを明らかにすることが必要であることを述べました。そして、その価値とのバランスでどこまで調整するのが良いとしました。テストの価値の一例として、Rex Blackの「ソフトウェアテスト12の必勝プロセス(日経BP社)」から、テストの価値として4つ挙げました。

• バグを発見し、結果的にそれが修正される。場合によってはバグを未然に防止する

• バグを発見し、結果的にそれが修正されなくてもバグは既知の問題となる

• テスト実行により、（潜在的に重大性を持つ）リスクを軽減する

• 各時点の必要に見合った正確かつ信頼性の高い情報提供により、プロジェクト進捗の把握を助け、プロジェクトを成功に導く

前回は、欠陥の修正と未然防止にかかるコストから投資効果を考えたので、この4つからは、上記の最初の価値について触れたことになります。

欠陥が既知の問題となる効果

欠陥を発見しても、修正をしないままリリースすることがあります。修正しない理由は様々です。まず、修正することによる日程遅延が起きることを回避するために修正をしないと言う判断をする場合があります。これは納品直前の欠陥に対してそのような判断をする場合があります。もうひとつ、欠陥を修正することによって他の欠陥が入ってしまうことを回避するためです。

ただ、修正しないからといって、その欠陥は見つけても意味がなかった訳ではありません。見つけておくことによって他の対処が可能になるのです。例えばリリースノートに既知の問題をその回避策と共に明記しておく方法や、サポートの人たちに予めその情報（問題の内容と回避策）を伝えておくことで、問題が起きないようにするといったことは価値があります。投資効果を考えるために金額換算するためであれば、1件の問い合わせサポートにかかるコストと問い合わせ件数の予測で投資効果が算出できます。

他にも、積み残した欠陥が明確であれば次期開発の際、やるべきことが明確になります。また目の前の1件1件の欠陥を修正するのではなく、積み残した欠陥全体を見渡した上での解決策を考えることが出来るため、行き当たりばったりの修正をしないで済むといった効果も考えられます。（ただ、この効果を金額換算するのは難しいです。）

潜在的に重大性を持つリスクを軽減

これは、欠陥がそもそも見つからないとしてもテストをする価値があることを説明するための考え方です。RexBlackは「テストとは本質的には品質リスクをマネジメントするための手段であり、保険のようなもの（[基本から学ぶテストプロセス管理(日経BP社)]より引用）」だといっています。保険のようなものというのは、保険金が必要となる状況（自動車保険であれば車の事故）が起きなくても投資をするという意味です。保険では、損失額と損失の確率から保険支払額を出していきます。これと同じ考え方を利用してテストが合格する価値を定量化できます。実はこれはリスクベースドテストと言うテストの考え方そのものです。詳しくは、筆者が過去にCIOオンラインにて連載した以下の2つの記事を参照してもらえればと思います。

【第5回】品質リスクを使いビジネス価値判断のための優先順位を付ける

【第6回】品質リスクを使いビジネス価値判断のための優先順位を付ける

2017年3月6日追記　今上記の記事は消えてしまっています。上記の記事をこっちに転載するのもやりますのでそうしたらリンク貼り直します。

リスク分析には一般的に4象限の分類をすることが多くあります。

欠陥が無いとしてもテストをすることに価値がある領域には上記図のように優先順位をつけることが出来ます。この優先順位が高いほどテストをすることでその損害が発生してしまうリスクを軽減させる価値が高くなります。見積もりの際にこのリスク分析も一緒に行い、各領域に入ると思われる要件がどの程度あるかを計算できるようにしておきます。各領域の1件あたりの金額は、過去の市場トラブルにかかった費用をベースに算出した損害額と、その発生度合いを基に推定します。

ただ、これらの考え方から出した金額は、単純に投資効果として積み上げるのは誤解を招きます。なぜなら、こういう計算をすると、むやみに大きな金額になってしまうことが多く、単に不安の押し付けになってしまうことがあるからです。この価値を説明するために保険の例を挙げていますが、保険には、そもそも保険に加入するかどうかという選択もありますし、加入するにしても計算のパラメータである「損失額」は保険に加入する人が選択するわけです。1億円の保険に入るか、100万円の保険にはいるかによって毎月の支払額が変わります。テストで言えば、欠陥による損失額が1億円なのか100万円なのかは、その合意がとても大事になります。

信頼性の高い情報提供による効果

ソフトウェア開発の見積りに間する専門家であるCapers Jonesは、ソフトウェア開発の成功と失敗を左右する要因のひとつとして、「最適な品質管理アプローチ」を挙げています。Capers Jonesの「ソフトウェア見積もりのすべて(共立出版)」という本では、品質管理アプローチの良し悪しで成功率が2倍以上違うとも書かれています。Capers Jonesの成功の定義は、計画のコストやスケジュールがの超過が25%以内に収まるプロジェクトのことを指していますので、品質管理を正しく行うことが25%超過を防ぐと言うものです。テストは、品質管理の中で重要な位置づけを占めますし、テスト結果は、開発の後半になってきた時によりプロジェクトの正しい状況を把握するためにはもっとも重要な情報となります。この情報が適切に収集できない時にかかる判断ミス、及び判断ミスによって発生する不適切なコストを計算することで、価値を定量化できますが、実際はかなりしっかりしたデータ取りを常に行っていない限り、この価値を定量化した投資効果として表現するのは難しいかもしれません。

投資効果を表す目的

投資効果を表す目的は、見積もったテスト量を日程の都合だけで削減してしまうという誤った判断をしないためです。間違っても投資効果を大きく見せて、より多くテストに投資させると考えてはいけません。実際、そこまで投資効果を正確に見積もれるわけではなく、言えることは、日程の都合だけでテスト量を大幅に削減するよりは意味のある説明が出来ると言うことです。

今回は、前回と含めてテストの投資効果について説明しました。テストの見積りのどこにでも適用できる一般的な数値はありません。前述したソフトウェア見積りの専門家であるCapers Jonesでさえテスト工数の比率はどのくらいか？といった質問には「残念ながら、このような質問は聞くこともまたは答えることも非常に危険である。あらゆる規模と種類のソフトウェアプロジェクトについて、確実に見積もれるようなアクティビティの固定的な工数比率などは存在しない。特定のアクティビティに関わる工数比率を考えるほうがはるかによく、それを特定分野や特定規模のアプリケーションの文脈の中で考えるほうがはるかに適切である。」と述べています。

次回からはテストのモニタリングとコントロールの話に入っていきます。