「*[法律]」の検索結果を表示しています
2017-05-31 23:21

個人情報・パーソナルデータに関すること(28)第三者提供履歴の開示請求

昨日,平成29年5月30日に,平成27年改正個人情報保護法が全面施行された。改正の範囲は幅広く,実務への影響は少なくないが,トレーサビリティに関する義務の新設と,開示請求権等に関する変更に跨る論点について考えてみる。


設例

あるユーザから次のような問い合わせがあったとしよう。

私は,御社のサービスを利用しています。利用規約を改めて見たところ,規約には「利用者は,当社が取得した個人情報を第三者に提供することにつき,あらかじめ同意します。」と書いてありました。

ところで,改正された個人情報保護法のもとでは,第三者に個人情報*1を提供する場合,記録を残さなければならないとなっていたかと思います。私の個人情報が,いつ,誰に提供されたのか,開示してください。


このような要求をされた場合,果たして事業者は従わなければならないだろうか。


論点

まず,改正法(以下,単純に「法」という。)28条1項では,本人は,個人情報取扱事業者に対し,当該本人が識別される「保有個人データ」の開示を請求することができるとされている。個人情報取扱事業者は,この請求がなされたときは,遅滞なく開示しなければならないのが原則である(同条2項)。そして,この請求に対して応答しなかったり,請求を拒絶したりした場合には,訴訟を提起して開示を求めることができることが明文化された(34条1項)。


そうすると,仮にこの事業者が改正法を遵守して,「第三者提供に係る記録」を作成して保存していた場合,その記録自体が「保有個人データ」に当たれば(【論点1】),原則として開示しなければならないことになる。


仮に保有個人データに該当した場合でも,事業者は28条2項但書各号,特に「業務の適正な実施に著しい支障を及ぼすおそれがある」(2号)には開示を拒絶できる。果たして,第三者提供の相手方やタイミングなどを開示することが,業務の適正な実施に著しい支障を及ぼすといえるか(【論点2】)。


ちなみに,改正法施行前でも,第三者提供の際には本人の同意が必要とされていたが(23条1項),同意を得るに際して,提供先や提供時期までも必要とはされていなかった*2。また,記録義務は課されていなかったから,上記のような請求を受けて,「記録はありません」「提供先をお伝えすることはできません」と回答したとしても特に何の問題もなかっただろう。


【論点1】第三者提供に係る記録の個人データ該当性

開示請求権の対象となる「保有個人データ」の定義は2条7項に定められている。大雑把にいえば,個人情報取扱事業者にとって開示等をおこなうことができる権限を有する個人データをいうので,問題となるのは,第三者提供に係る記録が「個人データ」に該当するかどうかである。


個人データの定義は2条6項に定められている。個人情報データベース等(2条4項に定義されている。)を構成する個人情報をいう。


個人情報の定義は2条1項にある。大雑把にいえば,特定の個人を識別することができる情報である。では,第三者提供に係る記録が,特定の個人を識別できる状態になった情報だろうか。そもそも,トレーサビリティ義務として求められる記録事項にはどんなものがあるのか。この設例では,利用規約で同意を得て提供しているが,その場合の記録事項は以下のとおりである(法25条1項,規則13条1項2号ロ,同項1号)。

なお,オプトアウトによる第三者提供の場合と異なり,同意を得て提供する際には,提供年月日を記録する義務はない。


ここでポイントとなるのは,「当該本人を特定するに足りる事項」(規則13条1項1号ハ)が記録事項に含まれていることである。ガイドライン(確認記録義務編)21頁では,例として,

本人ごとに番号・ID などを付して個人データの管理をしている場合において、当該番号・ID などにより本人を特定できるときの当該番号・ID

が挙げられている。さらには,実際に提供したデータ自体にこうした特定するに足りる事項が含まれていれば,そのデータを保存することを以って記録義務を履行したとされている(同頁)。


