MONOLITH LAW OFFICE+81-3-6262-3248Dni powszednie 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Czy umowa o rozwój systemu jest ważna bez umowy pisemnej?

IT

Czy umowa o rozwój systemu jest ważna bez umowy pisemnej?

W przypadku rozwoju systemów, nie jest rzadkością, że deweloperzy przystępują do pracy przed sporządzeniem umowy. Jednakże, taki proces jest w praktyce “niebezpieczny”. Jeżeli umowa nie została sporządzona, istnieje ryzyko, że w przypadku problemów w późniejszym czasie, zamawiający może stwierdzić, że “umowa jeszcze nie została zawarta, a zatem nie ma potrzeby płacenia wynagrodzenia”. W rzeczywistych sporach związanych z rozwojem systemów, nie jest rzadkością, że kwestionowana jest sama zawarcie umowy, a następnie wydawane są decyzje niekorzystne dla deweloperów. Dla deweloperów istnieje ryzyko, że jeżeli zamawiający zdecyduje się na zakończenie projektu lub przejście do innej firmy, nie będą mogli otrzymać wynagrodzenia. Co więcej, jak zostanie to wyjaśnione później, nawet jeśli umowa została sporządzona, może zdarzyć się, że zawarcie umowy zostanie zaprzeczone.

W tym miejscu wyjaśnimy, jakie są kryteria dla zawarcia umowy o rozwój systemu oraz jakie są prawne konsekwencje, gdy nie można potwierdzić zawarcia umowy i żąda się zapłaty.

Zawarcie umowy

Zasada jest taka, że umowa jest zawierana, gdy obie strony zgadzają się co do elementów umowy (zgodność oświadczenia woli składającego ofertę i oświadczenia woli akceptującego ofertę).

Gdy umowa zostaje zawarta, obie strony są związane umową, a jeśli jedna ze stron nie realizuje treści umowy, druga strona może zmusić do wykonania lub żądać odszkodowania za niewykonanie za pomocą sądu. “Elementy umowy” muszą być określone lub konkretne do stopnia, który pozwala na egzekwowanie wykonania i stwierdzenie niewykonania.

Zawarcie umowy to bardzo ważna kwestia

Zawarcie umowy o rozwój systemu

Natura umowy o rozwój systemu polega głównie na umowie o dzieło i umowie o zlecenie. Umowa o dzieło to obietnica wykonania pracy i zapłaty za nią. Umowa o zlecenie za wynagrodzeniem to obietnica wykonania zadania i zapłaty za nie.

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

Dlatego, jeśli istnieje porozumienie między stronami co do “treści pracy lub zadania” i “kwoty wynagrodzenia”, które są elementami umowy, uznaje się, że umowa została zawarta.

Należy zauważyć, że umowa może być zawarta nawet na podstawie samej obietnicy ustnej, a umowa pisemna nie jest wymagana.

Żądanie zwrotu pieniędzy w przypadku anulowania umowy o rozwój systemu po jej zawarciu

Jeśli umowa o rozwój systemu została zawarta, a użytkownik jednostronnie oświadczy, że ją anuluje, prawnie oznacza to, że zostało złożone powiadomienie o rozwiązaniu umowy.

Jeśli zawarta jest umowa o dzieło, dostawca ma prawo do odszkodowania, jeśli użytkownik może rozwiązać umowę w dowolnym momencie przed zakończeniem pracy (zgodnie z art. 641 Kodeksu cywilnego Japonii). Dlatego, jeśli użytkownik nie wypłaci odszkodowania, dostawca może żądać odszkodowania za “szkodę”, która jest równa kosztom poniesionym przez dostawcę do tego momentu i kwotą wynagrodzenia, które mogłoby być uzyskane, pomniejszoną o koszty zaoszczędzone dzięki uniknięciu zakończenia systemu.

Z drugiej strony, jeśli zawarta jest umowa o zlecenie, zleceniobiorca może żądać wynagrodzenia proporcjonalnie do stopnia wykonania, gdy zlecenie kończy się w trakcie wykonania (zgodnie z poprawionym art. 648 ust. 3 Kodeksu cywilnego Japonii). Dlatego dostawca może żądać zapłaty za pracę, którą już wykonał.

