Czym są akceptacja rozwoju systemu i przypadki stosowania klauzuli domniemanej akceptacji?

W kontekście rozwoju systemów, etap, który często prowadzi do problemów prawnych, to “odbior”.

“Odbiór” odnosi się do obowiązku inspekcji i kontroli, który pojawia się po stronie zamawiającego, gdy wykonawca dostarcza produkt. Jeśli zamawiający nie przeprowadzi “odbioru” przez długi czas po dostarczeniu, dostawca, czyli dostawca, zostanie postawiony w niepewnej sytuacji prawnej.

Wiele umów zawiera klauzulę “domniemanego odbioru” w celu rozwiązania takich problemów.

W tym artykule omówimy, kiedy stosuje się “domniemany odbiór”, na podstawie rzeczywistych przypadków sądowych.

Co to jest akceptacja w rozwoju systemów?

Na wstępie, “akceptacja” w projekcie rozwoju systemu oznacza, że użytkownik, jako zamawiający, sprawdza i kontroluje, czy dostarczone przez dostawcę (tutaj mówimy o systemie IT) produkty spełniają specyfikacje zgodne z zamówionym celem.

Z punktu widzenia dewelopera, można to również traktować jako etap testowania, sprawdzający, czy system został naprawdę ukończony.

Praca polegająca na tworzeniu systemów IT ma charakterystykę, która łatwo daje dużą swobodę dostawcy, co może prowadzić do rozbieżności między produktem, który faktycznie stworzyli, a tym, czego oczekiwał użytkownik.

Mówiąc ogólnie, zaliczenie akceptacji oznacza, że użytkownik sam potwierdził, że produkt spełniający cel, o który prosił (lub cel, dla którego poprosił o rozwój systemu), został faktycznie dostarczony.

W praktyce, nawet jeśli można przewidzieć, że w rzeczywistości mogą pojawić się wady w systemie po akceptacji, wiele umów zawiera warunek płatności za zaliczenie akceptacji.

Uważaj na klauzulę domniemanej akceptacji

Kiedy wystąpią problemy podczas fazy akceptacji, zarówno użytkownik, jak i dostawca mogą znaleźć się w trudnej sytuacji.

Na przykład, co się stanie, jeśli dostawca stworzy produkt, a mimo że już go zaprezentował, osoba odpowiedzialna po stronie użytkownika z jakiegoś powodu nie przystąpi do akceptacji?

Przewidując takie sytuacje, w umowach na rozwój systemów często zawiera się coś, co nazywa się “klauzulą domniemanej akceptacji”.

Czym jest klauzula domniemanej akceptacji?

(Akceptacja oprogramowania) Artykuł 28
W przypadku oprogramowania będącego przedmiotem dostawy, strona A musi przeprowadzić inspekcję na podstawie specyfikacji inspekcji z poprzedniego artykułu w okresie określonym w umowie indywidualnej (zwany dalej “okresem inspekcji”) i sprawdzić, czy specyfikacja systemu i oprogramowanie są zgodne.

2. Jeżeli oprogramowanie spełnia wymogi inspekcji, strona A powinna podpisać i pieczętować certyfikat zgodności i przekazać go stronie B. Jeżeli oprogramowanie nie spełnia wymogów inspekcji, strona A powinna natychmiast dostarczyć stronie B pisemne wyjaśnienie konkretnych powodów niespełnienia wymogów i zażądać poprawek lub uzupełnień. Jeżeli powody niespełnienia wymogów są uzasadnione, strona B powinna dostarczyć poprawki bezpłatnie w określonym terminie po konsultacjach, a strona A powinna przeprowadzić ponowną inspekcję w zakresie określonym w poprzednim artykule.

3. Nawet jeżeli certyfikat zgodności nie jest dostarczany, jeżeli strona A nie zgłosi sprzeciwu na piśmie z konkretnym uzasadnieniem w okresie inspekcji, oprogramowanie uważa się za zgodne z inspekcją określoną w tym artykule.

4. Zgodność z inspekcją określoną w tym artykule oznacza zakończenie akceptacji oprogramowania.

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

W kontekście prawnym, punkt 3, który mówi, że “jest uważane za”, jest jednym z punktów, na które warto zwrócić uwagę. Jeżeli spojrzymy na to z perspektywy terminologii prawnej, “uważać za” i “przypuszczać” mają zupełnie różne znaczenia.

Uważać za…
→Nawet jeśli rzeczywiście nie jest to tak, jest traktowane tak samo jak w przypadku, gdy jest to prawda z punktu widzenia prawa.

(Przykład) Jeśli operujesz smartfonem podczas testu, jest to “uważane za” ściąganie.
→Niezależnie od tego, czy rzeczywiście operowałeś smartfonem w celu ściągania, zostaną podjęte takie same działania jak w przypadku ściągania.

Przypuszczać…
→Jeżeli nie ma szczególnych dowodów przeczących faktowi, że jest to prawda, jest traktowane jako fakt.

(Przykład) Jeśli patrzysz na smartfon podczas testu, jest to “przypuszczane” jako ściąganie.
→Zasada jest taka, że uważa się, że doszło do ściągania, ale jeśli można udowodnić, że był to inny cel niż ściąganie, to ocena ta może zostać zmieniona później. (Chociaż prawdopodobnie nie usłyszysz takiego ogłoszenia na miejscu egzaminu.)

