ทนายความที่เคยเป็นวิศวกร IT อธิบายความคล้ายคลึงระหว่างการตรวจสอบสัญญาและการดีบั๊ก

งานหลักของที่ปรึกษาทางกฎหมายของบริษัท หรือที่เรียกว่า “ทนายความที่ปรึกษาของบริษัท” คือการตรวจสอบและแก้ไขสัญญาที่บริษัททำกับลูกค้าหรือคู่ค้าทางธุรกิจในทุกวัน และการตรวจสอบและแก้ไขเหล่านี้จำเป็นต้องทำโดย “ผู้ที่มีความรู้ทั้งในด้านกฎหมายและด้านธุรกิจ” มิฉะนั้นจะไม่สามารถทำได้อย่างเต็มที่ จะอธิบายเหตุผลว่าทำไมต้องเป็นอย่างนั้น

อย่างไรก็ตาม คำอธิบายต่อไปนี้อาจจะยากต่อการเข้าใจสำหรับคนที่ไม่ใช่วิศวกรหรือไม่มีประสบการณ์ในการเขียนโปรแกรม สำนักงานทนายความ Monolith นั้นมีทนายความที่เคยเป็นวิศวกร IT และมีประสบการณ์ในการบริหารธุรกิจเป็นผู้แทน ดังนั้น บทความนี้จัดทำขึ้นเพื่อ “อธิบายเกี่ยวกับการตรวจสอบและแก้ไขสัญญาสำหรับผู้บริหารที่มีประสบการณ์ในการเขียนโปรแกรม โดยสำนักงานทนายความที่มีทนายความที่เคยเป็นวิศวกร IT และผู้บริหารธุรกิจเป็นผู้แทน”

และในบริบทนี้ การตรวจสอบและแก้ไขสัญญานั้นคล้ายกับการทำ “ดีบั๊ก”

1. อะไรคือ “บั๊ก”
2. การ “ดีบั๊ก” คือการทำงานอย่างไร
3. สัญญากำหนดอัลกอริทึมอย่างไร
4. การแก้ไขสัญญาคือการทำงานอย่างไร

จะเริ่มจากเรื่องที่สำหรับวิศวกรนั้น “เป็นเรื่องปกติ” แต่จะอธิบายต่อไป

คืออะไร “บั๊ก” และ “ดีบั๊ก”

บั๊กไม่ใช่ ‘การชำรุดของคอมพิวเตอร์’

เมื่อพูดถึง ‘บั๊ก’ บางคนอาจจะนึกถึงภาพของคอมพิวเตอร์ที่ทำงานอยู่แล้วเกิดควันออกมาและหน้าจอแสดงผลอย่างแปลกประหลาด… แต่จริงๆ แล้วคอมพิวเตอร์จะทำงานตามที่ ‘ถูกสั่งให้ทำ’ อย่างเดียว ซึ่งสิ่งนี้เป็นเช่นเดียวกับกรณีที่เกิดบั๊ก นั่นคือ ‘บั๊ก’ คือ

• คอมพิวเตอร์ทำงานตามที่ถูกสั่งให้ทำ แต่
• สำหรับผู้ใช้งาน การทำงานนั้นเป็น ‘พฤติกรรมที่ไม่คาดคิด’

นั่นคือปรากฏการณ์ที่เรียกว่า ‘บั๊ก’.

เหตุผลที่เกิด “พฤติกรรมที่ไม่ได้คาดคิด”

เช่น ลองคิดเกี่ยวกับ “บั๊กผ่านผนัง” ในเกมแอคชั่นแบบ Mario ดูสักหน่อย

การกระโดดของ Mario เป็นฟังก์ชันกำลังสอง คือ ความเร่ง ความเร็ว และพิกัด แต่ถ้าเป็นฟังก์ชันกำลังสองทั่วไป เราสามารถแบ่ง X ออกเป็นส่วนย่อยๆได้เรื่อยๆ เช่น “Y ที่ X=1.76582 คืออะไร?” แต่ในกรณีของวิดีโอเกม เราไม่สามารถแบ่งเวลาออกเป็นส่วนย่อยๆได้เรื่อยๆ เพราะหน้าจอสลับไปมาได้เพียง 30 ครั้งต่อวินาที (เช่น) ดังนั้น Mario จึง “โทรพรต” ไปมา 30 ครั้งต่อวินาที

