Do jakiego stopnia powinno się implementować funkcje, które nie są zawarte w specyfikacji rozwoju systemu z punktu widzenia prawa?

Projekty dotyczące rozwoju systemów IT stosowanych w firmach zasadniczo są tworzone zgodnie z wcześniej zdefiniowanymi specyfikacjami. Jednak z drugiej strony, biorąc pod uwagę, że dostawca jako ekspert od rozwoju systemów ma powierzone wszystkie zadania związane z rozwojem, oczekiwania użytkownika mogą nie być tak niskie, jak tylko mechaniczne wdrażanie tego, co jest napisane w specyfikacji. W tym artykule omówimy, do jakiego stopnia powinniśmy ponosić obowiązek wdrożenia programu, który “nie jest opisany w specyfikacji, ale jest niezbędny do wdrożenia w świetle celów rozwoju”.

Problemy prawne związane z implementacją elementów nieuwzględnionych w specyfikacji

Od dostawcy wymaga się swobody decyzyjnej

Wielką cechą kontraktów związanych z projektami tworzenia systemów i różnych problemów prawnych z nimi związanych jest to, że dostawca, który przyjmuje zlecenie, ma dużą swobodę decyzyjną.

Artykuł powiązany: Obowiązki zarządzania projektem w tworzeniu systemów

Jednakże, “swoboda decyzyjna”, o której mówimy tutaj, niekoniecznie dotyczy wszystkich etapów procesu tworzenia systemu. Po zidentyfikowaniu poszczególnych etapów i podzieleniu ich na szczegółowe zadania, wiele z nich może stać się pracą zbliżoną do prostych czynności. Niemniej jednak, im bardziej jesteśmy na początku procesu, czyli na etapie wstępnym, tym trudniej jest wykonać pracę bez dużej swobody decyzyjnej. To jest również powodem, dla którego kontrakty na etapie wstępnym często najlepiej pasują do modelu quasi-mandatu.

Artykuł powiązany: Różnica i rozróżnienie między kontraktem na wykonanie a kontraktem quasi-mandatu w tworzeniu systemów[ja]

Swoboda decyzyjna powinna być wykorzystywana nawet w ścisłym procesie tworzenia systemu

Jednakże, nawet jeśli dostawca tworzący system ma dużą swobodę decyzyjną, przyjmowanie żądań klienta w sposób nieformalny może przynieść ogromne szkody w późniejszych etapach. Jeden system IT składa się z wielu drobnych elementów, dlatego nawet niewielka zmiana na zewnątrz może wymagać znacznej ilości pracy dla dewelopera. Co więcej, w odniesieniu do zmiany specyfikacji w tworzeniu systemów, poniżej znajduje się artykuł, który wyjaśnia, jak zarządzać zmianami z punktu widzenia prawnego. Ten artykuł omawia zarządzanie zmianami, ale również omawia, jak duży wpływ zmiana specyfikacji może mieć na pracę z punktu widzenia inżyniera.

Artykuł powiązany: Jak zarządzać zmianami w tworzeniu systemów z punktu widzenia prawnego[ja]

Co powinien zrobić specjalista, nie ograniczając się do specyfikacji?

Aby sprawnie prowadzić projekt tworzenia systemu, ważne jest, aby zdefiniować wymagania na początku i postępować zgodnie z nimi w sposób planowy. Z drugiej strony, istnieją sytuacje, w których nie można w pełni spełnić swojej roli jako specjalista tworzenia systemów, jeśli tylko robi się to, co zostało powiedziane, zgodnie z zdefiniowanymi wcześniej wymaganiami. W takim dylemacie pojawia się pytanie: “Co powinno być zaimplementowane, nawet jeśli nie jest to wskazane w specyfikacji?”

Zobowiązania prawne są ustalane zgodnie z “intencją” specyfikacji i umów

Zawartość tego, co powinno być zaimplementowane, nawet jeśli nie jest zapisane w umowie lub specyfikacji, jest nadal ustalana na podstawie “intencji” tych umów i specyfikacji, czyli “jakie znaczenie lub intencje miały miejsce, kiedy takie decyzje zostały podjęte”. Poniżej przyjrzymy się kilku przykładom orzecznictwa.

