Чи можна повторно доручити договір про неповне доручення та договір про підряд? Пояснення на прикладі розробки системи

На місцях розробки систем, часто можна спостерігати ситуації, коли вендор, який отримав доручення на розробку, передає це доручення іншому підряднику.

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

У цій статті ми розглянемо питання про можливість використання передачі доручення, розділивши їх на договори про часткове доручення та договори про підряд.

Що таке договір про розробку системи

У договорі про передачу розробки системи (SES-договір) зазвичай використовуються два типи: договір про підряд та договір про квазі-повірення.

У випадку з договором про підряд, гарантується завершення системи, яка є результатом роботи, до встановленого терміну. З іншого боку, у випадку з договором про квазі-повірення, завершення системи не є зобов’язанням, а замість цього гарантується, що вендор надасть технічні поради та підтримку користувачеві при виконанні робіт, таких як визначення вимог.

Розробка системи включає різні процеси, і вибір відповідного договору вимагається відповідно до змісту кожної роботи.

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

Для детального роз’яснення різниці між договором про підряд та договором про квазі-повірення в розробці систем, будь ласка, зверніться до наступної статті.

Пов’язана стаття: Різниця та відмінності між договором про підряд та договором про квазі-повірення в розробці систем[ja]

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

Повторне замовлення розробки системи може призвести до більш складних конфліктів, оскільки це включає багато сторін.

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

Якщо повторне замовлення не виконується, такі проблеми залишаються проблемами між користувачами та постачальниками.

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

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

Крім того, якщо саме повторне замовлення було заборонено, постачальник, який самовільно виконав повторне замовлення, може стати об’єктом іншої контрактної відповідальності.

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

У наступній статті детально розглядаються проблеми, пов’язані з розробкою систем. Будь ласка, зверніть на неї увагу.

Пов’язана стаття: Юридичні аспекти “згоряння” проектів з розробки систем[ja]

Якщо це договір про делегування обов’язків, то повторне делегування, як правило, неможливе

По-перше, якщо ви прийняли на себе розробку системи за договором про делегування обов’язків, то повторне делегування, як правило, заборонено.

Це пов’язано з тим, що суть делегування ґрунтується на довірі до сторони, якій делегують обов’язки, і використання інших виконавців без дозволу для виконання делегованих обов’язків може порушити цю довіру.

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

Якщо це договір про підряд, то принципово можливе повторне доручення

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

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

Однак, якщо розробка системи не буде завершена до кінцевого терміну, навіть якщо ви повторно доручили роботу іншому виконавцю, відносини з користувачем зобов’язують первинного виконавця нести безпосередню відповідальність за невиконання зобов’язань.

У наступних статтях детально розглядаються питання, на які слід звернути увагу при укладанні договору підряду щодо розробки системи. Будь ласка, ознайомтеся з ними.

Пов’язана стаття: Що означає завершення роботи в договорі підряду при розробці системи[ja]

Пов’язана стаття: На що слід звернути увагу при укладанні договору підряду при розробці системи[ja]

Важливі судові рішення щодо договорів підряду та субпідряду

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

У цьому випадку, виконавець подав позов про відшкодування збитків, спричинених одностороннім зміненням думки користувача.

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

У висновку суд визнав, що плата за доручення субпідряднику також входить до сфери відшкодування збитків.

Позивач, при розробці цієї системи, вже просував розробку системи управління передачею та отриманням медичних даних (медична система зв’язку та система збору медичних даних) з X, який має знання та досвід у розробці подібних систем, передбачаючи укладання договору про доручення роботи після укладання договору про доручення роботи у цій справі…

З іншого боку, відповідач стверджує, що він не приймав роботу, яку X виконав як субпідрядник, для позивача… Однак… не було заборонено використовувати субпідрядників при розробці цієї системи позивачем, тому незалежно від того, чи приймав відповідач X як субпідрядника, плата за доручення роботи, яку позивач заплатив X, є збитком позивача

Рішення Токійського окружного суду від 16 квітня 2012 року (2012 рік за Григоріанським календарем)

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

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

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

Пов’язана стаття: Чи може договір про розробку системи бути укладений без договору[ja]

Особливості прийняття рішення про можливість повторного доручення

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

При підрядному договорі, вільне повторне доручення неможливе, якщо є спеціальна угода

За підрядним договором, в принципі, можна вільно здійснювати повторне доручення.

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

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

Тому, з боку користувача, може бути встановлено спеціальну угоду, яка забороняє повторне доручення без попереднього згодження, щоб уникнути небажаного повторного доручення.

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

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

Повторне доручення можливе, навіть якщо це договір про делегування, якщо користувач погоджується

З іншого боку, за договором про повторне доручення, в принципі, повторне доручення неможливе.

Однак, відповідне повторне доручення може допомогти досягти гладкого та повного розвитку системи. Тому, згідно з цивільним законодавством, якщо користувач погоджується на повторне доручення, можливе повторне доручення, навіть якщо це договір про делегування.

Тому, навіть якщо ви уклали договір про делегування, ви зможете здійснювати повторне доручення, якщо ви зрозумієте значення повторного доручення для користувача та отримаєте його згоду.

Увага на Закон про субпідряд

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

У сфері розробки систем, угоди, за якими замовник повторно доручає розробку субпідряднику, можуть підпадати під дію Закону про субпідряд.

Якщо Закон про субпідряд застосовується, замовнику, який є батьківським підприємством, накладаються обов’язки створення та зберігання певних документів, заборона відмови від прийняття предмету угоди або його повернення, тощо.

У разі порушення цих обов’язків та заборон може бути накладено штраф або може бути винесено рекомендацію.

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

Однак, якщо користувач має можливості розробки системи і виробляє систему для власного використання в компанії, Закон про субпідряд може застосовуватися до угод, за якими користувач доручає розробку системи іншому підприємцю, тому потрібно бути обережним.

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

Пов’язана стаття: Роз’яснення застосування Закону про субпідряд до розробки систем та санкцій за порушення[ja]

Увага на маскувані підрядні роботи

“Маскувані підрядні роботи” – це коли, хоча контракт формально є підрядним або дорученням, замовник керує та використовує працівників підрядника, а насправді це є відправкою працівників.

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

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

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

У випадку “маскуваних підрядних робіт”, підрядник не отримує дозволу як постачальник працівників, а просто отримує доручення на розробку від користувача.

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

Тому це порушує як Закон про відправку працівників, так і Закон про стабілізацію зайнятості, і може призвести до ув’язнення або штрафу.

Тому, як підрядник, ви повинні керувати та контролювати своїх працівників, щоб не бути визнаними як “маскувані підрядні роботи”.

У наступній статті детальніше розглядається питання “маскуваних підрядних робіт”. Будь ласка, зверніть на неї увагу.

Пов’язана стаття: Критерії та заходи протидії маскуваним підрядним роботам в IT-індустрії[ja]

Підсумок: Якщо у вас виникають проблеми з повторним дорученням, зверніться до адвоката

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

Для розробки системи важливо, щоб користувачі та вендори активно спілкувалися та розвивали проект на основі взаємної довіри.

Тому, незалежно від того, який тип договору ви обираєте, важливо попередньо узгодити з користувачем та вендором можливість повторного доручення, а в деяких випадках може бути важливо встановити спеціальні умови.

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