アカウント名:
パスワード:
とりあえず責任が離れるってことだよ
相手が責任を取り切れるという前提があれば真なんですがね ^^
責任すら取らないんだったら元請けってなんのためにいるんだろう
＞元請けってなんのためにいるんだろう
つ 「ピンハネ」
まあ、そういってしまうと身も蓋もないので、「財務上の与信の担保」ぐらいに思っておきましょう。それだけなら人いらないって、気づいたら、元請けの人間はばっさりいなくなるのかなあ。
ところがだな、元請が下請に投げる間隔で、機能ごとに切り分けて海外にアウトソーシングとかやっちゃう奴らもいてだな。 （適当な日本風の）仕様書の責任は満たしているから契約上お金を払わざるえない、でも実際のソースは糞の山だし、仕様書から漏れてる機能や異常系なんかの部分が丸でなくて、元請が自腹で責任取らされるなんてケースもあったりするんだ。 アウトソーシングが悪いんではなく、ソフトウェア開発というものを理解せず安いからって理由だけで安易にやっちゃう連中がどう考えても悪いんだけどな。
＃ 以上実体験から。結構大きな仕事で、最終的に火消しが追いつかず、/.Jにシステムトラブルの記事が掲載されるほどの事態に・・・（汗
仕様書が適当なのが悪いように読めるけど……
詳しくはしらないが
ＵＳＢ機器で１回処理すると応答がなくなる不具合があって＝＞抜き差しして通信するので問題ありません。「処理ごとに抜き差しするとは仕様に書いてない」対「処理ごとに抜き差ししてはいけないと仕様書にかいてない」の言い合いになってた
こんな仕様漏れでもだめだなんて、完璧な仕様書って大変そうだ
そんなこと言うなら「ククク。出しますとも。この利根川、こと金に限り虚偽は一切言わぬ。出す。出すが今回まだその時と場所の指定はしていない。つまり、我々がその気になれば金の受け渡しは１０年後も２０年後も可能ということ」って言って金払わなかったらいいんじゃね。
# 民法上ダメらしいけど。# 民法持ち出すなら、これも十分、錯誤無効で争えそうだし……
>仕様書が適当なのが悪いと一言でいってしまえば、じゃ完璧ならいいのか？そんな完璧な仕様書ってコーディングと同値で無駄じゃない？という事になるので、おそらくは請負という形式ではなくて、パートナーシップが理想なんだろうけど、難しいよな。
たとえば、仕様書をスクリプト言語のような高級言語で書いて同等の動作をする高速な実装を求めるなんて要求は割と普通かと
どこの普通やねん。
それはそうだけど、元請けが完璧な仕様書を書いて外部に出すんだったら、SIビジネスの元請けは成立しないんだ。コスト的にも技術的にもね。
穴だらけの要求仕様が来た場合、最悪はエンドユーザーのところまで御用聞きにうかがって仕様書作ることまでが作業の範囲になっちゃってるからなあ。
そんな感覚で同じ機能を3回ぐらい中国に投げて金だけ取られた挙句、結局別機能を担当してたうちの会社に発注するというアホなこともありましたなあ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
アウトソーシングのキモはだな (スコア:0)
とりあえず責任が離れるってことだよ
Re: (スコア:0)
相手が責任を取り切れるという前提があれば真なんですがね ^^
Re: (スコア:0)
責任すら取らないんだったら元請けってなんのためにいるんだろう
Re:アウトソーシングのキモはだな (スコア:1)
＞元請けってなんのためにいるんだろう
つ 「ピンハネ」
Re: (スコア:0)
まあ、そういってしまうと身も蓋もないので、「財務上の与信の担保」ぐらいに思っておきましょう。
それだけなら人いらないって、気づいたら、元請けの人間はばっさりいなくなるのかなあ。
要件に対する責任は果たすが (スコア:0)
ところがだな、元請が下請に投げる間隔で、機能ごとに切り分けて海外にアウトソーシングとかやっちゃう奴らもいてだな。
（適当な日本風の）仕様書の責任は満たしているから契約上お金を払わざるえない、でも実際のソースは糞の山だし、仕様書から漏れてる機能や異常系なんかの部分が丸でなくて、元請が自腹で責任取らされるなんてケースもあったりするんだ。
アウトソーシングが悪いんではなく、ソフトウェア開発というものを理解せず安いからって理由だけで安易にやっちゃう連中がどう考えても悪いんだけどな。
＃ 以上実体験から。結構大きな仕事で、最終的に火消しが追いつかず、/.Jにシステムトラブルの記事が掲載されるほどの事態に・・・（汗
Re:要件に対する責任は果たすが (スコア:1)
仕様書が適当なのが悪いように読めるけど……
1を聞いて0を知れ!
Re:要件に対する責任は果たすが (スコア:2, 興味深い)
詳しくはしらないが
ＵＳＢ機器で１回処理すると応答がなくなる不具合があって＝＞抜き差しして通信するので問題ありません。
「処理ごとに抜き差しするとは仕様に書いてない」対「処理ごとに抜き差ししてはいけないと仕様書にかいてない」
の言い合いになってた
こんな仕様漏れでもだめだなんて、完璧な仕様書って大変そうだ
Re:要件に対する責任は果たすが (スコア:1)
そんなこと言うなら「ククク。出しますとも。この利根川、こと金に限り虚偽は一切言わぬ。出す。出すが今回まだその時と場所の指定はしていない。つまり、我々がその気になれば金の受け渡しは１０年後も２０年後も可能ということ」って言って金払わなかったらいいんじゃね。
# 民法上ダメらしいけど。
# 民法持ち出すなら、これも十分、錯誤無効で争えそうだし……
1を聞いて0を知れ!
Re:要件に対する責任は果たすが (スコア:1)
>仕様書が適当なのが悪い
と一言でいってしまえば、じゃ完璧ならいいのか？そんな完璧な仕様書ってコーディングと同値で無駄じゃない？という事になるので、
おそらくは請負という形式ではなくて、パートナーシップが理想なんだろうけど、難しいよな。
#存在自体がホラー
Re: (スコア:0)
たとえば、仕様書をスクリプト言語のような高級言語で書いて同等の動作をする高速な実装を求めるなんて要求は割と普通かと
Re: (スコア:0)
どこの普通やねん。
Re:要件に対する責任は果たすが (スコア:1)
それはそうだけど、元請けが完璧な仕様書を書いて外部に出すんだったら、SIビジネスの元請けは成立しないんだ。
コスト的にも技術的にもね。
Re: (スコア:0)
穴だらけの要求仕様が来た場合、最悪はエンドユーザーのところまで御用聞きにうかがって仕様書作ることまでが作業の範囲になっちゃってるからなあ。
そんな感覚で同じ機能を3回ぐらい中国に投げて金だけ取られた挙句、結局別機能を担当してたうちの会社に発注するというアホなこともありましたなあ。