จุดที่ควรตรวจสอบในสัญญาการพัฒนาระบบแบบรับเหมาคืออะไร

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

การพัฒนาระบบและสัญญาจ้างงาน

สัญญาจ้างงานคืออะไร

สัญญาจ้างงานถูกกำหนดตามกฎหมายญี่ปุ่น (Japanese Civil Code) ดังนี้

บทที่ 632
สัญญาจ้างงานเกิดขึ้นเมื่อฝ่ายหนึ่งสัญญาว่าจะทำงานให้เสร็จสิ้น และฝ่ายตรงข้ามสัญญาว่าจะจ่ายค่าตอบแทนสำหรับผลงานนั้น

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

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

ความแตกต่างจากสัญญามอบหมาย

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

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

ข้อความแบบจำลองและจุดตรวจสอบสำหรับรูปแบบของสัญญาจ้าง

การสนับสนุนในการจัดทำความต้องการของระบบ

การจัดทำความต้องการของระบบคือการรวบรวมข้อกำหนดที่ผู้ใช้ต้องการสร้างระบบ ในขั้นตอนการจัดทำความต้องการของระบบ จะทำการพิจารณาทิศทางในการสร้างระบบ และตัดสินใจว่าจะสร้างระบบอย่างไร ซึ่งเนื่องจากผลผลิตที่ได้ยังไม่สามารถกำหนดได้อย่างชัดเจน ดังนั้น สัญญาแบบตัวแทนจำเพาะของกระทรวงเศรษฐกิจ อุตสาหกรรมและการค้าของญี่ปุ่น (Japanese Ministry of Economy, Trade and Industry) ได้กำหนดไว้ รายละเอียดสามารถอ่านได้ในบทความด้านล่างนี้

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

ธุรกิจการสร้างเอกสารการออกแบบภายนอก

（การดำเนินงานในการสร้างเอกสารการออกแบบภายนอก）
มาตราที่ ○ ผู้รับจ้างจะต้องทำสัญญาตามมาตราที่ ○ ที่กำหนดไว้ และดำเนินการสร้างเอกสารการออกแบบภายนอกของซอฟต์แวร์นี้ตามเอกสารที่ระบุความต้องการที่ได้รับการยืนยันตามมาตราที่ ○ ในฐานะงานที่เกี่ยวข้อง

2. ในการดำเนินการสร้างเอกสารการออกแบบภายนอก ผู้รับจ้างสามารถขอความร่วมมือจากผู้ว่าจ้างได้ และผู้ว่าจ้างจะต้องตอบสนองต่อความต้องการนี้อย่างทันท่วงที

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

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

（การทำสัญญาเฉพาะเรื่องเกี่ยวกับงานสร้างเอกสารออกแบบภายนอก）
มาตราที่ ○ ทั้ง กษัตริย์ และ อัศวิน จะตกลงเงื่อนไขการทำธุรกรรมตามที่ระบุในมาตราที่ ○ ข้อที่ ○ หลังจากการปรึกษากัน และจะทำสัญญาเฉพาะเรื่องเกี่ยวกับงานสร้างเอกสารออกแบบภายนอก

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

（การประชุมพิจารณาการออกแบบภายนอก）
ข้อที่ ○ ผู้รับจ้างจะจัดการประชุมพิจารณาการออกแบบภายนอก (ในส่วนนี้เรียกว่า “การประชุมพิจารณาการออกแบบภายนอก”) ในความถี่ที่เห็นสมควรเพื่อทำความเข้าใจหรือยืนยันเรื่องที่จำเป็นสำหรับการสร้างเอกสารการออกแบบภายนอกตามข้อที่ ○ และผู้ว่าจ้างจะเข้าร่วมการประชุมดังกล่าว

2. ผู้ว่าจ้างสามารถจัดการประชุมพิจารณาการออกแบบภายนอกเมื่อเห็นว่าจำเป็นสำหรับการสร้างเอกสารการออกแบบภายนอก และผู้รับจ้างจะเข้าร่วมการประชุมดังกล่าว

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

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

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

