Что такое ответственность за несоответствие контракта в разработке систем и программного обеспечения? Объяснение изменений

Что делать с юридической точки зрения, если после поставки заказанной системы обнаруживаются ошибки?

Сложность управления, медленная скорость обработки, отсутствие заказанных функций… Перед такими проблемами системы, заказчик обычно обращается к разработчику системы с претензией о “нарушении условий договора”.

“Нарушение условий договора” было введено вместо “ответственности за недостатки”, которая была отменена в результате изменения Гражданского кодекса в 2017 году (Григорианский календарь, 2017 год). Поэтому необходимо обратить внимание на то, как это изменение влияет на разработку систем и программного обеспечения.

Часто возникают проблемы после поставки. Чтобы избежать таких проблем, мы объясним содержание “нарушения условий договора” и влияние изменений.

Изменения в Гражданском кодексе по ответственности за несоответствие контракта

«Закон о частичном изменении Гражданского кодекса Японии» был опубликован 2 июня 2017 года (29 год эры Хэйсей) и вступил в силу 1 апреля 2020 года.

В Гражданском кодексе основные правила, касающиеся контрактов и т.д., установлены в разделе, называемом «Закон о обязательствах».

С момента его принятия в 1896 году (29 год эры Мэйдзи), Закон о обязательствах почти не пересматривался на протяжении около 120 лет.

Поэтому, с целью адаптации к современному обществу, были проведены значительные изменения, которые включаются в эту редакцию.

Конкретные пункты изменений весьма разнообразны, но одним из основных является введение нового понятия ответственности за несоответствие контракта.

В результате этого, то, что ранее называлось «ответственностью за гарантию от дефектов», теперь заменено на «ответственность за несоответствие контракта».

Что такое несоответствие контракту

“Несоответствие контракту” означает, что функции, качество, производительность или состояние, которые должны быть в соответствии с соглашением сторон или сущностью контракта, отсутствуют.

Это понятие “несоответствие контракту” было введено вместо традиционного “дефекта” в результате изменения Гражданского кодекса (Японского Гражданского кодекса).

В разработке систем и программного обеспечения, “несоответствие контракту” возникает, когда завершенная система не соответствует заранее определенным спецификациям, или когда система или программное обеспечение не обладают функциями или производительностью, которые они обычно должны иметь, учитывая их характер.

При определении наличия “несоответствия контракту” особое внимание уделяется соглашению сторон и сущности контракта.

Поэтому важно оставить письменные записи о целях разработки системы или программного обеспечения и о процессе заказа, чтобы ясно показать, какие требования и представления имел заказчик.

Случаи, когда неисправности программного обеспечения соответствуют “несоответствию контракту”

В случае, когда программное обеспечение вызывает проблемы и исправление задерживается

Во-первых, можно предположить случай, когда в программном обеспечении возникает серьезная неисправность, которую нельзя быстро устранить, например, требуется пересмотреть процесс до стадии проектирования для ее исправления.

Например, есть прецедент, когда признали соответствие “несоответствию контракту” или “дефекту” в случае, когда возникли проблемы, такие как то, что поиск во внедренной системе инвентаризации занимает более 30 минут, и пришлось создавать рукописный реестр инвентаря для ответа на запросы клиентов (Решение Токийского окружного суда от 22 апреля 2002 года (Heisei 14)).

В случае, когда неисправности постепенно проявляются

Кроме того, даже если каждая неисправность незначительна и не требует много времени на исправление, можно предположить случай, когда неисправности проявляются снова и снова, и требуется много времени, чтобы исправить все неисправности и заставить их работать нормально.

Например, если во внедренной системе инвентаризации постоянно возникают неисправности, и не ясно, насколько серьезными будут неисправности в будущем и сколько времени потребуется на их исправление, и если невозможно выполнить обычные операции с использованием системы, можно сказать, что это “несоответствие контракту”.

Случаи, когда сбои в программном обеспечении не соответствуют “несоответствию контракту”

Если были немедленно внесены исправления или приняты альтернативные меры

Судебная практика показывает, что даже если пользователь указывает на баги или другие проблемы, если они были немедленно исправлены или были приняты альтернативные меры, согласованные с пользователем и признанные разумными, это не считается “дефектом” (Решение Токийского окружного суда от 18 февраля 1997 года (Heisei 9)).

В разработке систем и программного обеспечения невозможно полностью исключить появление багов, и некоторые проблемы неизбежно возникнут.

