Mikä on lakiin ja sopimuksiin liittyvät ongelmat Agile-kehityksessä?

Järjestelmäkehityksen etenemistavalla on metodologiansa. Klassisin ja yleisin on vesiputousmalli, ja monet järjestelmäkehitystä käsittelevät lakikirjat keskustelevat tämän mallin oletuksena. Tässä artikkelissa selitämme, millaisia ​​lainsäädännöllisiä ongelmia liittyy ketterään kehitysmalliin perustuvaan järjestelmäkehitykseen, josta on vaikea saada tietoa kirjoista ja muista lähteistä.

Agile-kehitysmalli ja oikeudelliset kysymykset

Mitä kehitysmallit tarkoittavat järjestelmäkehityksessä?

Järjestelmäkehitysprojekteissa on olemassa kehitysmalli, joka toimii viitekehyksenä projektin edistymisen seuraamiseksi. Tämän edustajana on niin sanottu “vesiputousmalli”. Toisin sanoen, kuten vesi putoaa joen “yläjuoksulta” “alajuoksulle”, se läpäisee vaatimusten määrittelyn, suunnittelun, toteutuksen, testauksen jne. yhdellä kertaa. Tämä on menetelmä, joka pyrkii vähentämään mahdollisimman paljon työvaiheiden toistoa ja suunnittelemaan työtä järjestelmällisesti.

Toisaalta, Agile-kehitysmallissa toteutetaan pieniä ohjelmia ja testataan niitä toistuvasti. Tällä tavoin, toistamalla pienten ohjelmien toteutusta ja testausta, rakennetaan vähitellen suurempi järjestelmä. Lisätietoja näistä järjestelmäkehitysmalleista ja molempien kehitysmallien etujen ja haittojen vertailusta löytyy seuraavasta artikkelista.

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

Agile-kehitysmallin ominaisuudet

Agile-kehitysmallin suurin etu on, että se mahdollistaa nopean siirtymisen käytännön työhön. Koska “yläjuoksun” tehtävät, kuten vaatimusten määrittely ja suunnitteludokumentaation luominen, ja ohjelman toteutustehtävät eivät ole erillään, se soveltuu joustavaan ohjaukseen, mukaan lukien toimintojen lisääminen ja muuttaminen, sekä eritelmien muuttaminen. Oikeudellisesti tarkasteltuna, erityisen tärkeää Agile-kehitysmallin onnistumiselle on, miten dokumentinhallinta ja muutoshallinta toteutetaan. Agile-kehitysmallissa roolit ja vastuut eivät ole yhtä selkeästi jaoteltuja kuin vesiputousmallissa. Lisäksi, koska se painottaa “nopeutta” pikemminkin kuin “hallintaa”, suunnitteludokumenttien, eritelmien ja pöytäkirjojen puutteellisuus on yleistä.

Lisäksi, muutoshallintaan liittyen, Agile-kehitysmalli mahdollistaa sujuvan reagoinnin muutoksiin, mikä voi johtaa siihen, että hyväksyntäprosessi ohitetaan ja projektin muutospyynnöt hyväksytään työmaatasolla, mikä voi johtaa projektin epäonnistumiseen. Tällöin “sujuva reagointi jälkikäteen tehtäviin muutoksiin” -kehitysmallin etu voi itse asiassa muuttua projektin epäonnistumisriskiksi.

Asiakirjahallinta ja muutoshallinta Agile-kehityksessä

Dokumenttien hallinnan merkitys

Agile-kehitysmalliin perustuvissa kehitysprojekteissa oikeudellisesti huolestuttava seikka on, että suullinen vuorovaikutus kertyy ja johtaa dokumentaation puutteeseen. Tässä yhteydessä, miksi dokumenttien hallinta on tärkeää järjestelmäkehitysprojekteissa, selitetään yksityiskohtaisesti seuraavassa artikkelissa.

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

Kyseisessä artikkelissa selitetään dokumenttien hallinnan merkitys järjestelmäkehitysprojekteissa kahdesta näkökulmasta: riitojen ennaltaehkäisy (eli “ennakoiva oikeudellinen työ”) ja todisteiden säilyttäminen riitatilanteessa (eli “kriisinhallinta”).

Yhteydenpitokokouksen perustaminen on tehokasta dokumentinhallinnassa

Kun otetaan käyttöön ketterä kehitysmalli, toisin kuin vesiputousmallissa, ei ole valmiiksi selkeää suunnitelmaa. Tästä johtuen, ei riitä, että vain hallitaan suunnitelman ja toteutuksen eroja, vaan on olemassa huoli siitä, että kustannukset kasvavat sekä rahallisesti että ajallisesti, jos asiat jätetään vain työmaan hoidettavaksi.