ในกรณีที่ “เมื่อ Mario กระโดดแล้วมีกำแพงอยู่ด้านบนทำให้เขาถูกสะท้อนกลับ” คือกรณีที่

1. Mario อยู่ในอากาศในช่วงเวลาก่อนหน้า
2. ในช่วงเวลาถัดไป พิกัดของ Mario อยู่ในกำแพง

นั่นคือกรณีที่เกิดขึ้น

ในกรณีเช่นนี้ เราสามารถตัดสินว่า “Mario ชนกับกำแพงที่อยู่ด้านบนขณะกระโดด” ดังนั้น ถ้าเราเขียนโปรแกรมว่า

ถ้าพิกัดของ Mario อยู่ในกำแพง ให้ดำเนินการสะท้อนกลับ (※1)

เราสามารถทำให้ “เมื่อ Mario กระโดดแล้วมีกำแพงอยู่ด้านบนทำให้เขาถูกสะท้อนกลับ” สามารถเกิดขึ้นได้

※1 ดูเหมือนจะถูกต้องถ้าเราเขียนตามที่กล่าวไว้ และในความเป็นจริง “ถ้าเงื่อนไขบางอย่างเป็นจริง” การดำเนินการนี้จะถูกต้อง

แต่ถ้าเราคิดดีๆ เราจะพบว่ามีกรณีที่เป็นไปได้ดังนี้ (※2)

ในกรณีนี้ “ช่วงเวลาที่พิกัดของ Mario อยู่ในกำแพง” ไม่มีอยู่จริง ดังนั้นการดำเนินการสะท้อนกลับจะไม่เกิดขึ้น และ Mario จะผ่านผนังไปได้

นี่คือ “บั๊ก” ในกรณีนี้ แม้ว่า “บั๊กผ่านผนัง” จะเกิดขึ้น แต่คอมพิวเตอร์ไม่ได้เสียหาย คอมพิวเตอร์เพียงแค่ทำตามที่ถูกสั่งให้ทำ และการประเมินว่าพฤติกรรมนั้น “ไม่ได้คาดคิด” หรือ “เป็นบั๊ก” คือการประเมินของมนุษย์ และ “บั๊ก” นั้นเกิดขึ้นเพราะอัลกอริทึมไม่เหมาะสม

การพิจารณาว่า “การทำงานที่ไม่ได้คาดคิด” จะเกิดขึ้นหรือไม่

อย่างไรก็ตาม, ในกระบวนการเล่นเกมจริง ๆ ไม่ชัดเจนว่า “การผ่านผ่านผนัง” ที่กล่าวถึงข้างต้นจะเกิดขึ้นหรือไม่ จากการคิดแบบนี้ที่ค่อนข้างนามธรรม “การผ่านผ่านผนัง” จะเกิดขึ้นหรือไม่ ขึ้นอยู่กับ

• พลังกระโดดของมาริโอ (ความเร็วเริ่มต้น) มีไอเท็มที่เพิ่มพลังกระโดดหรือไม่
• ผนังมีความหนาเท่าไหร่ในกรณีที่บางที่สุด

ขึ้นอยู่กับเงื่อนไขเหล่านี้ ขึ้นอยู่กับว่าสถานการณ์ที่ 2 จะเกิดขึ้นหรือไม่ ถ้าสถานการณ์ที่ 2 ไม่เป็นไปได้ โปรแกรมที่ 1 จะไม่มีปัญหา

งาน “ดีบัก” คืออะไร

ดังนั้น, “ดีบัก” หรือการค้นหาและแก้ไขบั๊กในโปรแกรมจำเป็นต้องมีกระบวนการดังนี้

