令和2年4月1日から改正民法が施行されました。これによって受託開発（請負契約）における受託者の責任が瑕疵担保責任保険から、契約不適合責任に変更されました。どちらもユーザーに対して負う責任であることに変わりはないのですが、両者はどのような違いがあるのか、しっかり理解できている人は多くありません。この点をしっかり押さえておかないと、システム開発を依頼する際にトラブルが起きてしまう可能性があります。

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

令和2年に改正民法が施行されるまでは、受託開発もSES（準委任契約）も瑕疵担保責任を負うこととなっていました。ここでは瑕疵担保責任と契約不適合責任の4つの違いと、SESでベンダーが負う責任について解説します。

瑕疵担保責任と契約不適合責任の4つの違い

システム開発における受託開発（請負契約）で、完成したシステムに不備があった場合、改正前民法でも次の3点が認められていました。

・修補請求権
・損害賠償請求権
・契約解除権

これを踏まえ、改正民法では次の4つの権利が認められています。（民法第636条） ・ 追完請求権
・ 代金減額請求権
・ 債務不履行による損害賠償請求権
・ 債務不履行による契約解除権

また、システム開発案件における両者の違いを表にすると次の通りです。

契約不適合責任と瑕疵担保責任の責任内容を比較すると、契約不適合責任に改正されたことによって、ユーザー（買主）側の権利が拡大しています。例えば、瑕疵担保責任では納品されたシステムに隠れた瑕疵があった場合に限って、修補請求権が認められていました。

しかし、契約不適合責任では、契約内容に不適合な不備を対象として、履行の追完請求や代金の減額請求など請求できる権利の選択肢が増えました。他にも、責任追及することができる期間が、引き渡し時点からではなく不適合を知った時から1年間とユーザー側が請求しやすく拡充されています。

SES（準委任契約）に契約不適合責任はない？

システム開発では受託開発だけでなく、SES（準委任契約）という契約類型もよく活用されます。SESは受託開発と異なり、成果物の納品ではなく委託された作業の遂行に対して報酬が支払われる契約形式です。そして、SESには請負契約とは異なり、ベンダーが負うのは契約不適合責任ではなく瑕疵担保責任です。

SESと受託開発の違いについて詳しく知りたい場合は、こちらの過去記事もチェックしてみてください。 準委任契（SES）と受託開発（請負契約）の違いとは？システム開発に最適な契約形態

SESには「成果完成型」（民法第648条の2第1項）と「履行割合型」（民法第648条第2項）の2種類があります。システム開発を目的とするSESでは作業の結果として達成された成果に対して報酬が支払われることから、多くが成果完成型に該当します。そのため、ベンダー側はSESであってもシステムを納品することで報酬が発生し、納品することができなければ、ユーザーに対して債務不履行責任を負うことが必要です。

さらに、SESには善管注意義務（民法第644条）を負い、システム開発に携わるものとして当然必要とされるスキルや知識をもって業務を遂行する義務を果たさなければなりません。SESでは契約不適合責任を負わないからという理由で、ベンダー側が果たすべき責任が実質的に軽くなるというわけではありません。

システム開発をめぐるトラブルの事例

契約不適合責任や瑕疵担保責任の概要について分かったところで、本章では具体的にどのような場合にその責任が認められてきたのか、2つの事例について解説します。

契約の目的に照らして瑕疵があると判断された事例（東京地裁平成16年12月22日判決）

概要

ベンダーに販売管理システムの開発を委託したが納入されたシステムには不具合があり、ユーザーは契約目的が達成できないため、契約解除と損害賠償請求をしたが、ベンダーがこれを拒否して訴訟になった

不具合の内容

移行データを使用した一括在庫引当て処理に30分以上の時間を要し業務が進まず、その間他端末においても受注登録処理が行えない

排他制御の問題で、商品マスタの登録データを開いていると、商品マスタを使用するすべてのプログラムの処理が止まる

判決

一括在庫引当て処理に時間を要することも、排他制御についても契約の内容に適合するものといえず、瑕疵に該当する

東京地裁平成16年12月22日判決では、販売管理システムの受託開発において納入されたシステムが契約の内容に適合するものといえず、契約目的を達成することができない瑕疵に該当すると判断されました。本判例では、「一括在庫引当て処理の速度」や「排他制御」については、要件定義に含まれていません。

