ソフトウェアテストにおいて「リスクを管理すること」は、品質保証の要です。
本記事では、ISTQB Advanced Level Test Management v3.0の**セクション1.3.3「Quality Risk Assessment（品質リスク評価）」**を、初学者にも分かりやすく解説します。
🔍 Quality Risk Assessmentとは？
**品質リスク評価（Quality Risk Assessment）**とは、テストプロジェクトで特定されたリスクに対して、
-
どれくらい発生しやすいのか（発生確率 / Likelihood）
-
発生したらどの程度の被害をもたらすか（影響度 / Impact）
を評価し、リスクレベル（Risk Level）を決定するプロセスです。
✅ 目的：
各リスクに対して「どの程度テストすべきか」を判断するための基準を作ること。
🧩 リスク評価の2つの要素
1. 発生確率（Likelihood）
リスクが実際に起こる可能性や頻度を表します。
これを高める要因には以下のようなものがあります。
|
要因 |
説明 |
|---|---|
|
システムの複雑さ |
複雑なアーキテクチャほど不具合リスクが高い |
|
組織の成熟度 |
品質保証の文化が弱いとリスクが増加 |
|
スキル不足 |
開発・テストメンバーの経験不足 |
|
コミュニケーション不足 |
地理的に分散したチームや不明確な報告ライン |
|
マネジメント不在 |
管理者の不在や監視の甘さ |
|
頻繁な人員入れ替え |
プロジェクトの知識が継承されず品質低下 |
具体例：
例えば、新しいプログラミング言語を使ったプロジェクトで、
チーム全体がその技術に不慣れな場合、**「テクノロジーの複雑性＋スキル不足」**が重なり、
不具合リスクの発生確率（Likelihood）は高くなります。
2. 影響度（Impact）
リスクが現実化したときに発生するダメージの大きさを意味します。
以下のような観点で評価されます。
|
要因 |
説明 |
|---|---|
|
機能の重要性 |
影響範囲が広いコア機能かどうか |
|
ビジネスへの影響 |
売上・顧客信頼・ブランドへの損失 |
|
法的・社会的影響 |
法令違反、データ漏洩、社会的非難など |
|
安全性リスク |
医療機器や自動車の安全に関わる要素 |
|
回避策の有無 |
ワークアラウンドが存在しない場合は影響度が大きい |
具体例：
たとえば、銀行システムで送金額を誤計算するバグが発生すれば、
金銭的損失や顧客信用の失墜につながり、**影響度は「非常に高い」**と判断されます。
⚖️ リスクレベルの決定方法
リスクレベルは、基本的に以下の式で表されます。
リスクレベル ＝ 発生確率（Likelihood） × 影響度（Impact）
たとえば：
|
リスク項目 |
Likelihood |
Impact |
リスクレベル |
|---|---|---|---|
|
UIの軽微な不具合 |
低 |
低 |
低 |
|
決済処理エラー |
中 |
高 |
高 |
|
セキュリティ脆弱性 |
高 |
非常に高 |
非常に高 |
このように定量的（数値化されたデータ）に扱うこともあれば、
定性的（High / Medium / Low）なスケール評価で行う場合もあります。
🧮 定量評価と定性評価の違い
|
評価方法 |
特徴 |
使用例 |
|---|---|---|
|
定量的評価（Quantitative） |
リスクを数値化して計算（％、金額など） |
リスク発生率：10%、影響損失：100万円 → リスク値=10万円 |
|
定性的評価（Qualitative） |
主観的に「高・中・低」で評価 |
「影響が大きそうだからHigh」と判断 |
ISTQBでは、データが十分にある場合は定量的評価、
データが少ない場合は**定性的評価（チームの判断）**を推奨しています。
🧭 リスク対応策（Risk Response）
リスク評価の次は、どう対応するかを決めます。代表的な対応方針は次の4つです。
|
対応方法 |
説明 |
|---|---|
|
Mitigate（軽減） |
テストや改善でリスクを減らす |
|
Transfer（移転） |
契約や外部委託で他者にリスクを移す |
|
Accept（受容） |
発生確率が低ければ、受け入れて何もしない |
|
Contingency（代替策） |
発生時に備えたバックアッププランを準備 |
例：
セキュリティ脆弱性のリスクに対しては、
「ペネトレーションテストを実施（軽減策）」、
または「外部専門会社に委託（移転）」といった対応を選択します。
🧠 テストマネージャーの役割
テストマネージャーは、次のような観点でリスクベースドテストを戦略的に導く必要があります。
-
プロジェクト初期からリスクを特定・評価する
-
LikelihoodとImpactの要因を正確に把握する
-
テスト優先度をリスクレベルに基づいて決定する
-
リスク対応策をチームと合意する
-
状況変化に応じてリスク評価を更新する
💡 ポイント：
「どこを重点的にテストすべきか」を明確にすることが、
効率的で品質の高いテストプロセスを実現します。
🧾 まとめ
|
項目 |
内容 |
|---|---|
|
対象章 |
ISTQB Advanced Test Manager v3.0 – 1.3.3 |
|
主題 |
Quality Risk Assessment（品質リスク評価） |
|
評価要素 |
Likelihood（発生確率）＋ Impact（影響度） |
|
評価手法 |
定量的または定性的 |
|
結果 |
リスクレベルを算出し、テスト優先度を決定 |
品質リスク評価は、単なる「危険性の分析」ではなく、
テスト計画と品質保証を最適化するための羅針盤です。
🏁 まとめの一言
テストの本質は「バグを探すこと」ではなく、
「リスクを見抜き、品質を守ること」です。
コメント