Sukces lub porażka umowy o rozwój systemu

Specyfika treści systemu

Zazwyczaj, w transakcjach między firmami, zwłaszcza gdy kwoty są duże, używa się dokumentów pisemnych, więc jeśli umowa została sporządzona, jej zawarcie jest łatwiejsze do uzyskania.

System, który jest celem rozwoju, stopniowo konkretyzuje się poprzez różne procesy, dlatego specyfika treści systemu, która jest elementem umowy o zlecenie, jest uznawana za wystarczającą, jeśli zrozumie się zakres i ogólny zarys systemu, który ma zostać zsystematyzowany.

W przypadku sądowym, nie było sporu o zawarcie umowy podstawowej i umowy o zachowaniu poufności, a w umowie podstawowej zawarto zapis, że “zlecenie wsparcia technicznego dla biznesu e-commerce, wsparcie budowy strony internetowej i powiązane usługi”, ale nie określono konkretnych treści biznesu e-commerce, zakresu usług zleconych, zakresu rozwoju i projektowania jako systemu, dlatego zawarcie umowy zostało zaprzeczone.

Nawet jeśli stworzysz umowę podstawową na rozwój systemu, treść pracy lub usługi jest abstrakcyjna i nie można powiedzieć, że została określona, więc zawarcie umowy jest trudne do uzyskania. Zawarcie umowy może być uzyskane przez umowy, takie jak umowy, które opisują treść pracy lub usługi, kwotę wynagrodzenia, w sposób wystarczająco konkretny, aby stały się podstawą do egzekwowania wykonania i stwierdzenia niewykonania.

Szczegółowe wyjaśnienia dotyczące punktów, na które należy zwrócić uwagę w umowach między inżynierami indywidualnymi a korporacjami, znajdują się w poniższym artykule.

https://monolith.law/corporate/engineer-joint-enterprise-contract[ja]

Dostawca przedstawia wycenę i specyfikację, a użytkownik zatwierdza i zamawia

Zazwyczaj, w transakcjach między firmami, używa się dokumentów pisemnych, więc jeśli umowa nie została sporządzona, zawarcie umowy jest trudne do uzyskania. W przypadku rozwoju systemu często zaczyna się pracę przed sporządzeniem umowy, ale jak myślisz o sukcesie lub porażce umowy w takim przypadku?

W wyroku sądu (wyrok Sądu Okręgowego w Nagoya z dnia 28 stycznia 2004 roku (rok 16 ery Heisei)), na temat zawarcia umowy o zlecenie rozwoju systemu, stwierdza się, że:

  • Po negocjacjach dotyczących specyfikacji itp. między dostawcą a użytkownikiem,
  • Dostawca przedstawia specyfikację i wycenę,
  • Użytkownik zatwierdza to i składa zamówienie, co prowadzi do zawarcia umowy.

W tym wyroku sądowym, dostawca otrzymał zlecenie od samorządu, który jest użytkownikiem, na wdrożenie systemu finansowo-księgowego itp., a RFP zatytułowany “O przedłożeniu propozycji dotyczącej wdrożenia zintegrowanego systemu informacji administracyjnej (na żądanie)” został przedstawiony, a dostawca przedstawił propozycję i wycenę w odpowiedzi na to, a użytkownik przedstawił “powiadomienie o przyjęciu”. Dostawca nie przeprowadził wystarczających badań, takich jak spotkania z użytkownikiem na temat treści pracy użytkownika itp., a nie stwierdzono, że wewnątrz użytkownika przeprowadzono konkretne badania dotyczące treści i kosztów dostosowania, a treść propozycji dostawcy nie była konkretna, a nie było jasne, co użytkownik zatwierdził, więc zawarcie umowy nie zostało uzyskane.

Dodatkowe wyjaśnienia dotyczące zawarcia umowy, jak opisano w wyroku sądowym, są podane poniżej, biorąc pod uwagę inne wyroki sądowe itp.

Po negocjacjach dotyczących specyfikacji itp. między dostawcą a użytkownikiem

Z faktu, że “po negocjacjach”, jeśli treść systemu i kwota wynagrodzenia, które są elementami umowy, są “w trakcie negocjacji”, zawarcie umowy jest trudne do uzyskania, ponieważ nie doszło do porozumienia.

