テストを金額にするといくら？：テスト駆動開発で行こう！（前編）（2/2 ページ）

[五十嵐博, 安中伸彦，株式会社シンプレクス・テクノロジー]

テストの価格って？

　「テスト！ テスト!!」とその重要性が叫ばれている割には、実際のプロジェクトではその存在が疎んじられ、軽視されていることって、よくありませんか。開発が延滞した結果、テスト工数が圧縮されてしまう、なんていう話は至る所で聞きます。テストがプロジェクト工数のバッファのように考えられていることも多いです（開発工数が足りなくなったらテスト工数を削る、なんて話です）。せっかくテスト駆動開発を導入しようとしても、プロジェクトの中にテストについてこの程度の意義（プロセスとして実施しとけばいいや、という感覚）しか感じていない人がいたとしたら、恐らくうまくいかないでしょう。

---

でもそんな人に限って、単体テストレベルで検出すべきバグがリリース後に発覚したようなときに「なんでテストしてないんだ」なんていう場合もありますよね。

---

　でもその結果、現実にどんなことが起こっているのかを正しく認識しなければなりません。そこで、私たちはテストの価値を認識するために、テストの価格を考えてみることをお勧めします。なぜならば、やっぱり金額で考えた方が、ビジネス的な観点からも意義がよりはっきりするからです。

　テストの価格ってテスト工数のコストでは？ という方もいると思いますが、ここでいう価格とは、テストの「価値」を金額で表示したものです（コストと価値は違いますよね）。ここではまったく別の観点からテストの価格を求めたいと思います。テストと交換可能な等価なものを見つけて、その金額からテストの価格を推定してみましょう。ではテストに見合うものとはどんなものなのでしょうか？

　それは、「リスク」です。テストはプロジェクトのある種のリスクと等価であるといえます。テストを減らせばそれだけリスクが高まります。逆に適切にテストを増やせばリスクが減ります。テスト工数を減らす決定をしたプロジェクトマネージャーは、その結果ある種のリスクを被ることになるのです。逆にいうと、テストを適切に増やすことによってそのようなリスクをカバーすることができる、といえます。

　リスクは金額に換算することが可能です。では、テストの値段を求めるために、それに見合うリスクの金額を求めてみましょう。ここでは厳密な金額を求めることが目的ではなく、その大きさを把握することが目的なので、簡略化しています。

---

共分散の効果や損失発生時点のずれなど、厳密に考えた場合にはここで紹介するやり方は決して十分ではありませんが、おおよその大きさを把握するという観点で割り切ってください。

---

リスクの金額を求める手順

1. まず、テスト不足によって発生するであろうさまざまなリスクとなる事象をリストアップし、それらの想定損失額を求めます
2. それらの事象の発生する確率を求めます
3. リスクの金額（期待値）＝Σ（想定損失額×発生する確率）

1. 想定損失額

　さて、テスト不足によって起こる損失にはどんなものがあるでしょうか？ さまざまなリスクの中でテスト不足によって損失が発生するであろう事象を列挙して、自分の立場（受注者、発注者など）における想定損失額を事象ごとに見積もってみましょう。次に示すのはシステム開発の発注者側、および受注者側それぞれの立場における想定損失額の例です。

◎ 想定損失額の例

・品質が確保できず、システムが稼働不能（検収されない）ケース

発注者　→　システム開発費用および関連費用、業務上の機会損失コスト

受注者　→　受注に伴う売上金額

・バグが収束せず、プロジェクト延滞コストが発生するケース

発注者　→　サービス開始が遅れたことによる機会損失

受注者　→　延滞で新たに発生したコスト（人件費など）

・重大なトラブルで損害賠償が請求されるケース

発注者　→　エンドユーザーから業務上の損失を訴えられるケース

受注者　→　発注者側から起こされる損害賠償額

・リリース後、バグ対応が大量に発生し、リリース後に想定以上のメンテナンス・コストが発生するケース

発注者　→　トラブルに伴う業務上の機会損失

受注者　→　メンテナンスに要する追加コスト……瑕疵（かし）担保責任に基づくメンテナンス

・システムの品質の悪さから顧客を失ってしまい、将来期待できる受注機会をなくしてしまうケース

発注者　→　エンドユーザーから期待し得る将来の売上金額

受注者　→　その顧客から期待し得る将来の売上金額

　最後の事象は将来の機会損失（ポテンシャル・エクスポージャー）に関するものです。これは金額的に大きなものとなりますし、ビジネス的にも大きな意味を持ちますので、忘れずに考慮しましょう。なお、これらの事象をリストアップする際には、「実は同じこと」がダブってリストアップされないように注意してください。

　テスト不足によって発生し得るリスクには発注者、受注者のいずれの立場にせよ、非常に不幸な状況が想定できます。また発生する確率はさておき、万が一発生してしまった場合のインパクト（金額）が非常に大きくなる可能性のある事象もあるかもしれない、ということが分かると思います。

2. 発生する確率

　上記でリストアップした事象が、どの程度の頻度で発生するかを求めましょう。これには過去のプロジェクトをひも解くのが一番ですが、正確な金額を求めることが目的ではないので、十分なサンプル数が得られない場合には「推定値」で代用してください。また事象の発生が必ずしもテスト不足だけによるものではない場合には、その事象に関するリスクの金額から、テスト不足によって発生した割合を推定して調整してください。サンプルがある場合には次のような数字を求めて、それを基にそれぞれの事象が発生する確率を求めてください。

• 過去のプロジェクトの実績数（母集団）
• 品質の問題から検収されなかったプロジェクトの数
• バグが収束せず、プロジェクト延滞コストが発生したプロジェクトの数
• 重大なトラブルで損害賠償請求が発生した数
• リリース後、バグ対応が大量に発生し、想定以上のメンテナンス・コストが発生した数・品質の悪さから顧客を失ってしまい、将来期待できる受注機会をなくしてしまった数

　上記のような数字が集まったら、最後は事象ごとに想定損失額と確率を掛けたものを合計します。これが「テスト不足で発生するリスクの金額（期待値）」、すなわち「テストの価格」に相当するものです。

　このように金額で把握することにより、払うべきコストの妥当性がはっきりしますよね。またシステムの性格により、想定損失額が変わればテストの価格も変化する、と考えるのは自然なことではないでしょうか。

　さあ、このテストの価格が求められていれば、テスト駆動開発に掛けるコストを合理的に説明できるようになります。あなたがテスト駆動開発を進めるに当たって大きな武器となるはずです。では、このテストの価格という武器を持って、テスト駆動開発（TDD）の世界に飛び込んでみましょう。

後編へ続く

「テスト駆動開発で行こう！」バックナンバー

• テスト駆動を導入するための3つのポイント
• テストを金額にするといくら？