アカウント名:
パスワード:
で、東証は東証でシステムを作った富士通が悪い、とか言ってたように思うんだが、あの決着は付いたのか？
私の中の認識では、一般的にはプログラム納品後にユーザー側で検収テストを行い、仕様通りの実装が行われているかチェックします。
チェックした上で、検収書にハンコなり貰って全て完了。仮に検収後に不具合が出たとしても、それはユーザー側の責任という事になってます。（ですので、その辺の流れは最初の契約時に、契約書に含めます）
富士通と東証みたいに、ハードソフト共にべったりで人もかなり入り込んでるようなとこって、どういう契約なんでしょうね…。
既に瑕疵担保責任についてコメントがあるけど、本当にその認識で開発してるの？
そんなことがまかり通るのであれば製造物責任とか法律にする必要ないよね・・・。もう少し自分の仕事に誇り（≒責任）を持った方が良いと思います。
ソフトウェアそのものは製造物責任法の対象外だし，この件のように受注開発したソフトウェアの場合は発注側の責任もあるので，一概に #1684659 のAC氏が無責任だとは言えないでしょう． パッケージソフトウェアであっても，利用者毎に動作環境が大きく違うので，全ての環境で間違いなく動作するように作成するのは非常に困難です．
この現状が必ずしも正しいとは思いません． しかし，現状の技術のままソフトウェアを製造物責任法の対象にすれば，ソフトウェア開発コストが一律10倍になったり，アプリケーションの追加インストールやOSの入れ替えが出来なくなってハードウェアへのバンドルだけになったりするでしょう． そのような事態は，個人的には受け入れ難いです．
#1684769のAC氏とは違いますが 瑕疵 [wikipedia.org]を参考にすると
売買契約において、買主が売主から目的物の引渡しを受けたものの、目的物に隠れた瑕疵があったことが判明した場合、買主がこれを知らず、かつ、そのために契約の目的を達することができないときは、買主は、契約の解除をすることができる。この条件を満たさないときは、損害賠償請求のみをすることができる(中略)(1)一般人が通常の注意を払っても知り得ない瑕疵であることと、(2)買主が善意・無過失であることが必要である。
の部分を見れば、#1684775にある
パッケージソフトウェアであっても，利用者毎に動作環境が大きく違うので，全ての環境で間違いなく動作するように作成するのは非常に
>自分の仕事に誇りを持っていろいろと考え、指摘していくべきだと思うのですが、どうでしょうか。エスパーじゃないので難しいんじゃないかな？ベンダーはシステムの専門家であって証券市場の専門家ではないですから、現実の使い方のパターンを網羅して、その上でどのような問題が発生しうるかまで予見出来ないでしょう。
>>ベンダーはシステムの専門家であって証券市場の専門家ではないですから、現実の使い方のパターンを網羅して、その上でどのような問題が発生しうるかまで予見出来ないでしょう。
そんなバカは、他人様のシステムに手を出しちゃいけません。自社システムだけ作ってなさい。 ＃自社の業務も専門家じゃなかったりするかｗ
なもんで、自分は上に流れてるのがなんであろうと大して違いがないネットワークが専門です。通常、責任範囲がガチガチなのでSI屋さんの感覚はちょっとわかんないかもしれません。
しかし、ぶっちゃけネットワークだけでもあんだけ検証がしんどいのに、よくサーバやソフトウェアなんてものを纏めてパッケージにして売るような仕事に出来るなと、素直にすごいなとは思いますね。更にそういう未来予知までベンダーの責任範囲だと大変そうで、やはりサーバやソフトを顧客に提供するような仕事にしなくて良かったなとは思います。てっきりそういう予見が完璧には出来ないからこそ試験運用の期間とかを設けるんだと思ってたんですが、そういうわけじゃないということで目から鱗です。
開発で儲けず運用で儲けるベンダーが多いというのは、たぶん近くにいるソフト屋さんを丹念に観察すれば気づけるはずです。開発は期間や瑕疵のリスクがあり儲からない可能性が高いが、運用はほぼ無瑕疵でいけることが理由です。この場合、平行運用などの期間については、開発の重大な瑕疵責任を軽減する役割でしかありません。そして大枠としては、開発担当を理由に受注できる可能性の高い運用を利用し、儲けを担保している形です。
ただし、パッケージソフトは売買契約となるため、瑕疵の範囲が変わってきますので、そうしなければならないほどのリスクはないものと考えればよいでしょう。
「場所によってはオペレータより立場や地位の弱い開発者という構図が少しずつ増えてきています。」というのはあまり無いんじゃないのかな？オペレータって基本的にはアウトソースでマニュアル対応をする部隊でしょ。ちょっと見てわかんないとか面倒とか思ったら即座に構築部隊にエスカレーションしてくるという印象が・・・。
会社として運用で儲かるから構築部門は利益をあげられず評価が低いという話であれば、それは営業判断として営業なり会社全体なりがフォローする話ですし、運用がどうだから構築はこうしなくちゃいけないとかってのは企画とか商品開発の部門がする話でしょう。金が出て要件が追加されてるとかなら構築部門の問題でしょうが、本来のサービス範囲外の要求をどこからのフォローも無くボランティアでやれってんなら、それを構築部門が必死こいて独断専行して積極的にやる理由はないように思えます。要件でこうしろってのに違う実装をするとかしたらそれこそ瑕疵になるでしょうし。また、運用から、「イレギュラーな設計なのでこちらでは対応できませんから構築側で直接保守してください」とか言われた日には目も当てられないと個人的には思うんですが・・・。何らかのイレギュラーな設計になる提言をして、その結果、会社のプロダクトを逸脱する責任を構築部隊の一エンジニアが取れるのかと。まぁ、今回の事例ではそもそも一点物でしょうからそういう話にはならないとは思いますけども。
会社としての責任範囲がどうかというのは営業とか法務の判断する話ですよね。それを踏まえて社内で決められている自部門の責任範囲を守り、自部門の責任範囲内の仕事を完璧にこなした上で会社内で構築部隊が評価されない。顧客に対するサービスの責任範囲に対して社内の責任範囲の分担では空白が出来、それが構築部隊の責任になるってんなら、その会社はそもそも会社として構築自体重視してないんじゃないかと。それで地位を脅かされるような会社は構築する人間にとっては碌な会社ではないので、早々に転職するなり運用の方に転向するなりした方が良いように思えるのですが・・・。
っていつの間にか部署間での評価の話になっちゃってますね。そんな話でしたっけ？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
取り消し操作が効かなかった (スコア:4, 参考になる)
Re: (スコア:0)
で、東証は東証でシステムを作った富士通が悪い、とか言ってたように思うんだが、
あの決着は付いたのか？
Re: (スコア:0)
私の中の認識では、一般的にはプログラム納品後にユーザー側で検収テストを行い、
仕様通りの実装が行われているかチェックします。
チェックした上で、検収書にハンコなり貰って全て完了。
仮に検収後に不具合が出たとしても、それはユーザー側の責任という事になってます。
（ですので、その辺の流れは最初の契約時に、契約書に含めます）
富士通と東証みたいに、ハードソフト共にべったりで
人もかなり入り込んでるようなとこって、どういう契約なんでしょうね…。
Re: (スコア:0)
既に瑕疵担保責任についてコメントがあるけど、本当にその認識で開発してるの？
そんなことがまかり通るのであれば製造物責任とか法律にする必要ないよね・・・。
もう少し自分の仕事に誇り（≒責任）を持った方が良いと思います。
Re: (スコア:0)
ソフトウェアそのものは製造物責任法の対象外だし，この件のように受注開発したソフトウェアの場合は発注側の責任もあるので，一概に #1684659 のAC氏が無責任だとは言えないでしょう． パッケージソフトウェアであっても，利用者毎に動作環境が大きく違うので，全ての環境で間違いなく動作するように作成するのは非常に困難です．
この現状が必ずしも正しいとは思いません． しかし，現状の技術のままソフトウェアを製造物責任法の対象にすれば，ソフトウェア開発コストが一律10倍になったり，アプリケーションの追加インストールやOSの入れ替えが出来なくなってハードウェアへのバンドルだけになったりするでしょう． そのような事態は，個人的には受け入れ難いです．
Re: (スコア:1, 興味深い)
#1684769のAC氏とは違いますが
瑕疵 [wikipedia.org]を参考にすると
の部分を見れば、#1684775にある
Re: (スコア:1)
>自分の仕事に誇りを持っていろいろと考え、指摘していくべきだと思うのですが、どうでしょうか。
エスパーじゃないので難しいんじゃないかな？
ベンダーはシステムの専門家であって証券市場の専門家ではないですから、現実の使い方のパターンを網羅して、その上でどのような問題が発生しうるかまで予見出来ないでしょう。
◆IZUMI162i6 [mailto]
Re:取り消し操作が効かなかった (スコア:-1, 荒らし)
>>ベンダーはシステムの専門家であって証券市場の専門家ではないですから、現実の使い方のパターンを網羅して、その上でどのような問題が発生しうるかまで予見出来ないでしょう。
そんなバカは、他人様のシステムに手を出しちゃいけません。
自社システムだけ作ってなさい。
＃自社の業務も専門家じゃなかったりするかｗ
Re:取り消し操作が効かなかった (スコア:1)
なもんで、自分は上に流れてるのがなんであろうと大して違いがないネットワークが専門です。通常、責任範囲がガチガチなのでSI屋さんの感覚はちょっとわかんないかもしれません。
しかし、ぶっちゃけネットワークだけでもあんだけ検証がしんどいのに、よくサーバやソフトウェアなんてものを纏めてパッケージにして売るような仕事に出来るなと、素直にすごいなとは思いますね。
更にそういう未来予知までベンダーの責任範囲だと大変そうで、やはりサーバやソフトを顧客に提供するような仕事にしなくて良かったなとは思います。
てっきりそういう予見が完璧には出来ないからこそ試験運用の期間とかを設けるんだと思ってたんですが、そういうわけじゃないということで目から鱗です。
◆IZUMI162i6 [mailto]
Re: (スコア:0)
開発で儲けず運用で儲けるベンダーが多いというのは、たぶん近くにいるソフト屋さんを丹念に観察すれば気づけるはずです。
開発は期間や瑕疵のリスクがあり儲からない可能性が高いが、運用はほぼ無瑕疵でいけることが理由です。
この場合、平行運用などの期間については、開発の重大な瑕疵責任を軽減する役割でしかありません。
そして大枠としては、開発担当を理由に受注できる可能性の高い運用を利用し、儲けを担保している形です。
ただし、パッケージソフトは売買契約となるため、瑕疵の範囲が変わってきますので、そうしなければならないほどのリスクはないものと考えればよいでしょう。
Re:取り消し操作が効かなかった (スコア:1)
「場所によってはオペレータより立場や地位の弱い開発者という構図が少しずつ増えてきています。」というのはあまり無いんじゃないのかな？オペレータって基本的にはアウトソースでマニュアル対応をする部隊でしょ。ちょっと見てわかんないとか面倒とか思ったら即座に構築部隊にエスカレーションしてくるという印象が・・・。
会社として運用で儲かるから構築部門は利益をあげられず評価が低いという話であれば、それは営業判断として営業なり会社全体なりがフォローする話ですし、運用がどうだから構築はこうしなくちゃいけないとかってのは企画とか商品開発の部門がする話でしょう。金が出て要件が追加されてるとかなら構築部門の問題でしょうが、本来のサービス範囲外の要求をどこからのフォローも無くボランティアでやれってんなら、それを構築部門が必死こいて独断専行して積極的にやる理由はないように思えます。要件でこうしろってのに違う実装をするとかしたらそれこそ瑕疵になるでしょうし。
また、運用から、「イレギュラーな設計なのでこちらでは対応できませんから構築側で直接保守してください」とか言われた日には目も当てられないと個人的には思うんですが・・・。何らかのイレギュラーな設計になる提言をして、その結果、会社のプロダクトを逸脱する責任を構築部隊の一エンジニアが取れるのかと。まぁ、今回の事例ではそもそも一点物でしょうからそういう話にはならないとは思いますけども。
会社としての責任範囲がどうかというのは営業とか法務の判断する話ですよね。
それを踏まえて社内で決められている自部門の責任範囲を守り、自部門の責任範囲内の仕事を完璧にこなした上で会社内で構築部隊が評価されない。顧客に対するサービスの責任範囲に対して社内の責任範囲の分担では空白が出来、それが構築部隊の責任になるってんなら、その会社はそもそも会社として構築自体重視してないんじゃないかと。それで地位を脅かされるような会社は構築する人間にとっては碌な会社ではないので、早々に転職するなり運用の方に転向するなりした方が良いように思えるのですが・・・。
っていつの間にか部署間での評価の話になっちゃってますね。そんな話でしたっけ？
◆IZUMI162i6 [mailto]