Czy jest możliwe zwiększenie kwoty wyceny po rozpoczęciu rozwoju systemu?

Praca związana z rozwojem systemów, ze względu na zaangażowanie wielu osób zarówno po stronie zamawiającego, jak i wykonawcy, nie jest łatwa do prowadzenia w sposób zgodny dla wszystkich. Nie trzeba mówić, że planowanie jest niezwykle ważne, ale czy zamawiający jest w stanie skutecznie przekazać odpowiednie informacje wykonawcy? W praktyce nie zawsze jest to możliwe. Kiedy proces rozwoju jest już na pewnym etapie, wykonawca może zastanawiać się, czy możliwe jest naliczenie dodatkowych opłat za zmiany specyfikacji lub dodatkowe funkcje, które są wymagane po fakcie.

Jakie prawa są przyznawane w takich przypadkach zgodnie z prawem? Jak ustala się kwotę wynagrodzenia za dodatkowy rozwój i modyfikacje funkcji? W tym artykule omówimy te i inne pytania.

Kiedy mówimy o dodatkowym rozwoju i modyfikacji funkcji?

W projektach rozwoju systemów, typy kontraktów, które zwykle przyjmujemy, to kontrakty na zlecenie lub kontrakty quasi-mandatowe. W obu tych typach kontraktów, obowiązki (tj. zadania do wykonania) i związane z nimi wynagrodzenie (tj. prawa) są przedstawiane razem w kontrakcie. Dlatego, jeśli pojawiają się zadania, które nie były uwzględnione w pracy, na której opiera się wynagrodzenie, można je uznać za dodatkowy rozwój lub modyfikację funkcji. Z drugiej strony, jeśli są one uwzględnione, są traktowane jako zgodne z pierwotnymi specyfikacjami (tj. w ramach istniejącego kontraktu).

Szczegółowe wyjaśnienia różnic między kontraktami na zlecenie i kontraktami quasi-mandatowymi znajdują się w innym artykule.

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

Jednakże, jeśli wszystko, nawet drobne dostosowania czcionek wyświetlanych na ekranie, musi być określone w specyfikacjach z góry, a następnie uznane za dodatkowy rozwój, może to znacznie utrudnić płynne transakcje handlowe. Dlatego, biorąc pod uwagę te dyskusje na temat szczegółów specyfikacji, nie jest łatwo dokonać jednolitego podziału. Jednakże, jeśli miałbym podać ogólne wytyczne, to:

• Jeśli po potwierdzeniu specyfikacji, zostaniesz poproszony o dodatkowe funkcje
• Jeśli po zakończeniu implementacji programu, zostaniesz poproszony o jego modyfikację

W takich przypadkach, twoje twierdzenia mogą mieć wysokie prawdopodobieństwo uzyskania pewnej legalności.

Przykłady sądowe, w których punktem spornym było, czy można mówić o dodatkowym rozwoju lub poprawie funkcji

Potwierdzenie: Przypadek, w którym specyfikacje podstawowego projektu zostały zmienione po fakcie

Poniższy przypadek dotyczy sytuacji, w której specyfikacje zostały zmienione po fakcie.

Rozwój oprogramowania obejmuje ①definiowanie wymagań, ②projektowanie zewnętrzne, ③projektowanie wewnętrzne, ④tworzenie programu źródłowego (projektowanie programu, kodowanie), ⑤różne testy (testy jednostkowe, testy kombinacyjne, testy systemowe) (…) Początkowe specyfikacje (…) są realizowane poprzez pracę po projektowaniu wewnętrznym, a to jest zakresem pracy związanej z prawem do wynagrodzenia na podstawie umowy o powierzenie rozwoju. Propozycja zmiany specyfikacji jest prawnie interpretowana jako nowa umowa o powierzenie pracy przekraczająca zakres pracy na podstawie pierwotnej umowy przez zleceniodawcę, a jeśli zleceniobiorca nie przedstawi kwoty dodatkowych kosztów robocizny i zakończy pracę związaną z dodatkowym zleceniem bez zgody na kwotę dodatkową, interpretuje się to jako nowa umowa o wykonanie pracy bez ustalonej kwoty, a odpowiedni obowiązek zapłaty za dodatkowy rozwój jest odpowiedni.