W związku z tym, “przypuszczać” i “uważać za” mają zupełnie różne poziomy trudności do obalenia. “Niezależnie od tego, czy akceptacja została zatwierdzona, jest traktowana tak samo jak w przypadku zatwierdzenia” – to jest to, co jest tutaj zawarte.

Przykłady sądowe związane z klauzulą domniemanej akceptacji

Istnieją przykłady, kiedy klauzula domniemanej akceptacji miała decydujące znaczenie w sądzie. Na przykład, w wyroku cytowanym poniżej, użytkownik nie przystąpił do akceptacji w określonym czasie po dostarczeniu produktu i później złożył pozew, twierdząc, że niektóre wymagane funkcje nie zostały zaimplementowane, co doprowadziło do procesu sądowego. Jednak sąd orzekł, że dostawa została już zakończona, opierając się na klauzuli domniemanej akceptacji.

W niniejszej umowie, firma Y zobowiązała się do przeprowadzenia inspekcji bez zwłoki po dostarczeniu systemu i do powiadomienia na piśmie o akceptacji w ciągu 10 dni, a jeżeli powiadomienie nie zostanie przekazane do wyznaczonego terminu, uważa się, że akceptacja została zatwierdzona, a ponieważ nie można uznać, że zostało powiadomienie o niespełnieniu wymogów inspekcji, można stwierdzić fakt dostawy i akceptacji.

Wyrok Sądu Okręgowego w Tokio z dnia 29 lutego 2012 roku (rok 24 ery Heisei)

Z drugiej strony, istnieją również przykłady sądowe, które zaprzeczają zastosowaniu tej klauzuli domniemanej akceptacji i uznają naruszenie obowiązków przez dostawcę.

W przypadku cytowanego poniżej wyroku, w przeciwieństwie do poprzedniego przykładu sądowego, dostawca nie udzielił niezbędnej współpracy w celu przeprowadzenia akceptacji.

Powód (dostawca) twierdzi, że na mocy artykułu 9, ust. 4 umowy o rozwój oprogramowania, pozwany (użytkownik) jest uważany za akceptującego produkt, ponieważ nie powiadomił o wynikach inspekcji w ciągu 10 dni od dostarczenia produktu. Jednakże, aby osiągnąć taki wynik, niezbędna jest współpraca powoda, a powód nie udzielił takiej współpracy pozwanej, więc w tym przypadku, nawet jeśli pozwany nie powiadomił o wynikach inspekcji w ciągu 10 dni od dostarczenia produktu, nie można uznać, że pozwany zaakceptował oprogramowanie na mocy artykułu 9, ust. 4 umowy o rozwój oprogramowania.

Wyrok Sądu Okręgowego w Tokio z dnia 23 czerwca 2004 roku (rok 16 ery Heisei)

Można przypuszczać, że celem klauzuli domniemanej akceptacji jest uwolnienie dostawcy z niepewnej sytuacji, w której “chociaż chcemy szybko przejść do akceptacji, nie możemy tego zrobić z powodu jednostronnych okoliczności po stronie użytkownika, co powoduje opóźnienia w pracy”, i utrzymanie sprawiedliwych relacji między obiema stronami.

W związku z tym, nie można po prostu powiedzieć, że “korzystając z klauzuli domniemanej akceptacji, spróbujmy zyskać na czasie i odwlekać akceptację, a potem narzucić wadliwy produkt”.

Jeśli produkt jest “uważany za” zaakceptowany, użytkownik musi zapłacić wynagrodzenie za rozwój systemu. Biorąc pod uwagę tę poważną kwestię, sąd dąży do sprawiedliwego osądu, uwzględniając również sytuację współpracy ze strony dostawcy.

Protokoły z postępów w rozwoju systemu mogą być ważnym dowodem wspierającym takie decyzje. Szczegóły na ten temat są omówione w poniższym artykule.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Co więcej, jeśli chodzi o to, jakie obowiązki powinien ponosić dostawca jako ekspert od rozwoju systemów wobec projektu, proszę zobaczyć poniższy artykuł.

Nawet jeśli akceptacja powinna być przeprowadzana zasadniczo przez stronę użytkownika, dostawca, jako ekspert od rozwoju systemów, powinien również udzielać różnego rodzaju współpracy w zakresie akceptacji. Ten punkt stanie się naturalny, jeśli weźmiemy pod uwagę treść poniższego artykułu.

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

Wzorce wykrywania wad podczas odbioru

Oczywiście, na etapie odbioru, może się zdarzyć, że zostaną wykryte braki w systemie (w języku prawnym często używa się słowa “wada”). W takim przypadku, problem prawny jest omówiony bardziej szczegółowo w poniższym artykule.

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

Podsumowanie

W kontekście rozwoju systemów, “akceptacja” zasady wskazuje na pełne wykonanie obowiązków po stronie dostawcy, co jest niezwykle ważne zarówno dla użytkowników, jak i dla dostawców. Aby uniknąć poważnych problemów, zarówno zamawiający, jak i wykonawca, powinni dobrze zrozumieć klauzulę “akceptacji domniemanej”.

Przyjmując na wypadek, że proces akceptacji może nie przebiegać płynnie, obie strony powinny dokładnie uzgodnić swoje oczekiwania dotyczące postanowień związanych z akceptacją już na etapie zawierania umowy. Jest to uważane za kluczowe dla zapewnienia sprawnego przebiegu procesu.