MONOLITH LAW OFFICE+81-3-6262-3248काम करने के दिन 10:00-18:00 JST [Englsih Only]

MONOLITH LAW MAGAZINE

IT

क्या सिस्टम विकास की अनुमानित राशि को बाद में बढ़ाया जा सकता है?

IT

क्या सिस्टम विकास की अनुमानित राशि को बाद में बढ़ाया जा सकता है?

सिस्टम विकास नामक कार्य में, आदेश देने वाले उपयोगकर्ता पक्ष और आदेश प्राप्त करने वाले विक्रेता पक्ष दोनों ही बड़ी संख्या में लोगों को शामिल करते हैं, इसलिए सभी के साथ मिलकर परियोजना को आगे बढ़ाना आसान नहीं होता। योजनाबद्धता अत्यंत महत्वपूर्ण कार्य होने के साथ-साथ, आदेश देने वाले उपयोगकर्ता के पास उचित जानकारी को संग्रहित करने और विक्रेता को स्पष्ट रूप से बताने की क्षमता होती है या नहीं, वास्तव में ऐसा नहीं होता। विकास प्रक्रिया के कुछ हद तक आगे बढ़ने के बाद, यदि विशेषताओं के परिवर्तन या विशेषताओं के जोड़ने की मांग की जाती है, तो क्या पूर्वानुमानित राशि के ऊपर बिल करने की संभावना होती है या नहीं, यह काम करने वाले पक्ष के लिए बहुत ही चिंताजनक होता है।

ऐसे अधिकार कानूनी रूप से किस प्रकार के मामलों में मान्य होते हैं? और इस अतिरिक्त विकास और सुविधाओं के संशोधन के लिए पुरस्कार राशि का निर्धारण कैसे किया जाता है? इस लेख में, हम इन सभी प्रकार के सवालों को व्यवस्थित करेंगे।

अतिरिक्त विकास और सुविधाओं की सुधार कब कहा जा सकता है

सिस्टम विकास के प्रोजेक्ट में, जब काम किया जाता है, तो सामान्यतः ठेका या अर्ध-नियुक्ति अनुबंध होते हैं। इन अनुबंधों में, काम करने वाले पक्ष के करने योग्य कार्य (अर्थात् कर्तव्य) और उससे संबंधित मुआवजा (अर्थात् अधिकार) एक जोड़ी बनाकर अनुबंध में दर्शाए जाते हैं। इसलिए, अगर मुआवजे की राशि के आधार पर कार्य नहीं होते हैं और बाद में उन्हें जोड़ा जाता है, तो यह कहा जा सकता है कि यह अतिरिक्त विकास और सुविधाओं की सुधार है। विपरीत, यदि यह शामिल होता है, तो यह मूल विशेषताओं के अनुसार (अर्थात् मौजूदा अनुबंध के दायरे में) इलाज किया जाता है।

वैसे, ठेके और अर्ध-नियुक्ति अनुबंध के अंतर आदि के बारे में हमने अन्य लेख में विस्तार से व्याख्या की है।

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

हालांकि, यदि हम सभी फ़ॉन्ट की सूक्ष्म समायोजन आदि को भी पहले से ही विशेषताओं में निर्धारित करते हैं, तो यह सभी अतिरिक्त विकास हैं, तो यह सुचारू व्यापारिक लेन-देन को गंभीर रूप से बाधित कर सकता है। इसलिए, इन विशेषताओं के विवरण के बारे में चर्चा करने के बाद, यह एक सामान्य रेखा खींचना आसान नहीं है। लेकिन यदि हम एक सामान्य दिशा-निर्देश देते हैं, तो

  • विशेषताएं एक बार निर्धारित होने के बाद, अतिरिक्त सुविधाओं का आदेश दिया गया
  • प्रोग्राम का कार्यान्वयन पहले से ही समाप्त हो चुका है, और उसकी सुधार का आदेश दिया गया है

ऐसी स्थितियों में, उनके दावे की कानूनी रूप से कुछ वैधता हो सकती है।

अतिरिक्त विकास और सुविधाओं की सुधार को लेकर विवादित बिंदु बने न्यायिक मामले

सॉफ्टवेयर विकास में “विशेषताओं का परिवर्तन” क्या होता है?

सकारात्मक उदाहरण: मूल डिजाइन की विशेषताओं में पश्चाताप संशोधन का मामला

निम्नलिखित मामला, विशेषताओं में पश्चाताप संशोधन का है।