1. อ่านและเข้าใจอัลกอริทึมของโปรแกรม (โดยทั่วไปโปรแกรมจะเขียนด้วยภาษาเฉพาะทาง ทำให้การอ่านและเข้าใจนั้นยาก)
2. ศึกษาว่าโปรแกรมนั้นทำงานภายใต้เงื่อนไขอะไร (เช่น การศึกษาเรื่องพลังกระโดดหรือความหนาของกำแพง)
3. ตรวจสอบว่ามีการทำงานที่ไม่ได้คาดคิดไว้หรือไม่

นี่คือกระบวนการที่จำเป็นสำหรับการดีบัก

การตรวจสอบสัญญาคืองานประเภทใด

การตรวจสอบสัญญามีลักษณะคล้ายกับการดีบักนี้ สัญญาเองคือสิ่งที่กำหนดสิทธิ์และหน้าที่ที่จะเกิดขึ้นในอนาคตสำหรับผู้ที่เกี่ยวข้อง และในกรณีที่เหตุการณ์ที่คาดการณ์ไว้เกิดขึ้น ผลที่จะตามมาคือการกระทำของทั้งสองฝ่าย ดังนั้น สัญญาสามารถถูกอธิบายได้ว่าเป็น “โปรแกรมที่ควบคุมโลกความจริง” ตัวอย่างเช่น

หากเกิดสถานการณ์ ●● ผู้ที่เกี่ยวข้องจะต้องชดใช้เงิน 1 ล้านเยนให้กับฝ่ายที่เกี่ยวข้อง

สัญญาที่กำหนดเงื่อนไขและผลที่ตามมาสำหรับเหตุการณ์ที่จะเกิดขึ้นในอนาคตนั้น คือการกำหนดเงื่อนไขและผลลัพธ์

และการตรวจสอบว่า “โปรแกรมที่ควบคุมโลกความจริง” นี้ไม่มีปัญหา และหากพบปัญหา การแก้ไขปัญหานั้นจะคล้ายกับการ ‘ดีบัก’

ไม่ได้ระบุรายละเอียดทั้งหมดของอัลกอริทึมในสัญญา

อย่างไรก็ตาม, สิ่งที่เรียกว่า “สัญญา” มีจุดสำคัญหนึ่งที่อาจจะยากต่อการเข้าใจสำหรับคนที่ไม่ได้เชี่ยวชาญในกฎหมาย แต่มันก็ยังคงมีความสำคัญอยู่ นั่นคือ สัญญาเป็นเพียง “ส่วนหนึ่ง” ของอัลกอริทึมที่ควบคุมความสัมพันธ์ระหว่างผู้ทำสัญญา หรือกล่าวอีกอย่างหนึ่ง การอ่านสัญญาเพียงอย่างเดียวจะไม่ทำให้คุณรู้ว่าคุณและคู่สัญญาของคุณจะถูกควบคุมภายใต้อัลกอริทึมแบบใด และคุณจะไม่สามารถทราบรายละเอียดทั้งหมดได้

ตัวอย่างเช่น ในกรณีที่คุณซื้อซีดีมือสองจากร้านค้า ร้านค้าและลูกค้าไม่ได้ทำ “สัญญาซื้อขาย” แต่ถ้าซีดีที่คุณซื้อมีรอยขีดข่วนที่ทำให้ไม่สามารถเล่นได้บนเครื่องเล่น คุณอาจจะต้องการที่จะร้องเรียนกับร้านค้า และคุณคาดหวังว่าร้านค้าจะตอบสนองต่อความไม่พอใจของคุณ นี่ไม่ใช่เรื่องที่เกี่ยวข้องกับ “การให้บริการ” แต่จากมุมมองทฤษฎี คุณสามารถอธิบายได้ว่า

1. แม้ว่าจะไม่มีสัญญาซื้อขาย แต่สัญญาซื้อขายก็ยังถูกทำขึ้น
2. กฎหมายญี่ปุ่น (Japanese Civil Code) กำหนดว่า สำหรับสัญญาซื้อขายของสินค้าที่ระบุเป็นเฉพาะ (เรียกว่า “สินค้าเฉพาะ”) เช่น ซีดีมือสอง ผู้ขายมีความรับผิดชอบในการรับประกันความบกพร่อง
3. ดังนั้น อัลกอริทึมที่กฎหมายญี่ปุ่นกำหนดขึ้นกำลังทำงานระหว่างร้านค้าและลูกค้า และร้านค้ามีความรับผิดชอบในการรับประกันความบกพร่อง

