Kas süsteemiarenduse hinnanguline summa on võimalik pärast suurendada?

Süsteemiarenduse töö hõlmab nii tellija kui ka tarnija poolel paljusid inimesi, mistõttu on kõigil keeruline projekti ühtlaselt edasi viia. On ilmne, et planeerimine on äärmiselt oluline, kuid samal ajal ei pruugi tellija, kes on kasutaja, suuta koguda asjakohast teavet ja seda tarnijale selgelt edastada. Kui arendusprotsess on jõudnud teatud punkti, võib tekkida küsimus, kas on võimalik nõuda spetsifikatsioonide muutmist või funktsioonide lisamist pärast seda, ning kas on võimalik lisada see eelnevalt hinnatud summale. See on kindlasti midagi, mis muret tekitab neile, kes tööd vastu võtavad.

Kuidas neid õigusi seaduslikult tunnustatakse? Kuidas määratakse lisatööde ja funktsioonide parandamise tasu? Selles artiklis käsitleme neid ja muid küsimusi.

Mis on lisatööde ja funktsioonide parandamise mõiste?

Süsteemiarenduse projektides on tavalised lepingutüübid kas töövõtulepingud või poolvolituse lepingud. Mõlemal juhul on lepingus määratletud töövõtja kohustused ja nendega kaasnevad õigused (tasu). Seega, kui töö, mis ei kuulu tasu aluseks oleva töö hulka, lisatakse hiljem, võib seda nimetada lisatööks või funktsiooni parandamiseks. Vastupidi, kui töö kuulub algse spetsifikatsiooni hulka (st see on osa algsest lepingust), käsitletakse seda sellisena.

Täpsemalt töövõtulepingute ja poolvolituse lepingute erinevuste kohta saate lugeda eraldi artiklist.

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

Kuid kui me ütleme, et kõik, isegi ekraanil kuvatava fondi peenhäälestus, on lisatöö, kui seda ei määratleta eelnevalt spetsifikatsioonis, võib see takistada sujuvat äritegevust. Seega, kui arvestada arutelusid nende spetsifikatsioonide üksikasjade üle, ei ole ühtse joone tõmbamine lihtne. Kuid kui anda üldine juhis, siis:

• kui pärast spetsifikatsiooni kinnitamist nõutakse täiendavaid funktsioone
• kui pärast programmi rakendamist nõutakse selle parandamist

siis on sellistel juhtudel tõenäoline, et sellisel väitel on seaduslik alus.

Vaidluspunktiks sai kohtupraktika, kas seda saab nimetada lisatöötluseks või funktsiooni paranduseks

Positiivne näide: Põhikujunduse spetsifikatsioonide muutmine tagantjärele

Alljärgnev näide käsitleb juhtumit, kus spetsifikatsioone muudeti tagantjärele.

Tarkvaraarendus hõlmab järgmisi etappe: ① nõuete määratlemine, ② väline kujundus, ③ sisemine kujundus, ④ lähtekoodi loomine (programmi kujundus, kodeerimine), ⑤ erinevad testid (üksiktestid, kombinatsioonitestid, süsteemitestid) (jäetakse vahele)… Algsete spetsifikatsioonide (jäetakse vahele) realiseerimine sisemise kujunduse ja järgnevate tööde kaudu ning see on töö ulatus, mis on seotud tasu nõudmise õigusega ja vastutasuga vastavalt arenduslepingule. Spetsifikatsioonide muutmise taotlus tõlgendatakse juriidiliselt kui uue töödelepingu taotlus, mis ületab algse lepingu alusel määratud töö ulatuse, ja kui töövõtja ei esita lisatööde eest lisatasu ning lisatasu kokkulepet ei ole, kuid lisatöödega seotud tööd on lõpetatud, siis tõlgendatakse, et töö tellija ja töövõtja vahel on sõlmitud uus töövõtuleping, mille suhtes ei ole määratud tasu, ja et tekib õiglane lisatööde maksmise kohustus.

