システム開発と契約と民法改正

「システム開発 受託契約の教科書」を読んで契約の学習したので、その中で自分の基準で重要だと思った点をメモりました。契約について全然詳しくないので、間違っている点もあるかもしれません。

契約とは

民法の規定だが民法上に契約の定義が明記されているわけではない
強行規定と任意規定があり、民法における契約の規定は基本的に任意規定。民法の強行規定、契約書記載事項、民法の任意規定の順に適用される。そのため、強行規定以外は自由に契約で契約当事者が決められる。
契約は口頭でも成立する

契約書の目的

債権・債務の明確化

どのようなシステムを作るのか、納期・金額はいくらか、といった項目。契約書にない場合には民法の規定が適用される。

紛争発生時の拠り所

紛争発生時の契約解除や損害賠償について規定しておく。

開発プロセスを規定して開発円滑化

体制、作成物、承認方法に関する条項規定して開発円滑化を図る。

著作権の所在を明確化

特許権と違い、著作権は申請や登録なしに発生します。原則としては、プログラムを書いた人に帰属するため、契約に規定しないとプログラムを作成した会社が著作権を有する。

契約基礎知識

基本契約書

反復・継続して行われる取引に対する取引横断型と、導入プロジェクト全体に適用される基本的ルールを最初に決めるフェーズ横断型の2種類がある。取引横断型はベンダーの元請・下請間で使われることが多い。

契約書体裁

標題はあったほうが望ましいが、法的な意味がなく必須ではない。

知っておくべき法律上のポイント

民法改正

民法の債権法改正法案が2017年6月に公布され3年以内に施行。債権を中心に改正され、システム開発関連として影響があるのは、瑕疵担保責任、解除、損害賠償、仕事ができなくなった場合の報酬です。

請負と準委任

民法上、「請負は、当事者の一方がある仕事の完成をすることを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。」としています。請負とする場合、そのため、完成する仕事が明確である必要があります。
一方、準委任は事務の委託です。仕事の完成は目的としておらず、善良な注意者の管理義務(善管注意義務)を負って仕事を行います。

請負特徴

• 完成する仕事(システム)が具体的
• 完成したら代金を支払う
• 報酬が工数に関係なく決められている
• 瑕疵担保責任・検収の条項がある
• 契約書標題が「請負契約」

準委任特徴

• 完成する仕事(システム)が不明確
• システムベンダーが投入した人月に応じて代金が決まる
• システム完成ではなく作業実施有無によって支払が生じる
• 契約書標題が「業務委託契約書」

債務不履行

簡単に言うと契約違反をすると債務不履行となり、履行不能・不完全履行・履行遅滞の3種類があります(ここでは会計の「債務」というより「責務」に近いです)。システムベンダーが請負契約で納期を守れない場合、ユーザーが代金未払いの場合などが債務不履行です。

損害賠償

債務不履行の場合、債務不履行と因果関係がある損害について賠償請求することができます。
損害賠償額が大きくなるリスクが見込める場合(医療機器やユーティティ関連など)には、契約で上限を求めることがよく行われます。

解除

契約を双方が合意して途中で無効にしたい場合は合意解除といいます。双方の合意がなくても、一定の事由に該当した場合法定解除ができます。
解除事由によって以下の解除があります。

• いきなり解除可能な無催告解除
• 催告をしても相手方が履行しない場合に解除可能な催告解除

民法で無催告解除可能な事由(債務履行ができない場合等)が定められていますが、それだけでは不足するので、相手の倒産危機などを契約に追加することが多いらしいです。
請負契約でシステム完成前の解除の場合でも、仕事結果が「可分」であれば、完成部分に相当する報酬を払う必要があります(民法改正により条文化された)。この報酬額は投入原価に応じてではなく、注文者が受ける利益の割合に応じて算定されます。

瑕疵担保責任と契約不適合

瑕疵担保責任は請負契約で適用される欠陥に対する責任です。瑕疵担保責任に対するアクションとして追完請求(修補請求)、損害賠償、解除があります。
民法改正によって瑕疵担保責任は契約不適合に置き換わります。
契約不適合は、目的物が契約内容に適合しないことを示します。瑕疵担保責任と比べて当事者の合意、契約趣旨と性質が重視されています。契約不適合に対するアクションとして、追完請求(修補請求)、代金減額、損害賠償、解除の4種類があります(「代金減額」が民法改正により追加)。
期間制限の起算点は以下のように変更されています

内容	瑕疵担保責任	契約不適合
責任の期限	引渡から1年	注文者が不適合を知った時から1年
責任追及の方法	1年以内に瑕疵内容、損害額算定の根拠を示して請求	1年以内に契約不適合の種類と大体の範囲を通知。請求はその後でOK。

著作権

プログラムは「物」ではなくため、所有権ではなく著作権で管理します。システムに関係するものに限定した種類として以下の分類です。

• 著作財産権

  • 複製権:コピーすることをコントロールできる権利
  • 翻案権:既存の著作物の表現上の本質的な特徴の同一性を維持しつつ、具体的な表現形式を変更して新たな著作物を創作する権利

• 著作者人格権

  • 同一性保持権:著作物およびその著作者の意図に反して変更、切除その他の改変を禁止することができる権利

上記の定義があるのですが、著作権法の例外としてバックアップや不具合改修等のためのプログラムコピー・変更は著作権がなくても可能です。
原則的に、著作権は特許権と異なり申請不要で著作者(法人)に帰属します。しかし、契約書上でユーザに移転する規定を設けることも多いです(規定がない場合は、システムベンダー側に帰属)。著作人格権は著作権法の規定により譲渡できないため、著作人格権を行使しないことを契約書上に書いておくことが一般的です。
プログラムだけでなく、設計書等のドキュメントやマニュアルも著作権の対象となり得ます。

再委託

民法上、準委任契約は再委託は委託者の許諾が必要で、請負契約は再委託は受託者の自由です。しかし、民法の規定より契約が優先されます。そのため、情報漏えいリスクやスキルなどを鑑みて契約書に再委託の可否・条件を記載します。

協働と役割分担

システム開発を成功させるためにユーザとベンダーが協働作業することが必要です。また、システム開発が失敗した場合のリスクに備えて契約書に役割分担を明確にすること望ましいです。

検収/検査

法的に請負契約における「検収」とは「最後の工程まで完了したことを確認すること」です。品質が問題ないかを検収することではありません。
ベンダー側からすれば、バグがあったからとりって検収が不合格で支払がなされないことは不都合ですし、ユーザ側からするとバグがないことのお墨付きを与えるわけではありません。
検収仕様書の作成と承認プロセスを契約書に明記することが望ましいです。
また、「みなし検収条項」を入れることがあります。検収不合格や検収遅滞の理由が非合理的な場合に検収合格とみなすことです。