Поэтому, даже если есть проблемы, если были приняты меры, такие как немедленное исправление, они не должны считаться “дефектами”.

Это также применимо к текущему понятию “несоответствия контракту”.

Важно отметить, что основой для определения “немедленности” являются доказательства, такие как протоколы собраний, созданные в процессе разработки системы.

Подробнее об их важности можно прочитать в следующей статье.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Если конкретный индивид не смог легко понять метод операции

В отношении удобства использования и удобства в использовании, поскольку они в значительной степени зависят от субъективных оценок, они будут считаться “несоответствием контракту”, если они не пригодны для использования для обычного пользователя.

Только то, что конкретный индивид не смог легко понять метод операции, не означает, что это “несоответствие контракту”.

Если проблема возникла по причинам, не связанным с работой поставщика

Если проблема возникла по причинам, не связанным с работой по разработке системы или программного обеспечения поставщика, это не означает, что в этой системе или программном обеспечении есть “несоответствие контракту”.

Например, если проблема возникла из-за проблем с оборудованием, которое поставщик не обязан закупать, это не будет считаться “несоответствием контракту”.

[Дополнение] Если проблема возникла из-за указаний пользователя

Если проблема возникла в завершенной системе или программном обеспечении из-за неправильных указаний пользователя, даже если в системе или программном обеспечении признается “несоответствие контракту”, поставщик, как правило, не несет ответственности за несоответствие контракту.

Например, если в процессе разработки бизнес-системы было дано неправильное объяснение об обстоятельствах, которые знает только пользователь, и из-за этой неправильной информации возникли проблемы в программном обеспечении, разработанном на основе согласованных спецификаций, поставщик не несет никакой ответственности.

За этим решением стоит предположение, что в разработке программного обеспечения заказчик, то есть пользователь, также несет “обязанность сотрудничества”. Подробнее об этом можно прочитать в следующей статье.

Вопросы, которые заказчик/покупатель может заявить на основании ответственности за нарушение договора

Здесь мы рассмотрим содержание ответственности за нарушение договора в отношении разработки систем и программного обеспечения, учитывая изменения, внесенные поправками.

Требование о восстановлении

Если недостаток оценивается как нарушение договора, заказчик может потребовать его устранения.

До внесения изменений, если дефект не был важным и требовался чрезмерный расход на восстановление, требование о восстановлении не могло быть предъявлено. Это ограничение было удалено поправками.

Однако, даже после внесения изменений, если “нарушение договора не является важным и требует чрезмерных затрат на восстановление”, восстановление может быть признано невозможным, и требование о восстановлении может быть отклонено.

Требование о компенсации ущерба

Если система или программное обеспечение с дефектами приводят к невозможности нормального ведения бизнеса или к дополнительным расходам, заказчик может потребовать компенсации ущерба.

До внесения изменений, требование о компенсации ущерба могло быть предъявлено независимо от наличия вины, если не было специального соглашения.

Однако, после внесения изменений, если у исполнителя есть основания для освобождения от ответственности (обстоятельства, которые не могут быть приписаны вине должника), требование о компенсации ущерба не может быть предъявлено.

Следовательно, если поставщик доказывает наличие оснований для освобождения от ответственности, он не несет ответственности за компенсацию ущерба.

Расторжение договора

Договор о разработке может быть расторгнут по причине нарушения договора системой или программным обеспечением.

В уже упомянутом судебном решении, было признано расторжение договора из-за дефектов, таких как слишком долгое время обработки поиска в системе проверки запасов, которое занимало более 30 минут, и проблемы, которые делали невозможным использование терминала, что привело к отказу от продолжения использования внедренной системы (Решение Токийского окружного суда от 22 апреля 2002 года (2002 год по Григорианскому календарю)).

До внесения изменений, договор мог быть расторгнут только в случае, если “цель договора не может быть достигнута из-за дефекта”. Однако, это ограничение было удалено поправками.

Однако, даже после внесения изменений, следует обратить внимание на то, что расторжение не признается, если степень нарушения договора “незначительна”.

Требование о снижении вознаграждения

Право на требование о снижении вознаграждения было введено поправками.

Если в системе есть дефекты и заказчик требует их устранения, но они не устраняются в течение разумного срока, заказчик может потребовать снижения вознаграждения.

Период ответственности

• Требование о восстановлении
• Требование о компенсации ущерба
• Расторжение договора
• Требование о снижении вознаграждения

