Систем хөгжүүлэлтийн үнэлгээний дараах нэмэгдүүлэлт боломжтой юу?

Систем хөгжүүлэх ажил гэдэг нь захиалагч болон гүйцэтгэгч талууд хоёулаа олон хүний оролцоотойгоор хэрэгждэг учраас, бүх хүмүүсийн алхамыг зэрэгцүүлэн төслийг урагшлуулах нь амаргүй байдаг. Төлөвлөгөөтэй ажиллагаа маш чухал болох нь өөрөөсөө яригдаж байгаа хэрэг ч гэсэн, захиалагч болох хэрэглэгчид зохих мэдээллийг цогцлоон, тодорхойгоор гүйцэтгэгчид шилжүүлэх нь бодит байдал дээр хэр зэрэг боломжтой вэ гэдэг нь үнэндээ тийм биш. Хөгжүүлэлтийн явц нэлээдгүй хэсэгтээ хүрсэн үед, дараа нь шаардлагатай өөрчлөлтүүд ба нэмэлт функцүүдийг хүссэн тохиолдолд, анхны үнийн дүнгийн дээр нэмэлт төлбөр тооцох боломжтой эсэх нь гүйцэтгэгч талын хувьд маш их сонирхол татах асуудал байх болно.

Энэхүү эрхийг хууль ёсны хувьд ямар нөхцөлд олгодог вэ? Мөн нэмэлт хөгжүүлэлт, функцүүдийн засварын төлбөрийг хэрхэн тогтоодог вэ? Энэхүү нийтлэлд бид эдгээр төрлийн олон асуултад цэгцтэй хариулт өгөх болно.

Үндсэндээ нэмэлт хөгжүүлэлт ба функцын засвар гэж юу вэ?

Систем хөгжүүлэлтийн төслийн хүрээнд ажил хийх гэрээний хэлбэр нь ерөнхийдөө гүйцэтгэлийн гэрээ эсвэл харьяаллын гэрээ гэх мэт байдаг. Эдгээр гэрээний хэлбэрүүд нь аль аль нь ажил гүйцэтгэгчийн хийх ёстой үүрэг (үүрэг) ба түүнд холбогдох хөлс (эрх) нь гэрээнд хослуулан заасан байдаг. Иймд, тухайн хөлсний үндэслэл болгон тооцогдсон ажлын хүрээнд багтаагүй нэмэлт ажил нэмэгдсэн тохиолдолд, нэмэлт хөгжүүлэлт ба функцын засвар гэж үзэж болно. Эсрэгээрээ, хамааралтай байгаа тохиолдолд, эхний тодорхойлолт дагуу (өмнөх гэрээний хүрээнд) боловсруулагдсан гэж үзнэ.

Та бүхэнд мэдэгдэхэд, гүйцэтгэлийн гэрээ ба харьяаллын гэрээний ялгаа зэргийг бусад нийтлэлд дэлгэрэнгүй тайлбарласан байдаг.

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

Гэхдээ, дэлгэц дээр харагдах фонтын жижиг тохируулга зэргийг бүгдийг урьдчилан тодорхойлолтод зааж өгөхгүй бол, тэдгээрийг нэмэлт хөгжүүлэлт гэж үзэх болвол, энэ нь арилжааны гүйлгээг ихээхэн саад болох эрсдэлтэй. Иймд, эдгээр тодорхойлолтын дэлгэрэнгүй мэдээллийг харгалзан үзвэл, журамтай шугам татах нь тийм ч амар биш. Гэхдээ ерөнхий зарчим гаргах гэвэл:

• Тодорхойлолт батлагдсаны дараа нэмэлт функц нэмж үүсгэхийг заасан
• Програмын хэрэгжүүлэлт дууссаны дараа түүний засварыг заасан

Ийм тохиолдлуудад, тухайн үйлдлийн хууль ёсны хүчин төгөлдөр байдал нь өндөр магадлалтай гэж үзэж болно.

Нэмэлт хөгжүүлэлт ба функц засварласан эсэх нь маргааны цэг болсон шүүхийн шийдвэр

Баталгаажуулсан жишээ: Үндсэн төлөвлөгөөний шаардлагыг дараа нь өөрчилсөн тохиолдол

Доорх жишээ нь дараа нь шаардлагыг өөрчилсөн тохиолдлууд юм.