（การส่งมอบเอกสารการออกแบบภายนอก）
ข้อที่○ ท่านจะต้องส่งมอบเอกสารการออกแบบภายนอกและแบบฟอร์มการร้องขอการตรวจรับเอกสารการออกแบบภายนอก (พร้อมทั้งเป็นเอกสารการส่งมอบสินค้า) ให้แก่ทางผู้ว่าจ้างภายในวันที่กำหนดตามสัญญาเฉพาะ

เนื่องจากโปรเจคนี้เป็นแบบทำเป็นงานรับจ้าง ผู้ขายจึงต้องส่งมอบเอกสารการออกแบบภายนอกและอื่น ๆ เป็นผลงานที่ต้องส่งมอบ

（การอนุมัติและการยืนยันของเอกสารการออกแบบภายนอก）
มาตราที่ ○ ทาง ก จะตรวจสอบเอกสารการออกแบบภายนอกภายในระยะเวลาที่กำหนดในสัญญาแต่ละรายการ (ต่อไปนี้เรียกว่า “ระยะเวลาตรวจสอบเอกสารการออกแบบภายนอก”) ว่าเอกสารการออกแบบภายนอกนั้นสอดคล้องกับเอกสารการกำหนดความต้องการที่ได้รับการยืนยันตามมาตราที่ ○ และเรื่องที่ตัดสินใจในการประชุมการออกแบบภายนอกตามมาตราที่ ○ หรือไม่ และว่าไม่มีข้อผิดพลาดทางตรรกะ และจะเป็นหลักฐานว่าได้รับการอนุมัติว่าเอกสารการออกแบบภายนอกนั้นสอดคล้องและไม่มีข้อผิดพลาดทางตรรกะ ผู้รับผิดชอบของทั้งสองฝ่ายจะลงชื่อและประทับตราในเอกสารการอนุมัติการออกแบบภายนอก อย่างไรก็ตาม หากจากการตรวจสอบพบว่าเอกสารการออกแบบภายนอกไม่สอดคล้องกับเอกสารการกำหนดความต้องการที่ได้รับการยืนยันตามมาตราที่ ○ หรือเรื่องที่ตัดสินใจในการประชุมการออกแบบภายนอก หรือพบข้อผิดพลาดทางตรรกะ ฝ่าย ข จะสร้างเอกสารแก้ไขภายในระยะเวลาที่กำหนดหลังจากการปรึกษาและนำเสนอให้กับฝ่าย ก ซึ่งฝ่าย ก จะดำเนินการตรวจสอบและอนุมัติอีกครั้ง

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

3. ด้วยการอนุมัติของฝ่าย ก ตามข้อ 1 และ 2 เอกสารการออกแบบภายนอกจะถือว่าได้รับการยืนยัน

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

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

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

（ความรับผิดชอบในการรับประกันความบกพร่อง）
มาตรา○ หลังจากการยืนยันในข้อก่อนหน้านี้ หากพบว่ามีความไม่สอดคล้องหรือความผิดพลาดทางตรรกะ (ที่เรียกว่า “ความบกพร่อง” ในข้อนี้) ในเอกสารการออกแบบภายนอกกับเอกสารการกำหนดความต้องการและสิ่งที่ตัดสินใจในการประชุมการออกแบบภายนอกตามมาตรา○ ที่กำหนดไว้ ผู้รับจะสามารถขอให้ผู้ให้แก้ไขความบกพร่องดังกล่าว และผู้ให้จะต้องแก้ไขความบกพร่องดังกล่าว อย่างไรก็ตาม ผู้ให้จะรับผิดชอบในการแก้ไขเฉพาะกรณีที่ผู้รับได้ร้องขอภายใน○ เดือนหลังจากการยืนยันในข้อก่อนหน้านี้เท่านั้น

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

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

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

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

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

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

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

https://monolith.law/corporate/defect-warranty-liability[ja]

ธุรกิจการพัฒนาซอฟต์แวร์