Jednakże, w umowie o zlecenie, można ustalić cenę na podstawie ceny rynkowej, więc jeśli użytkownik zatwierdził treść systemu i “mniej więcej” kwotę wynagrodzenia, wyrok sądowy uznał, że zawarto umowę o zlecenie za cenę rynkową.

Aby móc powiedzieć, że “po negocjacjach”, dostawca powinien dokładnie zbadać treść pracy użytkownika, treść systemu itp. poprzez spotkania z użytkownikiem itp. i zachować to w rekordzie, takim jak e-mail lub protokół.

Dostawca przedstawia specyfikację i wycenę, a użytkownik zatwierdza to i składa zamówienie

  • Jeśli użytkownik wyda zamówienie lub zamówienie, zawarcie umowy jest łatwiejsze do uzyskania. Jeśli dostawca przedstawi wniosek lub przeprowadzi pracę na podstawie zamówienia itp., będzie łatwiej uzyskać “porozumienie”, co ułatwi uzyskanie zawarcia umowy.
  • Wewnętrzne dokumenty użytkownika często mówią o planowanym zawarciu umowy w przyszłości, co utrudnia uzyskanie zawarcia umowy. Jednakże, jeśli nie ma takiego zapisu i możliwe jest uzyskanie jak najbardziej konkretnego opisu treści rozwoju systemu i kwoty wynagrodzenia, które są elementami umowy, to będzie działać na korzyść uzyskania zawarcia umowy.
  • Memorandum, umowa, potwierdzenie, jeśli są one na podstawie przyszłego zawarcia umowy lub są abstrakcyjne, zawarcie umowy jest trudne do uzyskania.
  • Jeśli pieczęć nie jest naciśnięta na projekcie umowy, zawarcie umowy jest trudne do uzyskania, ponieważ pieczęć oznacza zawarcie umowy.
  • Wycena służy jako dowód na uzgodnioną kwotę wynagrodzenia między stronami.

Na przykład, w przypadku rozwoju systemu, gdy proces jest na pewnym etapie, szczegółowe informacje na temat tego, czy można zażądać dodatkowych kosztów za zmiany specyfikacji po fakcie lub dodanie funkcji, znajdują się w poniższym artykule.

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

Porozumienie o rozliczeniu

Jeśli wykonujesz pracę na podstawie instrukcji od użytkownika, zakładając, że zawrzesz umowę, w przypadku przerwania pracy, możesz uzyskać “porozumienie o rozliczeniu”, które pozwala na rozliczenie wynagrodzenia za pracę wykonaną do tej pory. Aby to porozumienie było łatwiejsze do uzyskania, powinieneś uzyskać od użytkownika zapis na piśmie, takie jak wewnętrzny dokument, dotyczący metody rozliczenia wynagrodzenia w przypadku, gdy umowa nie zostanie zawarta, lub uzyskać zgodę osoby uprawnionej użytkownika na dokument sporządzony przez dostawcę.

Prawna konstrukcja żądania pieniędzy w przypadku, gdy nie doszło do zawarcia umowy

Co się dzieje, gdy nie doszło do zawarcia umowy?

Zaniedbanie w zawieraniu umowy

Gdy rozpoczynają się negocjacje w celu zawarcia umowy, strony mają obowiązek, na mocy zasady dobrej wiary (japońskie Prawo Cywilne, artykuł 1, ustęp 2), dołożyć wszelkich starań, aby nie naruszyć majątku drugiej strony. Jeśli nie doszło do zawarcia umowy, można złożyć roszczenie o odszkodowanie, jeśli istnieją obiektywne okoliczności, które skłoniły drugą stronę do oczekiwania, że umowa zostanie zawarta, oraz jeśli istnieje odpowiedzialność. To nazywamy zaniedbaniem w zawieraniu umowy.

