สัญญาพัฒนาระบบ 2026 – จ้างทำของหรือกึ่งมอบหมายและเกณฑ์ตรวจรับ

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

สิ่งที่ต้องตัดสินใจจริง ๆ ใน “สัญญาพัฒนาระบบ” – เหตุใดหลักการทั่วไปจึงไม่เพียงพอ

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

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

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

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

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

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

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

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

สัญญาจ้างทำของกับสัญญากึ่งมอบหมายต่างกันอย่างไร

เริ่มจากความแตกต่างของสัญญาสองประเภท โดยจำกัดเฉพาะผลที่มีความหมายในทางปฏิบัติ

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

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

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

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

สรุปคือสัญญาสองประเภทนี้ไม่ได้ดีกว่าหรือแย่กว่ากัน แต่เหมาะกับคนละเฟส ความอึดอัดเกิดจากการพยายามคลุมทุกขั้นตอนด้วยสัญญาฉบับเดียว หากแบ่งเฟสแล้วเปลี่ยนประเภทสัญญา ก็หลีกเลี่ยงจุดอ่อนของทั้งสองแบบได้

ควรเลือกแบบไหน – ตัดสินจากระดับความชัดเจนของความต้องการ

แล้วจะตัดสินจุดสลับที่ตรงไหน เกณฑ์คือระดับความชัดเจนของความต้องการ ฟังดูเป็นนามธรรม แต่ตัดสินได้จากการตอบคำถาม 3 ข้อต่อไปนี้ให้ได้หรือไม่

ข้อแรก ขอบเขตของงานที่ระบบจะรองรับ โรงงานที่ครอบคลุม และแผนกที่ครอบคลุม ถูกกำหนดแล้วหรือยัง ข้อที่สอง มีรายการหน้าจอหลักและแบบฟอร์มรายงานออกมาแล้วหรือยัง และแต่ละรายการระบุช่องข้อมูลนำเข้าและข้อมูลผลลัพธ์ได้ครบหรือไม่ ข้อที่สาม จุดเชื่อมต่อกับระบบเดิมหรือเครื่องจักร กล่าวคือจะเชื่อมอะไรเข้ากับอะไร ตัดสินใจแล้วหรือยัง

หากตอบได้ครบทั้ง 3 ข้อ การสั่งจ้างเฟสการพัฒนาด้วยสัญญาจ้างทำของก็จะไม่เกิดความคลาดเคลื่อนรุนแรง ในทางกลับกัน หากมีแม้เพียงข้อเดียวที่ตอบว่ายังต้องไปตกลงกันต่อ ส่วนนั้นควรถูกทำให้นิ่งก่อนในเฟสที่ใช้สัญญากึ่งมอบหมาย

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

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

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

เกณฑ์การตรวจรับควรกำหนดเมื่อใด และยึดอะไรเป็นฐาน

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

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

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

เมื่อเขียนเกณฑ์การตรวจรับ หัวข้อที่ควรมีอย่างน้อยมีดังนี้

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

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

อีกวิธีหนึ่งคือให้แต่ละบริษัทเสนอร่างเกณฑ์การตรวจรับมาตั้งแต่ขั้นเปรียบเทียบราคา ซึ่งใช้เป็นแกนเปรียบเทียบข้อเสนอได้ดีด้วย กระบวนการนี้เราเรียบเรียงไว้อย่างละเอียดในบทความว่าด้วยการทำ RFP สำหรับระบบบริหารการผลิต

ความรับผิดเพื่อความไม่เป็นไปตามสัญญาคืออะไร – ต่างจากความรับผิดในความชำรุดบกพร่องแบบเดิมอย่างไร

เมื่อพบข้อบกพร่องหลังส่งมอบและผ่านการตรวจรับไปแล้ว จะให้บริษัทผู้พัฒนาแก้ไขได้ถึงระดับใด สิ่งที่กำหนดเรื่องนี้คือความรับผิดเพื่อความไม่เป็นไปตามสัญญา

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

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

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

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

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

