パスワードを忘れた？ アカウント作成
Close
206314 story
ソフトウェア

経済的側面から言えば、「小さなバグ」は残しても良い ? 141

ストーリー by reo
小さなバグに根源的なミスの陰が 部門より

ある Anonymous Coward 曰く、

本家 /. 記事「The Economics of Perfect Software 」より。

とあるブログ記事で、「ソフトウエアに小さなバグを残すのは良いことだ」との論が展開されている。

その記事によると次のようなことらしい。「バグは、誰がそのバグにぶち当たり、そのときにどれだけ怒りが沸くだろうかということを考えてその大きさを判断すればよい。例えば、ユーザがメニューを 3 階層たどり、詳細設定を開き、チェックボックスを 3 つクリックし、そして『A』のキーを押したときに変なエラーメッセージが表示されるというのは小さなバグであると言える。非常に深く埋もれているバグであるし、このユーザは恐らく「あれ ?」と思いながらも、そのまま作業を続行するだけであろう。しかし通常の設定画面を開こうとしてクラッシュするような場合、多くの人がこれに遭遇し腹だたしく思うことが予想されるため、大きなバグであると判断できる。全てのバグの修正・確認を行うのと、わずかな人しか遭遇しないどうでもいいバグを残すことを比較すると、前者にかかるコストはあまりに高すぎると言える。」

経済的側面から言えば「小さなバグ」は残しても良い、というこの論、/.Jer はどう思う ?

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

