テスト自動化ROI試算式の構成要素と5つの例。そしてCBAとは何か:テスト自動化のROIを計算してみよう(2)(2/2 ページ)
テスト自動化の導入理由や効果測定をROIという観点で説明できるように、テスト自動化のROIの概念から実際の計算式までを解説する連載。今回は、テスト自動化ROI試算式の構成要素を解説し、5つの試算式の例を出しながらCBA(Cost Benefit Analysis)とは何かを解説。
『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) = テスト自動化による利益 / テスト自動化のコスト
ROI(t) = Δ手動テストに対するテスト自動化の利益 / Δ手動テスト対するテスト自動化のコスト = ΔB(t) / ΔC(t)
『CBAoTA』では、試算式1にある、他と比較のない「テスト自動化による利益」と「テスト自動化のコスト」を正確に試算するのは難しいとしております。そのため、以降、試算式2をブレークダウンして解説しています。
ΔB(t) = Σ(自動テストによる固定費の削減分)(t) + Σ(n2回手動テストを実施した場合の変動費)(t) - Σ(n1回自動テストを実施した場合の変動費)(t) ΔC(t) = Σ(自動テストによる固定費の増加分)(t) + Σ(自動テストの開発費) - Σ(手動テストの開発費) + Σ(自動テストのメンテナンスコスト) (n1/N) n1 = 自動テストの実行回数 n2 = 手動テストの実行回数 N = メンテナンスが必要になるまでの自動テストの平均実行回数
この式では時間軸と共に、テスト自動化による改善と増加コスト、自動テストと手動テストの実行頻度の違い、実行回数とは異なる頻度で発生する自動テストのメンテナンスコストが考慮されています。
前述の『TABOK』の【2】Efficiency ROI Methodを金額ベースにして精緻化したものと考えてよいでしょう。
次回はスモークテストとGUIテストを自動化するROIを計算
次回は、上記『CBAoTA』の試算式2の要素を詳細に解説するとともに、この式を使ってスモークテスト(初期テスト)とGUIテストを自動化するROIを実際に求めていきます。
著者プロフィール
太田健一郎
大手SIerで開発支援ツール開発SEを経験した後、商用・オープンソースを使った各種の自動テスト、パフォーマンステスト、インスペクションをお客さまプロジェクトで担当。その後、大手Webサービス会社でJenkinsを始めとするCIやテスト自動化、パフォーマンスチューニングなどを担当。
現在、株式会社SHIFTでテスト自動化やCIの導入、トレーニングを担当。その他、コミュニティ活動として、JaSST実行委員会、テスト自動化研究会などに所属し、公私ともにテスト自動化を始めとする自動化に情熱を燃やしている。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- テスト自動化の歴史と今後、良い/悪い事例〜システムテスト自動化カンファレンス2013レポート
テスト自動化を開発の“武器”にするための3つのポイントや、“自動化”の良い事例、悪い事例など、テストの現場を「進化させる」知見が多数紹介されたカンファンレンスの模様をレポートする。 - Selenium WebDriverでWebアプリのテストが変わる(前編):iPhone/Android含むブラウザ自動テストの最終兵器Selenium WebDriverとは
Chrome、Firefox、Internet Explorer、Opera、Android、iOSといったブラウザに対応し、Java、C#、Python、Rubyが使えるWebテスト自動化ツールの3つの特徴と環境、実装方法を簡単に紹介 - フレームワークで実践! JavaScriptテスト入門(5):Capybara-Webkit+Cucumber+Sinon.JSでJavaScriptのテストはここまで変わる
RubyでWebKitをヘッドレス化するフレームワーク、受け入れテストの記述が日本語でできるツール、スタブやモック、スパイが使えるライブラリを組み合わせたテスト方法などを紹介。 - Railsで目指せ、情熱エンジニア(8):実例で学ぶRailsアプリのテスト方法
前回はRailsで使われるテストフレームワークをご紹介しました。今回は具体的なWebアプリを例に、簡単なテストを使ったリファクタリングについて解説します - Androidアプリ開発テスト入門(2):Android SDKでビジネスロジックのテストを自動化するには
Android開発におけるビジネスロジックについて解説し、Android SDKのテストフレームワークの概要と使い方、テストの書き方を紹介します - 特集:受け入れ検査の自動化手法の考察:Windowsアプリの受け入れテストを自動化しよう
単体テストの次は、エンド・ユーザーへの納品時の受け入れテストも自動化したい? それを実現する手法を紹介する。 - 特集:UIオートメーションによる自動UIテスト:WindowsアプリのUIテストを自動化しよう!
Windowsアプリのユーザー・インターフェイス、どうやってテストしていますか? 単体テストで徹底的に自動化して開発効率アップ! - 連載:ASP.NET MVC入門【バージョン3対応】最終回 テスト自動化でアプリケーションの品質向上
M、V、Cに明確に分離されたアプリ構造は従来に比べ単体テストも実施しやすい。テストの基礎からモック・ライブラリ活用までをまとめる - PHP開発者のためのテストのすゝめ(1):ユニットテストはなぜ必要なの?
開発の全工程の中で、あまり人気がないのがテスト工程だ。ソフトウェアの品質を証明するためのテストは、なぜ低く見られてしまうのか - Eclipseプラグインq4eでカンタンMaven入門(前編):ビルドやテスト、依存ライブラリ追加は自動化できる!
ビルドやテスト、レポート作成、依存ライブラリ追加を自動化するMavenと、その操作を簡単にするEclipseプラグインを紹介 - 第1回Androidテスト祭りレポート:Android開発で泣かないための「テスト」の重要性
その自由度の高さや多様性ゆえに、さまざまな課題を抱える、Androidアプリ開発の“テスト”に焦点を当てたイベントの模様を紹介します - UX Clip(28):JavaScriptのテストを開発工数に入れてもらうには?
Webアプリの大規模化とフロントエンド領域の拡大により、JavaScriptのテストの必要性が高まっている。数ある高機能なテストフレームワークをどう使いこなせば、高速かつ高品質な開発が可能になるのだろうか。