システム開発を依頼する際、開発会社との間でトラブルが発生するケースがあります。その中でも、瑕疵担保責任、およびその後継の規定として誕生した契約不適合責任は、システム開発にとって重要な概念です。

これらの法的責任について理解を深めることで、契約解除やステークホルダー（開発者やベンダー、ユーザー）間でのトラブルや損害といったリスク未然に防ぎ、円滑なシステム開発を進められるでしょう。

本記事では、瑕疵担保責任と契約不適合責任の違いについて詳しく解説するとともに、実際の判例も交えながらご紹介していきます。

※2020年4月1日より改正民法が施行され、受託開発（請負契約）における受託者の瑕疵担保責任の法概念は廃止され、契約不適合責任と名称を変えています。

システム開発における瑕疵担保責任と契約不適合責任の違い

瑕疵担保責任と契約不適合責任、どちらも、システム開発者側がクライアントやユーザーに対して負うべき法的責任です。

法改正に伴いシステム開発業務にどういった変化をもたらしたかをしっかり押さえておくことで、企業に業務委託あるいはユーザーからの依頼・発注の際のリスクマネジメントとして活用できるでしょう。

瑕疵担保責任とは

瑕疵担保責任は、システム開発において長年適用されてきた責任概念です。開発されたシステムに欠陥や不具合があった場合に、開発会社がその修正や損害賠償の責任を負うというものです。

「瑕疵（かし）」とは、一般的に、「通常有すべき品質や性能を備えていない状態」を指します。システム開発の場合、プログラムのバグや機能の不具合、性能不足などが該当するでしょう。

ただし、瑕疵担保責任の適用には一定の期間制限があります。この期間内に欠陥や不具合が発見された場合にのみ、開発会社に責任が生じる点が特徴でしょう。

契約不適合責任とは

契約不適合責任は、2020年4月に施行された改正民法により導入された新しい責任概念です。この責任は、納品されたシステムが契約で定められた内容に適合していない場合に適用されます。

納品物が契約で合意された仕様や品質を満たしていない場合、開発会社が責任を負う点が特徴があり、契約不適合責任では、欠陥や不具合だけでなく、契約で定められた仕様や品質との不一致も対象となります。

改正民法施行後、多くの企業がシステム開発契約書のひな型を見直し、契約不適合責任に関する条項を盛り込むようになりました。「瑕疵」でなく「契約」の観点から成果物を判断する概念がうまれたのです。

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

瑕疵担保責任と契約不適合責任の4つの違いや責任範囲・内容の差異ついて解説していきます。

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

不履行時の買主の権利

1点目が責任不履行時の権利の違いです。

システム開発における受託開発（請負契約）で、完成したシステムに不備があった場合、改正前の瑕疵担保責任では次の3つの権利が認められていました。

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

これを踏まえ、改正後の契約不適合責任では次の4つの権利が認められています。

• 履行の追完請求権
• 代金減額請求権
• 損害賠償請求権
• 契約解除権

契約不適合責任と瑕疵担保責任の責任内容を比較すると、履行の追完請求権（不適合の修補や代替物の引渡しを求めることができる権利）など、ユーザーやクライアント側（買主）の権利が拡大しています。

不備の範囲

2点目が、責任を負う不備の範囲です。

瑕疵担保責任では納品されたシステムに隠れた瑕疵があった場合に限り、責任の行使が認められていました。つまり、発見されなければ潜在的な欠陥が容認されてしまうデメリットがありました。

従来の瑕疵担保責任が、主に物理的な欠陥や不具合を対象としていたのに対し、契約不適合責任は、より広く「契約で定められた内容との不適合」を対象としている点が特徴と言えます。

債権の履行期間

3点目が、債権の履行期間、および始点の変更です。

瑕疵担保責任では成果物の引き渡しから1年が原則でしたが、契約不適合責任では契約内容の締結後の不適合発見時から1年と原則が見直されました。

つまり開発が進行中であっても、契約内容との相違点があれば、買主側は請求権を行使できるのです。そのため、契約履行者間での厳密な契約内容のすり合わせが重要視されるようになりました。

損害賠償の範囲

4点目が、損害賠償の範囲の変更です

瑕疵担保責任が信頼利益のみが対象でした。信頼利益とは、欠陥がないと信じて購入した開発システムによって伴った直接的な損害を指します。たとえば、システムの導入にと雇用したエンジニアがいたとして、瑕疵の発見により作業が滞ったとします。その間に発生した人件費の補填などが該当します。

