脆弱性対応（Heartbleed）の責任の所在 東京地判令元.12.20（平29ワ6203） - IT・システム判例メモ
クレジットカード情報漏えい事故に関し，その原因の一つと考えられる脆弱性対応が運用保守業務に含まれていたか否かが争われた事例。 事案の概要 Xは，Xの運営する通販サイト（本件サイト）を第三者に開発委託し，運用していたが，その後，2013年1月ころまでに，Yに対し，本件サイトの運用業務を月額20万円で委託した（本件契約）。本件サイトはEC-CUBEで作られていた。なお，XからYへの業務委託に関し，契約書は作成されておらず，注文書には「本件サイトの運用，保守管理」「ＥＣ－ＣＵＢＥカスタマイズ」としか記載されていない。 2014年4月には，OpenSSL*1の脆弱性があることが公表されたが*2，本件サイトでは，OpenSSLが用いられていた。 2015年5月ころ，Xは，決済代行会社から本件サイトからXの顧客情報（クレジットカード情報を含む）が漏えいしている懸念があるとの連絡を受け（本件情報漏えい）
アジャイルと契約 / Agile Contracts
忙しい人向けダイジェストをこちらに用意しました。 https://www.agile-studio.jp/post/agile-contracts
つれづれなる技術屋日記: アジャイルだって偽装請負には留意
このサイトではWindowsやPMBOKなど、登録商標および商標を記載省略しています。以前の記事閲覧で、カレンダー経由「ページが見つかりません」になったら、”バックナンバー”経由で辿ってください。 少し旧聞の類だが、日経SYSTEM 2010年9月号のアジャイル特集で記載されていた「最近見たRFP(提案依頼書)の中に『開発はアジャイルで』と書かれていたことです」は、気になっていた。 RFPとか契約の類で具体的な表現をせずに、アジャイルと一括りに記載することって無いよな～というのが、率直な感想。ただし、実際のRFPでは具体的なプラクティスが記載されていたけど、紙面上ではぼかして記載したと考えられなくはない。（もしそうでも、アジャイルに興味ある読者を想定すれば、具体的に記載してあった方が良い。そこそこ浸透しだした昨今のことを考えれば。） で、最近つぶやきの類で目に止まったのは、アジャイルと契約
「情報システムの信頼性向上のための取引慣行・契約に関する研究会」～情報システム・モデル取引・契約書～
情報システムの信頼性 非機能要求グレード報告書 ソフトウェアメトリクスの高度化 産業構造・市場取引の可視化 「情報システムの信頼性向上のための取引慣行・契約に関する研究会」 ～情報システム・モデル取引・契約書～ 情報サービスソフトウェア産業における下請適正取引等の推進のためのガイドライン ADR（裁判外紛争解決手続） 情報システムにおける価値の可視化 「IT投資価値評価に関する調査研究」（試行版） 情報サービス・ソフトウェアを巡る取引構造・産業構造の不透明性が、ベンダ間、ユーザ・ベンダ間、ユーザ内に存在しております。 また、不透明な取引構造・産業構造は、ベンダの産業構造転換の遅れ、情報システムの信頼性問題の温存、ユーザ・ベンダ一体となった生産性向上の阻害の要因となっています。 このため、各局面の取引構造を透明化するツールを整備し、これらを普及することで、ベンダの産業構造転換、情報システム信
株式会社マジカジャパンの羽生章洋が書いてるブログ:契約のこと - livedoor Blog（ブログ）
先日、小室哲哉さんが逮捕されたという記事を見ました。自作の曲の権利を売るということでありながら、その権利を有していなかったということが問題になっているようです。この著作権に絡む問題は、実は私どものような業務システムを作っている商売でも非常に重要なことだったりします。 この契約書の内容ですが、基本的には「いつ・誰が・誰に・何を・どこに・どのように・何個・いくらで」納品するかということを明記しています。この「何を」が役務なのか具体的なブツ（成果物）なのかによって多少変わってきますが、大筋は納品に関することです。それに連動する形で対価のお支払い方法が記載されています。納品できなかった場合のペナルティなども併記されます。 さて、この契約書の中で役務ではない場合に、その成果物の取り扱いにおいて非常に重要なセクションがあります。それが「著作権に関すること」です。著作権者が誰になるのか。どのタイミングで
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
