Можно ли передать подрядные и агентские контракты на повторное выполнение? Объяснение на примере разработки системы

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

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

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

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

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

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

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

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

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

Связанная статья: Различия и различия между контрактом подряда и контрактом на предоставление услуг в разработке систем[ja]

Юридическое значение повторного аутсорсинга разработки систем

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

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

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

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

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

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

Поэтому важно знать, разрешено ли использование повторного аутсорсинга в зависимости от типа контракта.

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

Связанные статьи: Юридические аспекты “срыва” проектов по разработке систем[ja]

По принципу договора поручения, повторное поручение недопустимо

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

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

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

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

Далее, если вы принимаете на себя разработку системы по договору подряда, в принципе вы свободны в повторном субподряде (подряде).

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

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

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

Связанные статьи: Что такое завершение работы в договоре подряда на разработку системы[ja]

Связанные статьи: На что следует обратить внимание при заключении договора подряда на разработку системы[ja]

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

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

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

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

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

Истец, в связи с построением данной системы, предполагая заключение договора о субподряде после заключения договора о поручении работы, продвигал разработку системы управления передачей и приемом данных о медицинском осмотре (система связи с медицинской системой и система сбора данных о медицинском осмотре) с X, который имеет знания и опыт в разработке подобных систем…

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

Решение Токийского окружного суда от 16 апреля 2012 года (Heisei 24)

Таким образом, в решении объясняется, что если характер договора является подрядом, то в принципе использование повторного субподряда (подряда) свободно, и не требуется согласие пользователя.

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

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

Связанные статьи: Может ли договор о разработке системы быть заключен без договора[ja]

Особенности принятия решения о возможности повторного субподряда

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

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

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

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

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

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

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

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

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

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

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

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

Внимание на Закон о субподряде

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

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

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

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

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

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

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

Связанные статьи: Применение Закона о субподряде к разработке систем и санкции за нарушение[ja]

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

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

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

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

Однако, если агентство по трудоустройству получило разрешение на основании Закона о предоставлении рабочей силы (Японский Закон о надлежащем управлении бизнесом по предоставлению рабочей силы и защите работников), то предоставление рабочей силы особо разрешено.

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

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

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

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

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

Связанные статьи: Критерии и меры противодействия маскированному подряду в IT-индустрии[ja]

Вывод: Если у вас возникли проблемы с повторным доверением, обратитесь к адвокату

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

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

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

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