Osaka ringkonnakohtu otsus 29. augustil 2002 (Heisei 14)

“Vastutasu suhe” ja “uus leping” on märksõnad, mis aitavad mõista selle otsuse sisu.

Muuseas, ülaltoodud otsuses toodi välja veel üks väga huvitav punkt. See on see, et nuppude paigutus või kirja font, mis on väga detailne osa, ei kuulu siin mainitud spetsifikatsioonide muutmise alla. Vastav koht on alljärgnev.

Kuid tarkvaraarenduses ei ole tavaline, et väliste kujunduste etapis määratakse kindlaks sellised detailid nagu ekraanil kuvatava teksti font või nuppude paigutus, ja arvestades, et spetsifikatsioonide kinnitamise järel tehakse tavaliselt osapoolte vaheliste kohtumiste käigus mõningaid parandusi, ei ole mõistlik nõuda spetsifikatsioonide detailide muutmist.

Osaka ringkonnakohtu otsus 29. augustil 2002 (Heisei 14)

Otsuses kasutati huvitavat sõna “spetsifikatsioonide detailimine”.

• Juhul, kui hiljem muudetakse midagi, mis pidi juba olema kindlaks määratud
• Juhul, kui midagi, mida oleks võinud otsustada töö käigus, jäeti tahtlikult otsustamata ja tööd jätkati

Võib öelda, et see näitab mõtteviisi, et õiguslik käsitlus peaks erinema ka nendel juhtudel.

Muud positiivsed näited

Lisaks on juhtumeid, kus on tunnustatud lisatööd ja funktsioonide parandamist, nagu:

• Juhtum, kus tarnitud programmide arv on algsest plaanist peaaegu kahekordistunud (Tokyo Maakohtu otsus 22. aprillil 2017)
• Juhtum, kus tööperiood on peaaegu kolmekordistunud (Tokyo Maakohtu otsus 22. jaanuaril 2010 (Heisei 22))

Nagu näha, on tööperioodi pikendamine laiemalt mõistetav kui lisatöö ja sellele on antud teatud õiguslik kaitse.

“Lisatööde kokkulepped ja tasu suurendamine” ning “algse lepingu sõlmimine” on erinevad küsimused

Oluline punkt nende küsimuste osas on, et

1. “Kas süsteemiarenduse leping (algne leping) on kahe ettevõtte vahel üldse ametlikult sõlmitud?”
2. “Kas ametlikult sõlmitud süsteemiarenduse lepingu puhul on lisatööde leping (ka) lisaks sõlmitud?”

Kohtu otsustuskriteeriumid erinevad nendes olukordades. Kokkuvõtlikult öeldes on kohtu suhtumine

• 1. punkti suhtes range (ilma lepinguta olukorras ei tunnistata lepingu sõlmimist kergesti)
• 2. punkti suhtes suhteliselt leebem (isegi kui lisatööde lepingut pole, tunnistatakse tasu suurendamist jne paindlikult)

1. punkti kohta on üksikasjalikum selgitus eraldi artiklis.

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

Eituse näide: juhtum, kus lepingulise sisu käsitleti seaduslikult samaväärse sisuna

Kuid teiselt poolt on olnud kohtuotsuseid, kus tasu suurendamist ei ole tunnustatud. Allpool tsiteeritud kohtuotsuse puhul vaidlustati, kas tasu suurendamine on lubatud, kuna süsteemiarenduse lepingu sisu muudeti pärast lepingu sõlmimist.

Käesoleva asja vaidluspunktid on: (1) milline oli hageja poolt käesoleva lepingu alusel vastu võetud töö sisu, (2) kas hageja ja kostja vahel saavutati kokkulepe suurendada töö mahtu ja suurendada tasu, (jätka) jne. (jätka)

