アークウェブのブログ

○リスクとは何か？

リスク分析におけるリスク(Risk)は欠陥によって引き起こされる問題の重大性（Damage）と欠陥の発生確率（Probability of failure）によって定義されます。また、欠陥の発生確率はシステム利用時に欠陥の生じる確率（Usage frequency）と欠陥を作りこむ確率（Lack of quality）によって定義されます。

 Risk
    -> Damage
    -> Probability of failure
        -> Usage frequency
        -> Lack of quality

重大性（Damage）の定義はプロジェクト毎に異なりますが、一般には下記のような欠陥が重大性の高い欠陥と定義されます。
　・金銭に関する欠陥
　・ユーザーを失う欠陥
　・企業イメージを損なう欠陥
　・他の機能やシステムに影響を与える欠陥
　・復旧に多大な時間、コストを要する欠陥

発生確率（Probability of failure）も詳細にはプロジェクト毎の定義になりますが、大まかには

Probability of failure = 見積りサイズ × 複雑さ

で定義します。

そして、リスク（Risk）は重大性と発生確率の積によって定義します。

Risk = Damage × Probability of failure

○リスク分析の階層

リスク分析の階層はシステムレベル、サブシステムレベル、機能レベル、関数やクラス・モジュールレベルと様々にあり、プロジェクト、および開発フェーズの特性にあわせて階層を選択します。あるレベルのある項目（システム/サブシステム/機能/関数・クラス・モジュール）のリスクは次の式で与えられます。

R(i) = P(i) × C(i)
R(i) - 項目iのリスク
P(i) - 項目iの欠陥発生確率
C(i) - 項目iの重要度（欠陥によって生じるコスト）

○リスク分析をやってみる

Hans Schaefer氏がhttp://home.c2i.net/schaefer/testing.htmlで配布しているリスク分析用のエクセルシートをベースに利用してリスク分析を行ってみます。まずは、リスク分析のエクセルシートを想定するプロジェクトの特性に併せてカスタマイズします。今回はシンプルなWebフォームメールの作成プロジェクトを想定してみます。

※ このエントリで想定しているWebフォームメールシステム構築プロジェクト用にカスタマイズしたエクセルシートはこちらからダウンロードできます。 Webフォームメールシステム構築リスク分析シート

１．リスク分析の階層を決定し、分析対象の項目を洗い出す

リスク分析の階層を決定します。今回は機能単位に項目を洗い出してその項目単位にリスク分析を行ってみます。つまり機能単位にリスク分析を行うことになります。

以下に、例として想定するシンプルなWebフォームメールの機能を洗い出してみました。

・フォームを表示する
・フォーム上でクライアントサイドの入力チェックを行う
・フォームからの入力をサーバサイドでチェックを行う
・入力値に問題がある場合エラー画面を表示する
・確認画面を表示する
・完了時にフォーム入力値をメールでWeb管理者に送信する
・完了時にフォーム入力値をWebサーバ上のファイルにCSVで保存する
・完了画面が表示される

これらの項目をリスク分析シートのRisk addressedに配置します（図１を参照。赤枠で囲んだ箇所です）。
今回は機能レベルの分析なので含んでいませんが、より大きな階層の視点に立った場合、「ユーザビリティを向上させる」といったリスクというよりもユーザやお客様の価値に直接結びつくような項目が入ることもあります。

２．重要度、インパクトを決定する要素と重みを決定する

先に示したリスク計算の式、

R(i) = P(i) × C(i)
R(i) - 項目iのリスク
P(i) - 項目iの欠陥発生確率
C(i) - 項目iの重要度（欠陥によって生じるコスト）

においてはCは重要度、つまり欠陥によって生じるコストを考えていましたが、欠陥によって本来得られるはずの価値をユーザやお客様が失う度合いとも考えることができます。そのため、上式のCをI（インパクト）に置き換えて以下ではリスク計算の式を

R(i) = P(i) × I(i)
R(i) - 項目iのリスク
P(i) - 項目iの欠陥発生確率
I(i) - 項目iのインパクト（欠陥によって生じるコスト、および失われる価値）

とします。

リスク分析シートに話を戻しますと、次に決定することは各項目のインパクトを測る要素とその重みを決定することになります。リスク分析シートのImpact factorsの下に３つの要素が定義されています（visibility＝発見されやすさ、user impact＝ユーザ、顧客に与える影響、frequency＝頻度）。また、それぞれの要素の重みを1-3-10で表現しています。これはインパクトの小、中、大を表現するための重み付けになります。ここでは想定しているWebシステム用に要素の定義を変更します。といっても充分一般的ですが。

・小（Weight=1） - 仕様未満足
・中（Weight=3） - セキュリティ問題の混入
・大（Weight=10） - 利用頻度

この重み付けは本来であればユーザ、お客様と調整しながら決定するのがよいでしょう。
なお、要素数、重みの値ともに増減、調整は自由です（図１を参照。インパクトの定義は青枠で囲んだ箇所です）。

３．欠陥発生確率を決定する要素と重みを決定する