Програм хангамжийн хөгжүүлэлт нь ①Шаардлага тодорхойлох, ②Гадаад зураг төсөл, ③Дотоод зураг төсөл, ④Эх кодын програм бичих (програм төлөвлөлт, кодчилол), ⑤Төрөл бүрийн тест (нэгж тест, хослол тест, систем тест) гэсэн хөгжүүлэлтийн үе шатуудыг дамжуулан явагддаг. Энэ нь анхны шаардлагаг дотоод зураг төсөл болон түүнээс хойшхи ажлуудыг гүйцэтгэх замаар бодит болгох бөгөөд энэ нь тухайн хөгжүүлэлтийн гэрээний үндсэн дагуу хүлээн авах төлбөр ба үүнтэй холбоотой ажлын хүрээ гэж ойлгогдох ёстой.
Шаардлагын өөрчлөлтийг санал болгосон нь, эрх зүйн хувьд, гүйцэтгэгчээс шинэ ажлын гэрээний санал гэж үзэгдэх бөгөөд энэд гүйцэтгэгч нэмэлт ажлын төлбөрийн дүнг тодорхой бус, нэмэлт төлбөрийн дүнгээр санал нийлээгүй байхад нэмэлт ажлыг гүйцэтгэсэн тохиолдолд, шинэ барилгын гэрээ байгуулагдсан гэж үзэж, зохих нэмэлт хөгжүүлэлтийн зардал төлөх үүрэг үүссэн гэж ойлгох нь зүйтэй.

Осака газрын шүүх Хейсэй (2002) 14 жилийн 8 сарын 29-ний шийдвэр

“Төлбөрийн харилцаа”, “Шинэ гэрээ” гэх мэт түлхүүр үгсийг анхаарч, энэ шийдвэрийг ойлгоход туслах болно.

Мөн таамаглаж хэлэхэд, дээрх шийдвэрт бас нэгэн маш сонирхолтой зүйл илэрсэн байна. Энэ нь товчлуур байрлуулах, үсгийн фонт гэх мэт маш нарийн детальд хийсэн жижиг засварыг энд дурдсан шаардлагын өөрчлөлтөд тооцохгүй гэсэн явдал юм. Холбогдох хэсэг нь дараах байдлаар байна.

Гэхдээ програм хангамжийн хөгжүүлэлтэд, түүний онцлог шинж чанартай учраас, гадаад зураг төсөлд дэлгэцэнд үсгийг харуулах фонт, товчлуурын байрлал зэрэг нарийн детальд хүртэл шийдвэрлэгддэггүй бөгөөд, детальд хүртэлх шийдвэр нь шаардлага батлагдсаны дараа ч, талуудын уулзалтаар зарим засвар оруулах нь элбэг байдаг. Иймд, ийм нарийн шаардлагын детальжилт хүсэх нь шаардлагын өөрчлөлт гэж үзэх нь зүйтэй биш гэж үзэх ёстой.

Осака газрын шүүх Хейсэй (2002) 14 жилийн 8 сарын 29-ний шийдвэр

Шүүхийн шийдвэрт “Шаардлагын детальжилт” гэсэн сонирхолтой үг хэрэглэгдсэн байна.

• Урьдчилан тогтоосон зүйлсийг дараа нь өөрчилсөн тохиолдол
• Явцын үеэр шийдвэрлэх ёстой зүйлсийг түр зогсоосон байдал

Иймд, эрх зүйн хувьд ч бас өөр өөр байдлаар хандах ёстой гэсэн санааг илэрхийлсэн байна.

Бусад эерэг жишээнүүд

Мөн, нэмэлт хөгжүүлэлт болон функцын засварыг хүлээн зөвшөөрсөн тохиолдлуудад:

• Анхны төлөвлөгөөнөөс хамаарч, хүргэсэн програм хангамжийн тоо хоёр дахин нэмэгдсэн жишээ (Токио газар дундын шүүх 17 он (2005) 4 сарын 22-ны шийдвэр)
• Ажлын хугацаа гурван дахин сунгасан жишээ (Токио газар дундын шүүх Хэйсэй 22 он (2010) 1 сарын 22-ны шийдвэр)

Иймд энэхүү жагсаалтыг харахад, ажлын хугацааны сунгалт мөн өргөн утгаараа нэмэлт хөгжүүлэлт гэж үзэж, тодорхой хууль ёсны хамгаалалтанд хүрч болохуйц бодлого баримтлагдаж байгааг харж болно.

「Нэмэлт хөгжүүлэлттэй холбоотой гэрээ ба цалингийн нэмэгдэл」 ба 「Анхны гэрээний байгуулалт」 нь хоёр өөр асуудал

Эдгээр асуудлуудтай холбоотой чухал цэгүүдийг тодруулахад,