これらの記載からすると,まさに本人を特定する情報を記録せよとされていることから,「第三者提供に係る記録」は,そこに含まれる本人特定情報によって,特定の個人を識別できることになり,全体が個人情報,個人データ,保有個人データに該当する可能性が高いと思われる(記録保存義務を考えると,個人データの保管期間による除外(法2条7項,政令5条)によって保有個人データ該当性を否定することは難しいだろう。)。


こうした面から見ても,この確認記録義務は,事業者に過度な負担を強いるものになりかねないなと思う。せめて記録事項として,本人特定事項までは含めず,「過去1か月以内に当サービスを1度以上利用したユーザ」といった方法でも許されるようにしておけばよかったし*3,その程度の記録でも,トレーサビリティを確保するという趣旨に反するものでもないように思う。


保有個人データに該当しないという理屈付けとしては,例えば,第三者提供に係る記録は,単なるログのようなものであって,特定の個人情報を検索することができるように体系的に構成したものではないから,「個人情報データベース等」に当たらず,個人データでもないということが考えられるかもしれない。しかし,たとえテキストファイルだとしても,法令に定める記録事項がわかるようなフォーマットで作成されていれば,体系的に構成したものだと言えそうな気がするので,やや苦しい*4


【論点2】開示拒絶事由該当性

設例のようなユーザの開示要求に対して,第三者提供に係る記録から,該当する記録を探し出して開示するというのが事業者にとって負担がかかることは間違いない。また,もともと同意の際に第三者提供の提供先を明示する義務がないのに,提供先を開示していたのでは「業務の適正な実施に著しい支障を及ぼす」(28条2項2号)に該当すると言えなくないだろうか。


この拒絶事由については十分な議論の蓄積があるとはいえない*5ガイドライン(通則編)65頁でも,入試の採点情報とか,同一人からの繰り返しの要求の場合とか,「著しい支障」が明らかと思われる例しか示されていない。


仮に,この理由を以って拒絶した場合,「トレーサビリティの確保という趣旨からすれば,まさに今回のような本人からの請求の際に記録を開示すべきだ。」との反論が来るかもしれない。また,本人が第三者提供停止請求(30条3項)をするためには,まずどんな第三者提供が行われているのかを知る必要があり,第三者提供の記録を知らせるという必要性も一定程度ありそうである。しかし,25条,26条の確認記録義務は,直接的に本人を保護することを目的とした規定ではない(法の究極目的が本人保護にあるとしても。)。確認記録義務の履行だけでも大変な上に,本人からの請求に応じて,記録の該当部分の開示請求に対応できるようにしておかなければならないとなれば,まさにそれこそ「著しい支障」が生じるとも言えそうである(ただ,開示請求に対して実費請求をすることは否定されていないので(法33条),手間がかかるというだけでは説得力に欠ける気もする。)。


確認記録義務の設計の際には,記録が保有個人データになり得て,それが開示等請求の対象になるやもしれないということについて議論がされていたのだろうか。。

*1:正確には「個人データ」(法25条1項)

*2:ここは,異なる考えもあり得るところだが,改正法のもとでも,23条1項の同意を得るにあたり,提供先の名称を明示することまでは求められていないとされている(ガイドラインに関するQ&A5-9参照)。

*3:こうした記載では,ガイドライン(確認記録義務編)21頁に照らすとNGだろう。

*4:ログであってもIDによって整理されていれば,個人情報データベース等にあたるとする記載は,ガイドライン(通則編)17頁

*5:改正法の施行後に,事業者が28条2項2号を理由にバンバン拒絶し,たくさんの訴訟が提起されれば,裁判所の判断も蓄積されて,基準が見えていくのだろうが。

2017-05-10 23:54

プロジェクトマネジメント義務を考える(1)

システム開発紛争における近時のキーワードは,「プロジェクトマネジメント義務」である。


