Hatena::ブログ(Diary)

Footprints このページをアンテナに追加 RSSフィード

2017-06-22

第1回情報法制シンポジウム・オンラインゲーム業界の資金決済法問題

| 23:21

先週末,6月17日に第1回情報法制シンポジウムに参加した。


情報法制学会・情報法制研究所

■第1回情報法制シンポジウム プログラム

https://www.jilis.org/conference2017.html


無線LANのただ乗り問題など,多くの興味深いテーマがあったが,パネルディスカッション「オンラインゲーム業界の資金決済法対応の解決にむけて」で行われた議論を一部紹介する。


パネリストは,LINEの江口さん,弁護士の板倉さんらのほか,資金決済法といえばということで,MHMの堀先生も登壇。


議論の題材となったのは,昨年話題になったLINEの二次通貨問題に端を発するオンラインゲームのコインやアイテムの取り扱い。「宝箱の鍵」のようなアイテムが,資金決済法の「前払式支払手段」に該当するかという極めて実務的な論点はありつつも,もっと根源的な問題として,現在のAndroid/iPhoneのプラットフォームで動くスマホのオンラインゲームにおいて,同法の規制は本当に適切なものなのだろうか,具体的には,発行残高の50%もの供託金を積むことが本当に必要な規制なのだろうかといったことが議論された。


確かに,先に対価を得てコインやポイントなどを与えておきながら,ゲームの運営会社が倒産してしまってゲームの運営が停止してしまった場合,先に払った対価に見合うサービスを受けられなくなってしまう。そのような場合に消費者を保護する必要性があることについては理解できる。しかし,実際に自家発行型でそのような供託義務を定めている国はほとんどないようだ。その上で,


  • ゲームの運営が終了することはあるとしても,ゲーム会社が倒産してしまったというような事例は頻発しているのか?
  • そのために残高の50%もの供託金を各社が積んでおく必要があるのか?
  • 供託金は,Apple/Googleに払わされる手数料を考慮しないでグロスで計算されるが,それは妥当か?確かに,30%のApple税と,50%の供託金を考えると,下記の図の例では,ユーザが1000円を投じていても,ゲーム運営者の手元に残るのは200円だけになってしまう。
  • 法律上明らかにされていないのに,無料発行分と区別していなければ,無料発行分も含めて残高を計算しなければならないという規制は合理的なのか?(金融庁のガイドライン
  • そもそもゲームのユーザは,コイン等の一次通貨はともかくとして,二次通貨と呼ばれるものまで最終的に返金されることを望んでいるのか?

f:id:redips:20170622231902p:image:w540

資料 の9頁より引用)


といった疑問について,単なるゲーム事業者のボヤキといったレベルではなく,事実関係の調査を踏まえて中身の深い議論が行われた。そのうえで,いくつかの提言もなされた(詳細は,前掲資料を参照。)。


立法を担当された堀先生によれば,前払式支払手段の規制が導入される時点では,スマホのゲームでの課金が一般的ではなかったから,規制内容の議論の際に,これらを念頭に置かれたものではないし,規制を避けるためには180日の有効期限を設定すればよいのだから,大きな問題になるとは考えられていなかったようだ。しかし,Appleの規約により,アイテム等に有効期限を設けることができないから,現実には資金決済法の規制を形式的に交わすことができない*1


私も実務でオンラインゲームと資金決済法の問題を扱う際には,そもそも前払式支払手段該当性のレベルから悩むことも少なくない。「有償・無償は区別しておかないと無償分も供託しないといけなくなりますよ」と語りつつも,なんだか不合理というか過剰な誰得規制だなあと感じていたところ。正直なところ,法に触れないとしても,欺瞞的な手段で課金を煽るサービスも中にはあって,そういったものには感心しないが,規制は懲罰でもないわけで,保護法益に対して適切なバランスでなければならない。

*1AppleGoogleのルールは「教会法」だという指摘があった。教会法については私はまったく知見がないが,国家が定めたものでもないのに,国家が定めた法と同等かそれ以上の通用力を有する規範という意味で用いられており,興味深い。

2017-06-15

データの利用権限に関する契約ガイドライン

| 22:09

少し時間が経ったが,5月30日に経産省とIoT推進コンソーシアムから題記のガイドラインが公表された。


http://www.meti.go.jp/press/2017/05/20170530003/20170530003.html


データの利用や提供に関する契約については,平成27年10月に同じく経産省から「データに関する取引の推進を目的とした契約ガイドライン」が公表されているが*1,それとは趣旨・目的が異なるとされている。

具体的には,

「データの利用権限に関する契約ガイドライン」(今回のガイドライン)は,データの利用権限が誰にあるのか,ということを決めるための考え方を示しているのに対し,

「データに関する取引の推進を目的とした契約ガイドライン」は,権利関係が明らかであることを前提に,提供条件などのポイントを示しているものである。


拙書の宣伝になるが,「ITビジネスの契約実務」*2の7章では,後者のガイドラインも参考にしつつ,主にパーソナルデータの取引を行う場面を想定して,データ提供契約の考え方を示している。


さて,データの価値がますます高まってきているが,法律的な位置づけが明確でない,というか,排他的な権利(所有権等の物権や著作権等の知財権)で保護できるケースはかなり限られている。そういう中でIoTで創出・収集されたデータの「オーナーシップ」それ自体を議論することにはあまり意味がない。データに関係する当事者(例えば,装置の稼働データを生み出す装置の開発者,装置の所有者,ソフトウェアの開発者等)のいずれにデータを利用する権利があるのかということを調整,議論するための考え方の筋道を示しているのがこのガイドラインである。


筋道といってもピンと来ないかもしれないが,37頁以下の「適用例」を見ると少しわかりやすいだろう。

製造会社Aが,工作機械メーカーBから工作機械を購入し,ソフトウェアベンダCから購入したミドルウェアを用いて自社工場において工作機械を稼働。工作機械から創出する稼働データについてAB間で利用権限を定める。

といったケースが設定されている(上記の例は37頁)。こういうのはIoTネタでは頻出のケースであろう。その場合に,機械の稼働データを誰がどこまで使っていいのかということを決めるにあたって,私的自治だから,当事者間で交渉すればよいといえばそれで話は終わってしまう。しかし,お互いが権利を主張した場合に,どうやって調整していくのか,どんな要素を考慮して決めればよいのかということが書かれている。


また,特許法では「実施」が定義されていたり(2条3項),著作権法では「利用」が列挙されているが(21条以下),データについては「何ができるか」ということが法律で決まっているわけではないので,まず権限分配の対象となる「利用」行為を特定することも重要になるだろう。こうしたことを当事者間で合意さえできれば,あとは契約書に落とし込むことはそれほど難しいことではない。なので,まだまだ具体的なケースは少なく,これですべてに対応できるというわけではないが,単なる契約ひな形とその解説よりは,考え方の筋道を示すという意味で,まさに「ガイドライン」として有用なのではないかと思われる。

*1:このガイドラインについては,旬刊経理情報(中央経済社)NO.1431にて,解説記事を書いた。

*2https://www.amazon.co.jp/dp/4785724943

2017-05-31

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

| 23:21

昨日,平成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

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

| 23:54

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


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


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


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


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

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

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

Xのシステム開発へのかかわりについての管理に関して、より具体的に説明すれば、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頁。