Przypadek sądowy, w którym obowiązek implementacji został zaprzeczony z powodu braku zapisu

W cytowanym poniżej przypadku sądowym, system opracowany przez dostawcę doszedł do etapu testowego, ale doszło do konfliktu, kiedy klient zażądał rozwiązania umowy, twierdząc, że brakuje niezbędnych funkcji. Klient twierdził, że brakuje “funkcji automatycznego aktualizowania danych”, która była głównym punktem sprzedaży tego systemu, ale sąd nie uznał obowiązku jej implementacji.

Zgodnie z powyższym ustaleniem, w umowie oraz w dokumentach podstawowego i szczegółowego projektu nie ma żadnych zapisów wskazujących, że funkcja ③ jest celem rozwoju tego systemu.

Powód twierdzi, że funkcja ③ była głównym punktem sprzedaży systemu przez pozwanego dla powoda i podkreśla konieczność tej funkcji, ale jeśli jego twierdzenia są prawdziwe, powinny być wyraźnie zapisane w umowie itp., jest trudno uwierzyć, że rozwój tej funkcji został uzgodniony, mimo że nie ma takiego zapisu.

Sąd Okręgowy w Tokio, 18 lutego 2009 roku (Heisei 21)

Wydaje się, że ten wyrok jest prosty, jeśli weźmiemy pod uwagę tylko wniosek, że “jeśli nie ma zapisu w dokumentacji projektowej, nie musisz tworzyć czegoś, czego tam nie ma”. Jednak bardziej precyzyjnie, nie chodzi o formalne fakty, takie jak to, czy jest zapis w dokumentacji projektowej, ale o decyzję opartą na “intencji” tego zapisu w dokumentacji projektowej i umowie. Innymi słowy, “biorąc pod uwagę powody, dla których nie było zapisu w dokumentacji projektowej i umowie, jest rozsądne założyć, że nie było również zgody odpowiadającej temu zapisowi”.

Przypadek sądowy potwierdzający obowiązek implementacji, nawet jeśli nie jest on zapisany

Z drugiej strony, istnieją przypadki sądowe, które stwierdziły, że powinien być uznany obowiązek implementacji, nawet jeśli nie był on zapisany w umowie lub specyfikacji. Przytoczony poniżej przypadek sądowy dotyczył rozwoju systemu do zarządzania historią przyjmowania leków, w którym nie można było przenieść danych z istniejącego systemu do nowego systemu, co uniemożliwiło wykorzystanie nowego systemu, a użytkownik rozwiązał umowę. Jednak strona dostawcy sprzeciwiła się temu, twierdząc, że migracja danych nie jest w jej zakresie obowiązków.

Rozwój nowego systemu często wiąże się z likwidacją istniejącego systemu i migracją danych. Szczegółowe wyjaśnienia dotyczące znaczenia tych zadań i związanych z nimi problemów prawnych można znaleźć w poniższym artykule.

Powiązany artykuł: Problemy prawne związane z migracją z starego systemu podczas rozwoju systemu[ja]

W istniejącym systemie przechowywane są już dane ponad 50 tysięcy pacjentów, a powód dążył do zwiększenia efektywności pracy, wykorzystując te dane. Jeśli nie można przenieść danych pacjentów z istniejącego systemu do nowego systemu, to oczywiste, że spowoduje to problemy w pracy apteki, a reprezentant powoda z pewnością zdawał sobie z tego sprawę. Przed zawarciem umowy, reprezentant powoda zapytał reprezentanta pozwanego o możliwość migracji danych, co reprezentant pozwanego również przyznał (pominięcie), a reprezentant powoda z pewnością zdawał sobie sprawę, że istnieje duże prawdopodobieństwo, że będzie musiał wprowadzić ręcznie dane ponad 50 tysięcy pacjentów, trudno jest uwierzyć, że mimo to zdecydował się na wprowadzenie nowego systemu. Ponadto, jak wskazano powyżej w punkcie (1)I, pozwany nie był w stanie przenieść danych o historii leków z istniejącego systemu do nowego systemu, więc drukował te dane na papierze i przetwarzał je na pliki PDF, mimo że migracja danych nie była założona w umowie, trudno jest uwierzyć, że pozwany podjął tak pracochłonne zadanie jako usługę.

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