訴訟を初めてとして,システム開発に関する紛争案件を日々,多く担当しているが,「(ベンダは)プロジェクトマネジメント義務を履行していない」といったユーザの主張をよく見る。もちろん,自分がユーザを代理する場合でも,そういった主張をすることがある。


システム開発に関して弁護士や法務担当者が「プロジェクトマネジメント」(以下「PM」)という言葉を使うようになったのは最近のことだが,システム開発の現場では,かなり昔から普通に使われていた。これが,PMをしっかり果たさないと,法律上の責任が生じる場合があるということで,法務の世界においても注目されるようになってくると同時に,現場への重みも増すこととなった。


しかし,PM義務の内容は,まったく確立した考え方があるわけではない。ケースによって,違反を主張する側の当事者によって,その内容が異なる。


例えば,「プロジェクトマネージメント義務」という用語が最初に判決文に登場したとされる東京地判平16.3.10判タ1211-129では,

Yは、納入期限までに本件電算システムを完成させるように、本件電算システム開発契約の契約書及び本件電算システム提案書において提示した開発手順や開発手法、作業工程等に従って開発作業を進めるとともに、常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切に対処すべき義務を負うものと解すべきである。そして、システム開発は注文者と打合せを重ねて、その意向を踏まえながら行うものであるから』は、注文者であるXのシステム開発へのかかわりについても、適切に管理し、システム開発について専門的知識を有しないXによって開発作業を阻害する行為がされることのないようXに働きかける義務(以下、これらの義務を「プロジェクトマネージメント義務」という。)を負っていた

とされ,その具体的内容として

Xのシステム開発へのかかわりについての管理に関して、より具体的に説明すれば』は『における意思決定が必要な事項や『において解決すべき必要のある懸案事項等について、具体的に課題及び期限を示し、決定等が行われない場合に生ずる支障、複数の選択肢から一つを選択すべき場合には、それらの利害得失等を示した上で、必要な時期までにXがこれを決定ないし解決することができるように導くべき義務を負い、また『がシステム機能の追加や変更の要求等をした場合で、当該要求が委託料や納入期限、他の機能の内容等に影響を及ぼすものであった場合等に『に対し適時その旨説明して、要求の撤回や追加の委託料の負担、納入期限の延期等を求めるなどすべき義務を負っていた

と述べている。もちろん,民法その他の法律上で定められた義務でもなく,契約当事者間で明確に合意された形跡もない。


そして,PM義務が注目されたのは,スルガ銀行vs日本IBM事件控訴審判決(東京高判平25.9.26)である。

IBMは,前記各契約に基づき,本件システム開発を担うベンダとして,スルガに対し,本件システム開発過程において,適宜得られた情報を集約・分析して,ベンダとして通常求められる専門的知見を用いてシステム構築を進め,ユーザーであるスルガに必要な説明を行い,その了解を得ながら,適宜必要とされる修正,調整等を行いつつ,本件システム完成に向けた作業を行うこと(プロジェクト・マネジメント)を適切に行うべき義務を負うものというべきである。

「プロジェクトマネージメント義務」とダイレクトに書いていた前掲平成16年判決と異なり,「『プロジェクト・マネジメント』を適切に行うべき義務」という表現になっている。


具体的な義務内容はいろいろ書かれているが一部を引用する。

IBMは,スルガと本件最終合意を締結し,本件システム開発を推進する方針を選択する以上,スルガに対し,ベンダとしての知識・経験,本件システムに関する状況の分析等に基づき,開発費用,開発スコープ及び開発期間のいずれか,あるいはその全部を抜本的に見直す必要があることについて説明し,適切な見直しを行わなければ,本件システム開発を進めることができないこと,その結果,従来の投入費用,更には今後の費用が無駄になることがあることを具体的に説明し,ユーザーであるスルガの適切な判断を促す義務があったというべきである。また,本件最終合意は,前記のような局面において締結されたものであるから,IBMは,ベンダとして,この段階以降の本件システム開発の推進を図り,開発進行上の危機を回避するための適時適切な説明と提言をし,仮に回避し得ない場合には本件システム開発の中止をも提言する義務があったというべきである。