สิทธิในทรัพย์สินทางปัญญาตกเป็นของฝ่ายใด

จ่ายเงินสั่งจ้างไปแล้ว ระบบที่ทำเสร็จก็ต้องเป็นของบริษัทเราสิ ความรู้สึกนี้เป็นธรรมชาติ แต่ในทางกฎหมายไม่ได้เป็นเช่นนั้น

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

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

ทางเลือกในทางปฏิบัติมี 3 ทางใหญ่ ๆ

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

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

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

ช่องโหว่ 2 จุดที่มักถูกมองข้ามในสัญญารักษาความลับ

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

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

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

สัญญารักษาความลับเมื่อลงนามไปแล้วมักถูกใช้ต่อไปหลายปีโดยไม่มีการทบทวน จังหวะที่ทำสัญญาพัฒนาระบบจึงเป็นโอกาสดีในการตรวจสอบ 2 ประเด็นนี้

บทเรียนจากกรณีจริง – เมื่อออกแบบสัญญาผิดพลาดจะเกิดอะไรขึ้น

กรณีที่มักถูกอ้างถึงในฐานะตัวอย่างของการออกแบบสัญญาที่หละหลวมจนบานปลายเป็นข้อพิพาทขนาดใหญ่ คือคดีพิพาทการพัฒนาระบบระหว่างธนาคาร Suruga กับ IBM Japan

ตามรายงานข่าว ศาลแขวงโตเกียวมีคำพิพากษาเมื่อวันที่ 29 มีนาคม 2012 สั่งให้ชำระเงินประมาณ 7.4 พันล้านเยน ต่อมาศาลสูงโตเกียวซึ่งเป็นศาลอุทธรณ์มีคำพิพากษาเมื่อวันที่ 26 กันยายน 2013 ลดจำนวนเงินดังกล่าวลงเหลือประมาณ 4.2 พันล้านเยน มีรายงานว่าศาลสูงโตเกียวได้วางแนวว่า ความไม่แน่นอนในระยะเริ่มต้นของโครงการนั้น ฝ่ายองค์กรผู้ใช้ระบบก็ต้องแบกรับความเสี่ยงตามส่วนของตนด้วย

บทความนี้ไม่ใช่บทวิเคราะห์คำพิพากษา จึงจะไม่ก้าวเข้าไปประเมินในเชิงกฎหมาย สิ่งที่ผู้รับผิดชอบงานจัดจ้างควรจับให้ได้มีดังนี้

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

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

สาเหตุที่การนำระบบมาใช้ไม่ราบรื่นไม่ได้มีแค่เรื่องสัญญา รายการทั้งหมดที่ควรตัดสินใจภายในองค์กรก่อนสั่งจ้าง เราเรียบเรียงไว้ในบทความว่าด้วยความล้มเหลวในการนำระบบบริหารการผลิตมาใช้

ข้อสัญญา 3 ข้อที่ต้องเพิ่มเมื่อทำสัญญาในประเทศไทย

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

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

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

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

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

ดังนั้นเมื่อทำสัญญาเฟสการนิยามความต้องการกับบริษัทพัฒนาระบบของไทย การเขียนว่าให้เป็นสัญญากึ่งมอบหมายย่อมสื่อความไม่ได้ สิ่งที่ต้องทำคือบรรยายไว้ในสัญญาอย่างเป็นรูปธรรม ในฐานะลักษณะของงาน ว่างานนั้นเป็นการรับปากความสำเร็จของผลงานส่งมอบ หรือเป็นการจ่ายค่าตอบแทนให้กับการให้บริการ ต้องเขียนให้ครบด้วยถ้อยคำในข้อสัญญาว่าจะส่งมอบสิ่งใดเป็นผลงาน ค่าตอบแทนเกิดขึ้นเพื่อแลกกับอะไร และรวมการรับประกันความสำเร็จไว้ด้วยหรือไม่

