[テストマネジメント虎の巻]第八回:テストの投資効果(その1)
これは2011年11月にHPのマーケティングサイトであるBTOClub(当時)のブログへ投稿したものを転載しています。
------------------------
皆さんこんにちは。今回のテストマネジメント虎の巻は、テストの投資効果についてです。これはテストの見積もりの一環ですが、現場のプロジェクトで投資効果を予め計算して予測するというのはできていないのが実態ではないでしょうか。今回から数回に分けて、テストの投資効果の意義と具体例について述べていきたいと思います。
見積りの調整
前回、テストの見積りについてどのように進めるかをテーマにしましたが、その中では、必要な作業の見積り方法とそ の見積りの精度を上げる工夫についてしか説明していませんでした。ですので、読者の中には「やりたいだけできれ ば幸せだよ。現実的には必要な工数の半分も確保できない。」というような感想を持たれた方もいらっしゃるのではな いでしょうか?
その感覚はもっともです。ソフトウェア開発はビジネスであり、ビジネスとして成り立たないようなテストをやることは許 されません。ただ、だからと言って、予算にあうようにするために、やみくもにテスト工数を削ってしまっては本末転倒で す。そのため、まずは前回お話ししたような「本来やるべきテスト」を見積もることが大事です。その後、現実を加味して 見積りを調整するのです。ただ、現実を加味するといっても結局与えられた工数を基にだけ調整していたのでは、テストする立場として納得できないことが多々出てくるでしょう。
テストの価値をベースにした見積り調整
ここで初心に帰り、テストを何故するのかを考えてみてください。テストをする理由はテストがソフトウェア開発にとって価値があるからです。その価値とのバランスでどこまで調整すればよいかと考えれば納得感も出ませんか?あなたが テストをマネジメントする立場であれば、与えられた工数に甘んじるのではなく、ビジネスとして成り立つための価値を ベースにして必要となるテストを行うようにプロジェクトに提案をしましょう。それこそがマネジメントの仕事です。では、 テストにはどのような価値があるでしょうか?一例として、Rex Black の「ソフトウェアテスト 12 の必勝プロセス(日経 BP 社)」を引用すると、テストの価値は下記の 4 つになります。
・バグを発見し、結果的にそれが修正される。場合によってはバグを未然に防止する
・バグを発見し、結果的にそれが修正されなくてもバグは既知の問題となる
・テスト実行により、(潜在的に重大性を持つ)リスクを軽減する
・各時点の必要に見合った正確かつ信頼性の高い情報提供により、プロジェクト進捗の把握を助け、プロ ジェクトを成功に導く
上記 4 つがテストの価値であることは、疑う余地のないところでしょう。これらの価値を金額換算することで、本来テスト すべきだと見積もった金額との差が計算できます。この差が投資効果です。投資効果がプラスになるのであれば、そ のテストの見積りを価値あるものとして提案できます。
投資効果を算出するためには、それぞれの価値を金額換算しなければなりません。以降、どのように金額換算するの かを見てみることにします。
欠陥の修正、および未然防止
ここでは、欠陥(本稿ではバグと欠陥を同義として扱います)1件当たりのコストという考え方が必要です。
図1 欠陥コストの評価
図 1 は、欠陥は早い段階で見つけるほど低コストになるという調査結果です。このような調査は他にも多くあり、開発 の常識となっています。この調査結果の場合、リリース後の欠陥 1 件あたりの改修コスト(図 1 の例では 14,102 ドル) は、テストのときの改修コスト(図 1 の例では 7,136 ドル)の約 2 倍となっています。これは、テストの時までに欠陥を修 正したほうが、リリース後に修正するよりも低コストで修正できることを指します。これがテストによって欠陥が発見され、 修正されることの価値です。また、コーディングをする前(要求分析や設計)の段階で欠陥が混入されないようにすることを本稿では予防とよんでいます。予防とは、いろいろな方法で、そもそも欠陥が混入しないようにすることです。例えば虫歯予防のために1日3回食後に歯磨きをするようなことを指します。予防ができるとさらに価値が高くなります。
実際にこの価値を算出するにはコストを下記のように分類して計算します。
<予防コスト>
欠陥予測し未然に防ぐための活動(例:計画、教育、ツール、標準化)
<評価コスト>
正式な評価によって品質レベルを維持するための活動(例:テスト、レビュー費用)
<内部失敗コスト>
リリース前に仕様を満たすことが出来なかった場合やお客様の期待を満たすことが出来なかった場合 に修復するための活動。(例:プログラム修正、文書修正など)
<外部失敗コスト>
リリース後に、仕様を満たすことが出来なかった場合やお客様の期待を満たすことが出来なかった場 合に、修復するための活動。内部コストに加えて、ヘルプデスクの対応コスト、お客様の機会損失や、 欠陥によるブランド喪失の可能性も含まれる)
これらのコストを計算した結果、
であれば、テストが「欠陥の修正、未然防止」に対しての価値を提供できていることになります。
前述したように、失敗コストには、内部失敗コストと外部失敗コストがあります。テストの時点で全部の欠陥を修正して しまえれば(要は、すべてを内部失敗コストにできれば)よいと思うかもしれません。ただし、全ての欠陥を取り除こうと すると、どこかで「予防コスト+評価コスト」が「内部+外部失敗コスト」を超過します。図 2 の品質コストモデルの場合、 品質レベル 80%の時点で総品質コストが最低になる(つまり投資効果のプラス額が最高になる)ことを指しています。
図2 品質コストモデル
これは、欠陥を 1 件見つけるために行うレビューやテストの件数の割合が変わっていくことを意味しています。最初の 時期であれば数件のテストケースで欠陥が見つかるかもしれませんが、ソフトウェアの品質が安定してくると、1 件の 欠陥を見つけるためにとても多くのテストケースを実行することが必要になってくるという意味です。(ただし、このモデ ルにはお客様の機会損失や、開発会社のブランドイメージ損失といったコストは含まれていません。)
そのため、全てをテストするわけではなく、適切なポイントでテストを終わらせなければなりません。
現実的な対処方法
このようなグラフを使った説明は、仕組みを理解するには有効です。最終的にはこのようなグラフを現実のプロジェクトにあてはめて評価できることを目標としてもよいかもしれませんが、現実的にこのモデルにあわせて適切なポイントを見つけていくのは困難です。
簡略的な方法としては、見積りに使用した不具合の件数 1 件あたりのコスト効果を算出する方法があります。
内部失敗コストとして、テスト担当者が不具合 1 件あたりの発見/再テストに費やす工数、および開発者が修正を行う 工数を算出し、そこからコストを算出します。(全部の不具合が欠陥として修正されるわけではないので、たとえば 95%といった係数を使います。係数は当然のことながら、自らの組織で計測を続けて精度の高いものにする必要があ ります。)
また、外部失敗コストとして考えられること(修正と再テスト、およびお客様への技術サポートコスト)を基に 1 件当たり の工数を算出し、そこから金額を算出します。両方の差分が欠陥を修正することによる投資効果です。たとえば、欠陥1 件当たりの修正金額が 50 万円(内部失敗コスト)だとします。これがリリース後だと倍の 100 万円(外部失敗コスト) だと仮定します。(倍という仮定は、図 1 から来ています。)テストでは 100 件の不具合が見つかるとして、95%の不具 合が欠陥として修正されると、4750 万円の価値があるということになります。この場合、4750 万円以下でおさまるよう にテストを見積もるということです。
テスト前に欠陥を取り除く
図 1 の例からも理解できていると思いますが、テスト前に欠陥を取り除くとさらに効果的(予防コストと内部失敗コスト のコスト差)です。たとえば、95 件の欠陥のうち、20 件が要求分析の段階でテスト技術者がレビューすることで取り除くことができたとします。要求分析の段階であれば 1 万円のコストで修正が可能だと仮定すると、テスト前の段階で取り除くことができると、(20×99)+(75×50)=5730 万円の価値があるということになります。ですから、早い段階からレ ビューができるようなプロジェクト計画になるように提案することは価値を高めます。テストが早期レビューに貢献でき る方法として、テスト設計を要求分析と並行して行う開発モデル(一般的には W モデルとして有名ですが、HP では HPQM という名前のメソドロジーがあります。)も提唱されています。この考え方についてはまた別途詳しく説明したい と思います。
今回は、テストの投資効果を考える必要性と、具体的な投資効果の考え方として、欠陥の修正や予防にかかる投資 効果を説明しました。投資効果の算出は、ただ単にプロジェクトの予算だけで見積りを決めるのではなく、欠陥修正、 予防による価値を一緒に考えたうえでテストの見積りを決めるための手段です。ただ、欠陥修正だけをテストの価値と してしまうのは不十分です。次回は今回説明していない他のテストの価値についての投資効果を考えてみます。