特に最後の「中止をも提言する義務」という表現が衝撃的だったため,ベンダにそこまでの義務を負わせてよいものか,という議論も生じた。この事案でも,上記のような義務が明示的な合意に基づいて生じたものではなかったし,そもそもなぜそのような義務が生じるのか,ということについては明らかになっていない。


その後も,「PM義務」という用語を用いていなくても,

システムの開発過程においては、ユーザ側から、本来ベンダが開発義務を負うものではない項目について開発(カスタマイズ)が要望されることはしばしばみられる事態である。そうすると、システム開発の専門業者であるYとしては、納期までに本件システムが完成するよう、Xからの開発要望に対しても、自らの処理能力や予定された開発期間を勘案して、これを受け入れて開発するのか、代替案を示したり運用の変更を提案するなどしてXに開発要望を取り下げさせるなどの適切な対応を採って、開発の遅滞を招かないようにすべきであった

旭川地判平28.3.29


Yは,自らが有する専門的知識と経験に基づき,本件システム開発に係る契約の付随義務として,(略)本件プロジェクトのような,パッケージソフトを使用したERPシステム構築プロジェクトを遂行しそれを成功させる過程においてあり得る隘路やその突破方法に関する情報及びノウハウを有すべき者として,常に本件プロジェクト全体の進捗状況を把握し,開発作業を阻害する要因の発見に努め,これに適切に対処すべき義務を負うものと解すべきである。そして,システム開発は開発業者と注文者とが協働して打合せを重ね注文者の意向を踏まえながら進めるべきものであるから,Yは,注文者であるXの本件システム開発へのかかわりなどについても,適切に配意し,パッケージソフトを使用したERPシステム構築プロジェクトについては初めての経験であって専門的知識を有しないXにおいて開発作業を阻害する要因が発生していることが窺われる場合には,そのような事態が本格化しないように予防し,本格化してしまった場合にはその対応策を積極的に提示する義務を負っていた

東京地判平28.4.28


など,類似の内容の義務をベンダに負わせる判断が続いている。いずれの事例においても,契約書にそのような義務が書かれていた形跡はない。


これらの裁判例をベンダの立場からみれば,結果的にシステムの開発が失敗した場合において,「ベンダとして十分な対応ができなかったこと」を取り上げて,そのような義務を契約上負っていたことにされ,その義務が履行されていないと主張され,結果的に債務不履行あるいは不法行為上の責任を負わされるというのでは,余りにも予測可能性を欠くことになってしまうという懸念を抱くことになろう。何より,プロジェクト実施中は,義務の内容がはっきりしていないから,「これをやって,記録を残しておけば大丈夫」という行為規範が存在しないことになる。


一方で,ユーザの立場で見てみても,ベンダが負うべき義務を措定しても,そのような義務を負っていたわけではないと一蹴されるリスクがある。


義務の内容が不確定で,予測可能性が低いとなれば,訴訟の長期化を招くことにもなって,どちらにとってもいいことはない。


そこで,PM義務に関しては,


(1)そもそも,PM義務という法律上も契約上も明らかでない概念を使う必要があるのか。(善管注意義務とか,単なる履行遅滞,帰責性などの議論で足りないのか)

(2)PM義務はベンダが負うものなのか。共同プロジェクトであれば,双方が等しく(あるいは分担して)負っているのではないか。現在のような「ベンダのPM義務」という考え方は実務の実態に合っているのか。

(3)契約上,義務内容を明確にすることで,予測可能性を高められるか。契約書に書くとしたらどういうことを書くべきか。

(4)マルチベンダプロジェクトにおけるPM義務は誰が負うことになるのか。

(5)ユーザがPMO(プロジェクトマネジメントオフィス)をコンサル会社などの外部に委託した場合,ユーザ・ベンダ・コンサル三者の義務の範囲はどうなるのか。

