法とITの話

この「法とITの話」では、法とITについてのブログと書籍を紹介します。

ブログ「法とITの話」は、法とITにかかわる話題を広く扱っているブログです。
書籍「ディベートで学ぶシステム開発委託契約」と「IT判例で学ぶマネジメントと紛争対応」は、もう一歩進んだIT法務を扱った電子書籍です。

このブログ「法とITの話」では、トピックを特に限定せず、法とITに係わる話題を広く扱っています。



【ピックアップ記事】

システム・イコール・規則(システム開発)

 システム開発契約の主要トピックについて、ユーザとベンダの仮想ディベートで「解説」したものです。システム開発契約で押さえておくべき重要事項や、ユーザとベンダとの間で生じがちなトラブルを踏まえた契約書での対応について学びたい方に向いています。

1.多段階契約
2.請負/準委任
3.支払条件
4.再委託
5.変更管理
6.検収
7.瑕疵担保責任
8.著作権
9.秘密保持
10.損害賠償
11.仕様書
付録.平成29年債権法改正の概要

【あとがき】より
 英語に Battle of Forms という言葉がある。自己に有利なひな型(Forms)を用意しておいて、それを相手方に呑ませよういう交渉スタイルを揶揄したものである。実際、「交渉力」を背景にだだリスクを押し付け合うだけでは、交渉とは名ばかりである。もちろん、相手方との契約交渉で訳もなく譲歩を強いられたり、気づかないうちにリスクを背負わされたりすることは、何としても避けなければならない。しかし、その逆もまた好ましいことではない。契約交渉は、一面で Battle であるが、ただの Battle ではない。契約によって拓かれる取引の、公平で合理的な「私的ルール」を創り上げるためのものである。
 もっとも、何が公平で合理的かということになると、ユーザとベンダの見方は180度違ってくる。これは、契約のゼロサム面の現れである以上に、利用者と開発者という「文化」の違いの反映である。少なくとも相手方から見る限り、ユーザは開発者の「文化」に無理解であるし、ベンダは利用者の「文化」に無関心である。互いの「文化」を良く知ることは、ゼロサム関係を超えたパートナーとして、開発を成功させるための土台でもある。相手方からの少々耳の痛い主張には、真摯に耳を傾けなければならない。とても認め難いと思える主張にも、一分の理があるかもしれない。その意味で、むしろ相手方の主張にこそ、多くの「学ぶ」べきことがある。


【内容紹介】

 重要な論点を含むIT判例について、事案全体の流れの中で判旨をかなり詳細に引用したうえ、論点単位である程度完結した説明を試みたものです。判例を素材としてIT法を理解し、マネジメントや紛争対応に役立てたい方に向いています。

判例1.システム開発契約の基本三要素
判例2.システム開発契約の正否と契約準備段階の過失
判例3.コンサルティングにおける旧システムの重要機能の欠落
判例4.開発プロジェクト進行中の追加変更
判例5.ベンダのプロジェクトマネジメント義務とユーザの協力義務
判例6.ベンダが負うプロジェクト中止提言義務
判例7.処理時間や排他制御の瑕疵による契約解除
判例8.検収後に判明したシステムのバグ
判例9.データ移行に必要なデータ構造情報の入手不能
判例10.株式誤発注の取消不能に伴う責任関係
判例11.グループウェアの画面に対する著作権侵害
判例12.エステサロン事業者による個人情報の漏えい
判例13.ネットカフェからの名誉棄損の書込についての発信者情報開示

【あとがき】より
 訴訟には、「平成26年(ワ)第1234号」という形式の事件番号が付けられる。このうち「平成26年」の部分は、訴訟が受け付けられた暦年を表している。他方で、判決が出ると、「東京地判平成28年12月25日」などと呼びならわす。日付の部分は、言うまでもなく判決の言渡し日である。つまり、これらが分かれば、いちいち事件記録に当たらなくても、その訴訟の大体の係属期間を計算することができるわけである。
 試みに、本書で採り上げた裁判例について、提訴から第一審の判決までの訴訟期間をこの方法で計算してみると、(年の半ばに提訴したと仮定して)平均で3年強となる。「裁判の迅速化に関する法律」で2年以内の終局が目標とされていることから考えても、かなり長い部類に入る。世の中の大半のシステム開発プロジェクトよりも、更に長くかかっていることになる。
 筆者が最初に関与したIT訴訟も、3年以上かかった。しかも、その事案は、提訴に至るまでに調査や交渉等に相当な期間を費やしていたから、判決で全てが終わったのは、開発プロジェクトが始まってから実に10年後であった。訴訟は控訴されずに一審だけで終わったのだが、これは両当事者ともその時点で既に「疲弊」していたからかもしれない。そして、この紛争解決のため、ユーザ側では(頓挫した開発プロジェクトで予定していた)新システムの実現が10年間凍結されたままとなってしまった。
 IT訴訟は(これを生業とする筆者にとっては残念なことであるが)、開発頓挫にせよ、情報流出にせよ、既に発生してしまった損害を当事者間でいかに分担するかというだけの問題で、いかにも「後ろ向き」である。もちろん、起きてしまった紛争に透明性のある決着を付けるには訴訟によるのが正攻法であるし、長く苦しい訴訟追行を通して危機管理の視点が身に着くといった余得がないこともない。しかし、少なくとも、新しいものを生み出す「前向き」のビジネスとは、大きく違っていると言わざるを得ない。
 そこで重要になってくるのが、いかに紛争を予防するかという視点である。本書の表題を「マネジメントと紛争対応」としたのは、そうした問題意識からである。残念ながらITの世界に「銀の弾」はなく、内容的には至らないところも多くあるが、多少なりとも読者の参考になれば幸いである。


【内容紹介】