経済的側面から言えば、「小さなバグ」は残しても良い ? More

  • リスク評価 (スコア:5, すばらしい洞察)

    by yasuchiyo (11756) on 2010年03月30日 12時11分 (#1740571) 日記

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

    • Re:リスク評価 (スコア:3, 興味深い)

      by Anonymous Coward on 2010年03月30日 12時18分 (#1740576)
      細かいことにこだわる“力のある”人物のクレームのリスクをどう評価するか、難しいところでしょうねぇ（苦笑）
      シェア
      親コメント

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

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

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

      シェア
      親コメント

    • Re:リスク評価 (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2010年03月30日 12時22分 (#1740582)

      問題は、リスク評価にかかるコストの方が往々にしてバグ修正に必要なコストより大きいことで
      というよりバグ修正にかかるコストの大半が分析と評価だったり。

      シェア
      親コメント

    • Re:リスク評価 (スコア:1)

      by sunburn (21185) on 2010年03月31日 0時05分 (#1741046) 日記

      修正コストや修正による別なバグの発生リスク等も考慮してます。
      最終的には偉い人の一声で決まるけど。

      シェア
      親コメント

  • 誰の金でやってると思ってるんだ？ (スコア:4, すばらしい洞察)

    by Anonymous Coward on 2010年03月30日 12時44分 (#1740606)

    出たバグを全部潰すことを前提にスケジュール組んで見積もりを受けたのに、
    結果的にバグが大量に出ちゃって、納期に間に合わないから軽微なやつは残します、なんてのは納得いかないでしょう。
    だったら残したバグの分だけ金返せ、と言いたくなるのでは？

    • そんなん言うなら、Windowsだってバグが1個見つかる度に利用者全員に1セントでいいから払ってほしいわ。

      バグがないプログラムなんて、幻想なのです。
      光よりも速い車と同じで、そんなのを本気で要求しているのなら、要求している人がバカなのです。

      --
      1を聞いて0を知れ!
      シェア
      親コメント

  • つか、何をいまさら？ (スコア:4, すばらしい洞察)

    by Anonymous Coward on 2010年03月30日 13時49分 (#1740661)

    命にかかわるような装置の組み込みソフトや、金融関連などバグで引き起こされる被害が甚大になるものなどは例外として、
    コンシューマー向けの製品で、ある程度複雑なものになると、発見されたバグはそれぞれ重要度をランク付けされ、
    重要度の低いバグはほうっておかれてそのまま出荷されるもんだ。
    致命的なバグとその一個下のランクのバグを取るので精一杯というところ。

    WindowsなどのPC用OSや、ゲームソフト、携帯電話なんかはみんなそうじゃない？

    Vistaみたいにそれでも間に合わなくて、リリース時期が近づくにつれ搭載機能がどんどん削られていくという
    泥沼もｗ

    • Re:つか、何をいまさら？ (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2010年03月30日 17時51分 (#1740847)

      > 重要度の低いバグはほうっておかれてそのまま出荷されるもんだ。

      いえ、「仕様」あるいは「制約」と名前を変えて出荷されます。

      重要度の低いバグのうち、比較的重要度の高いものは(ややこしい)
      次期バージョンにて「仕様変更」「機能の追加」「制約の撤廃」なんて事がよくありますね。

      # おい、Firewallなのに現行バージョンじゃ○×組み合わせたポリシーが設定できないとかバグだろ！

      シェア
      親コメント

    • Re:つか、何をいまさら？ (スコア:1)

      by s02222 (20350) on 2010年03月30日 20時41分 (#1740942)
      そのバグのリスト、公開しちゃくれませんかね。滅多に出くわさないだろうけど、出くわしたときの被害が案外大きいんです。起こる条件が細かくなればなるほど、ググって原因を見つけ出すのが困難になるので。

      メニューボタンを押したらクラッシュ→検索すると一発で対処法が見つかる。「設定ファイルが壊れてるので消せ」とか。
      メニューの3階層目で・・・→どれをキーワードにして対処法を検索すりゃいいんだ、これorz
      シェア
      親コメント

  • タイトルだけ見て (スコア:4, 興味深い)

    by gonzo (38147) on 2010年03月30日 14時05分 (#1740673)

    [バグもなく、不都合もないシステムには後継が求められない]
    という事かと思った。

    僕自身はハード屋なのだが、
    設計委託先に「設計寿命は最低5年、できれば10年以上」と要求すると
    「そんなに長生きだと買い換えてもらえないアル」と反論された。
    という昔話を思い出した。

    # いや、そうだけどさ・・・。
        と、一瞬反論できなかったがIDで

  • 信用にかかわる (スコア:3, 興味深い)

    by .wii (33675) on 2010年03月30日 13時07分 (#1740630)
    バグを出さない業者と細かいバグを残しまくり（但し若干安あがり）の業者、発注するならどちらかと考えると
    やはり洋の東西を問わず前者を選ぶでしょう。
    自分が発注者であることを考えると、「害のないバグのためにあえて費用をかけない」という受注者の論理を好意的に受け入れるのは難しい。

    • Re:信用にかかわる (スコア:1)

      by firewheel (31280) on 2010年03月30日 15時24分 (#1740723)

      ＞バグを出さない業者と細かいバグを残しまくり（但し若干安あがり）の業者

      それは、たとえが極端すぎると思う。技術力その他が同じであれば、
      「バグを100％全部つぶす」コストと、「細かいバグを残す」コストとでは雲泥の差が生じる。

      もちろん技術力に差がある場合はこの限りではないが、いつから日本企業が技術力を気にするようになったのだ？
      ＃重要なのは「こみゅにけーしょん」スキルだってさ。アホか。。。。とは思いつつも泣く子と地頭とお客様には勝てませぬ。

      シェア
      親コメント

  • 日本では (スコア:2, おもしろおかしい)

    by Anonymous Coward on 2010年03月30日 12時13分 (#1740574)

    費用対効果の概念がないので、どんな小さなバグで、つぶすのに費用がかかったとしても残すことは許されません。とくに政府調達の場合そうなります。たとえばオバマ大統領のTwitterアカウントがクラックされて、さっそくそれ見たことか [srad.jp]という反応が出てます。
    ただし最初からバグをゼロにすることも許されません。テストフェーズで、予定された個数のバグを1個の狂いもなく出してから修正しなければなりません。

    • Re: (スコア:0)

      by Anonymous Coward
      一方では 電話の混信とか郵便の誤配のような「システム上の問題」は 皆無ではないし、「無限の予算で修正」まではしていないよね。

      何事も程度問題だけど、日本はその基準が高めという意味では同意ですが

      • Re:日本では (スコア:1)

        by firewheel (31280) on 2010年03月30日 14時31分 (#1740690)

        台風が直撃しているのに飛行機を着陸させろ、空港の閉鎖は絶対に許さない。
        雪が1m積もっていても、新幹線は定時に到着させろ。
        濃霧で100m先も見えないのに高速道路のトラックを80kmで走らせろ。
        10円の商品を盗まれないように警備会社と契約しろ。金はいくらかかってもかまわない。

        そんなことを言うバカはいない。

        ITが違うのは、
        「どの程度のトラブルが許容しうるか？
        　どのくらい損害が出たら容認できないか？
        　どれ以上予算をかけると採算割れするか？」
        が分からない／考えてないエライ人が多いということかな。

        シェア
        親コメント

  • そんなこと言われてもなぁ (スコア:2, 参考になる)

    by Anonymous Coward on 2010年03月30日 13時19分 (#1740637)
    それ納品してお金貰う条件が案件ごとに違うんだから
    個人的にどう思う？程度の話にしかならないよね…

    熟練のオペレータ集団が正確かつ高速にタイプするのが前提にあって
    画面まわりの障害に殆ど対応しなかった案件に従事したことあるよ

    typoどころか外注に拵えさせてラベルすら出てない画面項目すら
    あったんだけど、有っても見ないからOKとか言われて苦笑した
    validationも不要、画面レイアウトも不問、とにかく同じ順序で
    高速に入力し続けられるだけでいい、と

  • あれれ。なにか重要なものが抜けてる気がしますよ… (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2010年03月30日 13時37分 (#1740653)
    ※ ただし、自分が受注側の場合に限る。

    でしょ？
    自分の下流作業者、下請けに対してそれを許すわけではないんですよね。

  • 理想は (スコア:2)

    by iwakuralain (33086) on 2010年03月30日 15時23分 (#1740721)

    無いほうがいいに決まってる。
    でもそうもいかないのでリスクや優先順位を考えて対処するわけですが、人も時間も限りある資源なので影響の少ないものは後回しにされ、時間という資源(納期とも言うか･･･)が尽きると放置されたりする。

  • うーん (スコア:1)

    by ksiroi (24990) on 2010年03月30日 12時24分 (#1740585) 日記

    残しても「良い」んじゃなくて、残しても「そのときだけ影響が少ないからこのままイキで」ってことかなぁ
    言葉をそのまま捕らえると「リスクマネジメント出来てないんじゃない？」って感じる。

    優先順位を決定して、納期とのすりあわせで「間に合いません」なら
    そのバグは「対応しない」でなく「仕様です」って言うのが業界の常のようだし。
    確かにそれでコストは増えないだろうけど。うーん。

    // 泣きを見るのは使う人なわけですけど。皆が幸せになるために、潰せるバグなら全て潰したい・・・
    // 技術者的には「キチンと線引いてバグを全て潰せるようスケジューリング・顧客に提案するのが一流」かなぁ、と思ったり
    // まー現実はそんなに甘くないすけど(:>^

    • Re:うーん (スコア:2)

      by tks256 (30608) on 2010年03月30日 12時40分 (#1740600)

      小さなバグの定義が気になります。
      「たまたま発見した現象が、たいしたものではない」から小さなバグ、と言うのであれば、
      他の条件において、致命的なバグになる可能性があるのではないかと。

      「原因を見つけて、再現率が低くて、潜在的に大きなバグになることが想定できなくて、
      かつ影響範囲が大きい」
      と言う場合のみ、スルーしてもいいんじゃないのかなぁ、と思います。
      でも、大体原因見つけて治して終わりですよね。

      シェア
      親コメント

      • Re:うーん (スコア:1)

        by coffe_ata (31369) on 2010年03月30日 13時37分 (#1740652) 日記

        その辺りの小さなバグは、単体テストで見つかりそうなので、サクッと直して終わりな気もするんですよね。
        モジュールが複数絡むことで見るかるのは、見逃せない大物じゃないかと。

        シェア
        親コメント

  • この手のやつは、
    優先度をつけるときに、B(そのうち修正、なんかのついでがあれば修正)をつける。

    優先度Aはマスターアップまでに直すことになってる。
    優先度Aの修正が終わったら、Bに手を付けることになってる。

    つまり、Aの数が少ないときだけしか、Bは直さない。
    そんなことは、滅多に無い。

  • 日本建築では完成すると後は壊れるだけだからと一部だけわざと完成させなかったりしますね。それと同じ・・・・って違うか・・。

    --
    ◆IZUMI162i6 [mailto]

  • バグの話ではないのでオフトピ気味ではあるのですが、
    似たような話でコストと効果について、
    大分前に見たブログ記事を思い出しました。
    PS3 の性能の使い方 [cocolog-nifty.com]

    要は手間（≒時間 ≒お金）のかけどころの話なんだと思いました。
    # すでに多くの方がおっしゃっている通り

  • 正直すぎたんだね (スコア:1)

    by oj.wake (39498) on 2010年03月31日 9時00分 (#1741139)
    実際のところ、殆どのソフトウェア開発では 効率優先とか面倒くさいとかリソースかけたくないとかリリースに間に合わないとか、 いろんな理由からバグ対応は優先度をつけてやってる。 その際、影響度が低いバグに関してはあえて修正しないでいるのはごく普通。 ただ、対外的には本音丸出しはまずいから、 「他に優先しなくてはならないバグがあるので」「下手にいじると却って品質が落ちます」 「お約束の納期に間に合わせるためには…」 などの理由をつけて、本来は直すべきなんだけど、でもどうしても対応が難しいので… みたいなニュアンスをにじんだもっともらしい建前をつける事が多い。 でも、このブログの作者は真っ正面から 「ソフトウエアに小さなバグを残すのは良いことだ。その方が経済的だろ」 と建前を吹っ飛ばして現況を思いっきり肯定的に言っちゃっただけ、のような気がする。

  • 理系によくある勘違い (スコア:0, 荒らし)

    by sayuporn (33927) on 2010年03月30日 12時20分 (#1740579) 日記

    Aの方が重要だからBの方はやらなくていいよね。

    ではないのです！AもBも両方やるのです！

typodupeerror

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常