(6)ベンダがPMOを開発業務とは別の契約で受託していた場合,義務は加重されるのか。

(7)開発方法論(ウォーターフォールアジャイル等)や,システム構成(カスタムメイド,パッケージ等)によってPM義務の内容は変わるか。

(8)ユーザの力量(企業規模,システム部門の有無,システム開発経験の有無)によってPM義務の内容は変わるか。

(9)多重請負構造となっている場合,プライムのベンダと,サブコンとなったベンダの間では,PM責任はどのように分配されるのか。

(10)ユーザが負うとされる協力義務とベンダのPM義務とでは何がどう違うのか。

(11)PM義務あるいは協力義務は,契約上の付随義務だとされることが多いが,これを怠った場合に解除原因となるか。

(12)義務履行あるいは義務違反を立証するのにどんな証拠があればよいのか。


などの多数の疑問が湧く。


こうした疑問についてツラツラと考えてきたことをブログでまとめていこうというのが,このシリーズの主題である(最後までたどり着くかどうか)。

2017-03-27 00:23

裁判例から考えるシステム開発紛争の法律実務

タイトルにあるとおりシステム開発に関する裁判例をベースに,裁判所の考え方と当事者の行動指針を示す書である。


私自身,別館ブログ*1で少しずつ読んだ判例を書き溜めて,特にシステム開発に関する裁判例は,論点別に整理していたので,発売前の表題を見たときから,「いつかこういうの書きたいと思っていたんだよな・・・」というのが正直な感想で,中身を読むのを楽しみにしていた。


で,中身を読んでみれば,企業法務で著名な事務所の先生方4名の力を結集しただけあって,個人ブログの情報量など比べるべくもなく,大変充実した情報の整理,分析がなされている。


本書は,「多段階契約と一括契約」「瑕疵」「追加報酬」などの,システム開発紛争で論点となりやすいテーマ別に,裁判例を紹介しながら論点解説をするとともに,各章末にケースを挙げてポイント解説するという体裁になっている。純粋な法的な論点のみならず現実に,システム開発紛争で実務上よくありがちな問題点にも言及されており(例えば,仕様の「詳細化」と追加報酬請求の関係に関する本書170頁以下や,ベンダが謝罪文を出してしまった場合に関する本書242頁以下など),痒い所に手が届く仕様になっている。


こうして,システム開発関連の裁判例が150も分析されているだけに,かなりボリューム感がある充実した書であるが,本書を利用する際にはいくつか注意点しておくべきポイントがある。


第1に,多数の裁判例があるといえども,判例準則といえるほどの規範が確立しているわけではないことである*2システム開発案件は,規模も対象システムも,ベンダとユーザの関係も,開発方法論もバラエティに富んでいるので,ある事件でなされた判断は,あくまで当該事例でしか通用しないものと考えるべきで,それを過度に一般化できない。著者の方々はそのことを認識された上で,論点整理をされているが,読み手が,特定の裁判例の特徴的な判示部分に基づいて目の前の事件の判断をしてしまわないようにしておきたい。


第2に,本書の立場が「ベンダ寄り」になっていることである。表題や,具体的な本文中の表現において,ベンダサイドに寄った記述が目立つというほどではないのだが*3,各章末の「システム開発現場への教訓」の箇所では,基本的にベンダの視点に立った記述で,ベンダへのアドバイスが中心となっている。もっとも,ユーザの法務担当らにとっても,ベンダの対策が見えてくるという意味で有益である。


本書は,上記のとおり,ベンダ寄りに「紛争」を扱っているということで,過去の類書を含めて独断でマッピングすると以下のような感じになる(さりげなく,自分の著書をニュートラルなところに位置付けているが・・)。本書の登場によって,各領域に満遍なく文献が配置されるようになったといえる。

f:id:redips:20170327002123p:image