นั่นคือเหตุผลของมัน และ “สัญญา” คือสิ่งที่เขียนทับอัลกอริทึมที่กฎหมายญี่ปุ่นและกฎหมายอื่น ๆ กำหนดขึ้น ตัวอย่างเช่น ถ้ามีสัญญาหรือเอกสารที่ระบุว่า “ร้านค้าของเราจะไม่รับความร้องเรียนใด ๆ หลังจากการขายเกี่ยวกับความบกพร่องของซีดี” ระหว่างร้านค้าและลูกค้า

1. สัญญาซื้อขายถูกทำขึ้น
2. กฎหมายญี่ปุ่นกำหนดว่า สำหรับสัญญานี้ ผู้ขายมีความรับผิดชอบในการรับประกันความบกพร่อง
3. แต่ด้วยการกำหนดของสัญญา หลักการที่ 2 ถูกเขียนทับ และร้านค้าไม่มีความรับผิดชอบในการรับประกันความบกพร่อง

นั่นคือสิ่งที่เกิดขึ้น

สัญญาเป็นสิ่งที่ ‘เขียนทับ’ หลักการตามกฎหมายระหว่างบุคคลทั่วไป เช่น กฎหมายแพ่ง

นี่เป็นเรื่องที่เหมือนกันในกรณีของสัญญาที่ทำระหว่างองค์กร เช่น การพัฒนาระบบ ตัวอย่างเช่น ในกรณีที่มีการทำสัญญาการพัฒนาระบบแบบรับเหมาระหว่างสองฝ่าย

1. การทำสัญญาชัดเจนทำให้สัญญาการรับเหมาถูกทำขึ้น
2. ในกรณีของสัญญาการรับเหมา ตามกฎหมายแพ่ง จะมีความรับผิดชอบในการรับประกันความบกพร่องของผู้รับเหมา
3. ถ้ามีการกำหนดความรับผิดชอบในการรับประกันความบกพร่องในสัญญา กำหนดนั้นจะเขียนทับหลักการตามกฎหมายแพ่งที่ 2 ตัวอย่างเช่น ถ้ามีการกำหนดข้อตกลงการรับประกันความบกพร่องในระยะเวลาที่ยาวกว่าหลักการตามกฎหมายแพ่ง ข้อตกลงในระยะเวลานั้นจะมีผล

นี่คือโครงสร้างที่เกิดขึ้น นั่นคือ แม้ว่าในสัญญาจะไม่มีการกำหนดเฉพาะเกี่ยวกับความรับผิดชอบในการรับประกันความบกพร่อง ความรับผิดชอบในการรับประกันความบกพร่องก็จะเกิดขึ้น

นี่ไม่ได้จำกัดเฉพาะในการรับเหมาหรือการพัฒนาระบบเท่านั้น แต่เป็นความคิดทั่วไปเกี่ยวกับสัญญาทั้งหมดที่องค์กรดำเนินการ เช่น การโอนยอดหุ้น การระดมทุนด้วยหนี้ (การกู้ยืมเงินสด) การจ้างงาน การออกหุ้น และอื่น ๆ

ดังนั้น การอ่านสัญญาเพียงอย่างเดียวจะไม่ทำให้คุณเข้าใจ ‘อัลกอริทึม’ ที่ควบคุมความสัมพันธ์ระหว่างคุณและองค์กรของคุณทั้งหมด ในการเข้าใจภาพรวมทั้งหมด คุณต้องเข้าใจ ‘อัลกอริทึมเริ่มต้น’ ที่กฎหมายเช่น กฎหมายแพ่งกำหนดไว้ สัญญาเป็นเพียงสิ่งที่เขียนทับ ‘อัลกอริทึมเริ่มต้น’ นั้นเท่านั้น

หากไม่สามารถคาดการณ์เหตุการณ์ที่อาจเกิดขึ้นในอนาคต จะไม่สามารถ “ดีบัก” ได้