Co jest tu ważne, to cel umowy i “intencja” zapisów umowy. Jeśli obie strony zawarły umowę, uznając, że migracja danych nie jest w zakresie obowiązków, sąd wskazał, że zarówno użytkownik, jak i dostawca zawarli umowę z nienaturalnym zamiarem. To znaczy, że użytkownik zgodził się na ogromną ilość pracy ręcznej, a dostawca podjął się projektu, wiedząc, że to spowoduje problemy w pracy użytkownika, co jest bardzo nieracjonalne.

Co wynika z obu wyroków?

W kontekście migracji danych, nawet jeśli nie ma o tym zapisu w umowie czy specyfikacji, obowiązek implementacji został potwierdzony. Jednym z powodów tego jest prawdopodobnie fakt, że rozmawialiśmy o “danych”, które nie są widoczne na ekranie. Brak “kluczowych funkcji”, o którym mówiliśmy wcześniej, jest bezpośrednio widoczny na ekranie systemu. Dlatego nawet dla laika w dziedzinie tworzenia systemów, odkrycie pominięcia w specyfikacji nie jest zbyt trudne. Z drugiej strony, problem migracji danych ma cechę, że dla laika w dziedzinie tworzenia systemów trudno jest zrozumieć znaczenie tego procesu, trudność zadania czy ilość pracy. Dlatego też, prawdopodobnie istniała sytuacja, w której łatwiej było traktować to jako sprawę, którą strona dostawcy powinna sprawnie zarządzać ze swoją specjalistyczną wiedzą.

Patrząc na to w ten sposób, pominięcie w specyfikacji lub umowie jest problemem ściśle związanym z “obowiązkiem współpracy” użytkownika. Innymi słowy, jest to problem, czy użytkownik naprawdę “wypełnił obowiązek współpracy” w celu zawarcia umowy i stworzenia specyfikacji. Szczegółowe omówienie ogólnych obowiązków prawnych, które użytkownik powinien spełnić w projekcie tworzenia systemu, znajduje się w poniższym artykule.

Artykuł powiązany: Obowiązki współpracy po stronie użytkownika, który jest zamawiającym systemu[ja]

Jeśli sprawdzisz również powyższy artykuł, zrozumiesz, że w obszarach, gdzie wymagana jest duża współpraca ze strony użytkownika, takich jak identyfikacja ekranów i kluczowych funkcji, a w przypadku pominięcia rozważenia migracji danych, sytuacja jest znacznie inna.

Jak powinniśmy podchodzić do wynagrodzenia za rozwój, który nie jest zawarty w specyfikacji?

Innym zagadnieniem, które może nas zainteresować w kontekście tematu tego artykułu, jest pytanie, czy prawo dopuszcza żądanie dodatkowego wynagrodzenia za stworzenie czegoś, co nie było zawarte w specyfikacji. Szczegółowe wyjaśnienia dotyczące możliwości zwiększenia wynagrodzenia oraz metody obliczania kwoty wyceny w takim przypadku znajdują się w poniższym artykule.

Artykuł powiązany: Czy możliwe jest zwiększenie wyceny po rozpoczęciu rozwoju systemu?[ja]

W powyższym artykule wyjaśniamy, że istotne jest, czy były jakiekolwiek zadania wykraczające poza zakres pracy, który był związany z wynagrodzeniem. Innymi słowy, w kontekście tego artykułu, jeśli dostawca zdecyduje się na rozwój czegoś, co nie było zawarte w pierwotnej specyfikacji (w tym artykule, jest to przykład negatywny), może on żądać dodatkowego wynagrodzenia.

Podsumowanie

W rozwoju systemów, rola dostawcy jest z jednej strony określana zgodnie z treścią umowy i specyfikacji. Jednakże, biorąc pod uwagę fakt, że jako specjaliści są powierzani z wysokim zaufaniem, zrozumieć można, że ich rzeczywista rola nie jest z góry określona przez formalności. Niemniej jednak, w celu zrozumienia tej rzeczywistości, powinniśmy zrozumieć, że prawo odgrywa dużą rolę.