リスクマッピング
Quality Engineering サブ部門はリスクマッピングプロセスの促進を支援します。 これには、リスクと緩和計画への戦略的なアプローチを開発するために、プロダクトマネジメント、開発、UX、Quality チームの参加が必要です。
目標
リスクマップをツールとして活用して：
- カウンターパートチームが直面するリスクを理解する
- 緩和計画の透明性を高める
- 限られたリソースを効果的に配分する
- 品質向上に戦略的に協力する
リスク管理
リスク管理は、ビジネスと組織のすべての領域へのリスクとその影響を特定するプロセスです。これらのリスクを特定することは、マイナスの影響を最小限に抑える決定を行い、実行するチームを大きく支援できます。リスクとその緩和・管理のために必要なリソースにコミットすることで、チームは不確実性から自らをより良く守り、製品の安定性、品質、パフォーマンスを向上させることができます。
リスク管理サイクルは 6 つのフェーズで構成されています：
- 認識
- 特定
- 評価
- 制御
- 実施
- モニタリング
リスクマップの構築方法
一般的なリスクマップ
認識を高めてリスクの特定を始めるには、まず「エリア」と「ファセット」の 2 つのリストを作成してください。例：
| エリア |
|---|
| チーム |
| プロダクト |
| インフラ |
| UX |
| 品質 |
| コミュニティ |
| 顧客 |
| … |
| ファセット |
|---|
| 専門知識 |
| パフォーマンス |
| テストカバレッジ |
| マイグレーション |
| スケーラビリティ |
| 安定性 |
| エクスペリエンス |
| データ |
| … |
エリアとファセットを組み合わせて、各セルが関連するリスクである表を作成してください。例：
| エリア | チーム | プロダクト | インフラ | UX | 品質 | … |
|---|---|---|---|---|---|---|
| ファセット | —— | —— | —— | —— | —— | —— |
| 専門知識 | ドメイン知識の集中 | 不十分な SET | ||||
| パフォーマンス | バーンアウト | SLO/SLA を達成できないことが多い | 障害 | フレーキーテスト | ||
| テストカバレッジ | テスト環境の再現が困難 | |||||
| マイグレーション | 顧客が以前の製品 / プラットフォームからの移行に困難を経験する | データベースマイグレーションがしばしば障害を引き起こす | ||||
| スケーラビリティ | 要求を満たすための品質努力の低下 |
異なるエリアとファセットを組み合わせることでブレインストーミングのためのリスク名付けを行った後、次のフェーズである評価では、各リスクの影響と影響レベルおよび発生確率の推定を理解する必要があります。これらの 2 つの次元の積がリスクのスコアを決定します（スコアが高いほど優先度が高い）。
一般的なリスクマップの例
マップキー
- 影響 - リスクが緩和または排除されない場合に何が起こるか
- 影響レベル - 1（低）から 5（高）で評価
- 確率 - 1（低）から 5（高）で評価
- 優先度 - 影響 × 確率。最高スコアを最初に対処する。
- 緩和策 - 影響または確率を下げるために何ができるか
| リスクエリア | リスクの説明 | 影響 | 影響レベル | 確率 | 優先度 | 緩和策 |
|---|---|---|---|---|---|---|
| チーム / 安定性 | バーンアウト | 生産性低下と離職 | 5 | 2 | 10 | |
| チーム / スケーリング | 非効率なチームメンバーオンボーディング | 長期間にわたる生産性低下 | 3 | 2 | 6 | |
| チーム / 専門知識 | 知識の集中 | SLO/SLA の未達成 | 4 | 3 | 12 | |
| 顧客 | 約束違反 | GMAU の減少 | 5 | 2 | 10 | |
| 顧客 | コミュニティとの信頼の低下 | コミュニティ貢献の減少 | 5 | 1 | 5 | |
| プロダクト / スコープ | 製品の使用方法に関する十分な知識の欠如 | [METRIC] の減少 | 3 | 3 | 9 | |
| プロダクト / スコープ | 多くの異なる製品領域を持つことによるセキュリティ脆弱性の増加 | 信頼 / 収益の損失 | 5 | 1 | 5 | |
| プロダクト / データ | ユーザーメトリクスとアクティビティメトリクスが不完全で追跡が困難 | 不正確なセンシングデータ | 4 | 3 | 12 | |
| 品質 | ターゲット達成のために品質を低下させる | バグの流出 | 5 | 3 | 15 | |
| 品質 | 不確かなテストカバレッジ | テスト努力の優先付けが困難 | 3 | 3 | 9 | |
| フィーチャー / パフォーマンス | _____ によるパフォーマンス低下 | 顧客満足度の低下、[METRIC] の減少 | 5 | 4 | 20 | |
| フィーチャー / テスト容易性 | 実際のシナリオをドライブするのが困難 | バグの流出 | 4 | 4 | 16 | |
| フィーチャー / 依存性 | クロスグループの作業がタイムリーに優先されない | デリバラブルの遅延、顧客満足度の低下、チーム生産性の低下 | 3 | 3 | 9 |
チームはこの演習を拡張してプロダクトカテゴリまたはフィーチャーレベルに反復することができ、リスクをより詳細に理解できます。
リスク制御
リスクの影響と確率を評価した後、制御と実施フェーズでは、マイナスの影響を軽減するために各リスクに対して緩和策を作成する必要があります。緩和策は影響領域に関する作業計画のための戦略です。リスクに対処するいくつかの戦略的な方法：
- リスク回避 - 問題を緩和するコストを正当化するには結果が高すぎると判断された場合に使用する。
- リスク受容 - リスクを一定期間受け入れて、緩和努力を優先する。
- リスク移転 - リスクを保護または緩和する能力に応じて、異なるチーム間でリスクを配分する。
- リスクモニタリング - 関連するリスクの影響の変化についてプロジェクトと関連するリスクを追跡し続ける。
リスクと緩和に向けた作業の追跡とモニタリングは、チームが好むワークフロー次第です。
リスクマッピングツール
リスクマッピングツールはチームがリスクと計画された緩和策を簡単に視覚化するのに役立ちます。チームが手動でリスクマップを作成することを避けたい場合は、これを実装することができます。チームが全体的な品質を戦略的に改善する際に、より透明で協力的かつ効率的になれるようにするリスクマッピングプロセスをサポートします。
リスクマッピングツールの設定は必須ではありませんが、リスクステータスの迅速な視覚化に役立つ場合があります。リスクステータスを測定するためのメトリクスが整っている場合、リスクマッピングツールはこれらをより簡単に公開することができます。
リスクマッピングツールをインストールするには、README の手順に従ってください。
必要に応じて、チームまたはグループはこれらをビジュアルリスクマップに手動で入力することもできます。完全なビジュアルリスクマップの例はこちらです。
