開発者は自分の時間を使ってバグを修正するべき? 47
ストーリー by headless
修正 部門より
修正 部門より
本家/.「Ask Slashdot: Should Developers Fix Bugs They Cause On Their Own Time?」より
今日、上司が私のところに来て、バグの修正作業について彼自身がうまく言い当てたと考えている話を聞かされた。ソフトウェア開発者が書いたプログラムにバグが見つかった場合、修正費用は雇い主が払い、開発者は業務時間内に修正作業を行うことになる。しかし、建築業者が塀を作っている途中で下の方が崩れ始めたら、多くの場合は建築業者が自腹を切り、自分の時間を使って修復することになるというものだ。この話を聞いた時にはうまく反論できなかったが、なぜソフトウェアのバグは扱いが異なるのだろうか。
話の前後で比較対象がずれているというオチ (スコア:4, すばらしい洞察)
「建築業者の従業員が」塀を作っている途中で下の方が崩れ始めたら、修正費用は雇い主が払い、従業員は業務時間内に修正作業を行うことになる。
「ソフトウェア開発業者が」書いたプログラムにバグが見つかった場合、多くの場合は業者が自腹を切り、自分の時間を使って修復することになる。
何も違わないでしょ。この上司が(意図してか気づかないでか)、作業者と業者を混同しているだけ。
# 原文は確認してないので、本家ではそんなこと無いとかだったらサーセン。
Re:話の前後で比較対象がずれているというオチ (スコア:2)
原文もそうだし、同じツッコミ [slashdot.org]が入ってる。
Re: (スコア:0)
残念だけどバグ無しのソフトウェアを確実に開発できる方法ってのが無いんだよね。
Re: (スコア:0)
なんか、こういうコメントがたまに沸くけど、「瑕疵のない製品を確実に製造できる方法」はそりゃないだろう。
製造した後で瑕疵を無くす(もしくは不良率を一定以下とする)方法はあるだろうけど。
最初から明文化されていない利用者のニーズに反する事をバグと呼ぶのであれば、それを排除する事は原理的に不可能ではあるけど、そりゃねえだろ。
#少なくとも、それは無条件で瑕疵にはならない
「バグの無いソフトウェアは原理的に無い」(ドヤァ)ってのはどっから来てるのかね。
Re: (スコア:0)
人が作るからじゃね?
Re: (スコア:0)
なんでも程度問題でしょう。ソフトウエアは今まで間違っていても死人が出るわけではないから大目に見られていましたが、これからはどうですかね。バグについても誰も責任を取らなくてよいような契約はいずれ違法契約であり無効であるという社会になるのでは?
規模によりけりだけど (スコア:2)
個人宅~小規模な集合住宅クラスなら請負業者が自腹でってのは有りそうだけど
規模が大きくなると、修繕費も別で組まれてたりするから自腹ってのはないんじゃないのかなぁ?
理由は兎も角、労働に対し適切な対価を支払いたくがない故の強弁でしょうね。>自腹
初めから余裕が作れるほど「予算」がなかったのか、単に管理が悪く足りなくなったのかは
知りませんが、生じてしまった無理を押しつけているだけと言っても良いかと。
如何なる内容であろうとACでの書き込みは一切無視します。
委託と請負の違い (スコア:1)
委託 [wikipedia.org]
責任主体は委託する側(雇用主)、委託された側は代わりに手を動かしているだけ。
請負 [wikipedia.org]
責任主体は請け負った側(労働者)、請け負った側は完成品を納品する義務がある。
本家の人は請け負い開発者?
「委託」はあいまいな言葉 (スコア:5, 参考になる)
委託ではなく「準委任」という言葉が適切でしょう。
「請負」「委任」「準委任」は民法で規定されています。
「準」は法律行為が伴わないものが対象なので、ソフト開発などはこちらになります。
Re: (スコア:0)
雇用と委託って一緒にしていいの?
嘱託とごっちゃになってる?
あと責任と権限をもって請け負った人を「(労働者)」っていっちゃうのも、間違いかどうかはともかくそうとう粗雑じゃない?
Re:委託と請負の違い (スコア:1)
請負は民法の典型契約のひとつ。委託は民法に書いてない。日本で委託と呼称されている契約は実質的に請負。宅配便のバイトも袋詰めの内職も契約としては請負。
Re:委託と請負の違い (スコア:3)
それはどうだろう。請負契約なら契約前に何を完成させるかが決まっていて契約書に明記されているはず。しかし、末端というか実際にコードを書いている人のところでは稼働あたりの単金を決めて労働力を提供していることも多いように思う。これは少なくとも請負ではない。
# 運用・監視など、納品物が無い場合も当然請負ではあり得ない。準委任か。
もっとも、たとえ請負契約だとしても、個人事業主以外の労働者の労務契約は請負契約ではあり得ない。だから請け負った企業は瑕疵対応のために自己負担でバグを直すべきであっても、作業に従事する労働者がただ働きをするべきという話には決してならない。
これは建築業者であっても同じであって、請け負った企業が自腹で塀を修復するとしても、作業にあたる労働者はその修復する時間分も給与を当然もらうことになる。
法の原則として、使用者(会社)が利益をとるなら、損害のリスクも使用者が負わなければならない。なので、労働者は会社がぼろ儲けをしても労働契約で取り決めた賃金以上のものを請求する権利はないが、会社が損害を被っても賃金分は請求する権利がある。
リスク負担 (スコア:1)
建築業者は塀を完成して引き渡す義務があり、工事のリスク(工事した塀が崩れるなど)は通常は施主ではなく建築業者が負う契約になっている
雇用されているソフトウェア開発者の義務は労働力の提供であって、完全なプログラムの提供ではないので、通常はバグ発生のリスクは雇い主が負う
Re: (スコア:0)
上司が尋ねているのは、何故ソフトウェア開発者はプログラムを引き渡す義務を負わず、労働力しか提供しないのか、という問でしょう。
# 「停止性問題により、完全なプログラムを提供するのは不可能だから」というのは、
# 「天変地異に耐えられる塀を開発するのは不可能だから」というのと同じくらい無意味な説明です。
それ以前に「私は労働力を提供してるだけですから」なんてプログラマとは仕事したくないですね。
Re: (スコア:0)
ソフトウェアに公差という概念がないからだろう、設計図と実際の建築物は絶対に一致しない、
致命的な問題がない限り設計図と異なっても補修する意味がない。
堀が3cmズレようが、ドアの位置が1cm違おうが、何の問題もないだろう、
Re: (スコア:0)
致命的な問題がない限り設計図と異なっても補修する意味がない。
堀が3cmズレようが、ドアの位置が1cm違おうが、何の問題もないだろう、
建築業をなめてませんか?
塀が3cmずれて隣の敷地に侵入してたら、大問題ですよ。
Re:リスク負担 (スコア:1)
Re: (スコア:0)
塀と敷地で3cmくらいだと「ずれても支障がないように設計する」のがいいんじゃないかな。
作ってから大きな地震、とかもあるし。
ドアの位置が1cmずれてると、蝶番のねじ穴が柱にとどかないとかありそう。
でもその辺は設計図どおりにぴったり施行はできないから現物あわせで辻褄…のような気も。
Re: (スコア:0)
その敷地の境界はどうやって測るのかな、
ミラー置いてレーザで測るんだが、mm以下の数字に意味が出るような測定方法でもない。
Re: (スコア:0)
義務は○○
と
○○しかしない
は同義ではない
Re: (スコア:0)
たぶんよそでも出てると思うけど、そういう契約だから、でしょ。
上司と部下、じゃなくて、発注と受注、という関係なら、瑕疵担保責任も発生する。その分、コストも高くなると思いますが。
いろいろ混ざってるから.... (スコア:1)
たとえが悪いかな。この場合。
仕事でやっている以上、自分の時間を使って開発をする必要はない。でいいと思うけど。
「建築業者が塀を作っている途中で下の方が崩れ始めたら、」の部分を
「プログラムを作っている途中でバグを発見した」と読み取れば、
納品前に修正するのがあたりまえだと思うけど。
これ日本の話だよね? (スコア:0)
誰が本家に投稿したの?
Re: (スコア:0)
言い返す、あるいは論破する方便を考えるのに外人の知恵を拝借したいんだろうなw
ジャップじゃ黙って納得してしまうから
契約書を書きましょう (スコア:0)
問題が起こるのは、契約書を書いてないからでしょう。
比較対象が間違ってる (スコア:0)
建築作業を引き合いに出してくるのがおかしい
Re: (スコア:0)
なんで?
っていうのがこのストーリーなのでは
Re: (スコア:0)
塀を造っている前なら、納品前でしょ。請負なら完成物を納品しなければいけないので、費用は請負側が負担するのが当然では。でも、納品後は、債務不履行か瑕疵担保の問題。
Re: (スコア:0)
アーキテクチャー、設計(デザイン)、ビルド、フラグ(工事事務所に普通立ってるでしょ)、ファイヤーウォール、炎上、クラッシュ、仕様書、(多重・偽装他)下請け、中抜、プラットホーム、バス、トラック、ダンプ、土方、土管、etc・etc、良ぉく似ているじゃないか。
Re: (スコア:0)
ソフトウェアの設計段階で結果をシミュレートできるなら、土木とソフトウェアはよく似ているといってもいいだろう。
実際は、シミュレートできるならそのまま実用すればいいところまで実装が完了しているのがソフトウェア。
建築物の場合は、覆しようのない物理上の限界という大枠があるけど、ソフトウェアにはそれがない。
ここが最大の差。
Re: (スコア:0)
原発の事故処理なんてかなり払わされてるぞ
できないから (スコア:0)
完成時点で土台が崩れない建築物を建てるのは技術的に可能で、
実際に出来る職人も多数いる。
ところが、バグがないソフトを開発するのは現在困難で
それをやってくれる人が殆どいない。だから現在はバグ修正込みでの
仕事を出さないと誰もやってくれない。
その違い。今後どうなるのかはしらん・
できるとかできないとか (スコア:0)
たとえばせいぜい計測値を記録するソフトと、複数の計測値をもとに機器を制御するソフトじゃ複雑さが違いすぎるわけで、その辺の区別もせずに「バグがないソフトを開発するのは現在困難でそれをやってくれる人が殆どいない。」などと言い切るのは乱暴に過ぎませんか?
建築物でいうなら、乗用車を入れるガレージ建てるのと、タワーマンション建てるのを同じ技術と見なしてるようなものです。
そして多くの職人が関わっているタワーマンションにしたところで、コア抜きなんてひどいパッチあてが行われたり、鉄筋切って販売中止になっていたりするわけです。
要は契約範囲内なら粛々とやるし、範囲外なら別契約という当たり前の話です。
Re: (スコア:0)
ソフトウェアの規模に依らず。最適化が掛かるコードからバグを取り除くことは不可能、
オプティマイザ自体に確実にバグがあるので、
アーキテクチャ毎の最適化なんて最悪、当然JITコンパイルなぞ地獄
Re: (スコア:0)
その「バグを取り除くことは不可能」なシロモノで現実に様々な活動が営まれていることについてどうお考えなのでしょう。
完璧なソフトウェアがありえないのであれば、それは誰にも必要とされていない存在でしかないのですから、
ここでの議論においては全く無視して良いと言わざるを得ません。
Re: (スコア:0)
大きなシステムは必ずどこかが故障している。それでも現実に様々な活動が止まることなく営まれている。
大型旅客機がなんの故障もなく飛んでいることなどないのと同程度の問題としか。
建築業者には・・・ (スコア:0)
建築業者に頼むものは途中で部屋を増やしてくれとか構造を変えてくれくれとか注文しないのにソフトウェアには
注文してくるのは何ででしょうねぇ?
Re: (スコア:0)
最初に要件を定義しておかないからでは。
定義しておけば、あとから再見積もりとか納期見直しとか
すれば良い話です。
それができないのは、ソフトウエア業界の問題というよりは
個々の職場の問題です。体質改善が必要です。
下請法では最初に要件を定義しておくように定められていて、
あとからそれを変更することは禁止されていますので、
コンプライアンスを気にする企業はそのようなことは先方が
気にしてくれます。
「下請法」親事業者の禁止行為
http://www.jftc.go.jp/shitauke/shitaukegaiyo/oyakinsi.html [jftc.go.jp]
Re: (スコア:0)
それは幸せな建築業者ですね。
#聞きかじるソフトウェア業界との違いは出来なきゃ断るってところか。
##対下請けも含め許認可業だからってのもあるのかな。
Re: (スコア:0)
設計者の建築士に対しては行われてるんじゃないの?
現場の大工まで降りないだけで。
見える建築と違って結局は仕様書があいまいだからでしょ。
日本語で完璧な論理を記述するのと、コンピュータ言語で
同じものを記述するのと、どっちかやれといわれたら
コンピュータ言語を選ぶ私はだから現場が好き。
Re: (スコア:0)
一戸建て住宅を扱ってる知り合いによると、けっこうコンセントとかいろいろ建築途中で追加したり変更してくれという要望はあるそうな。
# 要出典なのでAC
Re: (スコア:0)
だって、内開きのドアのうしろになる場所に部屋の電気のスイッチがあるんだもん。
#実家のケースでは父が違法電気工事でなおしたがな
既に書かれてるが、治すのは (スコア:0)
バグではなくバカの方
なんかちがう (スコア:0)
ソフトウェアの作成は建築によく例えられるけど、俺の感覚では料理に近い。
べつに専門店のシェフでなくても、たとえばチェーン店の厨房で働く調理人でもいいけど、
味付けや焼き加減でミスったら、そりゃ自腹でなんとかせえよ、ってのが世の常識じゃね?
Re:なんかちがう (スコア:1)
私の感覚ではもっと前工程の設計・開発工程だな。
料理で言えば新メニューのレシピ開発。建築で言えば設計図を作る段階。
建築や料理の実際に作っている段階は、筐体組み立てて出来合いのソフトをインストールしている工程で、ソフトウェア開発は終わった後の世界。
その工程ならコンピュータの世界でも同じくらいの対応をしている。
Re: (スコア:0)
その通りだね。
ソフトウェアの場合、製造という工程がほぼ皆無なんだけど(コンパイル時間くらい)
その辺りを理解していない人がとても多いので
この業界が発展しないのかなぁ、と思います。
Re: (スコア:0)
>ソフトウェアの作成は建築によく例えられるけど、俺の感覚では料理に近い。
まぁメニューにあるものとして、過去の事例と同じものを弊社用にと言うのなら料理に近いが
その場でメニューにないものを注文してきてその内容が「魚の味のする肉料理」だとか「ツナサラダ味のステーキ」とかだったら懐かしの「顧客が必要とした物」状態になりかねん。