หากพัฒนาในประเทศเพื่อนบ้าน ความแตกต่างของแนวปฏิบัติในแต่ละพื้นที่ก็มองข้ามไม่ได้ ประเด็นสำหรับการพัฒนาในเวียดนามเราสรุปไว้ในบทความว่าด้วยการพัฒนาระบบในเวียดนาม

ประมาณการเฉพาะของเรา – ต้นทุนงานย้อนกลับที่เกิดจากการเลือกประเภทสัญญาไม่ตรง

ต่อไปจะลองแปลงข้อถกเถียงทั้งหมดข้างต้นออกมาเป็นตัวเงิน สิ่งที่จะกล่าวต่อไปนี้เป็นประมาณการเฉพาะของเราที่อิงกรณีตัวอย่างจำลอง ไม่ใช่ตัวเลขของบริษัทที่มีอยู่จริง ขอให้อ่านเป็นวัตถุดิบสำหรับตรวจสอบโครงสร้าง มากกว่าจะดูที่ขนาดของจำนวนเงิน

เริ่มจากตั้งสมมติฐาน สมมติว่าโรงงานสัญชาติญี่ปุ่นในประเทศไทยกำลังสั่งจ้างปรับปรุงระบบบริหารการผลิตใหม่ มูลค่าสัญญาของเฟสการพัฒนาคือ 3,000,000 THB ราคามาตรฐานของงานพัฒนาเพิ่มเติมคือ 3,000 THB ต่อคน-วัน และแรงงานพัฒนามาตรฐานต่อการเปลี่ยนข้อกำหนด 1 รายการคือ 3 คน-วัน บนพื้นฐานนี้ เราจะเปรียบเทียบ 2 กรณีที่มีระดับความชัดเจนของความต้องการต่างกัน

กรณี A คือกรณีที่ทำสัญญาเฟสการพัฒนาแบบจ้างทำของเหมารวม ในขณะที่การนิยามความต้องการชัดเจนเพียง 60% หลังลงนามสัญญาแล้วเกิดการเปลี่ยนข้อกำหนดขึ้น 8 รายการ

ภาระงานส่วนเกิน 4,500 THB ต่อรายการ คือการตีมูลค่างานที่เกิดขึ้นเพื่อจัดการการเปลี่ยนข้อกำหนดด้วยการเจรจาเป็นราย ๆ หลังลงนามสัญญาแล้ว โดยรวมการสำรวจขอบเขตผลกระทบ การจัดทำใบเสนอราคาใหม่ และการประชุมเพื่อตกลงเพิ่มเติม เข้าด้วยกันเป็นประมาณ 1.5 คน-วันต่อรายการ ในสัญญาจ้างทำของ งานที่อยู่นอกขอบเขตสัญญาเดินหน้าโดยไม่คิดค่าตอบแทนไม่ได้ การเจรจานี้จึงเกิดขึ้นทุกครั้ง

ยังมีต้นทุนที่ไม่ปรากฏเป็นตัวเงินด้วย ในบรรดา 8 รายการนั้น การเปลี่ยนแปลงที่พาดผ่านหลายโมดูลมี 5 รายการ และแต่ละรายการใช้เวลาสร้างข้อตกลงเฉลี่ย 6.4 วันทำการ รวมแล้ว 5 รายการ × 6.4 วันทำการ เท่ากับ 32 วันทำการ ที่สะสมเป็นความล่าช้าบนเส้นทางวิกฤต ความล่าช้านี้เราไม่ได้แปลงเป็นตัวเงิน ยิ่งไปกว่านั้น ยิ่งการเจรจายืดเยื้อ ความเสี่ยงที่จะบานปลายเป็นข้อพิพาทก็ยิ่งสูง และความไว้วางใจระหว่างผู้รับผิดชอบทั้งสองฝ่ายก็เสียหายไปด้วย สิ่งเหล่านี้วัดเป็นปริมาณไม่ได้ แต่ในทางปฏิบัติอาจกลายเป็นต้นทุนที่หนักที่สุด

