タグ

細川義洋に関するmohnoのブックマーク (5)

  • 仕様書通りにシステムを作りました。使えなくても知りません

    仕様書通りにシステムを作りました。使えなくても知りません:「訴えてやる!」の前に読む IT訴訟 徹底解説(113)(1/3 ページ) ユーザー企業が作った仕様書に抜け漏れがあり、その通りに作ったシステムが使いものにならなかった。悪いのは、ベンダー、ユーザー企業、どちらなのか? 連載目次 IT訴訟を例に取り、トラブルの予防策と対処法を解説する連載。今回取り上げるのは、要件の不備についての裁判例である。ユーザーが示した要件に抜け漏れや誤りがあり、これに沿って構築したシステムはユーザーが来望んだ動作をしなかったというものだ。 ユーザーはこれを債務不履行であると訴えるが、ベンダーは「言われた通りに作っただけで、こちらには責任はない」と反論した。 この手の紛争について、裁判所の立場はおおむね一貫しているように思われ、似たような判断が各地で示されている。今回取り上げる判決はこうした考え方の大とな

    仕様書通りにシステムを作りました。使えなくても知りません
    mohno
    mohno 2024/03/06
    「裁判所は、もしユーザー企業の示す要件が誤っていても、契約の目的や一般的な常識に照らして誤りがあるのであれば、これを指摘し是正させるのはシステム開発の専門家であるベンダーの責任であるとした」←大変だな
  • ベンダー社員過労死の遠因はユーザー企業にもあるのか

    ベンダー社員過労死の遠因はユーザー企業にもあるのか:「訴えてやる!」の前に読む IT訴訟 徹底解説(111)(1/2 ページ) 仕様確定が遅れ、プログラム数が大幅に増え、スケジュールが2カ月以上遅れ、しかも納期順守を求められたプロジェクト。そこに従事するエンジニアがある日、遺体で見つかった――。 連載目次 IT業界でバブル景気が生き残っていた1990年代、ソフトウェアエンジニアの長時間残業は常態化していた。金融機関向けシステム開発に従事していた私も、月の残業が100時間を下ることがなかった。 もっともそんなのは序の口で、私の周囲には、土日もほとんど休まず平日も徹夜で、残業が200時間をはるかに超えるエンジニアもいた。こうした長時間労働が元で心身に異常を来し、残念ながら命を落としてしまう人もいた。IT業界ではこうしたことがままあり、連載でも以前、システムエンジニアの死をテーマにした記事を書

    ベンダー社員過労死の遠因はユーザー企業にもあるのか
    mohno
    mohno 2023/11/14
    余裕のある見積りと余裕のない見積りをもらって、後者に発注したら余裕がなくて間に合いませんってなったら、だったら前者に発注したかもしれないのに、って言われそうではある。/給食でも似たような話があったね。
  • 顧客も社員も奪われて、わしゃもう死んでしまいたい

    顧客も社員も奪われて、わしゃもう死んでしまいたい:「訴えてやる!」の前に読む IT訴訟 徹底解説(102)(1/3 ページ) 社員が同僚を全員引き連れて転職し、顧客も奪われてしまったために支社を閉鎖せざるを得なくなったソフトウェア開発企業。泣き寝入りするしかないのか? ないのか? ないのかー!? 連載目次 引き抜き、顧客奪取はIT業界の日常茶飯事? 私の知人は、脱サラしてITベンチャーを立ち上げ、順調に経営していた。しかしある日、信頼していた社員が他の社員を連れて退職し、顧客も奪われた。知人はその後会社を立て直すことができたが、当時は従業員も顧客もないが会社設立時の借金だけはあるという状態で、自殺すら考えたそうだ。 別の知人は、勤めていた小規模なITベンダーに不満を持ち、退職して起業する意志を示したところ、同僚数名が一緒にやりたいと退職し、前の会社で担当していた顧客も幾つか引き継いだそうだ

    顧客も社員も奪われて、わしゃもう死んでしまいたい
    mohno
    mohno 2022/09/07
    「そもそも本判決も「原告企業X側の主張には証拠がない」として排除されたものが多く、別の証拠があれば結果は違ったかもしれない」/揉めたくないものだなあ。
  • パッケージソフトだか何だか知りませんが、現行システムと同じの作ってくださいよ

    連載目次 IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する連載。今回は「要件の範囲がい違ったことにより生じた紛争」を解説する。 ユーザーが望む機能がシステム開発の要件から抜け落ちたがために発生する紛争は、連載でこれまでにも何度か取り上げてきた。 IT紛争の類型は種々さまざまであり、過去の判例が全てそのまま適用できるわけではないが、裁判所が「たとえ要件としてユーザーから明示されていなくても、その機能が契約の目的を果たす上で、当然に必要な事柄であるとベンダーが認識し得る状態にあれば、ベンダーにはその機能を作り込む義務(債務)がある」と判断した例が幾つもある。 要件定義書よりも契約の目的の方が重いとする考え方だ。 今回取り上げる判例も、「ユーザーが必要と考える機能が、ベンダーの作成した要件定義書から抜け落ちており、これを作り込まなかった」というものだ。これまでと少し異なるのは、パ

    パッケージソフトだか何だか知りませんが、現行システムと同じの作ってくださいよ
    mohno
    mohno 2019/05/08
    「今と同じもの?いいですよ、今の仕様を全部屏風から出してください:-p」
  • 俺、コンサルタント。準委任だから品質には責任持ちません

    俺、コンサルタント。準委任だから品質には責任持ちません:「訴えてやる!」の前に読む IT訴訟 徹底解説(61)(1/3 ページ) コンサルティング会社が作った要件にヌケ漏れがあった。責任を取るのは、開発会社か、コンサルティング会社か、それともユーザー企業か?――IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防と対策法を解説する人気連載。今回のテーマは「コンサルティングの義務」だ。 連載目次 謹んで新年のお祝いを申し上げます。 いよいよ平成最後の年となるが、この30年間、オンプレの汎用機システムがクラウドやスマホアプリに変わり、ウオーターフォールがアジャイルになっても、IT紛争の類型に限っては相変わらず要件定義やプロジェクト管理の問題が取り上げられる。それでも、連載などを参考に、毎年少しずつでもIT導入に関わるプロセスを改善させ、その成功率を少しでも高めていただきたい。そんなこ

    俺、コンサルタント。準委任だから品質には責任持ちません
    mohno
    mohno 2019/01/07
    「既存のシステムに具備され、新しいシステムでも特に不要と判断されていない機能を、要件定義書に記されていないことを理由にベンダーが実装しなかったために、システムが完成したと認められなかった判例がある」
  • 1