一方、契約不適合責任では、履行利益の補填、つまり契約内の履行通りであれば獲得できていたはずの利益や、発生しなかったはずの出費に対しして請求権を行使できます。

一般的に逸失利益とも呼び、機会の損失に対しても賠償請求が可能となっています。

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

システム開発ではSES（準委任契約）という契約類型もよく活用されます。SESは受託開発と異なり、委託された作業の遂行に対して報酬が支払われる契約形式です。

前述した通りですが、2020年の民法改正により、瑕疵担保責任は契約不適合責任に統一されました。したがって、SESにおいても契約不適合責任が適用されます。

ただし、SESには「成果完成型」（民法第648条の2第1項）と「履行割合型」（民法第648条第2項）の2種類があり、システム開発を目的とするSESでは多くが成果完成型に該当します。後者はいわゆる歩合制（開発の貢献度や履行の割合に応じた契約）なので、やや特殊なケースと言えます。

成果完成型SESでは、ベンダー側はシステムを納品することで報酬が発生し、納品できなければ債務不履行責任を負います。

また、SESではベンダー側は善管注意義務（民法第644条）を基に業務を遂行しなければなりません。善管注意義務とは、客観的に見て、雇用した人物が開発に必要な要件（スキル・能力）を満たしておく義務のことです。

したがって、SESにおいて契約不適合責任の適用が限定的であるからといって、ベンダー側の責任が実質的に軽減されるわけではない点に注意が必要です。

システム開発における瑕疵担保責任や契約不適合責任に関するトラブルの事例

契約不適合責任や瑕疵担保責任の概要についてここまで解説をしてきました。

本章では具体的にどのような場合に法的責任が認められてきたのか、2つの事例を交えながら紹介していきましょう。

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

概要

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

不具合の内容

本件程度の開発システムにおける一括在庫引当処理に要する時間は、せいぜい数分程度が一般的に要求される内容であったが、テストデータ300件ですら処理時間に44分も要するシステムだった。よってこれは瑕疵担保責任における『瑕疵』に該当するのではないか。

また排他制御の問題により、システムの在庫引き当て処理をしている限り、他業務へも大いに支障がでており、実際の業務において使用に耐えないシステムであるとした。

判決

東京地裁平成16年12月22日判決にて、販売管理システムの受託開発において納入されたシステムが契約の内容に適合するものといえず、契約目的を達成することができない『瑕疵』に該当すると判断されました。

本判例では、「一括在庫引当て処理の速度」や「排他制御」については、要件定義に含まれていませんでした。つまり、契約内容をベースに考えれば、開発されたシステムは条件を満たしていたことになります。

しかし、判決では契約内容ではなくユーザー（買手）のシステム開発における「目的」に焦点を当てることで、瑕疵の判断が行われました。

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

概要

病院情報システムの導入のため、入札に応じたベンダー企業が複数企業と提携し共同プロジェクトが発足したが、ユーザー側の度重なる仕様変更により開発が難航した。ユーザーから契約解除の申告を受けるも、ベンダー側がこれを拒否し、訴訟に発展した。

経緯

病院情報システムの導入のため、入札に応じたベンダー企業が複数企業と提携し共同プロジェクトが発足した。平成21年2月までに仕様確定（凍結）を条件にしていたはずが、2月以降もユーザーから仕様の追加要望が続き、やむなく運用開始を延期。

その後も同年7月まで追加の要望が次々と続き、ベンダー側は協議を重ねた結果、それらを受諾。最終的な機能は6000項目を超えていた。翌年の平成22年3月まで機能の開発とテストを継続的に行っていたが、ユーザー側が納期遅延及び度重なる不具合に不服を申し入れ、開発は頓挫。

論点は、ベンダー側のプロジェクト管理不備にあるのか、ユーザーの現実的でない追加要望にあるのかに絞られていった。

判決

ユーザーが仕様凍結合意に反して大量の追加要望を出したことによって本件システム開発が遅延した、としてユーザーの協力義務違反を認めた。
札幌高等裁判所平成29年8月31日判決では、ユーザー側に巨額の損害賠償の支払いを命じました。※現在もユーザー側がこの判決に不服を唱えており、最高裁へ上告されている未解決の事例です。

