タグ

関連タグで絞り込む (1)

タグの絞り込みを解除

裁判に関するino-agileのブックマーク (3)

  • 技術的に不可能でも、セキュリティ対策は万全にしろ!

    技術的に不可能でも、セキュリティ対策は万全にしろ!:「訴えてやる!」の前に読む IT訴訟 徹底解説(94)(1/3 ページ) 連載目次 遅ればせながら、新年明けましておめでとうございます。 長引くコロナ禍の中ではあるが、各種業務のIT化やインターネットなどを活用した新企画など、組織のDX(デジタルトランスフォーメーション)推進が加速し、ITに関わる仕事をされている方にはより一層の期待がかかっている。 テレワークでの共同作業や人員確保をはじめとしたさまざまな困難の克服を強いられるなど、日々苦労の絶えない方が多いかと思う。しかしこれを期に日DXが世界にキャッチアップし、新しい利益源の開拓やコスト削減などが進むことで、国や自治体、企業その他団体がこれまでにない力と柔軟さを手に入れることも可能かと思う。2022年が皆さまと皆さまの組織にとって、実りある1年となることをお祈り申し上げる。 今回は

    技術的に不可能でも、セキュリティ対策は万全にしろ!
    ino-agile
    ino-agile 2022/01/27
    『被告…が「善良なる管理者の注意義務違反」には当たらないと判断されたのは、NEMにその時点の技術レベルでは対策が行えない部分があることを「説明した」点にあり、「説明できた」点にある。』自己防衛って大事
  • やった分はお金ください。納品してないけど

    連載目次 中途解約でもお金はもらえる? 実施していたプロジェクトが何らかの理由で中止となったとき、発注者(ユーザー企業や元請け企業)は、受注者に対してどこまで支払うべきなのか。逆に受注者であるベンダーは、どこまで請求できるのか。ソフトウェア開発の場合、その解釈が曖昧になりやすく、だからこそ紛争に発展してしまうケースも少なくない。 請負契約の途中解除に関する条文としてよく取り上げられるのが、「民法641条」の「請負人が仕事を完成しない間は、注文者は、いつでも損害を賠償して契約の解除をすることができる」という条文だ。 これを素直に解釈すれば、発注者は契約を解除できるが、それには損害の賠償が必要ということになる。ただ、これに従って損害を賠償しようとしても、受注者の損害をどのように算定するのかまでは規定してはいない。そこは基的には発注者と受注者の間で取り交わされる契約で決めておくべき事柄なのだ。

    やった分はお金ください。納品してないけど
    ino-agile
    ino-agile 2020/11/05
    『契約書には、成果物や途中解約の定義について、第三者が見ても正しく理解できるように記述をしておくべき』最悪揉めても白黒つくようにしておくことで争いが避けれるものと気をつけます
  • 丸投げしたんだから、頑張ってくださいよ(作業量は増えたけどね)

    丸投げしたんだから、頑張ってくださいよ(作業量は増えたけどね):「訴えてやる!」の前に読む IT訴訟 徹底解説(67)(1/3 ページ) 下請けに丸投げした作業の工数が当初見積もりの6.4倍にまで増えてしまった。下請けの追加費用支払い要請に応じるか、契約を結び直すか――どうする、元請け! 連載目次 IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する連載。今回取り上げるのは、「元請けベンダーと下請けベンダーの間に起きた機能追加費用を巡る争い」だ。 昨今、問題視されることの多いソフトウェア開発における多重請負構造。ユーザー企業から発注を受けた元請けベンダー(以降、文中は「元請け」と表記)が作業の一部(あるいはほとんど!)を下請けベンダー(以降、文中は「下請け」と表記)に再委託することは、むしろ一般的といってもいいほど数多く存在する。 両者の間で作業の分担や支払い、不具合の責任など

    丸投げしたんだから、頑張ってくださいよ(作業量は増えたけどね)
    ino-agile
    ino-agile 2019/06/24
    当初0.33億に追加見積1.6億。中断した時点までの作業量を換算すると1.95億ということは追加見積後にも増えたのね
  • 1