開発者は自分の時間を使ってバグを修正するべき？ 115
ストーリー by headless
修正 部門より
修正 部門より
本家/.「Ask Slashdot: Should Developers Fix Bugs They Cause On Their Own Time?」より
今日、上司が私のところに来て、バグの修正作業について彼自身がうまく言い当てたと考えている話を聞かされた。ソフトウェア開発者が書いたプログラムにバグが見つかった場合、修正費用は雇い主が払い、開発者は業務時間内に修正作業を行うことになる。しかし、建築業者が塀を作っている途中で下の方が崩れ始めたら、多くの場合は建築業者が自腹を切り、自分の時間を使って修復することになるというものだ。この話を聞いた時にはうまく反論できなかったが、なぜソフトウェアのバグは扱いが異なるのだろうか。
話の前後で比較対象がずれているというオチ (スコア:5, すばらしい洞察)
「建築業者の従業員が」塀を作っている途中で下の方が崩れ始めたら、修正費用は雇い主が払い、従業員は業務時間内に修正作業を行うことになる。
「ソフトウェア開発業者が」書いたプログラムにバグが見つかった場合、多くの場合は業者が自腹を切り、自分の時間を使って修復することになる。
何も違わないでしょ。この上司が（意図してか気づかないでか）、作業者と業者を混同しているだけ。
＃ 原文は確認してないので、本家ではそんなこと無いとかだったらサーセン。
Re:話の前後で比較対象がずれているというオチ (スコア:5, 参考になる)
原文もそうだし、同じツッコミ [slashdot.org]が入ってる。
Re: (スコア:0)
残念だけどバグ無しのソフトウェアを確実に開発できる方法ってのが無いんだよね。
Re:話の前後で比較対象がずれているというオチ (スコア:1)
人が作るからじゃね？
いろいろ混ざってるから.... (スコア:2)
たとえが悪いかな。この場合。
仕事でやっている以上、自分の時間を使って開発をする必要はない。でいいと思うけど。
「建築業者が塀を作っている途中で下の方が崩れ始めたら、」の部分を
「プログラムを作っている途中でバグを発見した」と読み取れば、
納品前に修正するのがあたりまえだと思うけど。
規模によりけりだけど (スコア:2)
個人宅～小規模な集合住宅クラスなら請負業者が自腹でってのは有りそうだけど
規模が大きくなると、修繕費も別で組まれてたりするから自腹ってのはないんじゃないのかなぁ？
理由は兎も角、労働に対し適切な対価を支払いたくがない故の強弁でしょうね。＞自腹
初めから余裕が作れるほど「予算」がなかったのか、単に管理が悪く足りなくなったのかは
知りませんが、生じてしまった無理を押しつけているだけと言っても良いかと。
如何なる内容であろうとACでの書き込みは一切無視します。
品質担保の手法、範囲の差でしょうに。。 (スコア:2)
リリースされる前の品質担保が、ほぼレビューとテストのみになってしまうソフトウェアと、自然法則＋検査で評価される建築物とでは、ちょいと質が違うかと。建築物は、ひどい手抜き工事であっても自然法則由来のテストは出来ているともいえます。
公開ベータや常にアルファ版相当での出荷するような、ユーザーにデバッグさせるような類のアプローチもありますが、それも、品質と時期、コストとバグのリスクを見据えた作戦の一種ですしねぇ。
建築物も、例えば、大規模震災に対する耐性や建築材料の劣化に関するトラブルは、法や技術の範囲外の想定外は散見されると思っていますし、それは瑕疵の範囲を逸脱しますよね。
委託と請負の違い (スコア:1)
委託 [wikipedia.org]
責任主体は委託する側(雇用主)、委託された側は代わりに手を動かしているだけ。
請負 [wikipedia.org]
責任主体は請け負った側(労働者)、請け負った側は完成品を納品する義務がある。
本家の人は請け負い開発者？
「委託」はあいまいな言葉 (スコア:5, 参考になる)
委託ではなく「準委任」という言葉が適切でしょう。
「請負」「委任」「準委任」は民法で規定されています。
「準」は法律行為が伴わないものが対象なので、ソフト開発などはこちらになります。
Re: (スコア:0)
雇用と委託って一緒にしていいの？
嘱託とごっちゃになってる？
あと責任と権限をもって請け負った人を「（労働者）」っていっちゃうのも、間違いかどうかはともかくそうとう粗雑じゃない？
Re:委託と請負の違い (スコア:1)
請負は民法の典型契約のひとつ。委託は民法に書いてない。日本で委託と呼称されている契約は実質的に請負。宅配便のバイトも袋詰めの内職も契約としては請負。
Re:委託と請負の違い (スコア:3)
それはどうだろう。請負契約なら契約前に何を完成させるかが決まっていて契約書に明記されているはず。しかし、末端というか実際にコードを書いている人のところでは稼働あたりの単金を決めて労働力を提供していることも多いように思う。これは少なくとも請負ではない。
# 運用・監視など、納品物が無い場合も当然請負ではあり得ない。準委任か。
もっとも、たとえ請負契約だとしても、個人事業主以外の労働者の労務契約は請負契約ではあり得ない。だから請け負った企業は瑕疵対応のために自己負担でバグを直すべきであっても、作業に従事する労働者がただ働きをするべきという話には決してならない。
これは建築業者であっても同じであって、請け負った企業が自腹で塀を修復するとしても、作業にあたる労働者はその修復する時間分も給与を当然もらうことになる。
法の原則として、使用者（会社）が利益をとるなら、損害のリスクも使用者が負わなければならない。なので、労働者は会社がぼろ儲けをしても労働契約で取り決めた賃金以上のものを請求する権利はないが、会社が損害を被っても賃金分は請求する権利がある。
これ日本の話だよね？ (スコア:1)
誰が本家に投稿したの？
Re: (スコア:0)
言い返す、あるいは論破する方便を考えるのに外人の知恵を拝借したいんだろうなｗ
ジャップじゃ黙って納得してしまうから
リスク負担 (スコア:1)
建築業者は塀を完成して引き渡す義務があり、工事のリスク（工事した塀が崩れるなど）は通常は施主ではなく建築業者が負う契約になっている
雇用されているソフトウェア開発者の義務は労働力の提供であって、完全なプログラムの提供ではないので、通常はバグ発生のリスクは雇い主が負う
Re: (スコア:0)
上司が尋ねているのは、何故ソフトウェア開発者はプログラムを引き渡す義務を負わず、労働力しか提供しないのか、という問でしょう。
# 「停止性問題により、完全なプログラムを提供するのは不可能だから」というのは、
# 「天変地異に耐えられる塀を開発するのは不可能だから」というのと同じくらい無意味な説明です。
それ以前に「私は労働力を提供してるだけですから」なんてプログラマとは仕事したくないですね。
Re:リスク負担 (スコア:1)
>何故ソフトウェア開発者はプログラムを引き渡す義務を負わず、労働力しか提供しないのか
労働力しか提供しないという働き方をしているケースは、通常は提供するのは「労働力」であるという契約で働いているから。
「責任」も込みならば、責任の範囲を明文化し、金額にリスクを上乗せするだけ。請負ってやつだね。
契約なんぞ知った事ではないなんていう人とは怖くて仕事できないよ。
大体、そう言っている人間が仕事に対して無限責任を負っているわけでもないし。負っているから言っていいわけではないし。
Re:リスク負担 (スコア:1)
＞何故ソフトウェア開発者はプログラムを引き渡す義務を負わず、労働力しか提供しないのか
雇用契約だから（請負契約をしてないから）でしょう。
日本で、このような妄言を吐く"上司"がいたら「請負契約を装った雇用契約をしたい」と言っている莫迦者だけど、米国の「雇用契約」では認められているのかしら？
＞なんてプログラマとは仕事したくないですね。
下請法をきっちり守って、請負契約だけしていれば良いのでは？
たぶん、そのほうが双方幸せになれると思います。
# 雇用されてても（労働者として行ってても）普通はそういう返事はしないから。
# 仕様をコロコロと変更し続けるとか、あいまいな指示を出し続けるとか、そういう事をされない限り、そんな返事はしないと思う。
# 請負契約として仕様を明確にしてくれた方が良い結果を生むはず。
notice : I ignore an anonymous contribution.
Re: (スコア:0)
ソフトウェアに公差という概念がないからだろう、設計図と実際の建築物は絶対に一致しない、
致命的な問題がない限り設計図と異なっても補修する意味がない。
堀が３cmズレようが、ドアの位置が１cm違おうが、何の問題もないだろう、
Re: (スコア:0)
致命的な問題がない限り設計図と異なっても補修する意味がない。
堀が3cmズレようが、ドアの位置が1cm違おうが、何の問題もないだろう、
建築業をなめてませんか?
塀が3cmずれて隣の敷地に侵入してたら、大問題ですよ。
Re:リスク負担 (スコア:1, すばらしい洞察)
Re:リスク負担 (スコア:1)
塀と堀間違えるかね？
堀なんて一般的には作ったりせんけど。
#どっちにしろ隣の敷地に侵入すれば怒られるのには変わりない。
Re: (スコア:0)
塀と敷地で3cmくらいだと「ずれても支障がないように設計する」のがいいんじゃないかな。
作ってから大きな地震、とかもあるし。
ドアの位置が1cmずれてると、蝶番のねじ穴が柱にとどかないとかありそう。
でもその辺は設計図どおりにぴったり施行はできないから現物あわせで辻褄…のような気も。
Re: (スコア:0)
その敷地の境界はどうやって測るのかな、
ミラー置いてレーザで測るんだが、ｍm以下の数字に意味が出るような測定方法でもない。
Re: (スコア:0)
義務は○○
と
○○しかしない
は同義ではない
Re: (スコア:0)
たぶんよそでも出てると思うけど、そういう契約だから、でしょ。
上司と部下、じゃなくて、発注と受注、という関係なら、瑕疵担保責任も発生する。その分、コストも高くなると思いますが。
契約書を書きましょう (スコア: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:建築業者には・・・ (スコア:1)
最初に要件を定義しておかないからでは。
定義しておけば、あとから再見積もりとか納期見直しとか
すれば良い話です。
それができないのは、ソフトウエア業界の問題というよりは
個々の職場の問題です。体質改善が必要です。
下請法では最初に要件を定義しておくように定められていて、
あとからそれを変更することは禁止されていますので、
コンプライアンスを気にする企業はそのようなことは先方が
気にしてくれます。
「下請法」親事業者の禁止行為
http://www.jftc.go.jp/shitauke/shitaukegaiyo/oyakinsi.html [jftc.go.jp]
Re:建築業者には・・・ (スコア:1)
いや、思い込みは良くない。
変えてくれってのはあります。
個人宅の場合は、壁にブレースを入れたりすので、
それでブレース位置変更が入ると、
構造計算もやり直しです。必要額もかなり増えることは
設計書の確認の時に何度も念をおします。
ブレースの位置は設計図にも出ていますし、部屋割り変えたいってのはあるので、両者の手間を省くために
設計初期からお客さんに話はします。
が、予算はないけど、あとから壁を取り除く場合はあります。
しかし、ブレースを取り除く訳には行かないので、
ブレースが入った壁ならブレースだけ残ります。
それでも良いから壁をなくしてほしいって場合だけです。
とか書いていますが、私が建築に関わっていたのは15年は前の話です。
今はどうなんですかね。
Re: (スコア:0)
それは幸せな建築業者ですね。
＃聞きかじるソフトウェア業界との違いは出来なきゃ断るってところか。
＃＃対下請けも含め許認可業だからってのもあるのかな。
Re: (スコア:0)
設計者の建築士に対しては行われてるんじゃないの？
現場の大工まで降りないだけで。
見える建築と違って結局は仕様書があいまいだからでしょ。
日本語で完璧な論理を記述するのと、コンピュータ言語で
同じものを記述するのと、どっちかやれといわれたら
コンピュータ言語を選ぶ私はだから現場が好き。
Re: (スコア:0)
一戸建て住宅を扱ってる知り合いによると、けっこうコンセントとかいろいろ建築途中で追加したり変更してくれという要望はあるそうな。
# 要出典なのでAC
Re: (スコア:0)
だって、内開きのドアのうしろになる場所に部屋の電気のスイッチがあるんだもん。
#実家のケースでは父が違法電気工事でなおしたがな
既に書かれてるが、治すのは (スコア:0)
バグではなくバカの方
Re:なんかちがう (スコア:2)
私の感覚ではもっと前工程の設計・開発工程だな。
料理で言えば新メニューのレシピ開発。建築で言えば設計図を作る段階。
建築や料理の実際に作っている段階は、筐体組み立てて出来合いのソフトをインストールしている工程で、ソフトウェア開発は終わった後の世界。
その工程ならコンピュータの世界でも同じくらいの対応をしている。
Re:なんかちがう (スコア:2)
実際どの探査アルゴリズムを使うかとか、どのメモリアドレスを変数に使うかといったレベルまで含めると
プログラミング時にプログラマの裁量で極詳細仕様の判断決定がなされているんですよね。
Re:なんかちがう (スコア:3)
ソフトウェアの場合、本当に人の判断が不要な段階まで設計が出来たとすると
それはつまり、ソースコードが完成した事と同等なんですよね。
人の判断がいらないレベルの設計があるならば、
あとは変換ソフトウェアに任せれば完全自動で完成させることが出来る、ということになります。
なので、製造のフェイズは究極的にはコンパイラやビルド処理のみということになるので、
まさに「寝てる間に勝手に出来上がる」わけですね。
Re:なんかちがう (スコア:1)
そーゆー意味じゃなくて、ソフトウェアの場合、コーディングは、他の業種の設計に相当と考えることができる、ってこと。
この場合、他の業種の製造に当たるのは、ソフトウェアの場合は、コンパイル・ビルドと単純コピーに相当すると考える。