読者です 読者をやめる 読者になる 読者になる

PSLブログ

ヨシナシゴトヲツヅリマス

請負契約にあたり考えること

請負契約は、委任契約と違い、完成保証があるので、引き受けた側にシビアな形態である。また、所有権の移転など、考えなしではあとからいろいろと問題が起きてくる。参考になるサイトがあったので記録を残しておく。

ITPro - トラブルを回避する契約・法律の基礎知識 網羅的に書かれている。これを読むと、発注側も請負側もいかにいい加減にやっているかがよくわかる。問題が起きるとどちらにも比があるのだが、発注側に比があるという自覚がないと、請負側は不利である。
あどみん法務・知的財産部 - 契約書のツボ(3) - システム開発契約書 請負側の立場寄りで書いてあってとても参考になる。仕事を続けていく上で防御的な知識は必要である。なかなかお客様のせいにしにくいのである。

なお、私が契約を結ぶ上では、以下のようなチェックポイントを設けている。

  1. みなし検収の規定 通常は検収のことには触れているが、諸事情により発注者が検収を行わず長い期間が経過したとき、請負金額が回収できなくなるため、例えば30日経過して検収の可不可の通知がないときは検収されたものとみなす、という文言を入れてもらう。
  2. 著作権移転の除外規定 典型的なパターンでは、著作権は、著作権法27条・28条の規定を含めて発注者側に移転させ、請負側が著作人格権も行使しないとするのであるが、この通りにやってしまうと、そのお客様に納品したコードはもう他では使えず、例えばどのシステムにも共通で使い回せるサブルーチンやモジュールが、以後使えないという重大な制約をもたらす。そこで、「契約締結以前に開発済みのモジュールまたはサブルーチン」について、移転対象から外してもらう。
  3. 機密保持の対象 機密保持の対象を、除外規定の各号を除く一切としてしまうと、お互いに機密情報と認識していないようなものでも、後からトラブルになったとき、発注者側の判断であれは実は機密情報だったとして請負側に一方的なペナルティが科せられる危険性がある。そこで、「あらかじめ発注者が機密情報だと指定したもの」に限定してもらうことで、お互いに何が機密情報かを把握できる。
  4. 損害賠償額の上限 システムの宿命だが、請け負った金額を超えて損害が発生することがあり得る。しかし、大手のSIerが数千万とか数億で請け負うものとは違って、こちらは数万ということもあるわけで、それに対して無過失責任である瑕疵担保責任を1年間負うことになり、リスクがとても大きい。そこで、賠償額の上限を請負金額としてもらうのだ。

以上の項目は、こちらから取引先にお願いするものであり、常に応じてくれるとは限らないが、相手から言ってきてくれるということはないので、やはり主張した方がよいと思っている。