（การดำเนินงานด้านการพัฒนาซอฟต์แวร์）
มาตราที่ 〇 ผู้รับจ้างจะดำเนินการพัฒนาซอฟต์แวร์ตามที่ได้ระบุไว้ในสเปคการพัฒนาระบบที่ได้รับการยืนยันจากส่วนต่างๆ ก่อนหน้านี้ โดยทำการทำสัญญาเฉพาะตามที่ระบุไว้ในมาตรา 25 และดำเนินการตั้งแต่การออกแบบภายในจนถึงการทดสอบระบบ

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

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

（การทำสัญญาเฉพาะสำหรับธุรกิจการพัฒนาซอฟต์แวร์）
มาตราที่ 〇 ทั้งสองฝ่าย กับ ฝ่ายที่ 〇 จะตกลงเงื่อนไขการทำธุรกรรมตามที่ระบุในมาตราที่ 〇 ข้อที่ 〇 หลังจากการปรึกษากัน และจะทำสัญญาเฉพาะสำหรับธุรกิจการพัฒนาซอฟต์แวร์

เราได้กำหนดว่า ขอบเขตของธุรกิจการพัฒนาซอฟต์แวร์ และอื่น ๆ จะถูกตกลงในสัญญาเฉพาะตามเงื่อนไขการทำธุรกรรมที่กำหนดไว้ล่วงหน้า

（การส่งมอบผลงาน）
มาตราที่ 〇 ผู้รับจ้างจะส่งมอบผลงานที่กำหนดไว้ในสัญญาแต่ละรายการให้แก่ผู้ว่าจ้างภายในวันที่กำหนดในสัญญาแต่ละรายการ พร้อมกับใบขอรับการตรวจสอบผลงาน (ใบส่งมอบผลงาน)
2. ผู้ว่าจ้างจะทำการตรวจสอบผลงานตามที่กำหนดในมาตราที่ 〇 (การตรวจสอบซอฟต์แวร์) ตามข้อกำหนดในเอกสารข้อกำหนดการตรวจสอบในบทถัดไป หากมีการส่งมอบผลงาน
3. ผู้รับจ้างสามารถขอความร่วมมือที่จำเป็นจากผู้ว่าจ้างในการส่งมอบผลงาน และผู้ว่าจ้างจะต้องร่วมมือกับผู้รับจ้างโดยเร็วที่สุดเมื่อได้รับคำขอ
4. ผู้รับจ้างจะรับผิดชอบความเสี่ยงในการสูญหายหรือเสียหายของผลงานก่อนการส่งมอบ และผู้ว่าจ้างจะรับผิดชอบความเสี่ยงดังกล่าวหลังจากการส่งมอบ

เนื่องจากโปรเจคนี้เป็นแบบรับเหมา จึงต้องส่งมอบซอฟต์แวร์ที่เสร็จสมบูรณ์และผลงานอื่น ๆ ที่เป็นผลลัพธ์ที่ต้องตรวจสอบ มาตราที่ 1 กำหนดว่าต้องส่งมอบผลงานพร้อมกับใบขอรับการตรวจสอบผลงาน (ใบส่งมอบผลงาน)

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

（การตรวจรับซอฟต์แวร์ในกรณีนี้）
มาตราที่ 〇 สำหรับซอฟต์แวร์ในกรณีนี้ที่เป็นส่วนหนึ่งของสินค้าที่ส่งมอบ ผู้ว่าจ้างจะต้องตรวจสอบซอฟต์แวร์ตามข้อกำหนดในสเปคการทดสอบที่ระบุไว้ในสัญญาแยกต่างหากภายในระยะเวลาที่กำหนด (ต่อไปนี้เรียกว่า “ระยะเวลาการตรวจสอบ”) และตรวจสอบว่าซอฟต์แวร์ในกรณีนี้ตรงกับสเปคของระบบหรือไม่

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

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

