ソフトウェアテストにおけるリスクの捉え方 〜アメリカと日本の違い〜

作成:2006年2月7日

吉田誠一のホームページ   >   ソフトウェア工学   >   技術コラム   >   開発プロセス

2006年1月に開催されたソフトウェアテストシンポジウム in 東京(以下、「JaSST '06」と記す)では、アメリカからリック・クレイグ氏が招待され、基調講演が行われた。

クレイグ氏は、リスク分析を行い、リスクに基づいてテストの優先度を決める、という考え方を提唱した人である。

このリスクという指標は、テストケースやバグの重要性を評価する上で、たいへん分かりやすく、かつ有効である。リスクに基づいてテストを考えることは、今では当たり前になっている。実際、JaSST '06のテスティングライブやパネルディスカッションでも、リスクという言葉が盛んに使われていた。

これを見ると、クレイグ氏が提唱した手法は、日本で広く受け入れられているように思われるかもしれない。

だが、日本国内で使われているリスク分析と、クレイグ氏が提唱した本来のリスク分析には、大きな違いがあるように感じられる。

アメリカと日本の、ソフトウェア開発における文化の違い。それが、リスクという指標の捉え方にも、反映しているように思われる。

目次

  1. リック・クレイグ氏のリスク分析とは
  2. テストケースではなく、機能に対してリスクを評価する
  3. アメリカ型のリスクと、日本型のリスク

リック・クレイグ氏のリスク分析とは

リック・クレイグ氏が提唱したリスク分析の手法については、下記の文献(以下「リスク・ベース・テストのススメ」と記す)に詳しい解説がある。

リスク・ベース・テストのススメ

宗雅彦著

JavaWorld 2005 June p158-170

JaSST '06の基調講演の内容も、この文献で紹介されているリスク分析の手順とほぼ同じである。

リスクとは、下記の2つのパラメータから算出される指標である。

  • ソフトウェアに欠陥を作り込んでしまう可能性(実現確率)。
  • 欠陥によって引き起こされる問題の重大性(損害)。

即ち、バグがありそうで、かつ、バグの影響が大きいところを、優先的にテストする。逆に、バグがほとんど無さそうで、しかも、あったとしても大した影響が無いのであれば、がんばってテストすることもないだろう。

もし、テストが完了する前に納期になったとしても、残っているリスクが十分に小さければ、その時点で納品する、という判断もある訳だ。

これを見て、

なるほど、たいへん合理的な考え方だ。私も、クレイグ氏の考えに従うことにしよう。

と考える人は多いはずだ。

確かに、表示メッセージのスペルミスを探すよりも、まずはきちんどアプリケーションが使えることから確認しなくてはいけないな。

スペルミスも無いにこしたことはないが、チェックできなかったとしても、納期を守ることの方が大切だな。

だが、これは本当に、クレイグ氏の考えを正しく受け取っているのだろうか。

テストケースではなく、機能に対してリスクを評価する

リスク・ベース・テストのススメ」でも、JaSST '06の基調講演でも、ATMのリスク分析を行う例が紹介されている。それは、次のようなものだ。

ATMのリスク分析の例

ここでは、リスクの値が3と4の間で足切り線が引かれている。即ち、印紙の購入まではテスト対象とするが、口座残高の確認などは、テスト対象外と判断している。

ここで注目すべき点は、リスクを評価している対象が、機能(Feature)および非機能要求(Attribute)であることだ。

これは、かなり乱暴な判断のように思える。このATMの例では、現金の引き出しに関することならば、どのような些細なことでもテストすることになる。一方、口座残高の確認については、そもそも全く動作しない可能性も残ってしまう。

この例を初めて目にした時、筆者は、これはあくまで手順を紹介するためのサンプルであり、実際にはもっと詳細化した項目に対してリスクを評価するのだろう、と思った。例えば、次のような形である。

ATMの詳細化したリスク分析の例

実際、リスクに基づくテストを実施している事例を見ると、このように具体的なテストケース(想定されるバグ、と言い換えても良い)に対してリスクを考えている場合が多い。

だが、クレイグ氏の例は、サンプルだから粗いレベルになっている訳ではないようだ。

JaSST '06の基調講演で、筆者はクレイグ氏に、リスク分析は項目を詳細化してから行うべきかどうか、という質問をしたが、回答は、詳細化しない方が良い、というものであった。

クレイグ氏の提唱するリスク分析とは、プロジェクトの早い段階で、過剰な手間をかけずに、機能レベルでリスクを評価するものである。個々の具体的なテストケース(またはバグ)に対してリスクを算出し、優先度を考えることは、クレイグ氏の本来の主旨からは外れているのかもしれない。

アメリカ型のリスクと、日本型のリスク

だが、前述のATMの例のように、粗い機能レベルでリスクを評価することは、我々にはあまり意味のないことのように思える。むしろ、具体的なテストケースごとに評価をしてこそ、リスクという指標を有効にテストに活かすことができるように思える。

この、リスクに対する考え方の違いは何なのか。筆者には、JaSST '06のパネルディスカッションで、山浦恒央氏が示された、アメリカ・インド型のソフトウェア開発と、日本型のソフトウェア開発の違いに、その答えが隠されているように思われる。

山浦氏は、次のような図を示した。

アメリカ・インド型と、日本型のソフトウェア開発の違い

アメリカ・インド型のソフトウェア開発では、市場へのインパクトがより重要視される。ソフトウェアの品質と市場へのインパクトの双方を勘案して、最も市場に受け入れられるタイミングで、出荷を行うべきである、という考え方だ。例えば、クリスマスなどの特別なタイミングが要求されるソフトウェア製品であれば、多少のバグがあっても、期日までに出荷されることになるだろう。

一方、日本型のソフトウェア開発では、ソフトウェアの品質的な成熟度がより重要視される。即ち、出荷のタイミングは、ソフトウェアの品質によって決まる。予定日になっても品質が悪ければ、出荷のタイミングを延期することになるだろう。

ソフトウェア製品に対するこのような文化の違いが、リスク評価の粒度の違いとなって表れているように感じられる。

アメリカ型のソフトウェア開発では、最適なタイミングで出荷するために、一部の機能をまるごと削ったり、制限を設けたりすることを、常に念頭に置いている。だからこそ、機能に対してリスクを評価しておくことが求められるのだろう。

一方、日本型のソフトウェア開発では、予定された機能がすべて問題なく動作するようになって、初めて出荷できる、というのが原則である。この考え方では、起こりうる現象に対して「問題ない」と言えるかどうかの閾値が必要となる。そのため、個々の具体的な現象に対して、リスクを評価することになる。

クレイグ氏が提唱したリスクという指標は、日本のソフトウェアテストの現場にも広く受け入れられた。だが、クレイグ氏が提唱したアメリカ型の概念がそのまま広まったのではなく、日本の文化に合うように、日本型のリスクに形を変えて普及したように思われる。

Copyright(C) Seiichi Yoshida ( comet@aerith.net ). All rights reserved.