существует ограниченный период, в течение которого эти права могут быть реализованы.

Конкретно, права могут быть реализованы только в том случае, если заказчик уведомил поставщика о наличии нарушения договора в системе или программном обеспечении “в течение одного года с момента узнавания об этом”.

До внесения изменений, период реализации прав был ограничен “одним годом с момента передачи” системы или программного обеспечения. Следовательно, можно сказать, что период реализации прав увеличился после внесения изменений.

Кроме того, кроме этого ограничения по времени, права, признанные на основании ответственности за нарушение договора, также подпадают под положения о сроке исковой давности.

Таким образом, например, если вы узнаете о наличии дефекта в системе или программном обеспечении спустя 11 лет после его получения, права, такие как право на требование о компенсации ущерба, “истекают” после истечения срока исковой давности в “десять лет”, независимо от того, уведомили вы о нарушении договора “в течение одного года с момента узнавания об этом” или нет.

Отказ от оплаты вознаграждения

Заказчик может отказаться от полной оплаты вознаграждения до тех пор, пока разработчик не выполнит восстановление или компенсацию ущерба.

Основные моменты условий контракта, учитывающие несоответствие контракта

Положения о несоответствии контракта являются дополнительными, и стороны могут ограничить содержание ответственности или сократить срок осуществления прав по специальному соглашению между ними.

В этом разделе мы рассмотрим условия контракта, на которые следует обратить внимание в связи с несоответствием контракта при разработке систем и программного обеспечения.

Пункт 1: События и область, которые являются объектом несоответствия контракта

Если заказчик недоволен системой или программным обеспечением, он, вероятно, захочет предъявить претензии к поставщику за несоответствие контракта.

Однако для поставщика неприемлемо, чтобы его преследовали за несоответствие контракта просто потому, что заказчику что-то не нравится, даже если это просто спецификация.

Кроме того, поставщик может значительно увеличить свою оценку, чтобы защититься от несправедливых претензий за несоответствие контракта, что будет невыгодно для заказчика.

Поэтому важно четко определить события и область, которые являются объектом несоответствия контракта, указав в письменной форме, с какой целью и какие функции системы хочет внедрить заказчик, и обеспечивая точное отражение этого в техническом задании.

Также можно рассмотреть возможность ясного указания на то, что если система или программное обеспечение, соответствующее условиям, указанным в техническом задании, будет поставлено, то даже если в спецификации есть какие-то неудобства, это не будет считаться несоответствием контракта.

Это положение позволит предотвратить обвинения в несоответствии контракта из-за предпочтений заказчика, даже если разработка была выполнена в соответствии с техническим заданием.

Пункт 2: Четкое определение гарантийного срока

Срок осуществления прав по несоответствию контракта начинается не с момента “передачи” продукта, а с момента “узнавания” о несоответствии контракта.

Кроме того, даже если применяется срок исковой давности, его максимальный срок составляет “десять лет” и он длится долгий срок.

Для поставщика это большая нагрузка, поскольку в некоторых случаях он должен предоставлять бесплатную гарантию на “десять лет”, и он должен учесть это на этапе оценки.

С другой стороны, для заказчика может быть выгоднее установить гарантийный срок гибко, в зависимости от срока использования системы или программного обеспечения, с точки зрения затрат и прочего.

Поэтому можно рассмотреть возможность гибкой установки гарантийного срока в зависимости от содержания системы и т.д.

Пункт 3: Реагирование на несоответствие контракта

Когда возникает несоответствие контракта, стороны могут ограничить права, признанные гражданским законодательством, такие как требование о возмещении ущерба или расторжение, до определенной части по соглашению между ними.

Как заказчик, вам необходимо полностью понимать, какие ограничения установлены в контракте.

Вывод: обратитесь к адвокату для составления договора, включающего “ответственность за несоответствие договору”

В результате изменений в Гражданском кодексе (Японский Гражданский кодекс) произошли значительные изменения в правовых отношениях, связанных с разработкой систем и программного обеспечения.

Если в поставленной системе возникают неполадки, нельзя однозначно утверждать, что это является “несоответствием договору”, и какую ответственность можно возложить.

Кроме того, для предотвращения споров заранее, на этапе заключения договора о разработке необходимо провести тщательные консультации между заказчиком и поставщиком.

Если у вас есть вопросы или сомнения относительно составления договора, обязательно проконсультируйтесь с профессиональным адвокатом.