Tästä syystä on tehokasta, että vastuuhenkilö järjestää säännöllisesti yhteydenpitokokouksia projektin sujuvan etenemisen takaamiseksi. Kun kehityksen laajuus on pieni, on tosiaan suosittua, että mieluummin kuin säännöllisten yhteydenpitokokousten järjestäminen, vastuuhenkilöt kokoontuvat yhteen aina kun he voivat. Kuitenkin, ketterän kehitysmallin tapauksessa on erityisen suuri riski, että ajankohtaisia kysymyksiä ei käsitellä kokouksessa. Siksi on turvallista sisällyttää säännöllisten yhteydenpitokokousten järjestäminen myös sopimuksiin. Säännösten osalta Japanin talousministeriön mallisopimuksessa esitetään seuraavasti:

(Yhteydenpitokokouksen perustaminen)

12 §:n mukaan A ja B järjestävät yhteydenpitokokouksen koko projektin keston ajan keskustellakseen edistymisestä, riskien hallinnasta ja raportoinnista, yhteistyöstä ja kunkin osapuolen tehtävien toteutuksesta, järjestelmävaatimusten sisällöstä, ongelmista ja ratkaisuista sekä muista asioista, jotka ovat tarpeen projektin sujuvan toteutuksen kannalta. Kuitenkin, (keskeneräinen).

2. Yhteydenpitokokous järjestetään periaatteessa säännöllisesti yksittäisessä sopimuksessa määritellyllä taajuudella, ja lisäksi se järjestetään tarvittaessa, kun A tai B katsoo sen tarpeelliseksi.

3. Yhteydenpitokokoukseen osallistuvat molempien osapuolten vastuuhenkilöt, päävastuulliset ja ne, jotka vastuuhenkilöt katsovat sopiviksi. Lisäksi A ja B voivat pyytää toista osapuolta tuomaan kokoukseen henkilöitä, jotka ovat tarpeen keskustelun kannalta, ja toisen osapuolen on suostuttava tähän, ellei ole järkevää syytä olla suostumatta.

4. B luo ja esittää edistymisraportin yhteydenpitokokouksessa A:n ja B:n välillä erikseen sovitun mallin mukaisesti, ja tarkistaa edistymisen raportin perusteella, onko viivästyksiä, ja jos on, niiden syyt ja toimenpiteet, tarve muuttaa tässä luvussa määriteltyä edistämisjärjestelmää (henkilöstön vaihto, lisäys, alihankkijan vaihto jne.), turvatoimien toteutuksen tila, tarve muuttaa yksittäistä sopimusta, ja jos on tarvetta muuttaa yksittäistä sopimusta, sen sisältö, ja keskustelee ja päättää näistä asioista tarvittaessa, ja vahvistaa päätetyt asiat, jatkotarkastelun kohteena olevat asiat ja jatkotarkastelun aikataulu ja osapuolet, jotka suorittavat tarkastelun, jos on jatkotarkastelun kohteena olevia asioita. 

(Jäljempänä olevat kohdat 5, 6 ja 7 jätetään pois.)

Yhteydenpitokokouksen olemassaolo antaa sopimusehtoihin tiettyä oikeutusta ja erottaa sen muista ad hoc -kokouksista. Tämä on tärkein kohta.

Yhteydenpito-neuvottelukunnan hyödyntäminen muutosjohtamisessa

Agile-kehityksessä molempien osapuolten alun perin sopimat asiat muuttuvat jälkikäteen, mikä on lähtökohtana. Siksi on erittäin tärkeää, kuinka hallitaan jälkikäteisiä teknisten vaatimusten muutoksia.

Tässä yhteydessä, jos yhteydenpito-neuvottelukunta kokoontuu säännöllisesti, muutosjohtaminen ja sen toteuttaminen sujuvat erittäin hyvin. Esimerkiksi, muutosneuvottelut voidaan järjestää yhteydenpito-neuvottelukunnassa, ja jos toinen osapuoli pyytää muutosneuvotteluja, sopimukseen sisällytetään velvollisuus vastata tähän neuvotteluun. (Alla on otteita Japanin talous-, kauppa- ja teollisuusministeriön mallisopimuksesta.)

(Muutosjohtamisprosessi)

