पूर्व IT इंजीनियर वकील द्वारा समझाया गया अनुबंध पत्र की जांच और डिबगिंग की समानता
जिसे हम ‘कंपनी के सलाहकार वकील’ कहते हैं, उनका मुख्य कार्य कंपनी द्वारा रोजाना क्लाइंट्स और व्यापारिक सहयोगी के साथ किए जाने वाले अनुबंधों की जांच और संशोधन होता है। और ऐसी जांच और संशोधन करने के लिए, आपको ‘कानून और उसके व्यापारिक क्षेत्र दोनों पर विशेषज्ञ’ होना चाहिए, अन्यथा यह कार्य पूरी तरह से नहीं किया जा सकता। हम इसके कारण की व्याख्या करेंगे।
हालांकि, निम्नलिखित व्याख्या को समझने के लिए आपको इंजीनियर या प्रोग्रामिंग का अनुभव होना चाहिए। मोनोलिथ कानूनी कार्यालय एक ऐसी कानूनी कार्यालय है जिसका प्रमुख पूर्व IT इंजीनियर और कंपनी के प्रबंधन का अनुभव रखने वाले वकील हैं। यह ‘पूर्व IT इंजीनियर और कंपनी के प्रबंधक द्वारा संचालित कानूनी कार्यालय के रूप में, इंजीनियर और प्रोग्रामिंग का अनुभव रखने वाले प्रबंधकों के लिए, अनुबंध की जांच और संशोधन के बारे में व्याख्या करने वाले लेख’ की स्थिति है।
और इस स्थिति के आधार पर, अनुबंध की जांच और संशोधन को ‘डीबग’ के कार्य के समान माना जाता है।
- पहले तो ‘बग’ क्या होता है
- ‘डीबग’ कौन सा कार्य होता है
- अनुबंध एल्गोरिदम को कैसे निर्धारित करता है
- अनुबंध का संशोधन कौन सा कार्य होता है
इस क्रम में, इंजीनियरों के लिए यह ‘स्वाभाविक’ बात हो सकती है, लेकिन निम्नलिखित में, हम इसकी व्याख्या करेंगे।
“बग” और “डिबग” क्या होते हैं?
बग का मतलब ‘पीसी की खराबी’ नहीं होता
‘बग’ के बारे में बात करते समय, कुछ लोगों को यह छवि हो सकती है कि वे पीसी पर काम कर रहे थे, फिर मशीन से धुआं निकलने लगा और स्क्रीन पर अजीब डिस्प्ले आने लगा। हालांकि, मूल रूप से, पीसी ‘बताए गए अनुसार’ काम करता है। यह बात बग के उत्पन्न होने के मामले में भी सच है। अर्थात ‘बग’ वह होता है जब,
- पीसी बताए गए अनुसार काम कर रहा होता है, फिर भी
- उपयोगकर्ता के लिए उसका व्यवहार ‘अनपेक्षित’ होता है
यही घटना होती है।
“अनपेक्षित व्यवहार” क्यों होता है
उदाहरण के लिए, मारियो टाइप के एक्शन गेम में “दीवार के बाहर” बग के बारे में सोचें।
मारियो की छलांग एक द्विघात समीकरण है। त्वरण, वेग, निर्देशांक। हालांकि, यदि यह एक द्विघात समीकरण होता है, तो “X=1.76582 के मामले में Y क्या है?” जैसा, आप X को अनंत रूप से बारीक तौर पर विभाजित कर सकते हैं, लेकिन टेलीविजन गेम के मामले में, आप समय को अनंत रूप से बारीक तौर पर विभाजित नहीं कर सकते हैं। क्योंकि स्क्रीन केवल प्रति सेकंड 30 बार ही बदलती है। इसलिए, मारियो प्रति सेकंड 30 बार “वार्प” कर रहा होता है।
इस पर, उदाहरण के लिए, “अगर मारियो ने कूदा और ऊपरी हवा में दीवार थी तो वह उछल कर वापस आ गया” ऐसे मामले में,
- पिछले क्षण में मारियो हवा में था
- अगले क्षण में, मारियो के निर्देशांक दीवार के अंदर हो जाते हैं
ऐसा होता है।
ऐसे मामले में, “मारियो ने छलांग लगाई और ऊपरी हवा में दीवार से टकरा गया” ऐसा निर्णय किया जा सकता है। इसलिए, प्राकृतिक भाषा में कहें तो
यदि मारियो के निर्देशांक दीवार के अंदर होते हैं, तो उछालने की प्रक्रिया करें (※1)
ऐसा प्रोग्राम लिखने से, “अगर मारियो ने कूदा और ऊपरी हवा में दीवार थी तो वह उछल कर वापस आ गया” ऐसी प्रक्रिया को साकार करने में सक्षम हो सकते हैं।
※1 जैसा कि ऊपर लिखा गया है, सही लगता है। और वास्तव में, “कुछ निश्चित स्थितियों में” यह प्रक्रिया सही है।
हालांकि, अगर हम ध्यान से सोचें, तो निम्नलिखित प्रकार की स्थितियाँ भी संभव हैं (※2)।
इस मामले में, “मारियो के निर्देशांक दीवार के अंदर” ऐसा क्षण मौजूद नहीं होता है, और इसलिए उछालने की प्रक्रिया नहीं होती है, और मारियो दीवार को पार कर जाता है।
यही है “बग” का उदाहरण। ऐसे कारणों से “दीवार के बाहर बग” होता है, लेकिन इसका मतलब यह नहीं है कि पीसी खराब हो गया है। पीसी सिर्फ उसे बताए गए व्यवहार को कर रहा है, और उस व्यवहार को “अनपेक्षित है” “बग है” ऐसा मूल्यांकन करने वाला मनुष्य है। और वह “बग”, एल्गोरिदम उचित नहीं होने के कारण, होता है।
“अनुमानित बाहरी कार्यवाही का विचार करना”
हालांकि, वास्तव में खेल खेलने के प्रक्रिया में उपरोक्त “दीवार के बाहर निकलने” की स्थिति होती है या नहीं, यह केवल उपरोक्त तरीके से अमूर्त रूप से सोचने से अस्पष्ट है। “दीवार के बाहर निकलने” की स्थिति हो सकती है या नहीं, यह निम्नलिखित बातों पर निर्भर करता है-
- मारियो की कूदने की शक्ति (प्रारंभिक गति) कितनी है, क्या कूदने की शक्ति बढ़ाने वाला कोई आइटम है
- दीवार की मोटाई सबसे पतली होने पर कितनी होती है
इसलिए यह स्थितियों पर निर्भर करता है। इन स्थितियों के आधार पर, यदि ऐसी स्थिति हो सकती है जैसा कि *2 में बताया गया है, तब यही बात है। यदि *2 संभव नहीं है, तो *1 का प्रोग्राम विशेष रूप से समस्या नहीं है, ऐसा माना जाता है।
「デバッグ」 कार्य किस प्रकार का होता है
इस प्रकार, ‘डिबग’, अर्थात्, बग को खोजना और उसे सुधारना, इस कार्य को करने के लिए,
- प्रोग्राम का कौन सा एल्गोरिदम है, उसे पढ़ना (उपरोक्त ※1 प्राकृतिक भाषा है, लेकिन वास्तव में प्रोग्राम अपनी भाषा में लिखा जाता है, इसलिए पढ़ना अपने आप में कठिन है)
- उस प्रोग्राम का विचार करना कि वह किस प्रकार की स्थिति में काम करता है (जम्प क्षमता और दीवार की मोटाई के बारे में जांचना)
- उस समय किसी अनपेक्षित व्यवहार का होना नहीं है, इसका विचार करना
इस प्रकार की प्रक्रिया आवश्यक होती है।
अनुबंध पत्र की जांच क्या होती है
अनुबंध पत्र की जांच भी, इस कार्य से मिलती जुलती होती है। अनुबंध पत्र का मूल उद्देश्य होता है कि उसके पक्षकार, अर्थात आ और बी, भविष्य में होने वाली घटनाओं को ध्यान में रखते हुए, उनके बीच कौन से अधिकार और कर्तव्य उत्पन्न होंगे, और उसके परिणामस्वरूप, दोनों पक्ष कैसे कार्य करेंगे, ऐसे बिंदुओं को नियंत्रित करने के लिए होता है। इस संदर्भ में, यह ‘वास्तविक दुनिया को नियंत्रित करने वाला प्रोग्राम’ कहा जा सकता है। उदाहरण के लिए,
यदि ●● परिस्थिति उत्पन्न होती है, तो आ ने बी को 10 लाख येन का हर्जाना देना होगा।
ऐसे नियम का पालन करने वाले अनुबंध पत्र में, भविष्य में होने वाली घटनाओं के लिए शर्तें और प्रभावों को परिभाषित किया जाता है।
और फिर, उस ‘वास्तविक दुनिया को नियंत्रित करने वाले प्रोग्राम’ की जांच करने का कार्य, और यदि कोई समस्या होती है तो उसे सुधारने का कार्य, अनिवार्य रूप से ‘डिबग’ के समान होता है।
संविदा पत्र में एल्गोरिदम का पूरा चित्रण नहीं होता है
हालांकि, ‘संविदा’ के संदर्भ में, एक ऐसा बिंदु होता है जिसे कानून के विशेषज्ञ न होने वाले व्यक्ति को समझना कठिन होता है, लेकिन यह अत्यंत महत्वपूर्ण होता है। संविदा पत्र वह होता है जो केवल उस एल्गोरिदम का ‘एक हिस्सा’ निर्धारित करता है जो पक्षों के बीच अनुशासन करता है। दूसरे शब्दों में, केवल संविदा पत्र पढ़ने से, हमें यह जानने की क्षमता नहीं होती कि हम और हमारा साथी किस प्रकार के एल्गोरिदम के अधीन अनुशासित होंगे।
उदाहरण के लिए, यदि आप एक दुकान से पुरानी CD खरीदते हैं, तो दुकान और ग्राहक ‘खरीद-फरोख्त संविदा पत्र’ जैसा कुछ समझौता नहीं करते, लेकिन यदि खरीदी गई CD की डिस्क पर, प्लेयर में चलने में असमर्थ खरोंच होती है, तो आप दुकान से शिकायत करना चाहेंगे, और आपकी उम्मीद होगी कि दुकान उस पर कार्रवाई करेगी। यह ‘सेवा उद्योग होने के कारण’ के स्तर की बात नहीं है, बल्कि सिद्धांततः,
- संविदा पत्र के बिना भी, खरीद-फरोख्त संविदा समाप्त हो जाती है
- नागरिक कानून (Japanese Civil Code) पुरानी CD आदि (जिसे ‘विशेष वस्तु’ कहा जाता है) की खरीद-फरोख्त संविदा के बारे में, विक्रेता पर दोष गारंटी की जिम्मेदारी होती है, ऐसा निर्धारित करता है
- इसलिए, नागरिक कानून (Japanese Civil Code) द्वारा निर्धारित एल्गोरिदम दुकान और ग्राहक के बीच चलता है, और दुकान को दोष गारंटी की जिम्मेदारी होती है
और ‘संविदा पत्र’ वह होता है जो नागरिक कानून (Japanese Civil Code) आदि द्वारा परिभाषित एल्गोरिदम को ओवरराइट करता है। उदाहरण के लिए, यदि दुकान और ग्राहक के बीच ‘हमारी दुकान CD की किसी भी कमी के लिए बाद में दावा स्वीकार नहीं करेगी’ ऐसा संविदा पत्र आदान-प्रदान किया गया होता है, तो
- खरीद-फरोख्त संविदा समाप्त हो जाती है
- नागरिक कानून (Japanese Civil Code) उस संविदा के बारे में, विक्रेता पर दोष गारंटी की जिम्मेदारी होती है, ऐसा निर्धारित करता है
- लेकिन, संविदा पत्र के निर्धारण के अनुसार, दूसरे सिद्धांत को ओवरराइट किया जाता है, और दुकान पर दोष गारंटी की जिम्मेदारी नहीं होती है
ऐसा होता है।
संविदा पत्र वह होता है जो ‘ओवरराइट’ करता है सिविल कोड (जापानी सिविल कोड) आदि के सिद्धांतों को
यह सिस्टम विकास आदि के लिए भी लागू होता है, जो कंपनियों के बीच समझौते के रूप में होता है। उदाहरण के लिए, यदि किसी कंपनी के बीच एक सिस्टम विकास का संविदा पत्र बनाया गया है, तो
- संविदा पत्र को बनाने से स्पष्ट रूप से, एक संविदा बनाई गई है
- संविदा के मामले में, सिविल कोड (जापानी सिविल कोड) के अनुसार दोष गारंटी की जिम्मेदारी उत्तरदायी पक्ष पर आती है
- यदि संविदा पत्र में दोष गारंटी की जिम्मेदारी का प्रावधान होता है, तो वह प्रावधान सिविल कोड (जापानी सिविल कोड) के सिद्धांत को ओवरराइट करता है। उदाहरण के लिए, यदि सिविल कोड (जापानी सिविल कोड) के सिद्धांत से अधिक समय के लिए दोष गारंटी की जिम्मेदारी का प्रावधान बनाया जाता है, तो उस समय का प्रावधान मान्य होता है
इसका धांचा इस प्रकार होता है। अर्थात, उदाहरण के लिए, यदि संविदा पत्र में विशेष रूप से दोष गारंटी की जिम्मेदारी का कोई प्रावधान नहीं होता है, तो भी दोष गारंटी की जिम्मेदारी उत्पन्न होती है।
यह सिर्फ संविदा या सिस्टम विकास आदि के लिए सीमित नहीं है, बल्कि शेयर के हस्तांतरण, ऋण के माध्यम से धन संचय (ऋण लेन-देन), रोजगार, शेयर जारी करना आदि, कंपनियों द्वारा किए जाने वाले सभी संविदाओं के बारे में सामान्य विचार है।
इसलिए, केवल संविदा पत्र पढ़ने से, आप और आपकी कंपनी के बीच के संबंधों को नियंत्रित करने वाले ‘एल्गोरिदम’ का पूरा चित्र समझने में सक्षम नहीं होंगे। इस पूरे चित्र को समझने के लिए, आपको ‘सिविल कोड (जापानी सिविल कोड) आदि के कानून द्वारा निर्धारित डिफ़ॉल्ट एल्गोरिदम’ को समझना होगा। क्योंकि संविदा पत्र सिर्फ ‘डिफ़ॉल्ट एल्गोरिदम’ को ओवरराइट करने वाला होता है।
यदि हम भविष्य में होने वाली घटनाओं का अनुमान नहीं लगा सकते तो हम ‘डिबग’ नहीं कर सकते
इसके अलावा, केवल एल्गोरिद्म को समझने से, “क्या इस एल्गोरिद्म से अनुमानित बाहरी कार्यवाही नहीं होगी” इस बिंदु की जांच करना संभव नहीं है। खेल के ‘बग’ के मामले की तरह, एल्गोरिद्म अंततः एक अमूर्त चीज होती है, और यदि हम भविष्य में कौन सी घटना हो सकती है, इसका अनुमान नहीं लगा सकते, तो हम “क्या ऐसी घटना होने पर अनुमानित बाहरी व्यवहार नहीं होगा” इसकी जांच नहीं कर सकते।
यह, विशेष रूप से, नए ऐप्स या सेवाओं जैसे उत्पादों, नए व्यापार योजनाओं, आदि के मामले में एक गंभीर समस्या होती है। ऐसे उत्पादों या योजनाओं के साथ व्यापार का विस्तार करने के मामले में, भविष्य में क्या हो सकता है। यह, यदि उनके पास उस क्षेत्र के बारे में ज्ञान नहीं होता, तो उन्हें अनुमान लगाना कठिन होता है। इसके अलावा, विशेष रूप से कंपनियों के बीच समझौतों के मामले में, दूसरी पक्ष की कंपनी भी और आपकी कंपनी भी, एक निश्चित आर्थिक तर्क के तहत कार्य करती है, इसलिए भविष्य की घटनाओं, और उन्हें लाने वाले दूसरे पक्ष की कार्यवाही की भविष्यवाणी के लिए, कंपनी के प्रबंधन के बारे में खेल सिद्धांत की सोच भी आवश्यक होती है।
「अप्रत्याशित」 होने का निर्णय व्यवस्थापन निर्णय पर भी आधारित होता है
इसके अलावा, एक घटना को “बग” के रूप में निर्धारित करने वाला कंप्यूटर नहीं बल्कि मनुष्य होता है, ठीक उसी प्रकार, एक समझौते के परिणामस्वरूप एक नतीजे को “अप्रत्याशित” होने का निर्णय लेना भी, शुद्ध कानूनी मामले की समस्या नहीं होती, बल्कि यह व्यवस्थापन निर्णय समस्या होती है।
उदाहरण के लिए, “सिविल कोड के सिद्धांत के अनुसार” एल्गोरिदम, किसी कंपनी के किसी व्यापार में स्वीकार्य नहीं हो सकता है, ऐसा मामला वास्तविकता में हो सकता है। यहां तक की उदाहरण बदल जाता है, लेकिन उदाहरण के लिए, सिविल कोड ने अनुबंध के बारे में, “ट्रस्टी द्वारा पुनः अनुबंध अनुबंध उल्लंघन होगा” ऐसा डिफ़ॉल्ट एल्गोरिदम निर्धारित किया है। लेकिन उदाहरण के लिए, “किसी कंपनी के लिए, किसी व्यापार के लिए, स्वाभाविक रूप से उप-ठेकेदार कंपनी का उपयोग करने की उम्मीद की जाती है” ऐसा मामला हो सकता है। ऐसे मामलों में, पुनः अनुबंध करने का असंभव समझौता, अर्थात
- पुनः अनुबंध की संभावना के बारे में कुछ भी स्पष्ट रूप से नहीं लिखा गया है (इस मामले में, ऊपर के अनुसार, सिविल कोड के सिद्धांत लागू होते हैं)
- पुनः अनुबंध करने की संभावना नहीं होने का स्पष्ट रूप से उल्लेख किया गया है
ऐसा समझौता स्वीकार करना, यद्यपि यह “सिविल कोड के सिद्धांत के अनुसार” हो, संभव नहीं होना चाहिए।
इसके अलावा, प्रबंधन में हमेशा “कुछ कारणों के कारण जिम्मेदारी उठानी पड़ेगी” ऐसा जोखिम होता है। अपनी कंपनी के लिए “जोखिम” के बारे में कोई संदेह नहीं होना चाहिए, ऐसा समझौता, मूल रूप से मौजूद नहीं होता है। उस जोखिम को स्वीकार करने का निर्णय, अंततः व्यवस्थापन निर्णय होता है। व्यवस्थापन निर्णय करने वाले व्यवस्थापक होते हैं, न कि सलाहकार वकील या अन्य कंसल्टेंट की स्थिति वाले लोग, लेकिन कंसल्टेंट को, व्यवस्थापक को व्यवस्थापन निर्णय करने के लिए आवश्यक और पर्याप्त जानकारी प्रस्तुत करनी चाहिए,
- जोखिम का उल्लेख करने की आवश्यकता नहीं होती
- स्वीकार करने का निर्णय लेना, जो कि उस कंपनी के लिए महत्वपूर्ण निर्णय हो सकता है, जिसमें मीटिंग आदि की आवश्यकता हो सकती है
ऐसे मामलों को, उनकी गहराई के साथ उल्लेख करना चाहिए। इस “गहराई” की सेटिंग के लिए, अन्य क्षेत्रों के कंसल्टेंट के मामले की तरह, समझौता चेक करने वाले वकील को भी “प्रबंधन” की भावना की एक निश्चित मात्रा की आवश्यकता होती है।
सारांश
इस प्रकार, अनुबंध पत्र की जांच और संशोधन, बड़े पैमाने पर, निम्नलिखित प्रकार का कार्य होता है।
- अनुबंध पत्र के द्वारा, नागरिक संहिता (Japanese Civil Code) आदि के सिद्धांतों को कैसे अधिलिखित किया जाता है, और परिणामस्वरूप यह कैसे एक एल्गोरिदम बन जाता है, इसे समझना
- उस एल्गोरिदम के तहत, भविष्य में कौन सी घटनाएं हो सकती हैं, इस पर विचार करना
- उस समय क्या अप्रत्याशित व्यवहार नहीं हो रहा है, इस पर विचार करना
और उपरोक्त हर एक
- कानून को समझने वाले व्यक्ति के बिना कठिन कार्य
- जिसे यह अनुबंध नियंत्रित करता है, उदाहरण के लिए ऐप्स या वेब सेवाओं जैसे व्यापार की सामग्री, व्यापार योजनाएं आदि को समझने वाले व्यक्ति के बिना कठिन कार्य
- संबंधित कंपनी या व्यापार की सामग्री, व्यवसायिक संवेदनशीलता को कुछ हद तक समझने वाले व्यक्ति के बिना कठिन कार्य
होता है।
अनुबंध पत्र की जांच और संशोधन, इन कारणों के कारण, बहुत ही ‘विशेषज्ञ’ होता है।
हमारे दफ्तर द्वारा अनुबंध पत्र निर्माण और समीक्षा आदि की जानकारी
मोनोलिथ कानूनी कार्यालय (Monolith Legal Office) एक कानूनी कार्यालय के रूप में, जिसमें IT, इंटरनेट और व्यापार में मजबूती है, हम विभिन्न अनुबंध पत्रों के निर्माण और समीक्षा जैसे कार्यों को हमारे सलाहकार कंपनियों और ग्राहक कंपनियों के लिए प्रदान करते हैं।
जो लोग इसके बारे में चिंतित हैं, कृपया नीचे दिए गए विवरण को देखें।
Category: IT
Tag: ITSystem Development
