ＩＴ法務

　契約書の契約条項を検討する場合、リスクヘッジについては考えるかも知れませんが、費用対効果については余り考えないかも知れません。しかし、実務で後者をなおざりにするのは、決して好ましいことではありません。 コストに引き合う場合 　以下に例を挙げるのは、ライセンサーと代理店との代理店契約にある、勧誘行為の優先権に関する非常 ...

　明治２９年に制定された民法（のうち契約等に関わる債権法の部分）が、約１２０年ぶりの大改正となります。実際に施行されるのは２０２０年４月からとなりますが、早くから準備するに越したことはありません。また、施行後も相当の期間にわたり、解釈や運用の状況をウオッチしていく必要があります。 　もっとも、改正議論の当初には３０００ ...

　それまで順調に動いていたシステムが、突然ダウンしました。よくよく調べてみると、データベースの定義に余計なユニーク指定のあるのが原因でした。この手の話は良く聞きますが、何かのヒントを含んでいるように思えます。 　ベテラン技術者の曰く、データベース設計をした担当者は、ユニーク指定の意味が、指定のデータでレコードを一意に特 ...

　契約書のリーガルチェックの目的は、契約にまつわる法的リスクへの対応です。リスクとは、「有利になるかも知れないが、不利にもなり得る」という不確定性を言いますから、単純な有利／不利とは話が違います。よく、リーガルチェックの際に、「出来るだけウチに有利に」と言う人がいますが、本当にそれだけのことならリーガルチェックなど要ら ...

　協議条項という、恐らくは日本独特の契約条項があります。「本契約について疑義を生じた場合、信義誠実の原則に従い甲乙協議し、円満に解決を図るものとする。」というようなものです。日本人論で著名な山本七平氏は「日本資本主義の精神」の中で、協議条項は要らないと述べています。協議条項があってもなくても、日本人同士の契約は、結局は ...

　「開発の中間成果と報酬支払」で言及した「システム開発の中間成果に独立した完成物としての価値があるか」ということをより一般化すると、契約ないし取引の単位の問題となります。つまり、契約の成立や履行、解除などは、まとまりのある「一単位」毎に考えるべきということです。 判例に見る「一単位」 　このような「一単位」は、通常は契 ...

　情報システムの保守は、パッケージ等を用いていればなおさら、そうでなくも、これを開発したベンダでなければ困難なのが通常です。そのため、開発委託契約とその後の保守契約は、切っても切れない関係になります。以下は、そうした関係の一例です。 　保守契約の範囲として、しばしば「障害の（一次）切り分け」という作業項目が現れます。ユ ...

　ＩＴ紛争を抽象的に論じるとき、「ベンダ対ユーザ」という観点、すなわち「党派性」が色濃く出ます。同じ論点についての考え方一つをとってみても、ユーザの見方とベンダの見方では（類型的に）１８０度違います。 　例えば、（望ましくない）仕様変更が生じてしまったとして、ベンダから見ればユーザの我儘であって契約範囲外のこと、ユーザ ...

　システム開発委託契約の殆どは、法律上、請負契約になると解されています。これは、受託者であるベンダはシステムを完成させる義務を負い、委託者であるユーザはその完成に対して報酬を支払う、ということを意味します。つまり、報酬の点で言えば「後払い」となるのです。問題は、契約書でこれと異なる支払条件を規定した場合です。 　例えば ...

　存続条項というものがあります。例えば、「第２５条　本契約の終了後においても、第○条、第○条、第○条の各規定は、なお有効なものとして存続する。」というようなものです。後払の支払義務や担保責任などが、契約期間が終了した途端に無効になってしまわないための条項です。 　ところで、列挙する条項の中に、２５条自体は要るでしょうか ...