Что такое завершение работы по договору подряда в разработке систем?

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

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

В этой статье мы рассмотрим юридические аспекты вопроса “В какой момент и после выполнения каких работ разработка системы считается завершенной?”.

Что такое завершение разработки системы

Завершение разработки системы с точки зрения инженера

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

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

Завершение разработки системы с юридической точки зрения

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

Объяснение различий между этими двумя типами контрактов представлено в статье выше, но если говорить о завершении разработки системы, то есть о выполнении обязательств, которые взял на себя вендор, критерии для этого определяются следующими статьями:

Контракт подряда: Статья 632 Гражданского кодекса Японии
Статья 632
Контракт подряда возникает, когда одна из сторон обязуется завершить определенную работу, а другая сторона обязуется оплатить результат этой работы.
Контракт на предоставление услуг: Статья 648 Гражданского кодекса Японии
Статья 648
1. Если нет специального соглашения, исполнитель не может требовать оплаты от заказчика.
2. Исполнитель может требовать оплату только после выполнения порученного дела. Однако, если оплата определена по времени, применяется положение пункта 2 статьи 624.
3. Если исполнение было прекращено на полпути по причинам, которые не могут быть приписаны исполнителю, исполнитель может требовать оплату в соответствии с долей уже выполненной работы.

Завершение разработки системы становится проблемой в контрактах подряда

Однако, не только в контексте разработки систем, вопрос о том, когда происходит “завершение работы”, обычно становится проблемой в контрактах подряда. В случае контрактов на предоставление услуг, вместо того чтобы считать выполнение обязательств достижением определенного результата или продукта, это тип контракта, который подразумевает, что специалист с определенной степенью усмотрения делает то, что он должен делать (независимо от результата). В контрактах на предоставление услуг, даже если ожидаемый продукт не был создан, возможно требовать оплату, если дело было обработано должным образом (пункт 2 статьи 648), и если исполнение было прекращено на полпути по причинам, которые не могут быть приписаны исполнителю, возможно требовать оплату в соответствии с долей уже выполненной работы (пункт 3 статьи 648). Контракты подряда сосредоточены на “результатах”, а контракты на предоставление услуг сосредоточены на “процессе”.

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

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

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

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

Судебные прецеденты, связанные с завершением работы

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

Статьи 632 и 633 Японского Гражданского кодекса (Japanese Civil Code) устанавливают, что срок оплаты вознаграждения подрядчика заказчиком наступает, когда подрядчик завершает работу и передает объект работы заказчику, в то время как статья 634 этого же кодекса устанавливает, что подрядчик несет гарантийную ответственность перед заказчиком, если в объекте работы есть дефекты (пункт 1), и что до выполнения подрядчиком своей гарантийной ответственности за дефекты объекта работы, заказчик имеет право на защиту от одновременного исполнения в отношении оплаты вознаграждения (пункт 2). Согласно этим положениям Гражданского кодекса, закон различает случаи, когда результат работы неполный, из-за наличия дефектов в объекте работы и когда работа не завершена, и понимается так, что даже если в объекте работы есть дефекты, независимо от того, являются они скрытыми или очевидными, это не означает, что работа не завершена.
Следовательно, для определения, завершил ли подрядчик работу, следует использовать в качестве критерия то, был ли завершен последний этап работы, запланированный в начальном договоре подряда, и считается, что заказчик не может отказаться от оплаты подрядной цены только по причине наличия дефектов в объекте работы, когда подрядчик завершил последний этап работы и передал объект работы.

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

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

【Обязательства в контракте подряда = Завершение работы = Завершение всех этапов】
========
Если работа не завершена…
↓
【Несение ответственности за невыполнение обязательств】
========
Если работа завершена, но есть недостатки…
↓
【Признание выполнения обязательств, вопрос гарантийной ответственности за дефекты】

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

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

Что означает завершение работы с юридической точки зрения

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

Освобождение поставщика от ответственности за невыполнение обязательств означает, что возможность расторжения контракта со стороны пользователя существенно сокращается. Это потому, что расторжение контракта на основании ответственности за дефекты ограничено случаями, когда невозможно достичь цели контракта. Если контракт расторгнут, поставщик также теряет право на запрос оплаты (то есть, в простых терминах, он не получает никакой оплаты), поэтому на практике часто возникают споры о “завершении работы”.

Подробное объяснение о “расторжении” контракта в системной разработке приведено в следующей статье.

https://monolith.law/corporate/cancellation-of-contracts-in-system-development[ja]

Важные замечания по завершению работы

Как мы относимся к изменению спецификаций и дополнительной разработке

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

Внимание на изменения в Гражданском кодексе

Кроме того, положения о гарантийной ответственности за дефекты на основе договора подряда подвержены сильному влиянию изменений в Гражданском кодексе, поскольку связь между предыдущими статьями была сложной и трудной для понимания. В контексте изменений в Гражданском кодексе, подробное объяснение того, как следует понимать “дефект”, приведено в следующей статье.

Заключение

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