Lehetséges-e a rendszerfejlesztési költségvetés utólagos növelése?

A rendszerfejlesztési munka, mely mind a megrendelő felhasználókat, mind a szolgáltatókat nagyszámú munkaerőbe vonja, nem könnyű feladat, hiszen mindenki együtt kell, hogy haladjon a projekten. Természetesen mondani sem kell, hogy a tervezés rendkívül fontos, de ugyanakkor nem biztos, hogy a megrendelő felhasználó képes-e összefoglalni a megfelelő információkat és hatékonyan továbbítani azt a szolgáltatónak. Ha a fejlesztési folyamat bizonyos szinten halad, és a specifikációk változását vagy további funkciók hozzáadását kérik utólag, akkor a szolgáltató számára nagyon fontos kérdés, hogy lehetséges-e a korábbi becsült összeghez képest többet számlázni.

Vajon milyen jogokat ismer el a törvény ilyen esetekben? És hogyan határozzák meg a további fejlesztési és funkció módosítási díjakat? Ebben a cikkben ezekre a kérdésekre próbálunk választ adni.

Mikor beszélhetünk kiegészítő fejlesztésről vagy funkció módosításról?

A rendszerfejlesztési projektekben a munkát általában vállalkozási szerződéssel vagy megbízási szerződéssel vállalják. Ezek a szerződéstípusok mindkét esetben a munkát vállaló feladatait (kötelezettségeit) és a hozzájuk kapcsolódó díjazást (jogokat) egy párban tartalmazzák a szerződésben. Tehát, ha a díjazás alapjául szolgáló munkán kívüli feladatok kerülnek hozzáadásra, azt kiegészítő fejlesztésnek vagy funkció módosításnak nevezhetjük. Fordított esetben, ha a feladatok a munka részét képezik, akkor azok az eredeti specifikációknak megfelelően (azaz a meglévő szerződés keretein belül) kezelendők.

Megjegyezzük, hogy a vállalkozási szerződés és a megbízási szerződés közötti különbségekről részletesen írunk egy másik cikkben.

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

Ugyanakkor, ha minden, például a képernyőn megjelenő betűtípus finomhangolását is előre meg kell határozni a specifikációban, és mindezt kiegészítő fejlesztésnek tekintjük, az jelentősen akadályozhatja a zökkenőmentes üzleti tranzakciókat. Tehát, ha figyelembe vesszük ezeket a specifikációk részleteit, nem egyszerű egyértelmű határokat húzni. Azonban, ha általános iránymutatást adunk:

• Ha a specifikációk már megerősítést nyertek, és további funkciókat rendelnek hozzá
• Ha a program implementálása már befejeződött, és módosításokat rendelnek hozzá

Akkor azt mondhatjuk, hogy ezek az érvelések jogilag is valószínűleg megalapozottak.

Vita tárgyát képezte a bírósági esetekben, hogy az továbbfejlesztésnek vagy funkció javításnak minősül-e

Pozitív példa: Alapvető tervezési specifikációk utólagos módosításának esete

Az alábbi esetben utólagos specifikáció-változás történt.

A szoftverfejlesztés a következő fejlesztési folyamatokon keresztül halad: ① követelmények meghatározása, ② külső tervezés, ③ belső tervezés, ④ forráskód létrehozása (programtervezés, kódolás), ⑤ különféle tesztek (egységteszt, kombinációs teszt, rendszerteszt) (részlet)… Az eredeti specifikációk (részlet) megvalósítása a belső tervezés és a további munkafolyamatok által, és ez a jelen fejlesztési megbízási szerződés alapján fizetendő díj és a viszonzás kapcsolatban álló munka területe. A specifikáció-változtatás javaslata jogilag a megbízó által az eredeti szerződésen alapuló munkaterület túllépésének tekinthető, mint egy új munkamegbízási szerződés ajánlata, és ha a megbízott nem adja meg az extra munkadíjat, és az extra díj megállapodás nélkül teljesíti az extra megbízást, akkor a megbízó és a megbízott között egy új szerződés jön létre anélkül, hogy a díjat meghatározták volna, és ezért megfelelő további fejlesztési költségek fizetési kötelezettsége keletkezik.