सॉफ्टवेयर विकास, ① आवश्यकता परिभाषा, ② बाहरी डिजाइन, ③ आंतरिक डिजाइन, ④ स्रोत प्रोग्राम की सिर्जना (प्रोग्राम डिजाइन, कोडिंग), ⑤ विभिन्न परीक्षण (एकल परीक्षण, संयोजन परीक्षण, सिस्टम परीक्षण) के विकास प्रक्रिया के माध्यम से आगे बढ़ता है। मूल विशेषताएं को आंतरिक डिजाइन के बाद के कार्य के माध्यम से साकार करने की बात है, और यह समझा जाता है कि यही, मूल विकास ठेका संविदा के आधार पर मुआवजा का दावा और मूल्य संबंधी कार्य की सीमा है।
विशेषता संशोधन का प्रस्ताव, कानूनी रूप से, नई कार्य ठेका संविदा का आवेदन के रूप में समझा जाता है, जो ठेकेदार के द्वारा मूल संविदा के आधार पर कार्य की सीमा से अधिक होता है, और इसके विपरीत, यदि ठेकेदार ने अतिरिक्त काम की राशि प्रस्तुत नहीं की, और अतिरिक्त राशि की सहमति नहीं होने पर अतिरिक्त ठेका के कार्य को पूरा किया, तो यह समझा जाता है कि ठेकेदार और ठेकेदार के बीच नई ठेका संविदा बन गई है, जिसमें उचित अतिरिक्त विकास शुल्क भुगतान का दायित्व उत्पन्न होता है।

ओसाका जिला न्यायालय, हेइसेई 14 (2002) 29 अगस्त का निर्णय

‘मूल्य संबंधी’, ‘नई संविदा’ जैसे कीवर्ड को ध्यान में रखना, इस निर्णय को बेहतर समझने का मार्ग प्रशस्त करेगा।

वैसे भी, उपरोक्त निर्णय में, एक और बहुत ही दिलचस्प बात उठाई गई थी। वह यह था कि बटन की व्यवस्था या अक्षरों की शैली जैसे बहुत ही विस्तृत हिस्सों की सूक्ष्म समायोजन, यहां कही गई विशेषता संशोधन के लिए पात्र नहीं है। संबंधित अनुच्छेद निम्नलिखित है।

हालांकि, सॉफ्टवेयर विकास में, इसकी प्रकृति के आधार पर, बाहरी डिजाइन के चरण में स्क्रीन पर अक्षरों की शैली या बटन की व्यवस्था आदि का विस्तार निर्धारित नहीं होता है, और विस्तार के बारे में, विशेषता की पुष्टि के बाद भी, पक्षों के बीच की बैठक के माध्यम से कुछ संशोधन किए जा सकते हैं, जो सामान्य होता है इस बात को ध्यान में रखते हुए, ऐसी विशेषताओं की विस्तार की मांग को भी विशेषता संशोधन के रूप में मानना उचित नहीं होगा

ओसाका जिला न्यायालय, हेइसेई 14 (2002) 29 अगस्त का निर्णय

निर्णय पाठ में, ‘विशेषताओं का विस्तार’ नामक दिलचस्प शब्द का उपयोग किया गया था।

  • पहले से ही तय किए गए चीजों को बाद में पलट दिया गया
  • काम करते समय निर्णय लेने की चीजों के बारे में, जानबूझकर निर्णय नहीं लेकर आगे बढ़ा

तो, कानूनी रूप से उनका व्यवहार भी अलग होना चाहिए, ऐसा मानना उचित होगा।

अन्य सकारात्मक उदाहरण

इसके अलावा, अतिरिक्त विकास और सुविधाओं के संशोधन के रूप में मान्यता प्राप्त करने वाले मामलों में,

  • मूल योजना की तुलना में वितरित किए गए प्रोग्राम की संख्या लगभग दोगुनी हो गई थी (टोक्यो जिला न्यायालय, 2017 वर्ष 22 अप्रैल का निर्णय)
  • कार्य की अवधि लगभग तीन गुना बढ़ गई थी (टोक्यो जिला न्यायालय, हेसी 22 वर्ष (2010) 22 जनवरी का निर्णय)

ऐसे मामले होते हैं। इस प्रकार संगठित करने पर, कार्य की अवधि के विस्तार को भी, व्यापक अर्थ में अतिरिक्त विकास के रूप में, कुछ निश्चित कानूनी सुरक्षा प्राप्त करने के लिए एक विचारधारा अपनाई गई है।

“अतिरिक्त विकास से संबंधित समझौते और वेतन वृद्धि” और “मूल अनुबंध का निर्माण” अलग-अलग मुद्दे हैं

