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

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

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

Укладання договору

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

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

Укладання договору на розробку системи

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

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

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

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

Вимога про виплату грошей у разі припинення договору про розробку системи після його укладання

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

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

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

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

Специфічність системного контенту

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

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

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

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

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

Постачальник подає кошторис та технічне завдання, а користувач затверджує та розпочинає замовлення

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

У судовому рішенні (рішення Нагоя District Court від 28 січня 2004 року (Heisei 16)) про укладання договору на розробку системи зазначено наступне:

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

У цьому судовому рішенні, постачальник отримав від користувача, який був місцевим самоврядуванням, доручення на впровадження системи фінансового обліку тощо. Було подано RFP (запит на пропозиції) з назвою “Про подання пропозиції щодо впровадження загальної системи адміністративної інформації (запит)”, на який було подано пропозицію та кошторис. Користувач подав “повідомлення про прийняття”. Постачальник не провів достатнього обговорення з користувачем щодо його бізнес-операцій тощо, і не було визнано, що він провів конкретне обговорення щодо змісту та вартості налаштування в межах користувача. Зміст пропозиції постачальника також не був конкретним, і не було ясно, що саме користувач затвердив, тому укладання договору не було визнано.

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

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

З фрази “після переговорів” стає зрозуміло, що якщо “переговори” щодо таких елементів договору, як зміст системи та сума винагороди, ще тривають, укладання договору важко визнати.

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

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

Постачальник подає технічне завдання та кошторис, а користувач затверджує та розпочинає замовлення

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

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

https://monolith.law/corporate/increase-of-estimate[ja]

Угода про розрахунок

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

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

Недбалість при укладанні договору

Починаючи переговори щодо укладання договору, сторони мають обов’язок дбати про те, щоб не порушувати майнові права одне одного відповідно до принципу добросовісності (стаття 1, пункт 2 Японського цивільного кодексу). Якщо договір не був укладений, можна вимагати відшкодування збитків, якщо були об’єктивні обставини, які дозволяли очікувати, що договір буде укладено, і була відповідальність. Це називається недбалістю при укладанні договору.

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

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

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

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

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

Стаття 512 Японського торгового закону

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

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

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

Підсумки

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

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

Якщо вам потрібно почати роботу до укладання договору, вам потрібно:

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

Можна сказати, що потрібно провести таке мислення.