Что такое приемка разработки системы и случаи применения положений о приемке по умолчанию

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

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

Чтобы решить эти проблемы, в контрактах часто включается пункт о “приемке по умолчанию”.

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

Что такое приемка в разработке систем?

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

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

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

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

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

Будьте внимательны к условиям предварительного приема

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

Например, что произойдет, если поставщик создал продукт и уже представил его, но ответственный сотрудник со стороны пользователя по каким-то причинам не согласен на приемку?

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

Что такое условия предварительного приема?

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

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

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

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

https://www.meti.go.jp/policy/it_policy/keiyaku/model_keiyakusyo.pdf[ja]

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

Считается…
→ Даже если на самом деле это не так, с юридической точки зрения это рассматривается как таковое

(Пример) Если вы использовали смартфон во время теста, это “считается” списыванием
→ Независимо от того, является ли то, что вы делали на смартфоне, списыванием или нет, применяются те же меры, что и в случае списывания.

Предполагается…
→ Если нет особых доказательств, опровергающих факт, он рассматривается как факт.

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

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

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

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

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

Решение Токийского окружного суда от 29 февраля 2012 года (2012 год по григорианскому календарю)

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

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

Истец (поставщик) утверждает, что в соответствии со статьей 9, пункт 4 контракта на разработку программного обеспечения, ответчик (пользователь) считается принявшим продукт, поскольку он не уведомил о результатах проверки в течение 10 дней после поставки продукта. Однако, для того чтобы это произошло, необходимо сотрудничество истца, которое, как признано, истец не оказал ответчику, поэтому в данном случае, даже если ответчик не уведомил о результатах проверки в течение 10 дней после поставки продукта, в соответствии со статьей 9, пункт 4 контракта на разработку программного обеспечения, ответчик не считается принявшим данное программное обеспечение.

Решение Токийского окружного суда от 23 июня 2004 года (2004 год по григорианскому календарю)

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

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

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

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

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

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

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

https://monolith.law/corporate/project-management-duties[ja]

Сценарии обнаружения дефектов при приемке

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

https://monolith.law/corporate/defect-warranty-liability[ja]

Заключение

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

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