Osaka District Court, 2002. augusztus 29. (Heisei 14)

A “viszonzás kapcsolat”, “új szerződés” és hasonló kulcsszavak megértése segíthet mélyebben megérteni ezt az ítéletet.

Egyébként az említett ítéletben egy másik, nagyon érdekes pontot is felvetettek. Ez az, hogy a gombok elrendezése vagy a betűtípusok, mint a legapróbb részletek finomhangolása, nem tartozik ide, mint specifikáció-változtatás. Az érintett rész a következő:

A szoftverfejlesztés természeténél fogva nem szokás, hogy a külső tervezési szakaszban a képernyőn megjelenő betűtípusok és a gombok elrendezése stb. részletei már meghatározottak lennének, és a részleteket tekintve, a specifikációk megerősítése után is, a felek közötti megbeszélések alapján bizonyos módosításokat lehet végrehajtani, ez a szokásos. Ezt figyelembe véve, nem lenne helyénvaló, ha ezt a specifikációk részleteinek igényét is specifikáció-változtatásként kezelnénk.

Osaka District Court, 2002. augusztus 29. (Heisei 14)

Az ítéletben az “a specifikációk részletezése” érdekes kifejezést használtak.

• Azok az esetek, amikor valamit, ami már eldöntöttnek tűnt, utólag megváltoztattak
• Azok az esetek, amikor valamit, amit menet közben is el lehet dönteni, szándékosan nem döntöttek el, és folytatták a munkát

Ez azt sugallja, hogy a jogi kezelésnek is különböznie kell ezekben az esetekben.

További pozitív példák

Ezen kívül, az alábbi eseteket ismerik el továbbfejlesztésnek és funkció javításnak:

• Az eredeti tervhez képest a szállított programok száma körülbelül megduplázódott (Tokiói Kerületi Bíróság, 2009. április 22-i ítélet)
• A munkaidő körülbelül háromszorosára nőtt (Tokiói Kerületi Bíróság, 2010. január 22-i ítélet)

Ilyen összefoglalók után látható, hogy a munkaidő meghosszabbítása is, mint a továbbfejlesztés tágabb értelmezése, bizonyos jogi védelmet élvezhet. Ez a gondolkodásmód láthatóan elfogadott.

“Továbbfejlesztési megállapodások és díjemelések” és “az eredeti szerződés létrejötte” külön kérdések

Ezekkel a problémákkal kapcsolatban fontos pont, hogy:

1. “Először is, vajon hivatalosan létrejött-e a rendszerfejlesztési szerződés (az eredeti szerződés) a két cég között?”
2. “Ha egyszer hivatalosan létrejött a rendszerfejlesztés, akkor vajon létrejött-e további fejlesztési szerződés (ek)?”

A bíróságok ítéletalkotási kritériumai eltérőek ezekben az esetekben. Egyszerűen fogalmazva, a bíróságok:

• 1. esetben szigorúak (ha nincs szerződés, nehezen ismerik el a szerződés létrejöttét)
• 2. esetben viszonylag engedékenyek (még ha nincs is továbbfejlesztési szerződés, rugalmasan elismerik a díjemeléseket és hasonlókat)

Mondhatjuk. Az 1. pontot részletesen tárgyaljuk egy másik cikkben.

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

Tagadó példa: Az esetek, amikor a jog szerint a megbízás tartalma azonosnak tekintendő

Ugyanakkor vannak olyan bírósági ítéletek is, amelyek nem engedélyezték a díj emelését. Az alább idézett ítéletben a rendszerfejlesztési szerződés keretében, miután egyszer már létrejött a megbízási szerződés, a megbízás tartalma megváltozott, és ezért vitatottá vált, hogy engedélyezhető-e a díj emelése.

A jelen ügy vitatott kérdései a következők: (1) Milyen volt a megbízott feladatok tartalma a jelen szerződésben? (2) Megállapodás született-e a megbízó és a megbízott között arról, hogy a megbízott feladatok méretét növelik és a díjat emelik? (…)