Sąd Okręgowy w Osace, wyrok z 29 sierpnia 2002 roku (rok 14 ery Heisei)

Kluczowe słowa takie jak “relacja wynagrodzenia” i “nowa umowa” mogą pomóc w głębszym zrozumieniu tego wyroku.

Co więcej, w wyżej wymienionym wyroku, został również przedstawiony inny, bardzo interesujący punkt. Mianowicie, że drobne korekty, takie jak rozmieszczenie przycisków czy czcionka, nie kwalifikują się jako zmiana specyfikacji, o której mowa tutaj. Odpowiednie fragmenty są następujące:

Jednakże, w rozwoju oprogramowania, ze względu na jego naturę, szczegóły takie jak czcionka wyświetlana na ekranie czy rozmieszczenie przycisków nie są zdecydowane na etapie projektowania zewnętrznego, a szczegóły są zwykle modyfikowane przez spotkania między stronami nawet po potwierdzeniu specyfikacji. Biorąc to pod uwagę, nie jest odpowiednie traktowanie żądań szczegółowych specyfikacji jako zmiany specyfikacji.

Sąd Okręgowy w Osace, wyrok z 29 sierpnia 2002 roku (rok 14 ery Heisei)

W wyroku użyto interesującego terminu “szczegółowanie specyfikacji”.

• Przypadek, w którym coś, co miało być już ustalone, zostało później zmienione
• Przypadek, w którym coś, co można było zdecydować w trakcie, zostało celowo niezdecydowane i kontynuowane

Można by powiedzieć, że wyraża to pogląd, że traktowanie prawne powinno być różne w zależności od sytuacji.

Inne przykłady potwierdzenia

Inne przypadki, które zostały uznane za dodatkowy rozwój lub poprawę funkcji, to:

• Przypadek, w którym liczba programów dostarczonych była około dwukrotnie większa niż pierwotnie planowano (wyrok Sądu Okręgowego w Tokio z 22 kwietnia 2009 roku)
• Przypadek, w którym okres pracy wydłużył się około trzykrotnie (wyrok Sądu Okręgowego w Tokio z 22 stycznia 2010 roku)

Podsumowując, można zauważyć, że rozszerzenie okresu pracy jest traktowane jako dodatkowy rozwój w szerszym sensie, a podejście polega na zapewnieniu pewnej ochrony prawnej.

“Zgoda na dodatkowy rozwój i zwiększenie wynagrodzenia” i “zawarcie pierwotnej umowy” to dwa różne problemy

Ważnym punktem w tych kwestiach jest to, że:

1. “Czy między dwiema firmami została formalnie zawarta umowa dotycząca rozwoju systemu (pierwotna umowa)”
2. “Czy po formalnym zawarciu umowy o rozwój systemu, została zawarta dodatkowa umowa dotycząca dodatkowego rozwoju”

Sądy mają różne kryteria oceny. Mówiąc wprost, sądy mają tendencję do:

• Bycia surowym w odniesieniu do 1 (rzadko uznają zawarcie umowy, jeśli nie ma umowy)
• Bycia stosunkowo łagodnym w odniesieniu do 2 (nawet jeśli nie ma umowy dotyczącej dodatkowego rozwoju, są skłonne do elastycznego uznawania zwiększenia wynagrodzenia)

1 jest omówione szczegółowo w innym artykule.

https://monolith.law/corporate/system-development-contract[ja]

Przypadek negacji: Przypadek, w którym został potraktowany jako zawarty w tym samym zakresie zlecenia prawnego

Jednakże, istnieją również przykłady sądowe, w których nie uznano zwiększenia wynagrodzenia. W przypadku cytowanego poniżej wyroku, sporne było, czy zwiększenie wynagrodzenia jest uzasadnione, ponieważ zawartość pracy została zmieniona po zawarciu umowy o powierzenie rozwoju systemu.

Kwestia sporna w tym przypadku polega na tym, (1) jaka była zawartość pracy powierzonej przez powoda na mocy umowy, (2) czy między powodem a pozwanym doszło do porozumienia w sprawie zwiększenia skali i zwiększenia wynagrodzenia za tę pracę, (…) i tak dalej. (…)