つまり、要件定義をベースに考えれば開発されたシステムは、その内容を満たしていたことになります。しかし、判決では要件定義ではなくユーザーのシステム開発における目的に照らして、瑕疵の判断がされました。

ユーザーの協力義務違反が認められた事例（札幌高等裁判所平成29年8月31日判決）

概要

病院情報システムの導入のため、入札を行い落札業者とプロジェクトを開始したが、ユーザーからの仕様追加が続いたため、納期遅延及び不具合が発生し開発は頓挫。ユーザーから契約解除を申し出、訴訟に発展

経緯

当初予定されていた仕様の確定日を過ぎてもユーザーからの仕様追加は続いた

仕様確定（仕様凍結）合意を行った後にも、ユーザーからの追加要求があった

判決

ユーザーが仕様凍結合意に反して大量の追加要望を出したことによって本件システム開発が遅延した、としてユーザーの協力義務違反を認めた

札幌高等裁判所平成29年8月31日判決では、ユーザーの協力義務違反を認め、ベンダーに対して損害賠償の支払いを命じました。 本判例では、仕様確定後に多くの追加要求が出されるなど、プロジェクトを進めるにあたってユーザーの協力義務が全うされていないと判断されています。このように、開発を行うベンダーに義務があるのは当然ですが、あくまで契約関係であるためユーザーにも一定の協力義務は存在します。

リスク回避のために契約書に盛り込むポイント

システム開発におけるトラブルは一定数起こりますが、トラブルに巻き込まれるのは誰しも避けたいはず。そこで、本章ではトラブルに巻き込まれるリスクを回避するために記載しておくとよい内容について紹介します。

契約の前提条件について

瑕疵担保責任から契約不適合責任へ改正されたことで、前章で紹介した判例にもあるようにシステムに瑕疵があるかどうかよりも、成果物が契約の内容や目的に適合するかどうかがポイントとなる可能性があります。そこで、契約書には業務範囲や成果物の完成基準、納入期日、システム環境などを可能な限り詳細に記載しておくとよいでしょう。

仕様変更等の対応方法について

仕様を確定し開発段階に入ってから見落としが判明し、どうしても仕様変更をしなければならない場合も一定存在します。そのような場合にユーザーとベンダーでどのように対応をしていくのか予め契約書に盛り込んでおくと、その後の対応もスムーズです。仕様変更や仕様追加を行う際の進め方や費用負担などに関する規定を、可能な範囲で記載しておくとよいでしょう。

スムーズに業務を進めるための打ち合わせ内容

ベンダーとの打ち合わせにおいて何を伝えればよいのか迷う方も多いでしょう。本章では、実際にシステム開発を行う上で、どのように打ち合わせを行えばよいのかについて解説します。

システムを開発する目的を明確に伝える

システム開発を行う上で、ユーザー側が最も伝えるべきことはシステム開発を行う目的です。何のためにシステムを導入したいのかが不鮮明だとベンダーも提案が行いにくく、意思疎通ができないまま契約へ向かってしまいます。そのため、どのような機能を実装しどのように業務効率化を図りたいのか社内でまとめておくのがよいでしょう。RFP（見積もり提案書）を作成しておくのもおすすめです。

仕様変更や追加の可能性がある場合は事前に伝える

どうしても開発過程で仕様の変更や追加が発生する可能性がある場合は、事前に伝えておくことがおすすめです。この時、どの部分がどのように追加・変更される可能性があり、いつまでに固まるのかについてできるだけ詳細にベンダーに伝えるようにしましょう。 これによって、ベンダーも開発スケジュールを事前に調整して提案を行うことができるため、追加費用やトラブルが発生しにくくなります。

今回はシステム開発における瑕疵担保責任と契約不適合責任の違いについて解説しました。株式会社Jiteraでは、SES（準委任契約）を中心にシステム開発を承っています。SESでは契約不適合責任ではなく、瑕疵担保責任が発生しますが、システム開発をするにあたって負う責任は、本記事で解説したように大きな差はありません。

問い合わせフォームに入力をいただければ、簡単な質問に答えるだけで開発したいシステムの種類や、実装する機能までをおおまかに決めた上で見積もり依頼ができます。そのため、作業範囲や納期をある程度明確にした状態で打ち合わせを開始することが可能です。Jiteraでは独自の開発自動化プラットフォームを有しており、今までにないコストと納期でシステム開発を行うことができます。今までにないシステム開発体験をしてみませんか。まずは以下のお見積もり入力フォームからお試しください。