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

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

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

Що таке відносини між розробкою системи та її скасуванням

Що таке скасування за цивільним кодексом

У зміненому Цивільному кодексі загальні положення про “скасування” договору визначені в статтях від 540 до 548. Скасування договору означає, що дія договору, який був укладений, може бути скасована згодом.

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

Крім того, якщо виникли збитки, можливе окреме відшкодування збитків.

Зв’язок між практикою розробки системи та скасуванням

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

У випадку, коли причиною є невиконання зобов’язань (затримка виконання)

(Приклад) Якщо постачальник не виконує поставку, незважаючи на те, що він перевищив початковий термін доставки

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

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

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

У випадку, коли причиною є відповідальність за дефекти

(Приклад) Якщо система, поставлена постачальником, має багато помилок або невідповідностей даних, і пізніше виявляється, що вона не придатна для практичного використання

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

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

Детальніше про відповідальність за дефекти описано в наступній статті.

https://monolith.law/corporate/defect-warranty-liability[ja]

Повідомлення про розірвання та пов’язані з ним юридичні питання

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

Громадянський кодекс (Японський ~) стаття 541: У випадку, коли одна із сторін не виконує своїх зобов’язань, інша сторона може встановити відповідний термін для виконання та повідомити про це, і якщо виконання не відбувається протягом цього терміну, інша сторона може розірвати договір.

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

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

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

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

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

Рішення Токійського окружного суду від 22 грудня 2004 року (Heisei 16)

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

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

• Було поставлено незавершену систему… → Невиконання зобов’язань
• Було поставлено систему з серйозними дефектами… → Відповідальність за дефекти

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

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

Що означає “відповідний період” в оголошенні?

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

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

В іншій статті ми пояснюємо визначення затримки виконання в розробці систем.

https://monolith.law/corporate/performance-delay-in-system-development[ja]

Яким чином повідомити про розірвання договору?

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

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

Підсумки

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