1. 「Эхлээд хоёр компанийн хооронд систем хөгжүүлэлттэй холбоотой гэрээ (анхны гэрээ) албан ёсоор байгуулагдсан эсэх」 тухай үе
2. 「Албан ёсоор байгуулагдсан систем хөгжүүлэлттэй холбоотой гэрээнд (мөн) нэмэлт хөгжүүлэлттэй холбоотой гэрээ нэмж байгуулагдсан эсэх」 тухай үе

гэдгийг шүүхийн шийдвэрлэх үндэслэл нь ялгаатай байдаг. Товчхондоо хэлбэл, шүүх нь,

• 1-тэй холбоотойгоор хатуу байдалтай (гэрээний бичиг баримтгүй үед гэрээ байгуулагдсаныг ховор зөвшөөрдөг) байдаг
• 2-тэй холбоотойгоор харьцангуй зөөлөн (нэмэлт хөгжүүлэлттэй холбоотой гэрээний бичиг баримтгүй ч, цалингийн нэмэгдлийг зөөлөн зөвшөөрдөг) байдаг

гэж хэлж болно. 1-тэй холбоотойгоор бусад нийтлэлд дэлгэрэнгүй тайлбарласан байдаг.

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

Үгүйлэх жишээ: Хууль ёсны хувьд ижил төстэй гэрээний агуулгад хамаарахаар үйлчлүүлэгчдэд хандсан тохиолдол

Гэхдээ төлбөрийн нэмэгдэл хүлээн зөвшөөрөгдөөгүй шүүхийн шийдвэрүүд ч байдаг. Доорх шүүхийн шийдвэрийн текстэд дурдсан хэргийн хувьд, систем хөгжүүлэлтийн гэрээгээр ажлын гүйцэтгэлд хийгдсэн өөрчлөлтөөс болж төлбөрийн нэмэгдэл хүлээн зөвшөөрөх эсэх нь маргаантай болсон билээ.

Энэ хэргийн маргааны цэг нь, (1) гэрээгээр өгөгдсөн ажлын агуулга ямар байсан бэ, (2) тухайн ажлын хэмжээг нэмэгдүүлж, төлбөрийг нэмэх талаар гэрээний талууд хоорондоо ойлголцсон эсэх, (дундас нь орхигдсон), гэх мэт асуудлуудад оршино. (дундас нь орхигдсон)

Эхлээд, энэ гэрээ нь гэрээний төлбөрийн хэмжээгээр өгөгдсөн ажлын (гүйцэтгэлийн) тодорхой хариуцлагыг хүлээхээр тохиролцсон гэрээ бөгөөд ажлын хэмжээ, нэгж үнэ гэх мэт нь зөвхөн гэрээний төлбөрийг тооцоолох үед дотоодын материал хэрэглэгдэх бөгөөд ажлын хэмжээний өсөлт гэх мэт нөхцөл байдлууд нь гэрээний төлбөртэй ямар ч хамааралгүй байдаг. (дундас нь орхигдсон)

Өмнөх тогтоолын дагуу, өгөгдсөн ажлын агуулга нь 1987 оны (Шоува 62 жилийн) 2-р сарын 25-нд өөрчлөгдсөн бөгөөд системийн удирдлага, гүйцэтгэлийн зардал тооцоолох болон утилитийн зарим хэсгийг хязгаарласан бөгөөд бусад нь үйлчлүүлэгчийн хариуцлагад орсон эсэх, энэхүү өөрчлөлтийн дараах ажлын агуулга нь анхны гэрээний хүрээнд байсан хөгжүүлэлтийн ажлын хүрээнд багтаж байгаа эсэх нь өөрчлөгдөөгүй бөгөөд тухайн ажлын хариуцлага нь гэрээний эхлэлд тохиролцсон тодорхой төлбөрөөр бүрэн хамарч байгаа болно.

Токио дүүргийн шүүхийн 1995 оны (Хэйсэй 7 жилийн) 6-р сарын 12-ны шийдвэр

Тухайн шийдвэрт, үйлчлүүлэгчид өгөгдсөн ажлын агуулга өөрчлөгдсөн ч, тухайн хөгжүүлэлтийн агуулга нь анхны гэрээний хүрээнд багтаж байгаа бөгөөд анх урьдчилан тохиролцсон төлбөрийн дотор хамарч байх ёстой гэж үзсэн байна.

Эцэст нь, төлбөрийн хэмжээ нь ямар ажлыг гүйцэтгэхийг үндэслэн тогтоосон байгааг харгалзан, түүнд багтаагүй ажлын хувьд нэмэлт төлбөрийн хүсэлтийг зөвшөөрөх байр суурьтай байгаа гэж үзэж болох юм.