กรณี B คือกรณีที่แยกเฟสการนิยามความต้องการออกมาเป็นสัญญากึ่งมอบหมายต่างหาก ยกระดับความชัดเจนขึ้นไปถึง 95% แล้วจึงทำสัญญาเฟสการพัฒนาแบบจ้างทำของ เฟสการนิยามความต้องการมีระยะเวลา 2.5 เดือน เดือนละ 150,000 THB มูลค่าสัญญาจึงเท่ากับ 375,000 THB

การเปลี่ยนข้อกำหนดหลังลงนามสัญญาลดลงเหลือ 2 รายการ ต้นทุนเพิ่มเติมรวมคือ 27,000 THB เมื่อเทียบกับ 108,000 THB ของกรณี A จะได้ 108,000 ÷ 27,000 เท่ากับต่างกัน 4.0 เท่า ส่วนต่างคือ 108,000 − 27,000 เท่ากับ 81,000 THB

ตรงนี้มีสิ่งที่ต้องเขียนไว้อย่างซื่อตรง กรณี B ลงทุนล่วงหน้าไปกับเฟสการนิยามความต้องการ 375,000 THB ในขณะที่ต้นทุนเพิ่มเติมที่ลดได้คือ 81,000 THB เนื่องจาก 81,000 THB ต่ำกว่า 375,000 THB การลงทุนนี้จึงไม่คืนทุนในการคำนวณเชิงเงินสด การอธิบายว่าแยกการนิยามความต้องการออกมาแล้วค่าใช้จ่ายจะลดลงนั้นไม่ถูกต้องนัก

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

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

เช็กลิสต์สัญญา – รายการที่ต้องตรวจก่อนสั่งจ้าง

ต่อไปจะเรียงเนื้อหาทั้งหมดข้างต้นใหม่ตามลำดับที่ควรตรวจเมื่อได้รับร่างสัญญามา เมื่ออ่านแบบฟอร์มที่บริษัทผู้พัฒนาเสนอมา การไล่ดูตามลำดับนี้จะช่วยลดการตกหล่น

ในรายการนี้ สิ่งที่ฝ่ายผู้ว่าจ้างตัดสินใจเองได้คือ 5 หัวข้อแรก ได้แก่ ประเภทสัญญา ขอบเขตงาน นิยามผลงานส่งมอบ เกณฑ์การตรวจรับ และระยะเวลาตรวจรับ ส่วนนี้อย่ายกให้บริษัทผู้พัฒนาเป็นคนเติม แต่ควรถือร่างของตนเองเข้าสู่การเจรจา ส่วนหัวข้อที่เหลือมีลักษณะเป็นการอ่านแบบฟอร์มให้ละเอียดแล้วตรวจว่าเงื่อนไขเสียเปรียบหรือไม่

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

จะใช้สัญญาต้นแบบของ IPA อย่างไร

ไม่จำเป็นต้องร่างสัญญาขึ้นใหม่จากศูนย์ เพราะมีแบบฟอร์มที่เป็นกลางซึ่งเผยแพร่โดยหน่วยงานของรัฐอยู่แล้ว

สำนักงานส่งเสริมเทคโนโลยีสารสนเทศแห่งประเทศญี่ปุ่น (IPA) ได้เผยแพร่สัญญาและรูปแบบธุรกรรมต้นแบบสำหรับระบบสารสนเทศ ฉบับที่สอง เมื่อวันที่ 22 ธันวาคม 2020 เอกสารนี้จัดทำขึ้นโดยมุ่งให้มีเนื้อหาที่เป็นกลาง ไม่เอนเอียงไปทางองค์กรผู้ใช้หรือผู้ให้บริการไอทีฝ่ายใด และในจังหวะเดียวกันก็ได้เผยแพร่แนวทางเกี่ยวกับข้อกำหนดด้านความมั่นคงปลอดภัยไว้ด้วย

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

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

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

