「経済的側面から言えば、「小さなバグ」は残しても良い ?」記事へのコメント

リスク評価

[yasuchiyo (11756)]

そのバグが出た時の影響の度合いと発生する頻度の積を点数化して、一定の得点がないものは対処しないってのは、
普通にシステム設計する時の基本的な考え方ですね。
評価の基準をどうするかってのを決めるのがたいへんですが。

リスクというよりは （Re:リスク評価

[kousokubus (37099)]

うちは影響度でやってましたね。
ものすごくレアだけど、巻き込んでクラッシュするようなモノは対処するし、
まあまあ再現するけれども機能に影響しない（例えば画面遷移するまでボタンが大きくなるとか）は対処しないとか。
# 政治的に正しい言い方にすると「対処しない」→「いつまでに対処することが決定している or 対応策の目処が立っている」:-P

大切なのはバグの洗い出しは終わっており、再現状況も確定していることですかね。
# 再現できないバグは、影響度不明なバグなのでクリティカルであるという定義

より正確な言い方をするのであれば「バグを残すのはNG」で「修正しない課題はOK」というところ。
納期が何よりも重視される職場且つ下請けでもなんでもなかったのでできたところではあるかな:-)
「ヘルプの英数字が統一されて無くて修正で1日納期が遅れちゃったよ」とか聞くと平和だなあと思います。
# 時折、何を守らなければならないのかが明確になっていない人が居て関係者軒並みぶっ飛ばされるのをみると、
# 日本はつくづく減点方式なんだなあと思ふことしきり
# 生産に関わる人にしか判らない限定的な話題かも知れないけどID

Re:

[Anonymous Coward]

＞# 政治的に正しい言い方にすると「対処しない」→「いつまでに対処することが決定している or 対応策の目処が立っている」:-P

その他の例：「次のサービスパックで対応予定です」

＞ものすごくレアだけど、巻き込んでクラッシュするようなモノは対処するし、
＃組み込み系だと、ほとんど全部がクリティカルという世界もある気がする。
＃でも上の人には、その違いが全然理解できてない。あの人が死んでくれて本当にホッとしたよ。