इन मुद्दों के संबंध में महत्वपूर्ण बिंदु हैं,

  1. “क्या दो कंपनियों के बीच सिस्टम विकास के लिए अनुबंध (मूल अनुबंध) आधिकारिक रूप से स्थापित हुआ था या नहीं” और
  2. “एक बार जब सिस्टम विकास आधिकारिक रूप से स्थापित हो गया, क्या अतिरिक्त विकास के लिए अनुबंध (भी) अतिरिक्त रूप से स्थापित हुआ था या नहीं”

इन मामलों में, न्यायालय के निर्णय के मापदंड अलग-अलग होते हैं। सीधे शब्दों में कहें तो, न्यायालय,

  • 1 के संबंध में कठोर (अनुबंध पत्र के बिना, अनुबंध की स्थापना को आसानी से मान्य नहीं करता) प्रवृत्ति होती है
  • 2 के संबंध में अपेक्षाकृत उदार (अतिरिक्त विकास के लिए अनुबंध पत्र के बिना भी, वेतन वृद्धि आदि को लचीलापन से मान्यता देता है) प्रवृत्ति होती है

यह कहा जा सकता है। 1 के बारे में विस्तार से अन्य लेख में व्याख्या की गई है।

नकारात्मक उदाहरण: ऐसा मामला जिसे कानूनी रूप से समान प्रतिनिधित्व के अंतर्गत माना गया था

हालांकि, एक ओर, कुछ न्यायिक मामले भी हैं जहां वेतन वृद्धि स्वीकार नहीं की गई थी। नीचे उद्धृत निर्णय में, सिस्टम विकास के अनुबंध के संबंध में, एक बार व्यापार प्रतिनिधित्व अनुबंध का निर्माण होने के बाद, कार्य की सामग्री में परिवर्तन होने के कारण, वेतन वृद्धि स्वीकार की जा सकती है या नहीं, इस पर विवाद हुआ था।

इस मामले का मुख्य विवाद यह है कि, (1) मुद्दायी ने इस अनुबंध में क्या कार्य स्वीकार किया था, (2) क्या मुद्दायी और प्रतिवादी के बीच में आयोजन को विस्तारित करने और दाम बढ़ाने की सहमति हुई थी, (अन्य)। (अन्य)।

सबसे पहले, इस अनुबंध का मुख्य उद्देश्य था कि, उसकी कीमत को मुद्दायी के स्वीकृत कार्य (ठेका) के लिए निश्चित मूल्य के रूप में मानने के लिए एक ठेका अनुबंध था, और स्वीकृत कार्य के संबंध में स्टेप संख्या, दर आदि केवल मुद्दायी के आंतरिक दस्तावेजों में ठेका राशि की गणना करने के लिए थे, और स्टेप संख्या की वृद्धि आदि की परिस्थितियाँ, ठेका राशि से पूरी तरह से असंबंधित थीं। (अन्य)।

जैसा कि पहले ही मान्यता प्राप्त है, मुद्दायी के स्वीकृत कार्य में शोवा 62 (1987) वर्ष के फरवरी 25 को परिवर्तन किया गया था, और सिस्टम प्रबंधन, ठेका निर्माण लागत और उपयोगिता का केवल एक हिस्सा सीमित हो गया था, और बाकी का हिस्सा प्रतिवादी ने संभाल लिया था, या मुद्दायी के कार्य का परिवर्तन मूल अनुबंध के अनुसार विकास कार्य के दायरे में था, और इस कार्य के लिए मूल्य, इस मामले में मूल अनुबंध के समय निश्चित मूल्य के रूप में तय की गई प्रतिनिधित्व राशि से पूरी तरह से कवर किया गया था।

टोक्यो जिला न्यायालय, हेइसेइ 7 (1995) वर्ष 12 जून का निर्णय

इस निर्णय में, वेंडर के द्वारा स्वीकृत कार्य की सामग्री में परिवर्तन होने पर भी, उस विकास सामग्री को मूल अनुबंध की सामग्री के दायरे में माना गया, और यह निर्णय दिया गया कि यह मूल रूप से वादा किए गए वेतन के अंतर्गत कवर किया जाना चाहिए।

अंत में, वेतन की राशि किस प्रकार के कार्य करने की आधारभूत धारणा के आधार पर तय की गई थी, इसे ध्यान में रखते हुए, उसमें शामिल नहीं होने वाले कार्यों के लिए, अतिरिक्त वेतन की मांग स्वीकार की जानी चाहिए, ऐसा माना जा सकता है।