Przede wszystkim, umowa ta jest umową o wykonanie pracy, która zgodziła się, że kwota wynagrodzenia jest ostatecznym wynagrodzeniem za pracę powierzoną powodowi, a liczba kroków, cena jednostkowa, itp. są tylko wewnętrznymi dokumentami używanymi do obliczania kwoty wynagrodzenia, a zwiększenie liczby kroków, itp. nie ma nic wspólnego z wynagrodzeniem. (…)

Zgodnie z powyższym uznaniem, praca powoda została zmieniona 25 lutego 1987 roku, a zarządzanie systemem, koszt budowy i część narzędzi były ograniczone, a reszta była obsługiwana przez pozwanego, ale praca powoda po zmianie jest w ramach pracy rozwojowej zgodnej z pierwotną umową, a wynagrodzenie za tę pracę jest pokryte całą kwotą wynagrodzenia umówioną jako ostateczne wynagrodzenie na początku umowy.

Sąd Okręgowy w Tokio, wyrok z 12 czerwca 1995 roku (rok 7 ery Heisei)

W tym wyroku, nawet jeśli zawartość pracy powierzonej dostawcy została zmieniona, stwierdzono, że ta zawartość rozwoju mieści się w ramach pierwotnej umowy i powinna być pokryta z wynagrodzenia pierwotnie obiecane.

Ostatecznie, po uwzględnieniu, jakie prace były podstawą ustalenia wynagrodzenia, dla prac, które nie są w nim zawarte, uznaje się prawo do dodatkowego wniosku o wynagrodzenie.

A jakie prace były wynagrodzeniem za wykonanie pracy, nie jest oceniane tylko na podstawie umowy, ale także na podstawie protokołów i innych dowodów. Ważność protokołów jest omówiona szczegółowo w poniższym artykule.

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

Jak ustala się wynagrodzenie za dodatkowy rozwój i poprawki funkcji?

Na placu budowy systemu, nie jest rzadkością, że specyfikacje, które wydawały się już ustalone, zmieniają się później. Za każdym razem, gdy coś takiego się zdarza, nie jest realistyczne przygotowywanie nowego dokumentu umowy i prowadzenie procedur umownych. W przypadku kwestii, które należy dodać lub poprawić, jeśli można ponownie ustalić zawartość specyfikacji i zawrzeć notatki itp., to jedno, ale jak obliczyć kwotę wynagrodzenia, gdy projekt upada bez możliwości przeprowadzenia takich procedur?

Artykuł, który powinien służyć jako punkt odniesienia w takich przypadkach, to cytowany poniżej artykuł 512 Kodeksu handlowego (podkreślenie dodane przez autora).

Artykuł 512 Kodeksu handlowego: Kiedy handlowiec działa na rzecz innej osoby w ramach swojej działalności, może żądać odpowiedniego wynagrodzenia.

Problemem jest to, ile wynosi “odpowiednie wynagrodzenie” w tym artykule, biorąc pod uwagę konkretną sytuację. Patrząc na poprzednie wyroki sądowe, wydaje się, że przyjęto podejście, że koszty powinny być proporcjonalne do ilości pracy, ilości lub czasu. Wynika to prawdopodobnie z faktu, że rozwój systemu jest z natury rodzajem usługi, a koszt jest głównie kosztem pracy.

W związku z tym, pomimo abstrakcyjności terminu “odpowiednie wynagrodzenie” w prawie handlowym, szacowanie rynkowej ceny dodatkowego wynagrodzenia w tym kontekście nie wymaga skomplikowanych obliczeń. Poniżej przyjrzymy się kilku przykładom wyroków sądowych.

Przypadek 1: Przykład, w którym dodatkowe wynagrodzenie zostało przyznane proporcjonalnie do wzrostu ilości pracy

Ilość pracy związana z rozwojem na podstawie zmiany specyfikacji w tym przypadku jest odpowiednia, jeśli jest to suma powyższych ilości pracy, czyli 257,5 osoba/dzień, a jeśli przeliczymy to na koszt rozwoju na osobę/dzień w tej samej umowie o zlecenie rozwoju, wynosi 32 500 jenów (w umowie A3, jednostkowy koszt wynosi 650 000 jenów (na osobę/miesiąc), a jeśli liczba dni roboczych w miesiącu wynosi 20 dni, koszt rozwoju na osobę/dzień wynosi 32 500 jenów.). Dodatkowy koszt rozwoju na podstawie żądania zmiany specyfikacji wynosi odpowiednio 8 368 750 jenów.

