Що таке прийняття розробки системи та ситуації застосування положень про прийняття за умовчанням

Сцена, де юридичні проблеми часто виникають під час розробки системи, – це етап “приймання”.

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

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

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

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

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

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

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

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

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

Уважно ставтеся до умов прийняття роботи

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

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

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

Що таке умова про вважаєму прийняття?

(Прийняття даного програмного забезпечення) Стаття 28
Серед поставлених товарів, щодо даного програмного забезпечення, замовник повинен перевірити, чи відповідає програмне забезпечення специфікаціям системи, виконуючи інспекцію на основі специфікацій інспекції, визначених у окремому договорі, протягом визначеного періоду (надалі – “період інспекції”).

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

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

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

https://www.meti.go.jp/policy/it_policy/keiyaku/model_keiyakusyo.pdf[ja]

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

Вважати…
→ Навіть якщо насправді це не так, воно вважається таким за законом

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

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

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

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

Судові випадки, пов’язані з положеннями про вважаємі умови

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

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

Вирок Токійського окружного суду від 29 лютого 2012 року (Heisei 24)

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

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

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

Вирок Токійського окружного суду від 23 червня 2004 року (Heisei 16)

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

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

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

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

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

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

https://monolith.law/corporate/project-management-duties[ja]

Патерни виявлення дефектів під час приймання

Однак, на етапі приймання, можливе виявлення недоліків системи (у юридичному контексті часто використовується слово “дефект”). Щодо юридичних питань у такому випадку, детальніше дивіться в наступній статті.

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

Підсумки

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

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