次に各項目における欠陥発生確率を測る要素とその重みを決定します。リスク分析シートのProbability factorsの下に３つの要素が定義されています（deadline pressure＝納期のプレッシャー（短い納期）、new people＝プロジェクトへの新人の参加、complexity＝複雑さ）。また、それぞれの要素の重みが1、3、3とされています。重みはインパクトの重みと同様に自由に割り振ることができます。より発生確率に大きな影響を与えると考える要素には高い数値の重みを割り当てるわけです。1-3-10を使うことで影響の小、中、大を表現してもかまいません。ここでも想定しているプロジェクト用に要素の定義を変更します（図１を参照。発生確率の定義は緑枠で囲んだ箇所です）。

・短い納期 - Weight=1
・開発者の経験不足 - Weight=3
・仕様変更 - Weight=5

例もそうですが、発生確率の要素は成果物の特性よりも、プロジェクトの体制、運用形態による特性に着目した要素となることが多いです。従って、技術的要素よりもプロジェクト体制、運用形態にリスクが高いプロジェクトの場合、発生確率の要素の重みはインパクトの要素の重みよりも大きくなる傾向があります。

図1. Webフォームメールシステム構築用にカスタマイズした分析用シート

４．各項目の各要素の値を埋めていく

次にシート上のRisk Addressed列に配置したリスク分析対象の各項目に対して、インパクト（Impact Factors）の各要素、欠陥発生確率（Probability Factors）の各要素の値を0～5の範囲でふっていきます。例えば、今回の例では、例えば、「フォームを表示する」という項目に対して、仕様未満足、セキュリティ問題の混入、利用頻度のインパクトを3、3、5。短い納期、開発者の経験不足、仕様変更による欠陥発生確率に与える度合いを1、1、3としています（図１参照）。すると、シートによって「フォームを表示する」のリスクがProb. of defect detectionのRisk行に算出されます（図2参照）。

図2. リスク算出結果

計算式は

R(i) = P(i) × I(i)
R(i) - 項目iのリスク
P(i) - 項目iの欠陥発生確率
I(i) - 項目iのインパクト（欠陥によって生じるコスト、および失われる価値）

を用い、さらに重み付けによりP(i)、I(i)はProbability factorsの要素数、Impact factorsの要素数をそれぞれm、nとして、

P(i) =
　　(Probability factorsの要素1の重み) × (項目iのProbability Factorsの要素1の値) +
　　(Probability factorsの要素2の重み) × (項目iのProbability Factorsの要素2の値) +
　　　・・・
　　(Probability factorsの要素mの重み) × (項目iのProbability Factorsの要素mの値)
m = 1,2,…,M (Mは自然数)

I(i) =
　　(Impact factorsの要素1の重み) × (項目iのImpact Factorsの要素1の値) +
　　(Impact factorsの要素2の重み) × (項目iのImpact Factorsの要素2の値) +
　　　・・・
　　(Impact factorsの要素nの重み) × (項目iのImpact Factorsの要素nの値)
n = 1,2,…,N (Nは自然数)

で算出されます。

各項目に対してリスクの算出が行われるとシートによってハイリスクな項目、ローリスクな項目のリスク列に色が塗られます。ハイリスクは赤、ローリスクはグリーンです。各項目のリスクの値を小さい方から数えて百分率で75%以上である項目がハイリスク、各項目のリスクの値を小さい方から数えて百分率で25%以下である項目がローリスクと判定されます。

結果を見ると、今回は「フォームからの入力をサーバサイドでチェックを行う」、「確認画面を表示する」が最もハイリスクの項目、「完了画面が表示される」、「入力値に問題がある場合エラー画面を表示する」が最もローリスクの項目となりました。具体的にこの案件のテストを考える場合はハイリスクの項目に対するテストを重点的に行い、ローリスクのテストは力を抜いて程々のテストをする（またはプロジェクトの状態によってはテストをしないという判断も取り得る）ことになります。

○まとめ

今回はリスクとは何かを解説し、架空の案件を想定してリスク分析を実際に行ってみました。
リスク分析を行うことでリスクベースドテストを行うための前提知識、どこがリスクが高く重点的にテストするべき箇所なのかを知ることができます。

また、実際にリスク分析を行ってみて、副次効果として、次の効果もあることに気づきました。

- リスク分析の過程でお客様が当該プロジェクトで何を重要視しているのかがわかる
- お客様自身がリスク分析を通して自分の望んでいるものを【優先順位付きで】認識できる
- プロジェクトが有する価値とリスクを関係者（お客様、開発メンバーなどステークスホルダ）に通知できる

従って、リスク分析を行うことによってプロジェクトの各意思決定がスムーズに進められるようになることが期待できます。特に今回紹介したシートを利用することで、リスク分析に変更が生じた場合にも、簡単に再計算と周知を行うことができると思います。数値でリスクが表示されるため、優先順位が明確になっている点も良い点ですね。

リスクベースドテストを実施しない場合でもリスク分析そのものに様々な利点があると思います。小さな範囲からでも是非、行ってみてはいかがでしょうか（できればお客様と一緒に）。

参考：
Risk based testing
Software testing