4. การผ่านการตรวจสอบตามข้อกำหนดในมาตรานี้จะถือว่าการตรวจรับซอฟต์แวร์ในกรณีนี้เสร็จสมบูรณ์

เนื่องจากกระบวนการนี้เป็นแบบรับเหมา มาตรานี้จึงกำหนดขั้นตอนในการตรวจรับซอฟต์แวร์ที่ส่งมอบ

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

（ความรับผิดชอบในการรับประกันความบกพร่อง）
มาตราที่ 〇 หลังจากการตรวจสอบในข้อก่อนหน้านี้เสร็จสิ้น หากพบว่าสินค้าที่ส่งมอบมีความไม่สอดคล้องกับข้อกำหนดระบบ (รวมถึงบั๊ก ในข้อนี้เรียกว่า “ความบกพร่อง”) ผู้ว่าจ้างสามารถขอให้ผู้รับจ้างแก้ไขความบกพร่องดังกล่าว และผู้รับจ้างจะต้องแก้ไขความบกพร่องดังกล่าว อย่างไรก็ตาม ผู้รับจ้างจะรับผิดชอบในการแก้ไขเฉพาะในกรณีที่ผู้ว่าจ้างได้ร้องขอภายใน○ เดือนหลังจากการตรวจสอบเสร็จสิ้น
2. ไม่ว่าจะเป็นอย่างไร หากความบกพร่องเป็นเรื่องเล็กน้อยและการแก้ไขสินค้าต้องใช้ค่าใช้จ่ายที่มากเกินไป ผู้รับจ้างจะไม่ต้องรับผิดชอบในการแก้ไขตามข้อก่อนหน้านี้
3. ข้อกำหนดในข้อที่ 1 จะไม่ใช้ในกรณีที่ความบกพร่องเกิดจากเอกสารหรือคำสั่งที่ผู้ว่าจ้างได้ให้ อย่างไรก็ตาม หากผู้รับจ้างไม่ได้แจ้งว่าเอกสารหรือคำสั่งดังกล่าวไม่เหมาะสม ข้อกำหนดนี้จะไม่ใช้

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

ข้อที่ 1 กำหนดว่า “ความไม่สอดคล้องกับข้อกำหนดระบบ” ในงานพัฒนาซอฟต์แวร์เป็นความบกพร่อง สำหรับข้อบกพร่องที่เกิดขึ้นในขั้นตอนการออกแบบภายนอก เช่น ฟังก์ชันที่ขาดหาย จะต้องตัดสินความรับผิดชอบตามข้อกำหนดเกี่ยวกับความรับผิดชอบในการรับประกันความบกพร่องในขั้นตอนการออกแบบภายนอก ไม่ใช่ข้อนี้ ระยะเวลาในการรับประกันความบกพร่องจะต้องพิจารณาจากขนาดของระบบข้อมูล ค่าตอบแทน และตกลงกันระหว่างทั้งสองฝ่ายในระยะเวลาที่เหมาะสม

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

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

ในกรณีใดที่ความบกพร่องจะถูกยอมรับ และในกรณีที่ความบกพร่องถูกยอมรับ รายละเอียดเกี่ยวกับความรับผิดชอบที่เฉพาะเจาะจงจะถูกอธิบายอย่างละเอียดในบทความด้านล่าง

https://monolith.law/corporate/defect-warranty-liability[ja]

ธุรกิจสนับสนุนการเตรียมการและการย้ายซอฟต์แวร์

ในขั้นตอนของการรับระบบและการนำมาใช้งาน ผู้ใช้มักจะเป็นผู้ดำเนินการโดยส่วนใหญ่ ดังนั้น ในสัญญาแบบต้นแบบของกระทรวงเศรษฐกิจ การค้าและอุตสาหกรรมญี่ปุ่น (Japanese Ministry of Economy, Trade and Industry) กำหนดว่าผู้ใช้จะเป็นผู้ริเริ่ม และผู้ขายจะสนับสนุน ในรูปแบบของการมอบหมายทั้งหมด

การตัดสินลักษณะของสัญญา

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

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