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

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

Что такое разница между аутсорсингом и подрядом

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

https://monolith.law/corporate/system-development-contact-agreement[ja]

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

https://monolith.law/corporate/criteria-for-disguised-contract[ja]

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

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

Требования к исполнению обязательств существенно меняются в зависимости от того, является ли это аутсорсингом или подрядом

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

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

Истец утверждал, что после того, как стало окончательно ясно, что истец не может разработать программу для данной системы, 1 апреля 1986 года (Шоуа 61) между истцом и ответчиком было согласовано, что ответчик немедленно оплатит истцу стоимость разработки, сниженную до 550 тысяч иен из общей суммы 7106000 иен за два периода и стоимость проведения тренингового лагеря, и что после 1 апреля того же года ответчик примет работу истца, и что в отношении разработки системы текстовой информации ответчиком, истец направит персонал в форме аутсорсинга, и что количество персонала составит три человека, и что стоимость составит 55000 иен за двоих и 30000 иен за одного. Однако ответчик отрицает, что было достигнуто такое соглашение, и утверждает, что истец изначально принял заказ на создание программы для данной системы от ответчика и был обязан завершить его, и что нет никакого основания для того, чтобы заказчик, то есть ответчик, освободил истца от обязательства по созданию программы в дальнейшем и оплатил истцу затраты, которые истец понес в течение этого периода. Если истец действительно был обязан завершить программу, то утверждение ответчика вполне обоснованно.
Поэтому, прежде всего, следует рассмотреть, был ли истец обязан завершить программу в рамках договора о разработке программы для данной системы.
(Пропуск) По результатам рассмотрения доказательств, невозможно найти доказательства того, что истец не был обязан завершить данную программу в рамках данного договора. (Пропуск) И в результате допроса представителя истца, он утверждал, что данный договор был общим заказом, и что программа была разработана внутри компании-истца, и что истец предполагал, что он обязан завершить данную программу, и ни разу не отрицал, что он обязан это сделать. По результатам рассмотрения документов, неоспоримо установлено, что (пропуск) график работ предполагает, что истец обязан завершить данную программу, и что содержит график до завершения работы. Поэтому, на основании этого, наоборот, можно признать, что истец был обязан завершить программу в соответствии с договором. (Пропуск)
Кроме того, нет доказательств, противоречащих признанию того, что истец был обязан завершить данную программу.
Если это так, то, как утверждает ответчик, тот, кто не выполнил свою обязанность завершить программу, несет ответственность за неисполнение обязательств, и, конечно, не может требовать оплаты за подряд, если нет особых обстоятельств, и заказчик не должен безоговорочно освобождать такого лица от его договорных обязательств и, более того, оплачивать затраты, которые он понес до этого. Представитель истца в результате допроса утверждал, что даже если программа не была завершена, если он работал в соответствии с указаниями заказчика, он выполнил свои обязательства, выполнив работу в пределах указанного срока, и поэтому он может требовать оплату за программное обеспечение за выполненную работу, но это противоречит общепринятым представлениям о подрядном договоре, и в отрасли истца и ответчика, которые занимаются разработкой программного обеспечения, невозможно признать факт наличия практики оплаты вознаграждения, даже если работа не была завершена, в отличие от общепринятых представлений, даже с учетом показаний свидетелей, поэтому результаты допроса представителя истца являются его собственным мнением и не могут быть приняты.

Решение Токийского окружного суда от 22 февраля 2011 года (Хэйсей 23)

Что можно узнать из этого судебного прецедента

В частности, в этом судебном прецеденте стоит обратить внимание на следующее:

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

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

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

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

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

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

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

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

Заключение

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

https://monolith.law/corporate/difference-contract-dispatch-loan-labor-supply[ja]

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