本判例では、仕様確定後に多くの追加要求が出されるなど、プロジェクトを進めるにあたってユーザーの協力義務が全うされていないと判断されています。

開発を行うベンダーに義務があるのは当然ではありますが、契約の合意性を観点にすることで協力義務が生まれ、より厳密で平等な法的責任に問われるケースにもなり得ます。

瑕疵担保責任や契約不適合責任を追われるリスク回避のために契約書に盛り込むポイント

システム開発プロジェクトを円滑に進め、瑕疵担保責任や契約不適合責任を問われるリスクを回避するためには、契約内容が重要となります。

トラブルは一定数起こりえるものですが、可能な限り影響や法的責任を低減しておく必要があるでしょう。本章ではトラブルに巻き込まれるリスクを回避するためのポイントを紹介します。

契約の前提条件について

法改正以降、システムに瑕疵があるかどうかよりも、成果物が契約の内容や目的に適合するかどうかが重要視されます。

そこで、契約書には業務範囲や成果物の完成基準、納入期日、システム環境などを可能な限り詳細に記載しておくとよいでしょう。

判例でも、成果物が契約の内容や目的に適合するかどうかが重視されています。詳細な記載により契約内容を明確化し、トラブルを未然に防ぐことができます。

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

次に、仕様変更や追加の対応方法を契約書に盛り込んでおくことも重要です。開発段階での仕様変更は一定程度発生するものですが、その対応方法や費用負担等を予め規定しておくことで、スムーズな対応が可能となります。

仕様変更や仕様追加を行う際の進め方や費用負担などに関する規定を、可能な範囲で記載しておくとよいでしょう。

契約内容を充実させることが、システム開発におけるトラブル回避の鍵となります。契約書の作成段階から、これらのポイントを意識し、ユーザーとベンダーの双方が納得できる内容で締結することが重要です。

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

システム開発を円滑に進めるためには、ベンダーとの打ち合わせが重要なカギを握ります。しかし、契約前では何を伝えればよいのか迷うことも多いでしょう。

ここでは、システム開発における効果的な打ち合わせの進め方をご紹介します。

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

まず、システム開発の目的を明確に伝えることが大切です。何のためにシステムを導入したいのか、どのような機能を実装し、どう業務効率化を図りたいのかをユーザー側でまとめてもらい、適切にヒアリングする必要があります。

目的が不明確だと、ベンダー側も適切な提案が行いにくくなり、意思疎通不足のまま契約に至ってしまう恐れがあります。RFP（見積もり提案書）を作成しておくのも効果的な方法の一つと言えるでしょう。

ヒアリング結果を基に要件定義書を作成し目的を明言化していきます。システムの目的、機能、性能、インターフェース、セキュリティ要件などを詳細に記載し、ユーザーとベンダーの間で認識のずれがないよう詰めていきます。

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

どうしても開発過程で仕様の変更や追加が発生する可能性がある場合は、事前に伝えておくことがおすすめです。開発ベンダー側は、どの部分がどのように追加・変更される可能性があり、いつまでに固まるのかについてユーザーへできるだけ詳細に伝えましょう。

これによって、ベンダーも開発スケジュールを事前に調整して提案を行うことができるため、追加費用やトラブルが発生しにくくなります。

加えて、定期的な進捗報告の場を設けることが大切です。開発の進捗状況や発生している課題について、ユーザーとベンダーの間で共有し、必要に応じて対策を講じていきましょう。

進捗報告の頻度は、プロジェクトの規模や期間に応じて適切に設定しましょう。影響度や対応の優先順位などを擦り合わせていくことが重要です。

まとめ：瑕疵担保責任と契約不適合責任について理解しておきましょう

ここまで、システム開発における瑕疵担保責任と契約不適合責任の違いについて、実際の判例を交えながら解説してきました。

これらの法的責任を理解することで、トラブルを未然に防ぎ、円滑なプロジェクト進行が期待できるでしょう。

当メディアを運営する株式会社Jiteraでは、豊富な開発実績と不動産業界に精通したコンサルタントが、御社の課題やニーズに合わせた最適なソリューションをご提案いたします。

SES（準委任契約）を中心に、作業範囲や納期を明確にした上で、柔軟な対応を心がけています。ぜひ、システムの選定から導入、カスタマイズ、アフターフォローまで、トータルでサポートいたしますので、お気軽にご相談ください。

株式会社Jiteraへの相談はこちら