Eredetileg a jelen szerződés egy olyan szerződés, amelyben a felek megállapodtak arról, hogy a díj a megbízott feladatokért cserébe fizetendő végleges ellenérték. A megbízott feladatokhoz kapcsolódó lépésszám, egységár stb. csak a megbízó belső dokumentumai, amelyeket a megbízási díj kiszámításakor használtak, és a lépésszám növekedése stb. teljesen összefüggéstelen a megbízási díjjal. (…)

Az előzőekben megállapítottak szerint a megbízott feladatok 1987. február 25-én (Showa 62) megváltoztak, és a rendszerkezelés, a szerződéses munka költségének felhalmozása és a hasznosság csak egy részére korlátozódott, a többit a megbízó vette át. A megváltozott megbízott feladatok azonban továbbra is a kezdeti szerződés hatálya alá tartoznak, és az ezekért a feladatokért fizetendő ellenérték a jelen szerződés kezdeti időpontjában megállapított díj, amely a megbízási díjat teljes mértékben fedezi.

Tokiói Kerületi Bíróság, 1995. június 12-i (Heisei 7) ítélete

Az említett ítélet szerint, még ha a megbízott feladatok tartalma meg is változott, a fejlesztés tartalma még mindig a kezdeti szerződés hatálya alá tartozik, és a kezdetben megígért díjnak kell fedeznie azt.

Végül is, azt kell figyelembe venni, hogy a díj milyen feladatok elvégzésének előfeltételeként lett meghatározva, és azokat a feladatokat, amelyek nem tartoznak ebbe a körbe, további díjazásra kell engedélyezni. Ez a hozzáállás valószínűleg a leginkább elfogadott.

Ráadásul, hogy a díj milyen feladatok elvégzésének ellenértéke volt, nem csak a szerződésből, hanem a jegyzőkönyvekből is megállapítható. A jegyzőkönyvek fontosságát a következő cikkben részletesen ismertetjük.

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

Hogyan határozzák meg a jutalmat a továbbfejlesztés és a funkciók javítása esetén?

A rendszerfejlesztés területén nem ritka, hogy a már meghatározottnak tűnő specifikációk később megváltoznak. Minden ilyen esetben nem reális új szerződést előkészíteni és a szerződéses ügyeket előmozdítani. Ha a továbbfejlesztendő vagy javítandó kérdéseket újra meghatározzuk, és összefoglaló megállapodást kötünk, az egy dolog, de mi történik, ha a projekt meghiúsul anélkül, hogy ezeket az eljárásokat végrehajtanánk? Hogyan határozzuk meg a jutalom összegét?

Ebben az esetben a következő, idézett kereskedelmi törvény 512. cikkelye lehet a hivatkozási alap (az aláhúzott részeket a szerző húzta alá).

Kereskedelmi törvény 512. cikkely: Ha a kereskedő a tevékenységi körén belül mások számára cselekszik, megfelelő jutalmat kérhet.

Ebben a cikkelyben a “megfelelő jutalom” kérdése, hogy a konkrét helyzetben végül mennyi lesz, problémát jelent. A korábbi bírósági ítéleteket tekintve úgy tűnik, hogy a munkaórák, a mennyiség vagy az időtartam arányában kell viselni a költségeket. Ez valószínűleg annak köszönhető, hogy a rendszerfejlesztési munka természete szerint szolgáltatási tevékenység, és az alapvető költség a munkaerőköltség.

Ezért, annak ellenére, hogy a kereskedelmi törvény “megfelelő jutalom” kifejezése absztrakt, a további jutalom összegének becslése ebben a kontextusban nem igényel túl bonyolult számításokat. Tekintsük át néhány bírósági ítéletet az alábbiakban.

Eset 1: Az eset, amikor az elvégzett munkaórák növekedésével arányosan engedélyezték a plusz díjazást