Algselt oli käesolev leping leping, milles lepiti kokku, et lepingu summa on hageja poolt vastu võetud töö (tellimuse) kindel tasu, ja sammude arv, ühikuhind jne on ainult sisemised dokumendid, mida hageja kasutas tellimuse summa arvutamiseks oma organisatsioonis, ja sammude arvu suurenemine jne on tellimuse summa suhtes täiesti seotud. (jätka)

Nagu eespool tunnustatud, muudeti hageja poolt vastu võetud tööd 1987. aasta (Showa 62. aasta) 25. veebruaril, süsteemi haldamine, tellimustööde kulude arvutamine ja osa utiliitidest piirati ning ülejäänud osa jäi kostja vastutusele. Kuid muudetud hageja töö on endiselt algse lepingu kohaselt arendatud töö ulatuses ja selle töö tasu on täielikult kaetud algse lepingu kohaselt kokku lepitud tasuga.

Tokyo District Court otsus 12. juunil 1995 (Heisei 7)

Selles otsuses otsustati, et isegi kui muudetakse töö sisu, mida tarnija peab täitma, jääb arendamise sisu algse lepingu ulatusse ja see peaks olema kaetud algse lepingu alusel kokku lepitud tasuga.

Lõppkokkuvõttes arvatakse, et tasu suurus sõltub sellest, millise töö tegemist eeldatakse, ja tööde puhul, mis ei kuulu sellesse, tunnustatakse lisatasu nõudmist.

Ja millise töö eest tasu maksti, ei määrata mitte ainult lepingu alusel, vaid ka koosoleku protokollid jne võetakse tõendina arvesse. Koosoleku protokollide tähtsust selgitatakse üksikasjalikult allpool toodud artiklis.

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

Kuidas määratakse lisatööde ja funktsioonide parandamise tasu?

Süsteemiarenduse valdkonnas ei ole haruldane, et esialgu kinnitatud spetsifikatsioonid muutuvad hiljem. Iga kord, kui selline olukord tekib, ei ole realistlik koostada uut kirjalikku lepingut ja jätkata lepinguliste toimingutega. Kui on võimalik uuesti kindlaks määrata, mida tuleb lisada või parandada, ja sõlmida kokkuvõtlikud märkused, on see üks asi, kuid kuidas peaks tasu arvutama, kui projekt on peatatud ilma selliste protseduurideta?

Sellistel juhtudel võib viitepunktiks olla allpool tsiteeritud kaubandusseaduse (Jaapani kaubandusseadus) paragrahv 512 (allajoonitud osa on autori poolt rõhutatud).

Kaubandusseaduse paragrahv 512: Kui kaupleja teeb teise isiku heaks tegevuse oma äritegevuse raames, võib ta nõuda mõistlikku tasu.

Küsimus on selles, kui palju see “mõistlik tasu” konkreetsetes olukordades lõpuks on. Varasemate kohtuotsuste põhjal tundub, et on vastu võetud arusaam, et tuleks katta kulud, mis on proportsionaalsed töö hulgaga, mahuga või perioodiga. See tuleneb tõenäoliselt asjaolust, et süsteemiarenduse töö on oma olemuselt teenindussektor ja põhikulu on tööjõukulud.

Seega, hoolimata kaubandusseaduse “mõistliku tasu” sõnastuse abstraktsusest, ei nõua lisatasu summa hindamine selles kontekstis keerulist arvutust. Vaatame mõnda kohtupraktikat allpool.

Juhtum 1: Näide, kus tunnustati lisatasu, mis on proportsionaalne tööaja suurenemisega

Arengutööde maht, mis põhineb sellel spetsifikatsiooni muutusel, on mõistlik hinnata kogusummana 257,5 inimese/päeva ja kui me konverteerime selle arenduskuludeks inimese/päeva kohta, mis on sama mis selle arenduse delegeerimise lepingu puhul, 32 500 jeeni (A3 puhul on ühikuhind 650 000 jeeni inimese/kuu kohta ja kui me eeldame, et ühe kuu tööpäevade arv on 20 päeva, siis arenduskulud inimese/päeva kohta on 32 500 jeeni.) Siis on mõistlik hinnata lisakulud, mis tulenevad sellest spetsifikatsiooni muutmise nõudest, 8 368 750 jeenina.