Przedstawiamy przykłady spraw, w których sąd uznał zaniedbanie w zawieraniu umowy.

  • Dostawca zakończył definiowanie wymagań na żądanie użytkownika i przeprowadził część podstawowego i szczegółowego projektowania. Użytkownik wyjaśnił, że działania mające na celu zaproszenie innej firmy do składania ofert są formalnością wymaganą do uzyskania zgody prezesa, ale tuż przed zawarciem umowy wybrano inną firmę i nie doszło do zawarcia umowy.
  • Dostawca kontynuował pracę na żądanie użytkownika, aby przestrzegać terminu dostawy, a data zawarcia umowy była już bliska. W firmie użytkownika prowadzono przygotowania do rozwoju wewnętrznego, ale zostało to utajone, a umowa nie została zawarta.
  • Dostawca został poinformowany przez użytkownika, że został wybrany jako wykonawca budowy, nie było żadnych wątpliwości co do wyceny, a na podstawie spotkań z użytkownikiem przeprowadzono prace związane z potwierdzeniem specyfikacji. Użytkownik był świadomy wydatków, ale umowa została odrzucona z powodu braku zgody co do kwoty wyceny.

Z drugiej strony, jako przykłady spraw, w których nie uznano zaniedbania w zawieraniu umowy, można podać te, w których wyraźnie określono możliwość wyboru innej firmy lub warunki zawarcia umowy.

Jeśli, mimo że pracowałeś na żądanie użytkownika, nie zostałeś poinformowany o możliwości wyboru firmy innej niż twoja lub o warunkach porozumienia, a negocjacje zostały niespodziewanie zerwane z tych powodów, możesz mieć prawo do roszczenia odszkodowania.

Nie ma sporu co do tego, że zakres “szkody” obejmuje koszty poniesione do tej pory. Dodatkowo, istnieją precedensy, które stwierdzają, że obejmuje to również zysk z faktycznie wykonanej pracy. Ponadto, jeśli możesz przedstawić dowody na to, że poniosłeś szkodę w wysokości zysku, który mógłbyś uzyskać, jeśli kontynuowałbyś pracę po odrzuceniu oferty od innej firmy, to również może być uwzględnione.

Artykuł 512 japońskiego Kodeksu Handlowego

Jeśli dostawca podjął działania związane z rozwojem systemu na rzecz użytkownika, może żądać odpowiedniego wynagrodzenia na podstawie artykułu 512 japońskiego Kodeksu Handlowego.

Gdy rozpoczynasz negocjacje na temat rozwoju systemu, dobrze jest zostawić dowody potwierdzające, że obie strony zrozumiały treść systemu i kwotę wynagrodzenia, na przykład za pomocą e-maili lub protokołów z posiedzeń, oraz że okoliczności sugerujące pewność zawarcia umowy i konkretne elementy umowy zostały uznane.

Nawet jeśli odmówiono płatności z powodów takich jak brak podpisanej umowy, jak wyżej opisano, może być możliwe żądanie pieniędzy.

Podsumowanie

Jak widać, sądy często wydają “negatywne” decyzje w sprawie relacji kontraktowych, gdy nie istnieje umowa, zwłaszcza w porównaniu do postrzegania sytuacji przez firmę zlecającą. Z punktu widzenia firmy zlecającej, chcielibyśmy powiedzieć, że “nawet jeśli zaczniemy pracować najpierw, umowa miała być zawarta później, a umowa sama w sobie jest już zawarta”. Jednak ten argument nie zawsze jest akceptowany.

Ponadto, jeśli zawarcie umowy jest zaprzeczane, jak wspomniano powyżej, istnieją przypadki, gdy można żądać pieniędzy na podstawie błędu w zawarciu umowy lub artykułu 512 japońskiego Kodeksu Handlowego (Japanese Commercial Code), ale to nie jest “pewne”.

Jeśli musisz rozpocząć pracę przed zawarciem umowy, musisz:

  • Zrozumieć, że jest to działanie ryzykowne i zdecydować, czy warto poświęcić czas na ten projekt, biorąc pod uwagę to ryzyko (szczególnie w przypadku małych i średnich przedsiębiorstw oraz startupów, mogą być sytuacje, w których muszą podjąć decyzję o “działaniu najpierw”, aby zdobyć doświadczenie w handlu z dużymi firmami. Jeśli ryzyko jest uwzględnione, jest to możliwa decyzja biznesowa.)
  • Rozważyć, czy nie można zawrzeć umowy likwidacyjnej na wypadek, gdyby umowa nie doszła do skutku

Można powiedzieć, że konieczne jest podjęcie takiego rozważania.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Wróć do góry