คำถามที่พบบ่อย

สัญญาจ้างทำของกับสัญญากึ่งมอบหมาย แบบไหนปลอดภัยกว่ากัน

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

ควรกำหนดเกณฑ์การตรวจรับเมื่อใด

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

ระยะเวลาความรับผิดเพื่อความไม่เป็นไปตามสัญญาเท่าใดจึงเหมาะสม

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

ต้องให้โอนลิขสิทธิ์มาที่บริษัทเราเสมอไปหรือไม่

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

แปลสัญญาญี่ปุ่นเป็นภาษาไทยแล้วเพียงพอหรือไม่

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

โครงการขนาดเล็กก็ต้องทำสัญญาละเอียดขนาดนี้ด้วยหรือ

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

สรุป

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

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

ในประมาณการเฉพาะของเรา กรณี A ที่ทำสัญญาจ้างทำของเหมารวมขณะที่ความต้องการชัดเจน 60% มีต้นทุนเพิ่มเติม 108,000 THB ส่วนกรณี B ที่แยกการนิยามความต้องการออกมาเป็นสัญญากึ่งมอบหมายอยู่ที่ 27,000 THB ต่างกัน 4.0 เท่า อย่างไรก็ตาม การลงทุนล่วงหน้า 375,000 THB ในการนิยามความต้องการนั้นไม่คืนทุนเป็นเงินสดด้วยส่วนต่างเพียง 81,000 THB สิ่งที่ได้คืนกลับมาคือการหลีกเลี่ยงความล่าช้า 32 วันทำการ และการลดความเสี่ยงข้อพิพาท ซึ่งเป็นคุณค่าที่แปลงเป็นตัวเงินได้ยาก การอธิบายจุดนี้ภายในองค์กรได้อย่างไม่กลบเกลื่อนคือสิ่งสำคัญต่อการขออนุมัติงบด้วย

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

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

ข้อมูลอ้างอิง

• BUSINESS LAWYERS — ความแตกต่างระหว่างสัญญาจ้างทำของกับสัญญากึ่งมอบหมาย และการเลือกใช้ในงานพัฒนาระบบ
• BUSINESS LAWYERS — แนวปฏิบัติเรื่องความรับผิดเพื่อความไม่เป็นไปตามสัญญาในงานพัฒนาระบบ
• สำนักงานกฎหมาย Tokyo Startup — ความรับผิดเพื่อความไม่เป็นไปตามสัญญาในงานพัฒนาระบบ
• Human Navi — การตรวจรับในงานพัฒนาระบบ และวิธีกำหนดเกณฑ์การตรวจรับเพื่อป้องกันปัญหา
• สำนักงาน Shu Sogo — การเป็นเจ้าของลิขสิทธิ์และสิทธิในการแก้ไขระบบในงานพัฒนาระบบ
• สำนักงานส่งเสริมเทคโนโลยีสารสนเทศแห่งประเทศญี่ปุ่น (IPA) — สัญญาและรูปแบบธุรกรรมต้นแบบสำหรับระบบสารสนเทศ ฉบับที่สอง
• Nikkei — คำพิพากษาชั้นอุทธรณ์ในคดีพัฒนาระบบระหว่างธนาคาร Suruga กับ IBM Japan
• สำนักงานกฎหมาย GVA — แนวปฏิบัติการทำสัญญาในประเทศไทย กฎหมายที่ใช้บังคับ ภาษา และเขตอำนาจศาล
• Legal Execution Thailand — ประมวลกฎหมายแพ่งและพาณิชย์ของไทย บรรพ 3 ลักษณะ 7 จ้างทำของ