A jelen esetben a specifikáció változásából adódó fejlesztési munkaórák száma összesen 257,5 ember/nap, ami megfelelőnek tekinthető. Ha ezt az összeget a fejlesztési költségek napi egy főre eső összegével számoljuk, ami a jelen fejlesztési megbízási szerződés szerint 32 500 jen (a K-3-as dokumentumban a napi díj 650 000 jen [havi egy főre eső összeg], ha a hónap munkanapjait 20 nappal számoljuk, akkor a fejlesztési költségek napi egy főre eső összege 32 500 jen), akkor a specifikáció változásából adódó további fejlesztési költségek összege 83 687 500 jennek tekinthető.

Osaka Kerületi Bíróság, 2002. augusztus 29-i (Heisei 14) ítélete

A “napi egy főre eső” kifejezés a kulcsszó. Ez azt jelzi, hogy a plusz díjazás kiszámításának alapjául a munkaórákat használják.

Eset 2: Az eset, amikor a programok számához arányosan engedélyeztek további díjazást

Ha megvizsgáljuk a jelen ügyben a további díjazás összegét, figyelembe véve, hogy a számítógépes rendszer fejlesztésének nagy része a műszaki személyzet bérköltsége, és ez a bérköltség nagyjából arányos a létrehozott programok mennyiségével, akkor a kezdeti szerződéses összeg, ami 23 250 000 jen, elosztva a második ellenőrzésig elkészült 206 program számával, és ezt a programonkénti egységárat megszorozva a harmadik ellenőrzésen átesett 414 program számával, az eredmény 46 725 728 jen (23,250,000 ÷ 206 × 414 = 46,725,728) lesz, amit elfogadhatónak tekintünk.

Tokiói Kerületi Bíróság 2005. április 22-i (Heisei 17) ítélete

Bár sok szám jelenik meg, ha nyugodtan olvasod, láthatod, hogy nem bonyolult számításokat végeznek. A kezdeti szerződés alapján megerősítik, hogy “mennyit becsültek a programonkénti egységár”, majd egyszerűen megszorozzák ezt az “egységár × mennyiség” képlettel.

Eset 3: Az időtartamhoz arányosan meghatározott további díjazás elfogadása

A Kő 3 szerződésben a felperes 2005. január és március közötti (Heisei 17) három hónapos időszakában végzett munkájának díjazásaként 60 millió jent határoztak meg. Ugyanebben az évben áprilistól kezdődően a munka ingyenesen végezhető, ugyanakkor, mint az előző évben, az új tanév kezdetével a tanulmányi regisztrációs rendszer működésbe lép, és a munkamennyiség növekedése várható. Ezek alapján a fent említett három hónapos munka díjazásaként meghatározott 60 millió jen alapján, a felperes 2005. április és szeptember közötti hat hónapos munkájának díjazása 120 millió jen lenne megfelelő.

Tokiói Kerületi Bíróság 2010. január 22-i (Heisei 22) ítélete

A fenti ítélet azt jelzi, hogy a meghosszabbított időszakokra is egyszerű arányos számítást alkalmaznak a további díjazás kiszámításához.

Összefoglalás

Ahogy a fentiekben bemutatott néhány bírósági ítéletből látható, a programozók és mérnökök munkájáért járó plusz juttatások jogi kezelésében bizonyos szabályszerűségek és közös pontok is megfigyelhetők. Alapelvként úgy tűnik, hogy a munkaerő, a (szállított programok stb.) formális munkamennyiség, a munkaidő vagy időtartam, és más, viszonylag objektív mutatók alapján próbálják a lehető legegyszerűbben kiszámítani a juttatásokat.

Ha azt vesszük figyelembe, hogy a szigorú értelemben vett eljárások és a tökéletes munkaerő-beállítások gyakran kudarcot vallanak, ami miatt további fejlesztések és funkciók javítása válik szükségessé, akkor talán furcsának tűnhet, hogy a befektetett munkaerő, a végzett munka formális mennyisége, vagy a ráfordított idő alapján további juttatások keletkeznek. Azonban, ha a megbízott szemszögéből nézzük, még akkor is, ha a cél a vevő érdekeinek előtérbe helyezése a munka végrehajtása során, a tény, hogy ezek a jogok jogilag is elismerhetők, bizonyos kríziskezelési szempontból is értelmes lehet.