システム開発に関する紛争のパターンにはどのようなものがあるか

IT・情報セキュリティ
尾城 亮輔弁護士 尾城法律事務所

 システム開発に関して、最近多くのトラブルが発生するようになっており、訴訟に至ることも珍しくありません。システム開発に関して発生する紛争には、どのようなものがあるのでしょうか。

 システム開発に関する紛争には、おおむね以下のようなものがあります。

  1. システムの完成の有無
  2. 瑕疵担保責任の有無
  3. 「仕様変更」による契約の追加または変更の有無
  4. 履行遅滞または履行不能における帰責性
  5. 契約書が未作成のときの契約の成立の有無

解説

目次

  1. システムの完成の有無
  2. 瑕疵担保責任の有無
  3. 「仕様変更」による契約の追加または変更の有無
  4. 履行遅滞または履行不能における帰責性
  5. 契約書が未作成である

システムの完成の有無

 典型的な場面としては、ベンダー(受託者)が成果物たるシステムを引き渡して、ユーザー(発注者)に検収を求めたところ、ユーザーが成果物には問題があるとして検収を拒絶したという場合に、仕事の完成の有無が争点となります。

ベンダー(受託者)が成果物たるシステムを引き渡して、ユーザー(発注者)に検収を求めたところ、ユーザーが成果物には問題があるとして検収を拒絶したという場合に、仕事の完成の有無が争点となる

 請負契約は、請負人が仕事の完成を約束し、その仕事の結果に対して報酬が支払われるという契約であることから(民法633条)、システム開発を委託する請負契約が締結された場合、仕事が完成したか否かにより、ベンダーが報酬請求権を行使できるか否かが定まることになります。

 また、仕事が完成すると、その後の不具合は瑕疵担保責任の問題となり、解除をすることができる場合が、契約の目的を達することができないときにのみに限られるなど、仕事の完成の前後で、法的な状態に差が生じることになります(ただし、平成29年の債権法改正により、瑕疵担保責任に基づく解除も、債務不履行に基づく解除の規定に基づいて行われるようになるため、改正法の施行後は「契約の目的を達することができない」という条件は不要となります)。

瑕疵担保責任の有無

 システムが完成して業務に用いるようになったがバグが発生する、仕様書どおりに動作しない、システムの動作が遅いというような場合に、ユーザーは、ベンダーに対して瑕疵担保責任を追及できるかという点が争点となります。

 請負契約の瑕疵担保責任の問題になりますが、システム開発の特徴を踏まえたうえでの判断が必要となります。まず、情報システムというのは、一般に非常に複雑で、テストなどを十分行ったとしても、プログラムにバグが生ずるのを完全に防ぐのは非常に難しく、稼働後も一定のバグが残ってしまうことが避けがたいため、バグの存在をもって、ただちに瑕疵があるとするのは適切ではないと考えられています。また、システムの動作速度などの、性能要件(非機能要件)についても争いとなりやすいのですが、要件が明確に定義されないことも少なくありません。そのような場合、何をもって瑕疵というかについて激しく争われることになります。

「仕様変更」による契約の追加または変更の有無

 システム開発では、プロジェクトを進めている最中であっても、ユーザー側から、開発すべきシステムの内容を変更するよう求められることがあり、これを「仕様変更」といいます。このような仕様変更は、プロジェクトの進捗に大きな影響を与えることから、一般的には望ましいものではありませんが、システム開発のプロジェクトでは、一定程度の仕様変更が発生するのは必然的であるとも考えられています。

 このような仕様変更は、本来契約で定めた仕様(合意内容)を変更するのですから、法的には契約の変更であると評価されます。しかし、実際の開発現場では、契約変更の合意書等を作成せず、費用について話し合いをすることもなく作業が進められてしまうことが珍しくありません。そのような場合、変更のために要する作業は、当初の契約に含まれる無償の作業なのか、あるいは、当初の契約内容に含まれない有償の作業なのかという点が争いになることがあります。特に、プロジェクトがとん挫するようなケースでは、仕様変更のための作業に非常に大きな工数が投入されることが多く、そもそもの「仕様」の内容が明確ではないことや、「仕様」が適切な内容となっていなかったことなどと相まって、非常に深刻な紛争に陥ることがあります。

履行遅滞または履行不能における帰責性

 プロジェクトの納期に遅延してしまった場合またはプロジェクトがとん挫してしまい、プロジェクトの完遂が不可能になってしまった場合、ベンダーは履行遅滞または履行不能に陥ることになりますが、ベンダーは自社に帰責性がないと主張立証することで、債務不履行責任を免れることができます

 一般にプロジェクト開発において、ベンダーは、プロジェクトの体制を維持し、プロジェクトの進行状況を管理するとともに、ユーザーのシステム開発への関わりについても適切に管理することが求められますが、他方で、ユーザー側も、ベンダーへの情報提供のほか、社内の意見調整を行い、どのような機能を要望するかなどの必要な意思決定を適時に行っていくことが求められます(それぞれ、ベンダーのプロジェクト・マネジメント義務とユーザーの協力義務といいます)。このように、プロジェクトにはベンダーとユーザーの共同作業的な側面があり、それぞれの当事者がこれらの義務を果たしたかを分析することによって、ベンダーの帰責性の有無が評価されることになります。

契約書が未作成である

 たとえば、発注者側であるユーザーの社内承認が完了していないが、プロジェクトを開始すべき時期は過ぎているといった事情がある場合、ユーザーとの間で契約書を作成したり、ユーザーから正式な発注書が提示されたりする前に、ベンダーが見切り発車的に作業を開始してしまうということがあります。このようにベンダーが作業を開始してしまったにもかかわらず、ユーザーが、プロジェクトを中止する、あるいは、別のベンダーに依頼するという判断をしてしまった場合、ベンダーはユーザーに対して、契約の成立または契約締結上の過失を主張することができるのかという問題が生じます。


 このように、システム開発にはさまざまな紛争類型があり、システム開発特有の性質を理解する必要がある場合も少なくありません。このような紛争を適切に解決するためには、法律面のみならず、システム開発の実務についてもよく理解する必要があります。

Q&Aでわかる日本版「司法取引」への企業対応 - 新たな協議・合意制度とその対応 -

無料会員にご登録いただくことで、続きをお読みいただけます。

1分で登録完了

この実務Q&Aを見ている人はこちらも見ています

無料会員登録で
リサーチ業務を効率化

1分で登録完了

無料で会員登録する