assuranceリスクマネジメントについての記事を読みました。タイム・コンサルタントの日誌から以下引用。稀な危機と、ありふれた失敗。リスク・マネジメントではどちらを注視すべきか標準的なリスク・マネジメントの進め方では、リスクの大小を、(与えるインパクトの大きさ)×(発生する頻度)のかけ算で整理する。問題は、「インパクトは小さいが、頻度が高い」リスクと、「滅多に起こらないが、インパクトが大きい」リスクとの比較である。ありふれたトラブルの方が、稀な危機に比べて過去に学ぶ作業のコスト・パフォーマンスが高いのである。飛行機で移動するとき、注意すべきなのは墜落事故ではなく、ありふれた遅延なのである。トラブル事象が小さい内は、Resistance(事前対策)の方が費用が小さくすむが、あまりに大きな「想定外」のトラブル事象に対しては、もうRecovery(事後対策)を考える方が経済的である。頻繁に起こる小さなリスクを予防する方がコスパいいよ!ってことです。見た目が派手だからって地震やテロ対策ばっかり優先してたら足元すくわれるぞ。これって経営の話だけじゃなくて、もっと身近な、例えばバグ修正の優先順位付けなんかにも使えるなぁと思いまして、ブログにメモっておくことにしました。的な考えになるかもしれませんが、ちゃんと考えてみると、小さいバグから直す方が正しいことだって多いのですよ、ってこと。開発者ならびに評価者は大きなバグから手をつけることが正しくなります。小さなバグへのリカバリーが1時間で終わるとしたら、その50倍は50時間≒5人日(1週間)。小さいバグから直すべきということになりますね*1。優先度はインパクトの大きさだけでなく、その発生頻度も考慮して決めなきゃ駄目ですよ、という話でした。*1:ただし、「リカバリーに5日もかけられない!発生したら絶対1日で復旧させなきゃいけない!でも復旧作業できるのは自分だけなんだ!」みたいな場合は、そもそもそのバグが発生した時点で詰むので、修正必須です。港区界隈でSEやってた暇人。今はITコンサルとかいう胡散臭い職種になっています。好きな和音はsus4です。(1)月別アーカイブ参加グループプログラミンググループテストしたい人のグループポケモンリンクはてなブログQiitaGitHubはてなブログをはじめよう!sakuramochi702さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。