障害管理における重要度と優先度の使い分け

障害管理における優先度と重要度の使い分けについてメモ。

【元ネタ】
ふたたび、優先度と重要度と緊急度のお話：シェアウェア販売者の独り言：So-netブログ

バグの優先度は意思決定プロセスの結果: プログラマの思索

TestLinkを運用して気付いたことpart9～後追いテスト: プログラマの思索

レビュー計画

【連載】実践ソフトウェアテスト考現学 (12) テストの新たなアプローチ - 複数の視点の組み合わせ | エンタープライズ | マイコミジャーナル

はじめてのバグジラ ver2.16-ja編

TracTickets -- mi

障害管理では、重要度と優先度の項目がチケットに普通は付いている。
Mantisには重要度と優先度は元から付いている。
だが、Redmine・Tracには優先度だけで重要度は付いていない。

はじめてのバグジラ ver2.16-ja編では、重要度は下記のように書かれている。

Blocker 開発やテストが出来なくなるくらいに極めて重大なものです。
Critical クラッシュやデータの損失、メモリリークなどの重大なものです。
Major 機能が動かないなどの大きな欠陥があるものです。
Minor 小さな欠陥で、簡単な代替手段があるものです。
Trivial ミススペルや誤った文章などといった機能そのものの動作に影響を与えない、さほど重要ではないものです。
Enhancement 機能強化の要望です。

「Trac入門」の一節では、重要度と優先度の違いについてうまく説明されていた。
Tracでは優先度のみ付属しているが、開発チームの内部では、重要度を付けるべきかどうか議論があったらしい。

TracTickets -- miでは下記のように書かれている。

バージョン 0.9 以前の Trac では 分類 (Type) 属性がありませんでしたが、代わりに 重要度 (Severity) 属性が提供されており、 優先度 (Priority) 属性のデフォルトの値も異なっていました。この変更を行ったのは、やや不鮮明な 優先度 (Priority) と 重要度 (Severity) の区別を排除し、チケットモデルを簡素化するためです。しかしながら以前のチケットモデルも利用可能です

普通の開発チームは、優先度しか使わず、重要度は特に運用していないのではなかろうか？
僕の考えでは、重要度と優先度の使い方は下記になる。

重要度
→ユーザ、業務の観点
　利害関係者のレベル
　　チーム内、プロジェクト内、会社内、顧客調整事項など
　ストーリーカード
　プロダクトリスク

優先度
→開発チーム、作業の観点
　作業の優先順位
　　緊急(blocker)、普通、trivial
　タスクカード
　プロジェクトリスク

つまり、重要度はユーザの観点であり、利害関係者のレベルで付ければいい。
優先度は開発チームの観点であり、作業の優先順位として付ければいい。

Agile開発の観点では、重要度はストーリーカードの観点、優先度はタスクカードの観点から付ければいいだろう。
普通は重要度が高ければ優先度も高くなるが、必ずしもそのようなパターンに当てはまらない作業もありうる。
その時、重要度と優先度を組み合わせたマトリックスで障害やタスクを一覧化すれば、作業の優先順位が見えやすくなるだろう。

例えば、顧客の業務で重要な機能だが非常に稀な潜在バグがあると判明した場合、重要度は高いけれど優先度は低いバグに相当する。
この場合は、リリース直後なら作業は一旦保留としておき、プロジェクトが落ち着いてからバグ修正に取り掛かる手法を採用することもあるだろう。

あるいは、今は本番稼動中で安定しているが、今後の２次開発で機能をリファクタリングして綺麗にしないと機能拡張しづらい場合、重要度は低いが優先度の高い作業に相当するだろう。
その場合は、あらかじめスケジュールを組んでおいて、進行中の作業に混ぜ込むなどする手法があるだろう。

特に、開発チーム内部でクリティカルパス上にある作業がボトルネックになっている場合、最優先で取り掛かなければ、プロジェクトは危険な状態に陥るだろう。
だから、重要度が低くても優先度を高くして、早めに手を打つのが必要なときもありうる。

品質管理の観点では、重要度はプロダクトリスク、優先度はプロジェクトリスクの観点になるだろう。
ここで、プロダクトリスクは製品(システム)の品質がユーザや社会に対して与える影響度であり、プロジェクトリスクは開発プロジェクトへ与える影響度を指す。
つまり、プロダクトリスクはユーザの観点、プロジェクトリスクは開発チームの観点に相当する。

特にリスクベースドテストでは、プロダクトリスクの高い要素を重視してバグを潰していき、プロジェクトリスクの要素は取捨選択して行う手法だ。
昨今のテストやレビューでは、作業範囲や作業量が大幅に増えているため、全てのバグを潰すことは難しくなっているから、リスクベースドテストが主流になっているだろう。

TestLinkを運用して気付いたことpart9～後追いテスト: プログラマの思索や「Redmineによるタスクマネジメント実践技法」で説明した後追いテストとは、プロダクトリスクの高いバグを潰した後に、プロジェクトリスクのバグを潰す手法の一つだ。
昨今は、iPhoneのソフトウェアアップデートやWebシステムのデプロイ作業のように、システムをすぐにアップデートしやすくなっている環境があるので、後追いテストのようなテスト手法も取りやすい時代背景がある。

BTSの解決状況(Resolution)は障害管理の名残り: プログラマの思索にも書いたけれど、BTSの項目には、障害管理の歴史から積み重ねられたノウハウがたくさん詰まっている。
それらノウハウはソフトウェア開発のベストプラクティスにつながると思っている。