あと,少しだけ注文を付けるとすると,本書の刊行が平成29年2月だったことを考えると,もう少し最新の裁判例も取り込んでおいていただきたかったかなと思う。本書では,最新のもので平成26年9月だが,平成27年,平成28年にも重要裁判例が多数出ている。ただし,この点は,著者の事務所のウェブサイトで公開されているコラムで順次取り込まれる予定のようなので,楽しみ。


また,本書では,判例索引は用意されていない。確かに,特定の裁判例をキーにして,そこに関連する記述を探すという使い方は,自分を含む一部のマニアックな層しかないのかもしれないが・・


150の裁判例のうち,平成20年以降のものの多くは,別館ブログで紹介してあったり,過去に読んだことがあるものだったが,見落としているものもあった。本書をきっかけにまた勉強しなおしたい。


それにしても,松尾剛行先生の執筆パワーはすごすぎる。

*1http://d.hatena.ne.jp/redips+law/

*2:敢えていうならば,システムの完成は,予定された最終の工程を終えているかどうかで判断するという規範は確立しているともいえるが(東京地判平14.4.22判タ1127-161ほか。本書137頁),これも,結局は,最終工程は何であるか,それが終えているのか,という事実のレベルでは問題になるので,それほど固い規範とはいえない。

*3:ベンダの義務として,プロジェクトの中止提言義務までも言及したスルガvsIBM事件控訴審の射程を限定的にとらえているところなどが一つの例として挙げられる。本書131頁。

2017-03-11 15:41

個人情報・パーソナルデータに関すること(27)匿名加工情報に関する資料

改正個人情報保護法の施行まであと2カ月とちょっとになった。最近,毎日,次から次へと新しい情報がリリースされる。なかなか追いつくのが大変。


各事業者としては,とりあえず,「最低限やっておかなければならないことへの対応」に追われていることだろう。具体的には,第三者提供の際の記録・確認義務をどうするか,外国にある第三者への提供に関することなどが考えられる。よって,「改正によって新たにできるようになった(とされる)ことの検討」は後回しになっているのではないか。後者の例は「匿名加工情報」である。


報道では,「改正法によりビッグデータが流通し,イノベーションが促進」というトーンで書かれることも少なくないので,匿名加工情報についての関心は相当程度あるとみられるが,個々の事業者単位でみると,「とりあえず今はその余裕はない」というところが多いのではないだろうか。


本エントリでは,とりあえず「匿名加工情報について検討せよ」と言われた担当者がとりあえず押さえておくべき情報を挙げるにとどめておく。


(経済産業省)匿名加工情報作成マニュアル 平成28年8月8日

http://www.meti.go.jp/press/2016/08/20160808002/20160808002-1.pdf

もっとも早くリリースされた資料。具体的なユースケースを挙げながら検討の順序や方法が示されているのでわかりやすい。当時としては信頼できるほぼ唯一の資料だったので,重宝されたが,現在は,個人情報保護委員会のガイドライン等も出てきたので,加工方法に関してはむしろ新しい資料を参考にしたほうが良いと思う。


(個人情報保護委員会)個人情報の保護に関する法律についてのガイドライン(匿名加工情報編)平成28年11月30日

http://www.ppc.go.jp/files/pdf/guidelines04.pdf

今後は,分野別ガイドラインや,認定個人情報保護団体が出す指針など,より詳細な基準が示されると思われるが,総本山のガイドラインとして押さえておきたい資料。


(個人情報保護委員会)「個人情報の保護に関する法律についてのガイドライン」及び「個人データの漏えい等の事案が発生した場合等の対応について」に関するQ&A 平成29年2月16日

http://www.ppc.go.jp/files/pdf/kojouhouQA.pdf

上述するガイドラインを補完する位置づけとしてのQ&A。匿名加工情報に関してもQ11-1からQ11-22まで,22個のQが用意されている。


(国立情報学研究所)匿名加工情報の適正な加工の方法に関する報告書 平成29年2月21日