Wyrok Sądu Okręgowego w Osace z dnia 29 sierpnia 2002 roku (rok 14 ery Heisei)

Kluczowym słowem jest “na osobę/dzień”. Wskazuje to, że do obliczenia dodatkowego wynagrodzenia użyto ilości pracy.

Przypadek 2: Przykład, w którym dodatkowe wynagrodzenie zostało przyznane proporcjonalnie do liczby programów

Jeśli rozważymy kwotę odpowiedniego wynagrodzenia, w tym dodatkową część w tym przypadku, biorąc pod uwagę, że większość kosztów rozwoju systemu komputerowego to koszty pracy techników, a te koszty pracy są generalnie proporcjonalne do ilości programów do stworzenia, początkowa kwota umowy wynosi 23 250 000 jenów, podzielona przez liczbę programów, które zostały zakończone do drugiego odbioru, czyli 206, a następnie mnożona przez liczbę programów, które przeszły trzeci odbiór, czyli 414, wynosi 46 725 728 jenów, co jest uważane za odpowiednie.

Wyrok Sądu Okręgowego w Tokio z dnia 22 kwietnia 2005 roku (rok 17 ery Heisei)

Występuje wiele liczb, ale jeśli przeczytasz spokojnie, zrozumiesz, że nie robią skomplikowanych obliczeń. Na podstawie początkowej umowy, sprawdzają, “ile wynosiła jednostkowa cena programu, o której rozmawialiśmy”, a następnie robią prosty rachunek “cena jednostkowa x ilość”.

Przypadek 3: Przykład, w którym dodatkowe wynagrodzenie zostało przyznane proporcjonalnie do długości okresu

W umowie A3, jako wynagrodzenie za pracę jako quasi-zlecenie w okresie trzech miesięcy od stycznia do marca 2005 roku, ustalono 60 000 000 jenów, podczas gdy prace od kwietnia tego roku zawierały prace wykonywane bezpłatnie, ale podobnie jak w poprzednim roku, można przewidzieć, że ilość pracy wzrośnie po rozpoczęciu nowego roku szkolnego w kwietniu tego roku, kiedy system rejestracji kursów itp. jest w użyciu. Biorąc pod uwagę te okoliczności, na podstawie 60 000 000 jenów ustalonych jako wynagrodzenie za pracę w ciągu trzech miesięcy, wynagrodzenie za pracę w okresie sześciu miesięcy od kwietnia do września 2005 roku wynosi odpowiednio 120 000 000 jenów.

Wyrok Sądu Okręgowego w Tokio z dnia 22 stycznia 2010 roku (rok 22 ery Heisei)

Powyższy wyrok wskazuje, że dodatkowe wynagrodzenie jest obliczane na podstawie prostego obliczenia proporcjonalnego do przedłużonego okresu.

Podsumowanie

Jak widać z powyższych przykładów, wydaje się, że pewne zasady i wspólne cechy zaczynają się wyłaniać w odniesieniu do prawnej kwestii dodatkowych wynagrodzeń dla programistów i inżynierów. Mówiąc ogólnie, wydaje się, że dążą do prostego obliczania na podstawie wskaźników o wysokiej obiektywności, takich jak nakład pracy, formalna ilość pracy (takiej jak dostarczone programy), czas pracy i okres.

Może wydawać się to nieco surowe, biorąc pod uwagę, że dodatkowy rozwój i poprawki funkcji wynikają z faktu, że nie udało się dokładnie określić procedur lub oszacować nakładu pracy. Można by pomyśleć, że dodatkowe wynagrodzenie powstaje tylko wtedy, gdy wkłada się więcej pracy, wykonuje się więcej formalnej pracy, lub poświęca się więcej czasu. Jednak, patrząc z perspektywy zleceniobiorcy, nawet jeśli dążą do wykonywania swojej pracy z naciskiem na korzyści klienta, prawdopodobieństwo, że takie prawa są uznawane prawnie, może mieć znaczenie z punktu widzenia zarządzania kryzysowego.