นอกจากนี้ การเข้าใจอัลกอริทึมเพียงอย่างเดียว ไม่สามารถตรวจสอบว่า “การทำงานที่ไม่ได้คาดคิดจะไม่เกิดขึ้นจากอัลกอริทึมนี้หรือไม่” นั่นเป็นเพราะอัลกอริทึมเป็นสิ่งที่เป็นนามธรรม และหากไม่สามารถคาดการณ์ว่าเหตุการณ์ใดจะเกิดขึ้นในอนาคต จะไม่สามารถตรวจสอบว่า “หากเหตุการณ์ดังกล่าวเกิดขึ้น จะไม่เป็นการทำงานที่ไม่ได้คาดคิดหรือไม่”

นี่เป็นปัญหาที่สำคัญโดยเฉพาะอย่างยิ่งในกรณีของผลิตภัณฑ์ใหม่ ๆ เช่นแอปหรือบริการ หรือโครงการธุรกิจใหม่ ๆ ในกรณีที่คุณขยายธุรกิจด้วยผลิตภัณฑ์หรือโครงการดังกล่าว สิ่งที่อาจเกิดขึ้นในอนาคตคืออะไร นี่เป็นสิ่งที่ยากที่จะคาดการณ์หากไม่มีความรู้เกี่ยวกับด้านนั้น นอกจากนี้ โดยเฉพาะอย่างยิ่งในกรณีของสัญญาระหว่างองค์กร ทั้งองค์กรที่เป็นฝ่ายตรงข้ามและองค์กรของคุณเอง จะดำเนินการภายใต้ความเหมาะสมทางเศรษฐกิจที่แน่นอน ดังนั้น การคาดการณ์เหตุการณ์ในอนาคตและการกระทำของฝ่ายตรงข้ามที่ทำให้เกิดเหตุการณ์นั้น จำเป็นต้องมีการคิดทางทฤษฎีเกมที่เกี่ยวข้องกับการบริหารธุรกิจ

การตัดสินใจว่าเป็น “เหตุการณ์ที่ไม่คาดคิด” ขึ้นอยู่กับการตัดสินใจในการบริหาร

นอกจากนี้ การตัดสินใจว่าเหตุการณ์ใดเป็น “บั๊ก” ไม่ได้ขึ้นอยู่กับคอมพิวเตอร์ แต่ขึ้นอยู่กับคน ในทำนองเดียวกัน การตัดสินใจว่าผลที่เกิดจากสัญญาเป็น “เหตุการณ์ที่ไม่คาดคิด” หรือไม่ ไม่ได้เป็นปัญหาที่เกี่ยวข้องกับเรื่องกฎหมายเพียงอย่างเดียว แต่เป็นปัญหาที่เกี่ยวข้องกับการตัดสินใจในการบริหาร

ตัวอย่างเช่น อัลกอริทึม “ตามหลักฐานของกฎหมายญี่ปุ่น (Japanese Civil Law)” อาจไม่สามารถยอมรับได้ในธุรกิจบางอย่างของบริษัทบางแห่ง ซึ่งเป็นสิ่งที่เป็นไปได้ในความเป็นจริง แม้ว่าเรื่องนี้จะเปลี่ยนจากตัวอย่างที่ผ่านมา แต่ตัวอย่างเช่น กฎหมายญี่ปุ่นกำหนดอัลกอริทึมเริ่มต้นว่า “การมอบหมายใหม่โดยผู้รับมอบหมายจะเป็นการฝ่าฝืนสัญญา” แต่ในบางกรณี “สำหรับบริษัทบางแห่ง ธุรกิจบางอย่าง มันเป็นสิ่งที่คาดว่าจะใช้บริษัทผู้รับเหมาย่อยอย่างเป็นธรรมดา” ในกรณีเช่นนี้ สัญญาที่ไม่สามารถมอบหมายใหม่ได้ นั่นคือ

• ไม่ได้ระบุเกี่ยวกับการมอบหมายใหม่ (ในกรณีนี้ ตามที่กล่าวไว้ข้างต้น หลักฐานของกฎหมายญี่ปุ่นจะถูกนำมาใช้)
• ระบุว่าไม่สามารถมอบหมายใหม่ได้

