リスクベースドテストにおけるリスク定義方法

リスクベースドテストにおけるリスク定義方法のメモ。
主に、リスク定義する上でのリスク算出要因（影響度（Damage）, 発生確率（Probability of Failure））と重みづけ方法、及びリスクスコアリングの精度向上のためのコンセンサスミーティングについて記載。（リスクベースドテスト自体については割愛）

結論と全体概要

結論

リスクベースドテストにおいてアプリケーションのリスク定義は、

定量リスク（リスクポイント） = リスクが発生した時の影響度（Damage） × 発生確率（Probability of Failure）

で算出する。

要は最終的に作りたいのは以下のような表。

一目瞭然だが、縦軸に機能、横軸にDamageの要素とProbの要素が複数あり、それぞれの合計を掛け合わせた数値がその機能のリスクポイントとなる。
また、Damage要素、Prob要素共にWeightがかかっている。これは、各要素の重要度をリスクポイントに反映する為に設定されており、これにより単純にスコアリングが高い機能＝ハイリスクとなるような事態を防いでいる。

最終形に至るプロセス

上の表を作る為には、以下のようなプロセスを経る。

縦軸（機能一覧）を洗い出す
リスクが顕在化した時の影響度（Damage）を定義する
発生確率（Probability of Failure）を定義する
Damage, Prob要素毎にWeightを計算する
機能別のリスクスコアリングを行う（アンケート）
コンセンサスMTG（レビュー）で機能毎のリスク定義を確定する

それぞれのプロセスで定義する内容を先ほどの表にマッピングすると以下のようになる。

1の機能一覧はプロジェクトですでに存在している物を利用すれば良いし、6のコンセンサスMTGは各有識者（経営、対顧・法人営業、企画、PM、アプリケーションエンジニアなど）でレビューを行い、最終的なリスク定義の精度を高めると共に、リスク定義を確定するというプロセスなので、今回は説明を割愛する。以降は2,3,4,5のプロセスについてそれぞれ詳細を記載する。

リスク顕在化時の影響度（Damage）定義

影響度（Damage）の定義はプロジェクト毎に異なるが、一般には収益やその基盤となるユーザー数、企業の信用力を著しく低下させるような障害（CSRに影響を与える障害）などが特に影響の大きい障害と定義される。

例えば銀行系のシステムだと、以下のようなリスク定義が考えられる。

上記の例では、収益・CSR・コンプラの３つの観点でDamageを定義した。
銀行における収益といえば預貸収益、役務収益（手数料）だし、それを生み出す顧客数（ユーザー数）、離脱率なども見逃せない。また、リテールよりも圧倒的に収益を生み出す法人取引、および銀行における最大コスト、システム開発・保守費用も収益に与える影響は大きいと考えられる。
CSRの観点では、企業が責任を果たすべきステークホルダー（誰に対する信頼か）と、レピュテーションも事業に対する影響が大きいと考えられる。
最後に、（これは銀行に限った話では無く全ての企業において重要だが）コンプラ（法令順守）の観点である。銀行はその業務特性上様々な他の業種よりも法定要件が厳しく定められている。障害によりそれらが遵守できなくなった場合には業務改善命令、最悪の場合業務停止命令を受ける恐れがあり事業に対するインパクトは相当大きいと言える。

発生確率（Probability of Failure）定義

障害の発生確率（Probability of Failure）は、PRISMAメソッド（参考文献　参照）などで提唱されている一般的に障害が発生しやすい機能の特徴から拝借し定義した。
どれもシステム屋からすれば「そりゃそうだ」というものしかないので、説明は簡単に済ます。

Prob Factor	定義
複雑性	複雑な機能の方が障害は起こりやすい。
変更頻度	CRがたくさん発生する機能は、それだけ機能としてもプロセスも複雑になり障害を起こしやすくなる。
新技術、新しい方法	新技術や新しいプロセスを採用した場合には、チーム内のスキルが成熟し切っておらずバグが埋め込まれやすくなる。
コミュニケーションパス	機能開発に関わる人数や組織が多くなると、それだけ品質リスクが高まる。
短納期	開発規模に対して適切な期間が無い場合、十分なテストが行えず障害を起こしやすくなる。
楽観主義によるコスト不足	その機能を開発するためのコストしか見積もられておらず、コミュニケーションによるタイムロスや突発的な問題に割く工数が無い場合、開発コストがショートし、結果十分なテストが行えず障害を起こしやすくなる。
欠陥発生数	開発期間に欠陥が集中的に発生した機能は障害が起こりやすい。
地理的な分散	ステークホルダーが地理的に分散して開発を行なっている機能の方がコミュニケーションミスによる障害が起こりやすい。（最近はツールの普及によりこのリスクは大分低減されているイメージだけど。。。）

Weightを計算する

Weightの計算については以前に書いたこちらの記事を参照。
参考重み付け決定手法（ウェイト計算）

なお、今回の例でDamageの一対比較表を作成しWeight計算するイメージは以下のようになる。

この質問と一対比較表をなるべく多くのプロジェクトステークホルダーに展開し回答してもらい、その結果を集計・平均してそれぞれの要素のWeightを算出するのが良いだろう。

リスクスコアリング

ここまできたら表の縦軸、横軸が定まったので、あとは中身（スコアリング）を記入するのみだ。
ただし、スコアリングのおいてもいくつか注意点があるため、そこを踏まえてスコアリングを実施する。

スコアリングはアンケート式で多角的な観点で実施する: スコアリングは多角的な観点で実施しないと意味がない。どんな有識者にも、自分の得意な領域とそうでない領域が存在する。
偏った有識者だけでスコアリングすると、当然彼らが詳しい領域の要素が重要と判断されてしまう。
できればスコアリングを実施する有識者は経営、対顧・法人営業、企画といった業務ファンクションを網羅的かつ均等に抽出して実施するのが望ましい。
また、Damage要素は業務サイドの有識者が、Prob要素はシステムサイドの有識者がスコアリングするというのも有効である。
結果のクラスター化を防ぐ: 結果のクラスター化とは、評価が中心に寄ってしまって結果の差別化がされなくなることである。（日本人にありがちな「どちらともいえない」ばかりの回答のやつ。）
それを防ぐ為には、フルレンジ（９点法であれば、１列の中で少なくとも1,3,5,7,9の全ての値を使う事）をルールとしてスコアリングを行うことが効果的。