Osaka ringkonnakohtu otsus 29. augustil 2002. aastal (Heisei 14)

“Inimese/päeva kohta” on võtmesõna. See näitab, et lisatasu arvutamise aluseks on kasutatud tööaega.

Juhtum 2: Näide, kus tunnustati lisatasu, mis on proportsionaalne programmide arvuga

Kui me arutame selle juhtumi puhul lisatasu õiglast summat, siis arvestades, et arvutisüsteemi arendamise põhikulu on tehnikute tööjõukulud ja need kulud on üldiselt proportsionaalsed loodavate programmide hulgaga, siis võime leida, et algne lepingusumma 23 250 000 jeeni, jagatuna 206 programmiga, mis olid lõpetatud teise kontrolli ajaks, ja korrutatuna 414 programmiga, mis läbisid kolmanda kontrolli, annab summa 46 725 728 jeeni (23,250,000 ÷ 206 × 414 = 46,725,728), mida peetakse õiglaseks.

Tokyo District Court otsus, 22. aprill 2005 (Heisei 17)

Võib-olla on numbreid palju, kuid kui rahulikult lugeda, saate aru, et ei tehta keerulist arvutust. Algne lepingu sisu põhjal kontrollitakse “kui palju hinnati ühe programmi ühiku hinda” ja tehakse lihtsalt lihtne korrutamine “ühikuhind × kogus”.

Juhtum 3: Näide, kus lisatasu on proportsionaalne perioodi pikkusega

Ja seega, A3 lepingus on määratud, et hageja töö eest, mis tehti alates 2005. aasta (Heisei 17) jaanuarist märtsini kolme kuu jooksul poolvolituste alusel, on tasuks 60 miljonit jeeni. Samas, tööd, mis tehti pärast sama aasta aprilli, sisaldasid tasuta tehtud töid, kuid eelmise aasta samal ajal, võrreldes perioodiga kuni sama aasta märtsini, eeldatakse, et töömaht suurenes pärast sama aasta aprilli, kui uue õppeaasta alguse tõttu käivitati süsteem, nagu kursuse registreerimine jne. Nendest asjaoludest lähtudes on mõistlik määrata hageja tasuks 120 miljonit jeeni kuue kuu jooksul alates 2005. aasta (Heisei 17) aprillist septembrini, võttes aluseks 60 miljonit jeeni, mis on määratud kolme kuu töö tasuks.

Tokyo District Court otsus 22. jaanuaril 2010 (Heisei 22)

Ülaltoodud otsus näitab, et pikendatud perioodi puhul arvutatakse lisatasu lihtsa proportsionaalse arvutuse alusel.

Kokkuvõte

Nagu eespool toodud kohtupraktika näitab, tundub, et programmeerijate ja inseneride lisatasude õigusliku käsitlemise osas on teatud seaduspärasusi ja ühiseid jooni. Põhimõtteliselt tundub, et eelistatakse lähenemist, mis põhineb võimalikult lihtsal arvutusel, mis omakorda põhineb suhteliselt objektiivsetel näitajatel, nagu kulunud tööaeg, (tarnitud programmide jms) formaalne töömaht, töötatud aeg või periood.

Kui mõelda, et lisatööde ja funktsioonide parandused tekivad just seetõttu, et on ebaõnnestunud täpne protseduuride järgimine või täiuslik tööaja hinnang, võib tunduda, et lisatasu tekib ainult siis, kui on kulutatud rohkem tööjõudu, tehtud rohkem formaalset tööd või kulutatud rohkem aega. See võib tunduda maitsetu ja igav. Kuid kui vaadata seda teenuse osutaja vaatenurgast, siis isegi kui eesmärk on klientide huve eelistades tööd teha, on see, et sellised õigused on seadusega tõenäoliselt lubatud, oluline kriisijuhtimise seisukohast.