और, वेतन की राशि मूल रूप से किस प्रकार के कार्य करने के लिए थी, यह अनिवार्य रूप से केवल अनुबंध के आधार पर नहीं होता है, बल्कि बैठक की कार्यवाही आदि भी साक्ष्य के रूप में मानी जाती हैं। बैठक की कार्यवाही के महत्व के बारे में नीचे दिए गए लेख में विस्तार से विवेचना की गई है।

अतिरिक्त विकास और सुविधाओं की सुधार में पुरस्कार राशि कैसे निर्धारित होती है

पुरस्कार राशि की गणना, सिस्टम विकास के अतिरिक्त और सुधार संबंधी मुद्दों की जांच करते हुए की जाती है।

सिस्टम विकास के क्षेत्र में, एक बार निर्धारित होने के बाद भी विशेषताएं बदलने की स्थिति अनोखी नहीं होती। ऐसा होने पर हर बार नए दस्तावेजीकृत अनुबंध की तैयारी करना और अनुबंध कार्यवाही को आगे बढ़ाना वास्तविक रूप से संभव नहीं होगा। अतिरिक्त और सुधार के लिए विषयों को पुनः निर्धारित करने के लिए, यदि हम सभी चीजों को एकत्र करके स्मृति लिख सकते हैं, तो यह एक बात है, लेकिन ऐसी स्थिति में जब परियोजना अचानक रुक जाती है और ऐसी प्रक्रियाएं भी नहीं हो पाती हैं, तो पुरस्कार राशि की गणना कैसे की जाएगी?

ऐसी स्थिति में संदर्भ के रूप में उद्धृत करने के लिए उपयुक्त धारा, निम्नलिखित वाणिज्य कानून 512 (जापानी वाणिज्य कानून) है (नीचे रेखांकित हिस्सा लेखक द्वारा उद्धृत किया गया है)।

वाणिज्य कानून 512: जब व्यापारी अपने व्यापार के दायरे में किसी अन्य व्यक्ति के लिए कार्य करता है, तो वह उचित पुरस्कार का दावा कर सकता है।

इस धारा में ‘उचित पुरस्कार’ का मतलब है, विशेष परिस्थितियों में, अंततः कितना होगा, यह समस्या बन जाती है। पिछले न्यायाधीशों के फैसलों को देखते हुए, कार्य की मात्रा, या समय के अनुपात में, उसकी लागत को उठाना चाहिए, ऐसा मान्यता प्राप्त होती है। यह सिस्टम विकास कार्य की प्रकृति के कारण होता है, जो एक प्रकार की सेवा उद्योग होती है, और मूल लागत मूल रूप से मजदूरी होती है।

इस प्रकार, वाणिज्य कानून के ‘उचित पुरस्कार’ शब्द की अमूर्तता के बावजूद, इस प्रकार के संदर्भ में अतिरिक्त पुरस्कार की राशि का अनुमान लगाना, इतना कठिन गणना करने की आवश्यकता नहीं होती है। निम्नलिखित में, हम कुछ न्यायाधीशों के फैसलों को देखने का निर्णय करते हैं।

केस 1: जिसमें कार्यकाल की वृद्धि के अनुपात में अतिरिक्त मुआवजा मान्य किया गया था

इस मामले में विकास कार्यकाल का विस्तार, उपरोक्त कार्यकाल की कुल योग्यता 257.5 मनुष्य/दिन होनी चाहिए, और इसे प्रति व्यक्ति/प्रति दिन की विकास लागत के रूप में इस मामले के विकास ठेका समझौते के समान 32,500 येन (जो कि अनुसूची 3 में, दर 650,000 येन [प्रति व्यक्ति/प्रति माह] है, और अगर हम माह के कार्य दिनों को 20 मानें, तो प्रति व्यक्ति/प्रति दिन की विकास लागत 32,500 येन होती है।) के रूप में परिवर्तित करते हैं, तो इस मामले की विशेषता परिवर्तन आवश्यकता के आधार पर अतिरिक्त विकास लागत 8,368,750 येन होनी चाहिए।

ओसाका जिला न्यायालय, हेइसेई 14 (2002) का 29 अगस्त का फैसला

“प्रति व्यक्ति/प्रति दिन” यही कीवर्ड है। यह दिखा रहा है कि अतिरिक्त मुआवजे की गणना के आधार के रूप में, कार्यकाल का उपयोग किया गया है।

केस २: प्रोग्राम की संख्या के अनुपात में अतिरिक्त मुआवजा मान्य करने की स्थिति