Мөн, төлбөрийн хэмжээ нь ямар ажлын төлөөх хариуцлага байсан бэ гэдэг нь заавал гэрээний бичиг баримт л биш, хуралдааны тэмдэглэл зэрэг бусад баримтуудыг ч гэрч болгон шүүхийн шийдвэрт харгалзах болно. Хуралдааны тэмдэглэлийн чухал байдлыг доорх нийтлэлд дэлгэрэнгүй тайлбарласан байна.

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

Нэмэлт хөгжүүлэлт ба функцын засварын хувьд хэрхэн төлбөрийн хэмжээ тогтоогдох вэ

Систем хөгжүүлэлтийн талбарт, нэг удаа батлагдсан шаардлага хэдийнээ өөрчлөгдөх нь тийм ч ховор зүйл биш. Ийм өөрчлөлт бүрт гэрээний шинэ хувилбарыг бэлтгэж, гэрээний ажлыг хийх нь бодит байдалд боломжгүй. Нэмэлт, засварлах зүйлсийн талаар дахин тодорхойлж, дурсгалын бичиг гэх мэт баримт бичгийг байгуулах боломжтой тохиолдолд бол тэр бүү хэл, ийм процедурыг хийж чадахгүйгээр төслийг зогсоох шаардлага гарвал төлбөрийн хэмжээг хэрхэн тооцоолох вэ?

Ийм тохиолдолд анхаарах ёстой заалт нь дараах Японы Худалдааны хуулийн 512-р зүйл байна (доорх хэсэгт зохиогчийн татаасыг хасав).

Японы Худалдааны хуулийн 512-р зүйл: Худалдаачин өөрийн үйл ажиллагааны хүрээнд өөр хүнд үйлдэл хийсэн тохиолдолд, зохих төлбөр авах эрхтэй.

Энэ заалтад дурдагдсан “зохих төлбөр” гэдэг нь тодорхой нөхцөлд хэрхэн, хэдэн төгрөг болохыг тодорхойлох нь асуудал болдог. Өнгөрсөн шүүхийн шийдвэрийг харахад, ажлын цагийн тоо, хэмжээ эсвэл хугацаагаар төлбөрийг тооцоолох нь зүйтэй гэсэн үзэл баримтлалыг хэрэглэж байгааг харж болно. Энэ нь систем хөгжүүлэлтийн ажил нь үндсэндээ үйлчилгээний салбар бөгөөд үндсэн зардал нь хүний нөөц байдагтай холбоотой байж магадгүй.

Иймд, Худалдааны хуулийн “зохих төлбөр” гэсэн үгийн абстракт хэлбэртэй харьцуулахад, ийм контекст дахь нэмэлт төлбөрийн хэмжээг тооцоолох нь тийм ч хүндрэлтэй тооцоо биш болохыг харуулж байна. Доорхи шүүхийн шийдвэрүүдийг харцгаая.

Кейс 1: Ажлын цагийн нэмэгдэлд харгалзан нэмэлт төлбөрийг зөвшөөрсөн жишээ

Энэхүү шаардлагын өөрчлөлтөд үндэслэн хөгжүүлэлтийн ажлын цагийн нийт хэмжээ нь 257.5 хүн/өдөр гэж үзэх нь зүйтэй бөгөөд, энэхүү хөгжүүлэлтийн ажлын цагийг нэг хүн/өдөр тутамд 32,500 иений (Японы төгрөг) (Ко 3-д, нэг хүн/сарын тутамд 650,000 иен гэж үзсэн бөгөөд, нэг сарын ажлын өдрийг 20 өдөр гэж тооцвол, нэг хүн/өдрийн хөгжүүлэлтийн зардал нь 32,500 иен болно.) гэж тооцоолбол, энэхүү шаардлагын өөрчлөлтөд үндэслэн нэмэлт хөгжүүлэлтийн зардал нь 8,368,750 иен байх нь зүйтэй гэж үзэв.

Осака засгийн газрын 2002 оны (Хэйсэй 14) 8-р сарын 29-ний шийдвэр

“Нэг хүн/өдөр тутамд” гэдэг нь түлхүүр үг юм. Нэмэлт төлбөрийн тооцооллын үндэслэлд ажлын цагийг ашиглаж байгааг харуулж байна.

Кейс 2: Программын тоонд харгалзан нэмэлт төлбөрийг зөвшөөрсөн жишээ

