この記事は、欠陥のトリアージについてのメモ書きポエムです*1。
ソフトウェアのテストや本番環境で検出されたインシデントには、さまざまな情報が付加されていきます。
インシデント管理システムなどへの最初の登録の際には、発生したソフトウェアのバージョン、事象、再現させるための条件などがあるでしょう。また調査や原因特定の過程で、事象の原因（ソフトウェア自体の欠陥なのか否かも含めて）、対策案といった情報も追加されていきます。
こういった情報の一つとして、「重要度」や「発生頻度」を管理することも一般的です。
重要度は、「重大度」「Severity」「Impact」などと呼ばれることもあります。「開発しているソフトウェアにとってどれほど致命的か」という情報です。
発生頻度は、「Frequecy」と呼ばれることもあります。「そのインシデントがどのくらいの頻度で起こり得るか」という情報です。
この「発生頻度」について、複数の意味があるなーと常々思っていたので、整理しておきます*2。
「発生頻度」の三つのパターン
「発生頻度が低いインシデント」というとき、少なくとも以下の三つがあります。
なおMECE性にまったく配慮していません。
- ロジック的に発生頻度が低い
- ユースケース的に発生頻度が低い
- 利用環境的に発生頻度が低い
パターン1: ロジック的に発生頻度が低い
内部状態の特別な組み合わせや、レアなタイミングでのみ起きるインシデントです。たとえば、「通信のシーケンス番号がある値をとったタイミングで特定の処理を実行した場合」みたいなものです。
「発生頻度が低い」というとき、一番イメージしやすいのがこのケースかもしれません。ユーザが意識的に制御できないのが特徴です。メモリリークもこのパターンに含まれそうです*3。
パターン2: ユースケース的に発生頻度が低い
発生させるための手順などが非常にまれ、普通はやらないようなものなので、通常は起こりえないと考えられるインシデントです。たとえば、「画面の”進む”と”戻る”を1,024回繰り返した場合」みたいなものです。
ユーザが意識する手順・使い方が発生条件なので、その条件をわざと満たせばサクッと出てしまうのですが、その条件をユーザに回避してもらうことで普通に使えるケースが多いです。使い方に制限を課すことになるので不便を強いることもある一方、ワークアラウンドが提示しやすい。
パターン3: 利用環境的に発生頻度が低い
ソフトウェア自体ではなく、それを利用する環境が特別な組み合わせの場合に起こるインシデントです。たとえば、「OSが〇〇でブラウザが△△でウィルス対策ソフトが◇◇の場合」みたいなものです。
この手のインシデントは再現条件に環境が含まれるので原因が特定しづらく、本番系で起こると調査が難航して泣きが入りやすいやつですね。
三つのパターンの違い
どれも「発生頻度が低い」と呼ばれうるものですが、注意すべき違いがあります。
まずパターン1と2は、「どのユーザにとっても発生しづらい」インシデントです。パターン1はユーザの意志で避けることが難しいかわりに、滅多には起きない。パターン2は、レアな使い方をしなければ発生しません。一方パターン3は、「起きるのはわずかなユーザに過ぎないが、そのユーザでは確実に起きてしまう」場合があるのが問題です。
雑な絵ですが、イメージを以下に示します。オレンジ色の部分が「インシデントが発生してしまう条件」です。
パターン1と2では、すべてのユーザ（縦軸）が同じ「頻度」でインシデントのリスクを受け持つのに対して、パターン3では一部の「特別な」（少なくとも開発側が「特別」だと信じている）ユーザが全部のリスクを引き受ける形になってしまいます。言い換えると、このユーザにとっては、発生頻度「高」なのです。
パターン3であっても、「ディスプレイの改造がものすごく低く、かつWindowsのハイコントラストモードで使用している場合」といった条件なら、まだ回避が可能そうにも思えます。しかし、ウィルス対策ソフトの動作との兼ね合いで起きてしまうようなインシデントに対し、「ウィルス対策ソフトを止めてください、ウチのソフトウェアと干渉するので」とは言えないわけで、回避不可能になりかねません。
パワポでお絵かきしてまでこんな話を長々としているのは、「発生頻度」がインシデント対応の優先度付けに使われることが多いためです。
発生頻度が低いと、それだけで対処の優先度もそのまま下げられてしまいがちです。そんなとき、「ここでいう発生頻度とは何を指しているのか。一部のユーザを犠牲にする判断になっていないか」という観点に立ち戻ることが必要だと思います。
正月早々のポエムでした。
