テスト自動化ROI試算式の構成要素と5つの例。そしてCBAとは何か：テスト自動化のROIを計算してみよう（2）（2/2 ページ）

[太田健一郎，STAR（テスト自動化研究会）]

『TABOK』の3つの試算式

　ROI試算式を構成する要素が分かりましたので、次は前回紹介したテスト自動化の知識体系『TABOK』と、前述の『CBAoTA』で解説している試算式のバリエーションを見ていきます。

　『TABOK』では、「Simple ROI Method」「Efficiency ROI Method」「Risk Reduction ROI Method」という3つの試算式を紹介しています。

　3つの試算式は『Test Automation ROI』（DiJohnInnovativeConsulting,Inc.／PDF）という記事でオープンになっているので、これを参考にしながら解説していきます。

【1】Simple ROI Method

　Simple ROI Methodは下記の式で表されます。分母に自動テストの初期開発コストも含んでいます。

ROI(t) = (手動テストを続けた場合の運用コスト(t) - 自動テストの初期開発コスト - 自動テストの運用コスト(t)) / (自動テストの初期開発コスト + 自動テストの運用コスト(t))

　Simple ROI Methodはコストの構成要素を金額で積み上げていくもので、以下の特徴を持ったテスト自動化において有効です。

• テストエンジニアの単価が明確になっている
• 自動化の投資期間が長い
• 既存の手動テストをテスト設計やカバレッジを変更せずに、そのまま自動化する

　Simple ROI Methodのメリットとデメリットは下記の通りです。

• メリット
  • 金額ベースで積み上げていくため、ROI試算の内訳についてマネジメント層とコミュニケーションが取りやすい
• デメリット
  • テストエンジニアの単価が明確ではない場合、適用できない
  • 余りに計算を単純化し過ぎている
  • テスト設計やカバレッジを変更せずに、手動テストがそのまま自動テストに置き換わることは少ない
  • 自動化に伴う欠陥対策コストの減少、手動テストのカバレッジ増加などを無視している
  • テスト自動化によりプロジェクトの予算を圧縮できるように見える。通常は圧縮するのではなく、手動テストのカバレッジを広げたり、別のテストタイプのテストに再配分したりする

【2】Efficiency ROI Method

　Efficiency ROI MethodはSimple ROI Methodを改良したもので、金額削減のみに注力してしまうことが多いSimple ROI Methodに対して、金額ではなく、工数（時間や日数）をコストとして積み上げ、工数を改善する効率をROIとします。

ROI(t) = (手動テストを続けた場合の運用工数(t) - 自動テストの初期開発工数 - 自動テストの運用工数(t)) / (自動テストの初期開発工数 + 自動テストの運用工数(t))

　Efficiency ROI Methodのメリットとデメリットは下記の通りです。

• メリット
  • 金額の削減のみに注力することを避けられる
  • テストエンジニアの単価が明確でなくても、適用できる
• デメリット
  • 工数削減のみに注力するため、同一条件下ではSimple ROI MethodよりもROIは低くなる
  • 金額とテストエンジニアの単価の問題以外はSimple ROI Methodと同様の問題を抱える

【3】Risk Reduction ROI Method

　Risk Reduction ROI Methodは、テスト自動化によりテストの実行頻度とカバレッジ（自動と手動の両方）が増加した影響を加味するものです。これは「間接コスト」、つまり手動テストを実施していた場合の「欠陥コスト」と、自動テストによる低減したコストの差分を盛り込んだものです。

ROI(t) = (欠陥コストの差分(t) + 手動テストを続けた場合の運用コスト(t) - 自動テストの初期開発コスト - 自動テストの運用コスト(t)) / (自動テストの初期開発コスト + 自動テストの運用コスト(t))

　Risk Reduction ROI Methodのメリットとデメリットは下記の通りです。

• メリット
  • 手動テストと自動テストの単純な開発・運用コスト比較ではないテスト自動化の効果をROIに盛り込める
• デメリット
  • 「欠陥コスト」の低減を正確に見積もるのは難しい
  • テストカバレッジやテストタイプの増加は手動テストのままでも実施できるため、ROI向上の理由としてテスト自動化を訴求しにくくなる

ROIとCBAの関係

　ここまで、『TABOK』の3つのROI試算式を見てきましたが、最後の【3】Risk Reduction ROI Methodで取り扱った「間接コスト」「欠陥コスト」について考えてみましょう。

変動要素の例