http://www.nii.ac.jp/about/reports/pd/report-kihon-20170221.pdf

匿名加工情報に関して実務上もっとも悩ましいのは,どこまで加工すれば,法2条9項の要件を満たすのか,法36条1項に定める方法を満たすのかというところであろう。その点に関して,この分野の技術・法律面から一線級の専門家を集めて行った研究成果をまとめた報告書。明確に,個人情報保護委員会のガイドラインを補完する位置づけであることが明記されているため,信頼していい資料。


(個人情報保護委員会)匿名加工情報 「パーソナルデータの利活用促進と消費者の信頼性確保の両立に向けて」平成29年2月27日

http://www.ppc.go.jp/files/pdf/report_office.pdf

個人情報保護委員会が出したレポート。加工方法に関する詳細な記載があるが,上述の国立情報学研究所のレポートの流れを受けている。後半のユースケースごとに加工例が示してある点は参考になる。

2016-12-31 17:54

2016年に紹介した裁判例

別館のIT・システム判例メモ(http://d.hatena.ne.jp/redips+law/)は,始めてから丸7年が経過した。掲載判例は220ほどになる。この1年は23個しか紹介できなかった。それを判決年月日順に並べてみると。。。


東京地判平28.4.28

http://d.hatena.ne.jp/redips+law/20160725/1469373646

今年出された大規模システム開発訴訟判決の一つ。ERPパッケージ導入が頓挫したのは,ユーザ側に問題があったとしつつも,ベンダがユーザを適切にリードする(付随)義務を怠ったとして,ユーザの請求の3割を認めた事例。


東京地判平28.4.1

http://d.hatena.ne.jp/redips+law/20161207/1481118619

弁護士が開発を委託した集団訴訟管理システムの完成が争点となった事例。ユーザが不具合であるとする個所について,当業者にとっては自明であっても,そうでないベンダにとって必要だといえないなどとして,仕様書に記載されていない機能が実装されていなくても完成は否定できないとした。


旭川地判平28.3.29

http://d.hatena.ne.jp/redips+law/20161103/1478099168

今年出された大規模システム開発訴訟判決の一つ。医療法人のシステム開発が頓挫した事例において,仕様凍結の合意後も仕様のやり取りが続いていたことについて,ユーザ側の責任を一定程度認めつつも,ベンダの過失割合を8割とした。


知財高判平28.3.23 

http://d.hatena.ne.jp/redips+law/20160405/1459783159

変数やテキストデータが格納されたファイルについてプログラムの著作物としての創作性を否定し,かつ,当該ファイルは項目が指定されているのみで情報それ自体が格納されていないからデータベースの著作物としても観念できないとした事例。


東京地判平28.2.26 

http://d.hatena.ne.jp/redips+law/20161215/1481810226

医療機器に存在した不具合について,売主はどこまで対応すればよいかが争われた事例。請負契約の目的物たるソフトウェアの不具合の場合,不具合の指摘を受けた後,遅滞なく補修するか,代替措置を講じたときは瑕疵には当たらないとされているが,それと考え方が近い。


知財高判平28.1.19 

http://d.hatena.ne.jp/redips+law/20160205/1454599999

旅行業者用システムに含まれるリレーショナルデータベースについて,体系的構成に創作性が認められるとし,著作権侵害を認めた事例。


大阪地判平27.9.24 

http://d.hatena.ne.jp/redips+law/20160403/1459668563

観光案内用のピクトグラムの著作物性,ライセンス契約の終了後の撤去・抹消義務等の存否について争われた事例。


大阪地判平27.8.20 

http://d.hatena.ne.jp/redips+law/20160629/1467191270

合意がない限り更新されるというサポート契約の自動更新条項の解釈について,やむを得ない事由があれば合意がなくとも更新拒絶ができると判断された事例。


東京地変平27.8.17 

http://d.hatena.ne.jp/redips+law/20160503/1462280857

利用規約の定める禁止事項に該当するとしてアカウントを停止されたユーザが,処分の有効性,規約変更の有効性を争った事例(本人訴訟)。


東京地判平27.8.5

http://d.hatena.ne.jp/redips+law/20160525/1464186337

ビットコインは所有権の客体にならないとして,破産法62条に基づく取戻し権の行使を認めなかった事例。


東京地判平27.6.25

http://d.hatena.ne.jp/redips+law/20160217/1455635342

請負契約という表題になっていた契約について,その実質は,いわゆるSES契約(判決文中にはその文言はない)であったとして,予定されていた期間を業務に従事させていれば報酬請求できるとした事例。


知財高判平27.6.18

http://d.hatena.ne.jp/redips+law/20160910/1473436116

ソフトウェアの違法販売による損害額について,原審が著作権法114条3項を適用して実施料率50%として標準小売価格の50%とした判断を変更し,ダウンロード版の販売価格である定価の10%引き全額について損害を認めた事例。


東京地判平27.6.2 

http://d.hatena.ne.jp/redips+law/20160619/1466344794

Linux, Apache, MySQL, PHPの開発能力があることを前提に採用されたエンジニアが,実際にはそのような能力を有していなかった等として解雇された場合において,解雇の有効性が認められ,賃金の一部相当額について不法行為による損害賠償責任が生じるとされた事例。


東京高判平27.5.21

http://d.hatena.ne.jp/redips+law/20160104/1451917027

多段階契約方式を採用するシステム開発プロジェクトにおいて,後続工程にかかる契約が締結されなかった場合に,締結済みの値引き分を改めて請求できるか否かが争われた事例。


東京地判平27.4.23

http://d.hatena.ne.jp/redips+law/20160401/1459436860

SEO対策業務が,実際に行われたかどうか(報酬支払義務の存否)が争われた事例。


東京地判平27.3.17

http://d.hatena.ne.jp/redips+law/20160321/1458571081

リアルの店舗への会員登録によって生じるアフィリエイト報酬の支払義務の存否が問題となった事例。


東京地判平26.11.28

http://d.hatena.ne.jp/redips+law/20160902/1472821104

サイトの管理契約をユーザが解約した場合において,ベンダに対し,解約によって生じる損害(外部委託費用)の賠償を認めた事例。


東京地判平26.10.1

http://d.hatena.ne.jp/redips+law/20160922/1474520139

ネットワークバンキングサービスの障害によって,金融取引に生じた損害については,金融機関から見れば予見可能性がないとされた事例。


東京地判平26.2.18

http://d.hatena.ne.jp/redips+law/20160820/1471667998

ウィルス対策ソフトの使用許諾契約(クリックオン型)の成否が問題となった事例。


東京地判平24.3.14

http://d.hatena.ne.jp/redips+law/20160111/1452489389

システム移行調査契約,保守管理契約の法的性質が,請負か準委任かが争われた事例。


山口地判平21.6.4 

http://d.hatena.ne.jp/redips+law/20160418/1460989091

再委託先の従業員の不注意によって個人情報が漏洩した事故について,再委託先に対する損害賠償請求が認められた事例。


大阪高判平19.3.27

http://d.hatena.ne.jp/redips+law/20161211/1481461570

他人のユーザID・パスワードを使って他人に成りすましてヤフーオークションにて落札行為を繰り返したことについて,私電磁的記録不正作出罪(刑法161条の2第1項)の成否が問題となった事例。


東京地判平16.6.30

http://d.hatena.ne.jp/redips+law/20160228/1456586212

ビジネスソフトウェアの画面の著作権侵害の有無が問題となった事例。


読まなくてはいけない裁判例,まとめておきたい裁判例はたくさんあるので,来年もまた,少なくとも30個くらいのペースは維持したい・・

redips
redips

弁護士。IT法務,法科大学院・新司法試験,子どもの将棋について。