（ヽ´ん`）「仕様書どおりにシステム作ったンモ。動かないけど仕様書どおりだから知らないンモ」⬅どうすんのこれ [158478931]
■ このスレッドは過去ログ倉庫に格納されています
内製した方が安いし早いのに絶対外注する会社ってなんなんだよ プログラマーはコミュ力いらんと思われてることあるよな
自分の好きなことやって金もらってるわけじゃないぞと この業界、発注側も組む側も残念な奴しかいないのはなんでだぜ？ >>1
ソース記事読んだら、要件通りに作っただけじゃ駄目って判決出てるじゃん… 仕様を外に任せると一々不明点があると確認しないといけないのがだるすぎる うるう年に動かないとかならまだしも
セキュリティの欠陥とかは指摘しないと大事になるしな >>132
内製してくれるプログラマ抱えておく金がねえんだろ
安くこき使えばすぐに転職されておしまいやぞ 仕様不備をあえて指摘せず仕様変更で2度稼ぐという手もある ベンダーが要件定義の金もらってるならそら仕様書不備の責はある程度ベンダーが負わないといけないだろ
ただし全部の責任を負うわけじゃない
致命的に運用に乗らないシステムな場合なだけ >>12
言いたいことは分かるが受注ケースによる
君はまだ青いね まさに今後始末やってるけど、こんな品質でよく納品出来たと驚いた 気付いたなら説明責任はあるよね 説明しなかったなら瑕疵取られても仕方ないレベル(´・ω・｀) その業務を理解しないで要件や仕様を決定して来て後から破綻するパターンやね
ただ書きなぐってるだけの設計書なんて腐るほど見て来たよw
物事の整理整頓ができない奴に限って糞な設計書を作成するw 言われた通りにやるだけで良いってのがまさに末端作業員的な思考で実際に末端作業員ばっかりなんだろうなケンモメンは でもそんなこと指摘しても追加の金は出さないとか言い出すんだろ？
マジで発注者側優遇しすぎなんだよ 逆に使えるように作ったら仕様通りじゃなくなっちゃうよ >>119
これで判決理解できたわ
ベンダーが要件定義サポしてたのかよ そもそも顧客すら何が必要な要件か、要件定義の段階ではわからない
それをベンダーが無理やりイエスノーで決めさせて、不要な要件入れ込んでしまったってことやろな 安心のジャップランドクオリティだぞ
動かないのは仕様です(´・ω・｀) 通常、要件定義は準委任契約でやるけども、それでも善管注意義務はあるって事だと 結局二度手間になるのに確認ができない奴ってなんなんだろうな 何も分からない人が要件定義して
何も分からない人がその要件を実装する
いわばまさに日本イット(´・ω・｀) >>119
サポートしてそんな使えねぇ要件て意味わかんねーな 顧客「んー、なんかもっと良い感じのシステムにしたいんだよなあ
ベンダー「では、こういう機能が必要ですよね！こういう仕様で作りますね！」←間違い
ベンダー「良い感じの前に、本当に必要なものは何か。もっと掘り下げましょう」←正解 これあるあるで困る
単体テストや結合テストも適当に帳尻合わせてくるんだよな
大体ユーザ試験で引っかかってくるけど 請負契約だったらそうはならんでしょ
仕様書通りに造れとか単純労働の役務の提供みたいな契約にしてるの？
そんなあほな お客さんがバカで作ってるのが下請けの新人ですぐ辞めてるんでしょｗ
銀行のシステムが～ｗｗｗ >>173
一般的なシステム開発やと詳細設計～結合テストまでは請負、要件定義、基本設計、STは準委任やね これの作る側をAIに置き換えてうまくいくと思うか？
AIに騙されたとか言い始める姿が目に浮かぶわ 仕様書なんて一緒に作るもんだからそんな単純な話にはならんちゃうの ベンダーが悪い
ベンダーはロボットでもユーザーの奴隷でもない 仕様通りは必須
動かないなら試験で引っかかるし
仕様変更で改修になるだけ
動かないまま納品にはならない いや受発注者間協議で確認しろよ ほんとにこれで作っていいの？って(´・ω・｀) ■ このスレッドは過去ログ倉庫に格納されています
