準委任契約だけど、責任は取ってください
連載目次 準委任契約と請負契約 今回は、システム開発の要件定義工程の契約形態についてお話しする。 本連載の読者ならご存じの方も多いと思うが、情報システムの開発は、準委任契約に基づいて行われる場合か請負契約に基づいて行われる場合が多い。そして1つの開発においても、要件定義工程は「ユーザーの作業を支援する」という意味合いで、成果物の完成責任を負わない準委任契約で、設計以降の工程（ここでは便宜的に「開発工程」と呼ぶ）は「ベンダーが主体となる」ために成果物の完成責任を伴う請負契約で行う場合がよくある。準委任契約は、「専門的知識やスキルを持つ人間が契約で合意した時間働けば、その対価は払ってもらえる」というのが原則である。 では、専門家が一定時間働きさえすれば責任を果たしたことになるのだろうか。 今回取り上げる事件は、ITベンダーが要件定義工程から開発工程までを一貫して行ったが、要件定義に抜け漏れがあ
フランスで増える“脱税プール” 国税局が導入した「マルサAI」活躍の裏側
フランスで増える“脱税プール” 国税局が導入した「マルサAI」活躍の裏側：ウィズコロナ時代のテクノロジー（1/2 ページ） いわゆる「第7波」の終息が見えてきたものの、いまだにCOVID-19のパンデミックから完全に抜け切れたとはいえない日本。経済への悪影響もさまざまな形で現れているが、意外なことに、日本の一般会計の税収は2年連続で過去最高を記録している。 理由については、政府のコロナ対策による支出の効果や、コロナ禍で逆に売り上げを伸ばした企業の存在、フリーランスや副業など新たな働き方の普及とさまざまな要因が挙げられている。いずれにせよ、パンデミックのように異常な状況下においては、さまざまな想定外の出来事が起きることを示しているといえよう。 実は日本だけでなく、フランスでも同様の事態が起きている。フランスでは、パンデミックの影響で意外な形の税収入が新たに生まれているという。そしてそこには、
仕様は確認しないし、運用テストもしません 全部出来上がってから確認します
連載目次 ソフトウェア開発における「ベンダーの専門家責任」は、恐らくベンダーが考える以上に重い。 開発失敗の責任を争う裁判では、ユーザー企業の不作為や非協力、非見識でさえも「ベンダーがITの専門家としてユーザー企業をリードしなかったためだ」と厳しい判断を下されることもある。本連載でごく初期に取り上げた平成16年3月10日の裁判は、ユーザー企業が要件変更を繰り返してプロジェクトが破綻してしまった責任を、「ユーザー企業の要望を断ったり、追加見積もりをしたりするなどして、プロジェクトの安全を図らなかったためだ」としてベンダーに負わせる判決が下され、当時私も末席を汚していた東京地裁のIT調停委員の間で話題になった。 無論、全てのプロジェクト破綻の責がベンダーにあるというわけではなく、ユーザー企業がしかるべき時期に必要な判断を下さない、必要な情報提供を行わないなどがあれば、「ユーザーの協力義務違反」
アジャイル開発を外部委託するときの契約事項をまとめた「情報システム・モデル取引・契約書」を改訂 IPA
情報処理推進機構（IPA）は2021年10月6日、アジャイル開発版「情報システム・モデル取引・契約書」を改訂した。厚生労働省が同年9月21日に公表した「『労働者派遣事業と請負により行われる事業との区分に関する基準』（37号告示）に関する疑義応答集（第3集）」に関する情報を追加した。これに伴い、「アジャイル開発外部委託モデル契約（解説付き）」も更新した。 アジャイル開発版情報システム・モデル取引・契約書は、IPAが設置した「モデル取引・契約書見直し検討部会」と「DX対応モデル契約見直し検討WG」で検討された、アジャイル開発を外部委託する際のモデル契約についてまとめたもの。アジャイル開発を外部委託する際の契約条項とその解説、補足資料で構成されている。 発注者の意見が反映されるアジャイル開発は偽装請負になる？ 改訂の基になった「労働者派遣事業と請負により行われる事業との区分に関する基準」（37号
製造工程に入ってるけど、やっぱこの機能も追加してくださーい
製造工程に入ってるけど、やっぱこの機能も追加してくださーい：「訴えてやる！」の前に読む IT訴訟 徹底解説（91）（1/3 ページ） 連載目次 IT開発を巡る裁判では、システムの要件――ベンダーがどのような機能をどこまで作るのか――についての争いの割合がかなり高い。本連載でも、そうした裁判の例を幾つも解説してきた。 ユーザー企業の「この機能を作ってくれるはずではなかったのか」というクレームに、ベンダーが「そんなことは約束していない」と反論をする。まさにIT訴訟の定番ともいうべきケースだ。アジャイル開発の割合が増えて開発中でもユーザーの要望を取り入れやすくなったといわれる今でも、こうした争いは後を絶たない。 今回取り上げるのも、「システムの要件の範囲」あるいは「契約の範囲」を巡る裁判だ。 簡単に説明すると、要件定義から開発までの全てを単一のベンダーが請負契約で行った。詳細設計中に要件の変更が
逆転敗訴した野村情シスがIBMに送った悲痛なメール、横暴なユーザーを抑えきれず
委託したシステム開発が頓挫したとして、野村ホールディングス（HD）と野村証券が日本IBMを相手取って計約36億円の損害賠償を求めた裁判。プロジェクト失敗はベンダー側に非があるとした2019年3月の一審判決から一転、2021年4月の控訴審判決はユーザー企業側に責任があるとした。工数削減提案に十分に応じなかったり、プロジェクト途中で追加要件を多発したりした野村側の姿勢を東京高裁は問題視し、逆転敗訴の判決を下した。 関連記事 野村HDが日本IBMに逆転敗訴の深層、裁判所が問題視した「X氏」の横暴な変更要求 野村HDが日本IBMに逆転敗訴のワケ、「工数削減に応じず変更要求を多発」と指摘 東京高裁が特に問題視したのが、システムの仕様を策定するうえで重要な役割を担っていた野村証券のユーザー部門「X氏」の振る舞いだ。 当時、投資顧問事業部（判決文では「投資顧問部」）の次長だったX氏は、パッケージソフトに
野村HDが日本IBMに逆転敗訴の深層、裁判所が問題視した「X氏」の横暴な変更要求
システム開発が頓挫したとして、野村ホールディングス（HD）と野村証券が日本IBMを相手取り計約36億円の損害賠償を求めた裁判。2019年3月の一審判決では日本IBMに約16億円の支払いを命じたが、東京高裁は2021年4月21日の控訴審判決で野村側の請求を棄却した。逆に野村側に未払いの業務委託料など約1億円の支払いを命じた。なぜ一審判決が覆され、野村2社の逆転敗訴となったのか。裁判記録を基に、控訴審判決の経緯を読み解く。 名門企業同士による泥沼の裁判に発展したシステム開発プロジェクトの始まりは2010年に遡る。判決文の事実認定によると、野村証券は当時、老朽化した基幹システムを2013年までに全面刷新する計画を進めていた。併せてシステム開発を野村総合研究所（NRI）に依存する体制からの脱却を狙っていた。野村証券のオフィスに常駐していた日本IBMの社員はこの動きを察知。野村証券に食い込むチャンス
脆弱性対応（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の顧客情報（クレジットカード情報を含む）が漏えいしている懸念があるとの連絡を受け（本件情報漏えい）
［スクープ］127億円の賠償求めるシステム裁判、三菱食品がインテックを訴えた理由
食品卸最大手の三菱食品がシステム開発の失敗を巡り発注先のインテックを提訴した事件の全貌が、2019年3月4日までに日経 xTECHの独自取材で判明した。原因はビジネスルール管理システム（BRMS）を利用したEDI（電子データ交換）システムの構築失敗にあった。 損害賠償請求額は127億円と、勘定系システムの開発失敗を巡るスルガ銀行と日本IBMの裁判の当初請求額を上回る。巨額裁判の行方は、発注側のユーザー企業と受注側のITベンダー双方の注目を集めそうだ。 インテックの親会社のTISが2019年2月4日に発表した2019年3月期第3四半期決算で、インテックが受託したシステム開発業務に関して三菱食品から127億円の損害賠償請求訴訟を受け、係争中だと公表していた。だが、係争の対象システムや損害賠償額の算出根拠、三菱食品の主張などは不明だった。日経 xTECHの取材により、システム開発が失敗した経緯や
サーバ事業者さん。契約は結んでいませんが、あなたを訴えます
サーバ事業者さん。契約は結んでいませんが、あなたを訴えます：「訴えてやる！」の前に読む IT訴訟 徹底解説（55）（1/3 ページ） クラウドサービスベンダーに預けたプログラムが、HDDの故障で消失した。「さあ、訴えてやる！」。でも、誰を？――IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防と対策法を解説する人気連載。今回は「クラウド上のデータの責任の所在」を考える。 連載目次 IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防と対策法を解説する本連載、今回は「ホスティング業者が預かったデータの消失」にまつわる紛争を解説する。 データの消失による紛争は珍しくない 近年、クラウドコンピューティングが企業ITの主役の座を奪った感がある。自社内に置いていた各種のシステムをセールスフォースやAWSなどのサービスに置き換える企業が多くなっている。 クラウドサービスを使うコストメ
HTMLに著作権なんてあるわけないでしょ
連載目次 IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防と対策法を解説する本連載、今回は「著作権」を考察する。 著作権については、過去にも本連載で「プログラムや設計書、画面デザインなどが著作権法で定める著作物として認められるためには、作成者独自の工夫や創意が必須である」と解説した。 今回はこの著作物の定義について、より分かりやすい判例を紹介する。あるユーザー企業（以降、ユーザー）がベンダーに依頼して作成したHTMLが著作物に当たるかどうかを争った裁判だ。 HTMLファイルに著作権は認められるのか HTMLファイルは、作成者が一生懸命に頭を悩ませて作り上げるものであり、全く同じものは他には存在しない。 その一方、他のプログラミング言語に比べると使用する単語や文法が限定的であり、誰が作っても同じようなものになりやすい。これを「著作物」としてしまうと、HTMLの作成者は、何を書いて
なぜNTT東日本は旭川医科大学に逆転勝訴できたのか。判決文から分かる教訓 | STORIA法律事務所
▼ 旭川医科大学による訴訟提起 旭川医科大学は平成２３年３月１６日に旭川地裁に訴訟を提起しました。 旭川医科大学は、ＮＴＴ東日本に対し、新システム導入失敗に伴う逸失利益として約１９億４０００万円を請求し、他方、ＮＴＴ東日本は、旭川医科大学に対し、不当な受領拒絶でリース料を受け取れなくなったとして約２２億８０００万円を請求しました。 ▼ 地裁判決（旭川地判平成２８年３月２９日） 旭川地裁は、ユーザ・ベンダの過失割合を２：８（ユーザ：ベンダ）としたうえでユーザ・ベンダの両請求とも一部認容し、実質、旭川医科大学からNTT東日本へ約１８００万円の支払いを命じる判決をしました。 双方ともに控訴をし、舞台は札幌高裁に移りました。 ▼ 高裁判決（札幌高判平成２９年８月３１日） 札幌高裁は、ユーザ・ベンダの過失割合を１０：０（ユーザ：ベンダ）に変更した上で、ベンダの請求を認容、ユーザの請求を棄却し、旭川医
契約書を巡るシステム開発トラブルが多発、民法改正も踏まえ条文の精査を
システム開発に当たり、ユーザー企業とITベンダーが交わす契約書。その条文の解釈を巡るトラブルが絶えない。大手ベンダーが用意した契約書だからとよく読まずに契約するのは禁物。法律の改正も踏まえ、公正な契約を結ぶ努力が欠かせない。 契約書の条文に関わるシステム開発のトラブルが近年、増えている。契約書の条文についての認識や解釈の違いから、ユーザー企業とITベンダーが対立し、訴訟に至るケースも多い。 数十年前のシステム開発案件では、ITベンダーとユーザー企業が契約書を取り交わさず、提案書と注文書を交わしただけで開発がスタートすることもあった。 現在のシステム開発では、さすがに契約書を取り交わすのが当たり前になっている。これは経済産業省や業界団体がシステム開発取引の健全化を図った成果といえる。 だが、契約書の存在がユーザー企業に不利益をもたらすケースもある。今回は大手国内ベンダーが作った契約書を十分に
ソフトウエアのバグは重過失か、みずほ証券・東証システム裁判の争点
みずほ証券が東京証券取引所（東証）に対して約415億円の損害賠償を求める訴訟を起こしたのは、2006年10月27日のこと。そのきっかけは、みずほ証券が2005年12月8日にジェイコム株を誤発注したことだった。誤発注の直後に取消注文を出したにもかかわらず、東証が運営するITシステムのバグによって損失が拡大したとして、みずほ証券は売却損とその他諸費用の賠償を東証に求めた。 それから10年近くたち、2015年9月3日に終結。東証に約107億円の支払いを命じた東京高等裁判所の判決が確定している。 ソフトウエアのバグは重過失に当たるのか――。争点はこれである。裁判の行方を最初に詳しく報じたのは、日経コンピュータ2007年4月30日号の記事「誤発注裁判で見えてきた不具合の真相」（大和田 尚孝＝日経コンピュータ）。その内容を全文公開しよう。 運用テスト工程で追加した条件分岐の記述ミスの可能性が高いーー。
関係が泥沼化、京都市が7億5000万円請求するもIT企業は支払い拒否
京都市が進めていたシステム刷新の稼働が遅延している件で、京都市とシステム開発を受託したシステムズ（東京・品川）の関係が泥沼化している。京都市は開発遅延の責任を巡って2017年10月12日、システムズに対して10月27日までに約7億5000万円の損害賠償を支払うことを求めていた。ところがシステムズはこの支払いに応じなかったことが、日経コンピュータの取材で分かった。京都市とシステムズともに、訴訟に発展する可能性を否定していない。 京都市の情報システム部門に相当する総合企画局情報化推進室は2014年から81億円を投じて、基幹系システムの刷新プロジェクトを進めてきた。この基幹系システムは、国民健康保険や介護保険といった福祉系のほか、徴税、住民基本台帳の管理など18業務を担うもの。NEC製メインフレーム上にCOBOLプログラムで構築したシステムで、稼働後約30年が経過している。 福祉系のオンラインシ
Activisionがゲーム内アイテムの購入を促す技術の特許を取得。マルチプレイのマッチングを操作し、プレイヤーの潜在意識に働きかける - AUTOMATON
ホーム ニュース Activisionがゲーム内アイテムの購入を促す技術の特許を取得。マルチプレイのマッチングを操作し、プレイヤーの潜在意識に働きかける アメリカの大手パブリッシャーActivisionが、US Patent and Trademark Office（米国特許商標庁）に2015年に出願していたある特許が、今月17日に登録されていたことが明らかになった。海外メディアRolling Stone/Glixelなどが報じている。 その特許は「System and method for driving microtransactions in multiplayer video games」としており、翻訳すると「ビデオゲームのマルチプレイにおいてマイクロトランザクション（少額決済）の利用を促進するためのシステムや手法」となる。それは、マルチプレイのマッチングシステムに「マイクロトラ
失敗の全責任はユーザー側に、旭川医大とNTT東の裁判で逆転判決
電子カルテを中核とする病院情報管理システムの開発が失敗した責任を巡り、旭川医科大学とNTT東日本が争っていた訴訟の控訴審判決は一審判決を覆す内容だった。 札幌高等裁判所は2017年8月31日、旭川医大に約14億1500万円を支払うように命じた。2016年3月の一審判決は旭川医大の過失割合が2割、NTT東が同8割として双方に賠償を命じていたが一転、旭川医大に100％の責任があるとした。同医大は2017年9月14日、判決を不服として最高裁に上告した。 なぜ判決が覆ったのか、裁判資料かと判決文から見ていく。旭川医大とNTT東は日経コンピュータの取材に「コメントできない」と回答した。 高裁もユーザーの義務違反を認定 旭川医大は2008年8月に病院情報管理システムの刷新を企画し、要求仕様書を基に入札を実施。NTT東が落札した。日本IBMと共同開発したパッケージソフトをカスタマイズし、6年リースで提供
文科省、教員処分歴の全国での共有を目指す | スラド
懲戒処分を受けた教員が退職後、他の都道府県などで再雇用されて再びトラブルを起こす、といった事例がたびたび起こっている。たとえば8月には愛知県で教え子にわいせつな行為をしたとして小学校の臨時講師が逮捕される事件があった。この講師は過去に埼玉県で児童買春・ポルノ禁止法違反で逮捕され懲戒処分を受けていたが、その後改名し逮捕歴を伏せた履歴書を提出して採用されていたという（中日新聞）。 こういった問題は、処分情報が都道府県間で共有されていないことが原因とのことで、文部科学省は教員免許管理システムを刷新しこの問題への対処を盛り込むという（朝日新聞、読売新聞）。 ただ、このシステムで検索できるのは免許失効のみで、停職などの処分については共有できないとのこと。そのため、採用時に処分歴の証明書を提出させる制度も導入するという。
改正民法が成立、「瑕疵担保責任」などシステム開発契約に影響大 | 日経 xTECH（クロステック）
物品の売買や契約のルールなど「債権」に関する民法の改正案が2017年5月26日、参議院本会議で可決・成立した。公布から3年以内に施行される。 民法の改正はITに関する契約に様々な影響をもたらす。システム開発委託時の契約内容や、その際に発生するユーザー企業とITベンダーの責任範囲などが変わる。 改正民法の変更点の一つが「瑕疵担保責任」をめぐる条文だ。民法634条から640条で規定されていたが、改正法では削除。代わりに（契約に対する）「不適合」という言葉を用いて同様の責任を求めている。 責任の内容も変更点がある。その一つがシステム完成後に見つかった欠陥の修正期限に関するもの。ユーザー企業はITベンダーから引き渡されてから1年以内に修正を求める必要があったが、改正法では欠陥に気付いてから1年以内にITベンダーに通知すれば、通知後5年以内は修正や報酬の減額などを求められるとしている。 外部の技術者
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
年金機構の委託先が無断で海外再委託、約95.2万人分入力ミス