การยอมรับสัญญาดังกล่าว แม้ว่าจะเป็น “ตามหลักฐานของกฎหมายญี่ปุ่น” ก็ไม่ควรจะเป็นไปได้

นอกจากนี้ ในการบริหารจัดการมี “ความเสี่ยงที่จะต้องรับผิดชอบถ้าเกิดเหตุการณ์บางอย่าง” อยู่เสมอ สัญญาที่ “ไม่มีความเสี่ยง” สำหรับบริษัทของเรา ไม่มีอยู่ในทางปฏิบัติ การตัดสินใจว่าจะยอมรับความเสี่ยงนี้หรือไม่ ในที่สุดก็เป็นการตัดสินใจในการบริหาร ผู้บริหารเป็นผู้ที่ต้องตัดสินใจในการบริหาร ไม่ใช่ผู้ให้คำปรึกษาทางกฎหมายหรือผู้ที่มีฐานะเป็นคอนซัลแตนต์ แต่คอนซัลแตนต์ควรจะนำเสนอข้อมูลที่เพียงพอและจำเป็นสำหรับผู้บริหารในการตัดสินใจในการบริหาร

• ความเสี่ยงที่ไม่จำเป็นต้องระบุทุกครั้ง
• ความเสี่ยงที่ต้องยอมรับและเป็นการตัดสินใจที่สำคัญสำหรับบริษัท ซึ่งอาจจำเป็นต้องมีการประชุมหรืออื่น ๆ

ควรระบุความเสี่ยงเหล่านี้ด้วยการให้ความเข้มข้นที่แตกต่างกัน สำหรับการตั้งค่า “ความเข้มข้ม” นี้ ทนายความที่ตรวจสอบสัญญา ต้องมี “ความรู้สึกเกี่ยวกับการบริหาร” ในระดับหนึ่ง ซึ่งเหมือนกับกรณีของคอนซัลแตนต์ในด้านอื่น ๆ

สรุป

ดังนั้น การตรวจสอบและแก้ไขสัญญาจะเป็นการทำงานที่สำคัญในด้านต่อไปนี้

1. เข้าใจว่าหลักการของกฎหมายญี่ปุ่น เช่น กฎหมายแพ่งและพาณิชย์ ถูกเขียนทับอย่างไรในสัญญา และผลที่ตามมาคืออัลกอริทึมอย่างไร
2. พิจารณาว่าเหตุการณ์ใดที่อาจเกิดขึ้นในอนาคตภายใต้อัลกอริทึมนี้
3. พิจารณาว่าจะมีการทำงานที่ไม่คาดคิดหรือไม่

และแต่ละข้อดังกล่าว

1. เป็นงานที่ยากถ้าไม่มีคนที่เข้าใจกฎหมาย
2. เป็นงานที่ยากถ้าไม่มีคนที่เข้าใจเนื้อหาของธุรกิจที่สัญญาควบคุม เช่น แอปพลิเคชันหรือบริการเว็บ และโครงสร้างธุรกิจ
3. เป็นงานที่ยากถ้าไม่มีคนที่เข้าใจเนื้อหาของธุรกิจหรือบริษัท และมีความรู้สึกทางธุรกิจในระดับหนึ่ง

นั่นคือเหตุผล

การตรวจสอบและแก้ไขสัญญาเป็นงานที่ “เฉพาะทาง” มากเนื่องจากเหตุผลดังกล่าว

คำแนะนำเกี่ยวกับการสร้างและตรวจสอบสัญญาจากทางสำนักงานของเรา

ที่สำนักงานทนายความ Monolis, เราให้บริการในฐานะสำนักงานทนายความที่มีความเชี่ยวชาญในด้าน IT, อินเทอร์เน็ต, และธุรกิจ โดยเราให้บริการสร้างและตรวจสอบสัญญาให้กับลูกค้าที่เป็นบริษัทที่เราเป็นที่ปรึกษาและบริษัทที่เป็นลูกค้าของเรา

หากท่านสนใจ กรุณาดูรายละเอียดที่ด้านล่างนี้

https://monolith.law/contractcreation[ja]