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

Якщо після поставки замовленої системи виникла помилка, як правово вирішити цю проблему?

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

“Відповідальність за невідповідність договору” була введена на заміну “відповідальності за гарантію від дефектів”, яка була скасована після змін до Цивільного кодексу в 2017 році (Григоріанський календар, Західний календар). Тому необхідно звернути увагу на те, як ці зміни впливають на розробку систем та програмного забезпечення.

Часто виникають проблеми після поставки. Щоб уникнути таких проблем, ми пояснимо зміст “відповідальності за невідповідність договору” та вплив змін.

Зміни в цивільному кодексі щодо відповідальності за невідповідність договору

«Закон про зміну деяких положень Цивільного кодексу Японії» був опублікований 2 червня 2017 року (29 рік ери Хейсей) і набрав чинності 1 квітня 2020 року.

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

З моменту прийняття Закону про зобов’язання в 1896 році (29 рік ери Мейджі), протягом майже 120 років він майже не переглядався.

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

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

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

Що таке невідповідність договору

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

Цей термін “невідповідність договору” був введений замість традиційного терміну “дефект” внаслідок змін у Цивільному кодексі (японський Цивільний кодекс).

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

При визначенні наявності “невідповідності договору” особливу увагу приділяють угоді сторін та суті договору.

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

Випадки, коли неполадки в програмному забезпеченні відповідають “невідповідності договору”

У випадку, коли програмне забезпечення викликає проблеми та затримки в ремонті

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

Наприклад, є судовий прецедент, коли визналося, що відповідає “невідповідності договору” або “дефекту” в японському праві, якщо виникають проблеми, такі як те, що пошукова обробка системи запиту на складські запаси, яку ви впровадили, займає більше 30 хвилин, і ви змушені створювати ручний реєстр складських запасів для відповіді на запити від клієнтів (Рішення Токійського окружного суду від 22 квітня 2002 року (Heisei 14)).

У випадку, коли неполадки поступово виявляються

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

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

Випадки, коли неполадки програмного забезпечення не відповідають “невідповідності договору”

У випадку, коли виправлення було зроблено без затримки або були вжиті альтернативні заходи

Згідно з судовою практикою, навіть якщо користувач вказує на наявність помилок або інших проблем, якщо виправлення було зроблено без затримки, або були вжиті альтернативні заходи, визнані відповідними після консультацій з користувачем, це не вважається “дефектом” (Рішення Токійського окружного суду від 18 лютого 1998 року (Heisei 9)).

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

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

Це можна розглядати так само і в рамках сучасного поняття “невідповідності договору”.

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

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

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

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

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

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

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

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

【Додаток】У випадку, коли проблема виникла через вказівки користувача

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

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

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

https://monolith.law/corporate/user-obligatory-cooporation[ja]

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

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

Вимога про виправлення

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

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

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

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

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

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

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

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

Розірвання договору

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

У вже представленому судовому рішенні, було визнано розірвання договору через те, що було виявлено дефект, який змушував відмовитися від подальшого використання встановленої системи, такий як те, що процес пошуку в системі перевірки запасів займав більше 30 хвилин, і це занадто довго, і виникали проблеми, які перешкоджали використанню терміналу взагалі (Рішення Токійського окружного суду від 22 квітня 2002 року (Heisei 14)).

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

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

Вимога про зменшення винагороди

Право на вимогу про зменшення винагороди було введено після внесення змін.

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

Період відповідальності

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

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

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

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

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

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

Відмова від оплати винагороди

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

Ключові моменти умов договору, враховуючи невідповідність договору

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

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

Пункт 1: Події та область, які стають предметом невідповідності договору

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

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

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

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

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

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

Пункт 2: Уточнення гарантійного терміну

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

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

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

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

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

Пункт 3: Реагування на виникнення невідповідності договору

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

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

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

Зміни в Цивільному кодексі Японії внесли значний вплив на правові відносини у сфері розробки систем та програмного забезпечення.

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

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

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