इस मामले में, अतिरिक्त भाग सहित उचित मुआवजा की राशि का विचार करते समय, कंप्यूटर सिस्टम के विकास की मूल लागत तकनीशियनों की मजदूरी होती है, और यह मजदूरी सामान्यतया बनाए जाने वाले प्रोग्राम की मात्रा के अनुपात में होती है, इसलिए, मूल अनुबंध राशि २३२५ मिलियन येन को द्वितीय समीक्षा के समय तक पूरा किए गए २०६ प्रोग्रामों की संख्या से विभाजित करें, और इस प्रोग्राम प्रति एक इकाई की कीमत पर तीसरी समीक्षा के बाद के ४१४ प्रोग्रामों की संख्या को गुणा की गई राशि ४६७२ मिलियन ५७२८ येन (२३,२५०,००० ÷ २०६ × ४१४ = ४६,७२५,७२८) को उचित माना जाता है।

टोक्यो जिला न्यायालय, हेइसेई १७ (2005) वर्ष २२ अप्रैल का निर्णय

बहुत सारे नंबर आ रहे हैं, लेकिन अगर आप शांति से पढ़ें, तो आपको समझ में आएगा कि यहां कोई कठिन गणित नहीं किया जा रहा है। मूल अनुबंध की शर्तों के आधार पर, “प्रति एक प्रोग्राम की कीमत कितनी मानी जाती है” की पुष्टि करने के बाद, यहां केवल “इकाई कीमत × मात्रा” जैसी साधारण गुणा की गणना की जा रही है।

केस 3: समयावधि की लंबाई के अनुपात में अतिरिक्त मुआवजा मान्य करने वाले मामले

और, जो कि आपके द्वारा किए गए कार्य के लिए, जो कि 2005 (हेइसेई 17) जनवरी से मार्च तक के 3 महीने के दौरान आपके द्वारा किए गए कार्य के लिए, 60 मिलियन येन का निर्धारण किया गया है, जबकि उसी वर्ष के अप्रैल के बाद के कार्य के लिए कोई मुआवजा नहीं दिया गया है, वहीं, पिछले वर्ष की तरह, उसी वर्ष के मार्च तक की अवधि के मुकाबले में, नए सत्र की शुरुआत के कारण रजिस्ट्रेशन सिस्टम आदि का कार्यभार बढ़ गया है, जो कि उसी वर्ष के अप्रैल के बाद सक्रिय हुआ था। इन सब बातों को देखते हुए, उपरोक्त 3 महीने के कार्य के लिए निर्धारित किए गए 60 मिलियन येन के आधार पर, 2005 (हेइसेई 17) अप्रैल से सितंबर तक के 6 महीने के कार्य के लिए मुआवजा, 120 मिलियन येन होना उचित होगा।

टोक्यो जिला न्यायालय, 2010 (हेइसेई 22) जनवरी 22 का फैसला

उपरोक्त फैसला में, बढ़ाई गई अवधि के लिए भी, सादे अनुपातीय गणना के द्वारा अतिरिक्त मुआवजा की गणना करने का संकेत दिया गया है।

सारांश

जैसा कि ऊपर दिए गए कुछ न्यायाधीन मामलों की तुलना करने पर दिखाई देता है, प्रोग्रामर और इंजीनियरों के अतिरिक्त कार्य के लिए अतिरिक्त मुआवजे के कानूनी व्यवहार के बारे में, कुछ प्रकार की कानूनी सिद्धांत और सामान्यता दिखाई देती है। यानी मूल सिद्धांत के अनुसार, जितना समय लगाया, (जैसे कि डिलीवर किए गए प्रोग्राम का) आकार, कितना समय और कितनी अवधि काम किया, इस तरह के अधिकतर विषयवस्तु पर आधारित, सरलता से हिसाब किया जाना चाहिए।

सख्ती से लिए गए कदमों या पूर्ण रूप से अनुमानित कार्य की विफलता के कारण ही, ऐसे अतिरिक्त विकास और सुधार कार्य की आवश्यकता पड़ती है, इसलिए जितना अधिक काम किया गया है, या जितना समय लगाया गया है, उतना ही अतिरिक्त मुआवजा मिलना चाहिए, यह बात शायद थोड़ी बेरसी लग सकती है। हालांकि, यदि हम सेवा प्रदान करने वाले की दृष्टि से देखें, तो ग्राहक के लाभ को प्राथमिकता देते हुए भी कार्य का निष्पादन करने का लक्ष्य रखते हुए, ऐसे अधिकारों को कानूनी रूप से मान्यता मिलने की संभावना होना, एक प्रकार से संकट प्रबंधन के दृष्टिकोण से भी महत्वपूर्ण हो सकता है।

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

ऊपर लौटें