Про закони та судові випадки, що стосуються розрізнення між аутсорсингом та підрядом у сфері ІТ

У проектах IT-сфери часто буває, що таланти багатьох компаній залучаються до одного проекту. У таких випадках, місце роботи інженера, що бере участь у проекті, часто відрізняється від місцезнаходження компанії, до якої він належить. Це відноситься до так званих випадків постійного розміщення клієнтів та SES. Неясність щодо форми зайнятості та форми контракту інженера, який працює на місці, може стати ризиком для подальшого конфлікту щодо прав працівників, а також може стати ризиком “спалаху” самого проекту. У цій статті ми розглянемо різницю між делегуванням та підрядом, які часто стають неясними у практичній роботі, а також пояснимо, який вплив такі проблеми з контрактами можуть мати на гладке виконання всього проекту.

Яка різниця між відправкою та підрядом

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

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

У вищезазначеній статті пояснюється, що сутнісну особливість підрядного договору становить те, що “завершення роботи” є умовою виконання зобов’язань. Також пояснюється, що важливо чітко визначити умови прийняття при укладанні договору, щоб запобігти виникненню проблем. Якщо ви відправляєте людей на місце роботи на основі підрядного договору, це лише комерційна угода між компаніями, тому замовник/місце роботи не має обов’язку дотримуватися трудового законодавства. Однак, в замін, вони не можуть законно віддавати прямі накази цим інженерам. Якщо ви не врахуєте ці пункти, навіть якщо на поверхні було укладено підрядний договір, існує ризик, що він буде визнаний як незаконне постачання робочої сили, або “прихований підряд”.

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

Справа, яка переросла в конфлікт через неясність різниці між відрядженням та підрядом

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

Вимоги до виконання зобов’язань значно відрізняються між відправленням та підрядом

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

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

Позивач стверджував, що після того, як стало відомо про неможливість розробки програми для цієї системи позивачем, 1 квітня 1986 року (Шоуа 61 рік) між позивачем та відповідачем було укладено угоду про те, що відповідач швидко сплатить позивачу вартість розробки, зменшену до 5,5 мільйонів єн з 7,106,000 єн за два терміни та доплату за проведення тренувального табору, а відповідач візьме на себе роботу позивача з 1 квітня того ж року, а щодо розробки системи текстової інформації відповідачем, позивач відправить персонал у формі відправлення праці, кількість відправленого персоналу буде три особи, а ціна за одиницю буде 550,000 єн за двох осіб і 300,000 єн за одну особу. Результати допиту представника позивача підтверджують це.
Однак відповідач заперечує наявність такої угоди, і позивач, який спочатку прийняв замовлення від відповідача на створення програми для цієї системи, мав обов’язок її завершити, і людина, яка знаходиться в такому становищі, не змогла завершити її і не могла передати програму, відповідач, який є замовником, стверджує, що неможливо, щоб він звільнив позивача від обов’язку створення в майбутньому і платив за витрати, які позивач зробив за цей час. Дійсно, якщо позивач мав обов’язок завершити програму, тоді відповідач має право стверджувати.
Тому спочатку розглянемо, чи мав позивач обов’язок завершити у контракті на розробку програми для цієї системи.
При розгляді доказів, не можна знайти докази, які б дозволили визнати, що позивач не мав обов’язку завершити цю програму в цьому контракті. (Пропущено) І представник позивача також у своїх відповідях на допит зазначив, що цей контракт був прийнятий в цілому, і програму розробляли в компанії позивача, і позивач припускав, що він мав обов’язок завершити цю програму, і ніколи не заперечував, що він мав цей обов’язок, це очевидно. Дивлячись на документи, без суперечок встановлено, що (пропущено) графік роботи передбачає, що позивач має обов’язок завершити цю програму, і записує графік до її завершення, тому, згідно з цим, навпаки, можна визнати, що позивач мав контрактний обов’язок завершити програму. (Пропущено)
Крім того, немає доказів, які б суперечили визнанню, що позивач мав обов’язок завершити цю програму.
Таким чином, як стверджує відповідач, людина, яка не виконала обов’язок створення програми, має відповідати за невиконання зобов’язань, але не може вимагати оплати за підряд, це очевидно, і якщо немає особливих обставин, замовник не має погоджуватися на безумовне звільнення від контрактних обов’язків і, більше того, на оплату витрат, зроблених до цього часу. Представник позивача в своїх відповідях на допит зазначив, що навіть якщо програма не була завершена, якщо він працював відповідно до інструкцій замовника, він виконав обіцяну роботу в межах вказаного терміну, тому він може вимагати оплату за програмне забезпечення за виконану роботу, але це суперечить загальному розумінню контракту на підряд, і в галузі позивача та відповідача, які займаються розробкою програмного забезпечення, не можна визнати факт, що є звичай платити винагороду, навіть якщо робота не була завершена, відмінний від загального розуміння, навіть при врахуванні свідчень свідків, тому результати допиту представника позивача можна прийняти лише як його власну думку.

Вирок Токійського окружного суду від 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]

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