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