　「間接コスト」の例として、製品あるいは本番サービスで発生した障害の対応コストがあるとします。その場合、欠陥を修正するコストについては、開発部門と（分離していれば）テスト部門が負うことになりますが、クレーム対応やリコール対応に掛かるコストはカスタマーサポート部門、広報部門、営業部門など、複数に及ぶこともあります。

　このような自部門外で発生するコストを除外して自部門のROI改善のみに注力すると、局所最適化になってしまう可能性があります。

　また、「内部」（自部門）と「外部」（自部門外）という考え方以外に、別の変動要素を考慮する必要があります。

　例えば、手動テスト、自動テストに限らず、同じメンバーで改善を進めていけば、1ケース当たりの設計コストや実装コストは下がっていくでしょう。また、逆にメンバーが入れ替わった場合は、一時的にコストが上昇することもあり得ます。

CBA（Cost Benefit Analysis）とは

　このような「外部」への影響、変動要素などを考慮する場合、CBA（Cost Benefit Analysis、費用・便益分析、*3）の考え方が参考になります。前述の『CBAoTA』の「CBA」部分のことです。

• *3：『電子政府政策における費用便益分析』（行政＆情報システム 2010年4月号／PDF）

　CBAとは、利益と投資のバランスを考える対象範囲を、「企業単体」から、「その企業の活動が影響を与える全ての範囲」にまで広げて、投資するかどうかを判断するものです。

割引現在価値とは

　また、CBAが対象とするプロジェクトは「規模」だけではなく（長期にわたるものが多いため）、「割引現在価値」という概念を取り入れています。「割引現在価値」はCBAを試算する際に不確実な将来の利益を現在の価値に割り引くものです。

　現在のように低金利状態が続いている日本では、「割引現在価値」まで考慮する必要はありませんが、長期かつ広範囲なテスト自動化を検討する場合、CBAにおける「時間経過」という概念を踏まえて、ROIを試算することもできます。

CBAについて学んでおこう

　このCBAは、通常、国が行う規制・施策に投資するかどうかを判断する際に用いられるものですが、前述した「欠陥コストの影響が、複数の部門にわたる場合のROI」を考える際にも有効な手法です。ぜひこの考え方も学んでみてはいかがでしょうか。

『CBAoTA』の2つの試算式

　CBAについてある程度理解していただいたところで、『CBAoTA』の2つの試算式を紹介します。

ROI(t) = テスト自動化による利益 / テスト自動化のコスト

試算式1

ROI(t) = Δ手動テストに対するテスト自動化の利益 / Δ手動テスト対するテスト自動化のコスト = ΔB(t) / ΔC(t)

試算式2

　『CBAoTA』では、試算式1にある、他と比較のない「テスト自動化による利益」と「テスト自動化のコスト」を正確に試算するのは難しいとしております。そのため、以降、試算式2をブレークダウンして解説しています。

ΔB(t) = Σ(自動テストによる固定費の削減分)(t) + Σ(n2回手動テストを実施した場合の変動費)(t) - Σ(n1回自動テストを実施した場合の変動費)(t)
 
ΔC(t) = Σ(自動テストによる固定費の増加分)(t) + Σ(自動テストの開発費) - Σ(手動テストの開発費) + Σ(自動テストのメンテナンスコスト) (n1/N)
 
n1 = 自動テストの実行回数
 
n2 = 手動テストの実行回数
 
N = メンテナンスが必要になるまでの自動テストの平均実行回数

試算式2の詳細

　この式では時間軸と共に、テスト自動化による改善と増加コスト、自動テストと手動テストの実行頻度の違い、実行回数とは異なる頻度で発生する自動テストのメンテナンスコストが考慮されています。

　前述の『TABOK』の【2】Efficiency ROI Methodを金額ベースにして精緻化したものと考えてよいでしょう。

次回はスモークテストとGUIテストを自動化するROIを計算

　次回は、上記『CBAoTA』の試算式2の要素を詳細に解説するとともに、この式を使ってスモークテスト（初期テスト）とGUIテストを自動化するROIを実際に求めていきます。

著者プロフィール

太田健一郎

テスト自動化研究会（STAR）／株式会社SHIFT

大手SIerで開発支援ツール開発SEを経験した後、商用・オープンソースを使った各種の自動テスト、パフォーマンステスト、インスペクションをお客さまプロジェクトで担当。その後、大手Webサービス会社でJenkinsを始めとするCIやテスト自動化、パフォーマンスチューニングなどを担当。

現在、株式会社SHIFTでテスト自動化やCIの導入、トレーニングを担当。その他、コミュニティ活動として、JaSST実行委員会、テスト自動化研究会などに所属し、公私ともにテスト自動化を始めとする自動化に情熱を燃やしている。