37 §:n mukaan A tai B, kun he ovat vastaanottaneet muutosehdotuksen toiselta osapuolelta (…), antavat toiselle osapuolelle kirjallisen dokumentin (jäljempänä “muutosjohtamisdokumentti”), jossa on seuraavat tiedot ○ päivän kuluessa vastaanottopäivästä, ja A ja B neuvottelevat muutoksen hyväksymisestä tai hylkäämisestä yhteydenpito-neuvottelukunnassa 12 §:n mukaisesti. (Seuraavat tiedot jätetään pois)

Yllä olevan määräyksen pääkohdat voidaan järjestää seuraavasti:

• Muutoksen esittämisen menetelmä on yhdenmukaistettu “muutosehdotusdokumentin” muodossa
  
• Aikaraja on asetettu ehdotuksen vastaanottamisesta neuvottelujen aloittamiseen → Tämä ei välttämättä tarkoita “◯ päivän kuluessa”, vaan voidaan harkita myös “välittömästi” tai vastaavaa ilmaisua.
  
• Muutoksen hyväksymistä tai hylkäämistä koskevat neuvottelut on yhdenmukaistettu “yhteydenpito-neuvottelukunnassa”
  

Toisin sanoen, menettelytapa on selkeytetty, jotta ei synny väärinkäsityksiä, kuten “esitin muutoksen, en esittänyt” tai “vastasin muutoksen hyväksymiseen tai hylkäämiseen, en vastannut”, jotka perustuvat suulliseen viestintään.

Ymmärrystä vilpittömän mielen velvollisuudesta ja lojaalisuusperiaatteesta vaaditaan

Olemme tähän mennessä esitelleet sopimusehtojen malleja, kuten “yhteydenpito-neuvottelukunta” ja “muutosneuvottelut”. Kuitenkin, näiden ymmärtämisen kannalta tärkeää on “vilpittömän mielen velvollisuus” ja “lojaalisuusperiaate”. Alun perin ketterä kehitysmalli on usein vaikea edetä ilman tilaajan ja toimittajan välistä luottamussuhdetta. Tämä johtuu siitä, että työn aloittamisen nopeus on tärkeämpää, ja normaalisti aloittamiseen johtavat menettelyt minimoidaan. Siksi on yleistä sisällyttää sopimukseen ehto, joka velvoittaa toisen osapuolen “vilpittömän mielen velvollisuuteen”.

4 artiklan 3 kohta: Muutosneuvotteluissa tarkastellaan muutoksen kohdetta, muutoksen mahdollisuutta, muutoksen vaikutusta hintaan ja toimitusaikaan, ja molemmat osapuolet neuvottelevat vilpittömästi siitä, tehdäänkö muutos.

Tämä on tarkoitettu estämään sellaiset menetelmät, jotka pettävät toisen osapuolen neuvotteluissa, jotka ovat alun perin edenneet luottamuksen perusteella, esimerkiksi yhtäkkiä väittämällä, että “on täysin vastaanottavan osapuolen vapaata tahtoa suostua sopimuksen muutokseen, eikä ole velvollisuutta suostua pakottamiseen”, ja käyttämällä muodollista oikeudellista argumentaatiota. Tämä heijastaa myös yksityisten välisen kaupankäynnin oikeudellisia periaatteita, ei vain järjestelmän kehittämistä.

Siviililaki, 1 artiklan 2 kohta

Oikeuksien käyttämisen ja velvollisuuksien täyttämisen tulee tapahtua lojaalisuuden mukaisesti ja vilpittömästi.

Laki ei aina painota vain muodollisia “sopimusasiakirjan sisältöjä” tai “pykälän sanamuotoja”. Erityisesti jos toisella osapuolella on kaupankäynti, sinun tulisi käyttää sitä joustavasti sisällyttämällä todellinen “lojaalisuus” ja “vilpittömyys”. Lisäksi olemme selittäneet yksityiskohtaisesti seuraavassa artikkelissa, että “velvollisuus”, joka laissa määrätään, ei välttämättä perustu “sopimus” -menettelyyn.

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

Yhteenveto

On tietenkin tärkeää ymmärtää riskit, jotka liittyvät hallinnollisten menettelyjen ja hallintorakenteiden holtittomaan huolettomuuteen järjestelmäkehitysprojekteissa, jotka perustuvat Agile-kehitysmalliin. Kuitenkin, ei riitä, että ymmärrämme vain nämä riskit. On myös tärkeää ymmärtää lain joustavat ominaisuudet, jotka perustuvat periaatteisiin kuten “hyvän uskon sääntö”, ja soveltaa näitä ymmärryksiä käytännön työhön.