ソフトウェアテストの現場では、すべてを完璧にテストすることは不可能です。
だからこそ、「リスクベースドテスト（Risk-Based Testing）」という考え方が重要になります。
本記事では、ISTQB Test Management v3.0 チュートリアルの第13回
「Identification of Quality Risks（品質リスクの特定）」の内容をわかりやすくまとめます。
特に、品質リスクの洗い出し方・具体的な特定方法・関係者の関わり方を理解することがポイントです。
🔍 リスクベースドテストの4つのフェーズ
まず、リスクベースドテストには次の4つの主要なフェーズがあります。
-
リスクの特定（Identification）
-
リスクの評価（Assessment）
-
リスクの緩和（Mitigation）
-
リスクの管理（Management）
今回扱うのは最初のステップ、**「リスクの特定」**です。
これは、テスト活動全体の成功を左右する最も重要なフェーズと言えます。
🧭 リスク特定の目的とは？
リスクの特定とは、
「どの部分にどのような問題が起こる可能性があるかを明らかにすること」です。
テストマネージャーは、関係者（ステークホルダー）と協力して、
**製品リスク（Product Risk）とプロジェクトリスク（Project Risk）**を洗い出します。
💡 例：
-
製品リスクの例：パフォーマンスが遅い、セキュリティの脆弱性、UIの不具合など
-
プロジェクトリスクの例：リソース不足、スケジュール遅延、開発環境の不安定さ
これらは互いに影響し合うことも多く、
例えば「パフォーマンスリスク（製品）」を調べていくと、
「設計レビュー不足（プロジェクト）」という根本原因が見つかるケースもあります。
👥 リスク特定には“多様な関係者”の参加が不可欠
効果的なリスク特定のためには、できるだけ多くのステークホルダーを巻き込むことが重要です。
関係者の例：
-
プロジェクトマネージャー
-
開発リーダー・設計者
-
テストチーム
-
ビジネスアナリスト
-
ネットワーク／データベース担当
-
UI/UXデザイナー
-
運用担当 など
全員が異なる視点を持つことで、「見落としていたリスク」を見つけやすくなります。
このため、テストマネージャーはリスク特定会議を企画し、関係者を調整する役割を担います。
⚠️ 注意点：
-
キー担当者が不在の場合は、必ず代理者を指名する。
-
ただし「代理出席」ではなく、「実質的な意見が出せる人」を選ぶこと。
-
可能であれば、キックオフミーティングで全員の参加を確認しましょう。
🧩 リスク特定に使える代表的なテクニック
リスクの特定には、さまざまな方法があります。
1つの手法だけに頼らず、**複数の方法を組み合わせる（ハイブリッドアプローチ）**のが効果的です。
|
手法 |
説明 |
具体例 |
|---|---|---|
|
エキスパートインタビュー（Expert Interview） |
各分野の専門家から直接意見を聞く |
セキュリティ専門家に脆弱性リスクを確認する |
|
ブレーンストーミング（Brainstorming） |
チーム全員で「もし〜だったら」を考える |
「もし通信が切れたら？」「もしユーザーが誤入力したら？」 |
|
過去の経験・事例参照（Past Experience） |
過去の失敗・成功からリスクを抽出 |
前回のリリースで見つかった欠陥を分析 |
|
リスクワークショップ（Risk Workshop） |
専門組織や同業他社のケーススタディを参考にする |
金融システム向けのリスク共有ワークショップに参加 |
|
レトロスペクティブ（Retrospective） |
プロジェクト終了後の振り返りから学ぶ |
「前回のテストではどんなリスクを過小評価したか？」 |
|
チェックリスト（Checklist） |
あらかじめ用意した質問リストで漏れを防ぐ |
要件の不明確さ、テストデータ不足などを確認する |
これらを組み合わせることで、より広範囲のリスクを洗い出せます。
🧱 リスク分布の考え方
リスクはシステム全体に均等に存在するわけではありません。
特定の領域に集中していることが多いのです。
例：
-
ユーザーが直接操作する画面 → ユーザビリティや性能リスクが高い
-
バックエンドの管理ツール → セキュリティリスクが高い
-
外部APIとの連携部分 → 接続エラーやデータ整合性のリスクが高い
そのため、コンポーネントごとに異なるリスクを特定することが大切です。
🧠 リスク特定の副産物（Byproduct）も見逃すな！
リスク特定を進めていく中で、次のような副産物も得られることがあります。
-
不完全な仕様書や設計書の発見
-
要件定義の抜け漏れ
-
チーム間の認識のズレ
これらはテスト品質だけでなく、プロジェクト全体の品質向上につながります。
テストマネージャーは、こうした情報を整理し、開発チームやPMにフィードバックすることで
「品質は全員の責任」という意識を広げる役割を担います。
🧩 効果的なリスク特定のための前提条件
リスク特定を行うには、十分な情報と準備が必要です。
要件や設計が曖昧な状態で始めると、曖昧な結果しか得られません。
チェックポイント：
-
要件・設計ドキュメントは完成しているか？
-
開発スケジュールや体制は明確か？
-
関係者のスケジュール調整はできているか？
これらを整えた上で実施することで、
**「意味のあるリスクリスト」**を作成することができます。
🎯 まとめ
|
ポイント |
内容 |
|---|---|
|
目的 |
どんなリスクが存在するかを明確にする |
|
方法 |
多様な関係者を巻き込み、複数手法を組み合わせる |
|
注意点 |
情報不足の状態で実施しない |
|
副産物 |
ドキュメント不備やチーム課題も同時に発見できる |
🪄 実務での活用例（QA視点）
-
新しい機能を追加する前に「リスク洗い出しミーティング」を実施する
-
バグトラッキングツール（Jiraなど）で「リスクID」を紐づける
-
スプリントレビューで、発生したリスクとその対策を共有する
こうしたプロセスを取り入れることで、
テストの優先順位付けやリソース配分が明確になり、効率的かつ戦略的なテストが実現します。
📝 まとめの一言
リスクの特定は、テストの出発点。
「誰が」「どの視点で」「どんなリスクを」見るかが、品質を左右します。
コメント