Энэхүү кейсэд нэмэлт хэсгийг оруулан зохих төлбөрийн хэмжээг авч үзэхэд, компьютерийн систем хөгжүүлэлтийн үндсэн зардал нь техникийн ажилтны хүний нөөцийн зардал бөгөөд, энэ хүний нөөцийн зардал нь ерөнхийдөө програм хангамжийн хэмжээнд харгалзана гэдгийг харгалзан, эхний гэрээний төлбөрийн хэмжээ болох 23,250,000 иенийг анхны шалгуурын үед дуусгасан 206 програм хангамжийн тоогоор хувааж, энэ програм хангамжийн нэгжийн үнэд гуравдугаар шалгуурыг давсан програм хангамжийн тоо 414-ийг үржүүлсэн дүн 46,725,728 иен (23,250,000 ÷ 206 × 414 = 46,725,728) байх нь зүйтэй гэж үзэв.

Токио засгийн газрын 2005 оны (Хэйсэй 17) 4-р сарын 22-ны шийдвэр

Тоо олон гарч ирсэн ч, тайван уншвал хүндрэлтэй тооцоо хийж байгаа нь биш гэдгийг ойлгох болно. Эхний гэрээний агуулгыг үндэслэн, “нэг програм хангамжийн нэгжийн үнийг хэдэн иенээр тооцож ярилцаж байсан бэ” гэдгийг тогтоосны дараа, “нэгжийн үнэ × тоо” гэсэн энгийн үржвэрийг хийж байгаа нь харагдана.

Кейс 3: Хугацааны уртад харгалзан нэмэлт төлбөрийг зөвшөөрсөн жишээ

Мөн, Ко 3 гэрээнд 2005 оны (Хэйсэй 17) 1-р сараас 3-р сар хүртэлх 3 сарын хугацаанд үйлчлэгчийн ажлын хөлс хүлээн авахаар 60,000,000 иен тогтоосон бол, тэр жилийн 4-р сараас эхлэн хийсэн ажил нь үнэгүй хийгдсэн ажилтай холбоотой байхад, өмнөх жилийн адил, тэр жилийн 3-р сар хүртэлх хугацаанд шинэ хичээлийн жил эхлэхэд сургалтын бүртгэл зэрэг систем ажиллаж эхлэх тэр жилийн 4-р сараас хойш ажлын хэмжээ нэмэгдэхийг төсөөлж болно. Эдгээр зүйлсийг харгалзан, дээрх 3 сарын хугацаанд ажлын хөлс хүлээн авахаар тогтоосон 60,000,000 иенийг үндэслэн, үйлчлэгчийн 2005 оны (Хэйсэй 17) 4-р сараас 9-р сар хүртэлх 6 сарын ажлын хөлс нь 120,000,000 иен байх нь зүйтэй гэж үзэв.

Токио засгийн газрын 2010 оны (Хэйсэй 22) 1-р сарын 22-ны шийдвэр

Дээрх шийдвэр нь сунгасан хугацаанд ч, энгийн харьцаатай тооцооллыг ашиглан нэмэлт төлбөрийг тооцоолохыг харуулж байна.

Хураангуй

Дээрх шиг тодорхой хэд хэдэн шүүхийн шийдвэрүүдийг дараалан харуулбал, програмист, инженерүүдийн нэмэлт хөлсний хууль ёсны боловсруулалтад зарим төрлийн хууль зүйн дүрэм, хамтын ойлголт гарч ирдэг болохыг харж болно. Өөрөөр хэлбэл, зарчмын хувьд, зарцуулсан хүчин чармайлт, (хүргүүлсэн програмуудын) формаль хэмжээ, ажилласан цаг болон хугацаа гэх мэт харьцангуй объектив үзүүлэлтүүдийг үндэслэн, энгийн байдлаар тооцоолох нь илүү тодорхой байх хандлагыг харж болно.

Нарийн төвөгтэй процедурыг боловсруулах, бүрэн бүтэн хүчин чармайлтын тооцоог одоо ч гэсэн амжилтгүй байгаагаас үзвэл, ийм нэмэлт хөгжүүлэлт, функцын засвар олон тохиолддог билээ. Иймээс, хүн ажиллуулсан хэмжээ, хийсэн ажлын формаль хэмжээ, зарцуулсан цагийн хэмжээгээр нэмэлт хөлс тооцох нь, магадгүй тун хуурай, сонирхолгүй санагдаж магадгүй. Гэхдээ, энэ нь гэрээт гүйцэтгэгчийн өмнөөс харахад, хэрэв үйлчлүүлэгчийн ашиг сонирхлыг эрхэмлэн ажиллахыг зорьж байгаа ч, ийм эрхийг хууль ёсны хувьд зөвшөөрөх магадлалтай гэдэг нь, хэрэгцээт удирдлагын хувьд чухал утгатай байж магадгүй.