คือสถานการณ์ที่ใช้ข้อกำหนดการตรวจรับและการตรวจรับโดยการถือว่าตรวจรับแล้วในการพัฒนาระบบ

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

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

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

ในบทความนี้ เราจะอธิบายว่าในกรณีใด “การตรวจรับโดยการถือว่า” จะถูกนำมาใช้ โดยอ้างอิงจากตัวอย่างคดีจริง

การตรวจรับในการพัฒนาระบบคืออะไร

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

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

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

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

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

ระวังข้อกำหนดเรื่องการรับมอบงานที่ถือว่าเสร็จสิ้น

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

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

เพื่อรับมือกับสถานการณ์เช่นนี้ ในสัญญาการพัฒนาระบบ มักจะมีข้อกำหนดที่เรียกว่า “ข้อกำหนดเรื่องการรับมอบงานที่ถือว่าเสร็จสิ้น” ถูกนำเข้ามา

ความหมายของข้อกำหนดการตรวจรับที่ถือว่าผ่าน

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

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

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

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

https://www.meti.go.jp/policy/it_policy/keiyaku/model_keiyakusyo.pdf

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

ถือว่า・・・
→แม้จริงๆ แล้วไม่ได้เป็นอย่างนั้น แต่ในทางกฎหมายจะถือว่าเป็นเหมือนกับกรณีที่เป็นอย่างนั้น

(ตัวอย่าง) ถ้าในระหว่างทำข้อสอบมีการใช้สมาร์ทโฟน จะถือว่าเป็นการโกง
→ไม่ว่าการใช้สมาร์ทโฟนจริงๆ แล้วจะเป็นการโกงหรือไม่ ก็จะได้รับการดำเนินการเหมือนกับกรณีที่เป็นการโกง

สันนิษฐาน・・・
→ถ้าไม่มีหลักฐานที่ปฏิเสธความเป็นจริง จะถือว่าเป็นความจริง

(ตัวอย่าง) ถ้าในระหว่างทำข้อสอบมีการมองสมาร์ทโฟน จะสันนิษฐานว่าเป็นการโกง
→โดยปกติจะถือว่าเป็นการโกง แต่ถ้าสามารถยืนยันได้ว่าการใช้สมาร์ทโฟนนั้นไม่ได้เป็นการโกง การตัดสินใจนั้นสามารถถูกยกเลิกได้ในภายหลัง (แต่ในที่สอบปกติคงไม่มีการประกาศแบบนี้)

ดังนั้น “สันนิษฐาน” และ “ถือว่า” จะมีความยากในการยกเลิกที่แตกต่างกันอย่างมาก “ไม่ว่าจะผ่านการตรวจรับหรือไม่ ก็จะได้รับการจัดการเหมือนกับกรณีที่ผ่านการตรวจรับ” คือความหมายที่อยู่ในนี้

ตัวอย่างคดีที่เกี่ยวข้องกับข้อกำหนดของการยอมรับสินค้าโดยปริยาย

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

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

คำพิพากษาศาลจังหวัดโตเกียว วันที่ 29 กุมภาพันธ์ พ.ศ. 2555 (Heisei 24)

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

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

ผู้ฟ้อง (ผู้ขาย) อ้างว่า ผู้ถูกฟ้อง (ผู้ใช้) ไม่ได้แจ้งผลการตรวจสอบภายใน 10 วันหลังจากที่สินค้าถูกส่งมอบ ดังนั้น ตามข้อ 9(4) ของสัญญาการพัฒนาซอฟต์แวร์ ผู้ถูกฟ้องถือว่าได้ยอมรับสินค้าแล้ว แต่ การที่ผลลัพธ์ดังกล่าวจะเกิดขึ้น ผู้ฟ้องต้องทำงานร่วมกับผู้ถูกฟ้อง แต่ผู้ฟ้องไม่ได้ทำงานร่วมกับผู้ถูกฟ้องในการตรวจสอบ ดังนั้น ในคดีนี้ แม้ว่าผู้ถูกฟ้องจะไม่ได้แจ้งผลการตรวจสอบภายใน 10 วันหลังจากที่สินค้าถูกส่งมอบ แต่ตามข้อ 9(4) ของสัญญาการพัฒนาซอฟต์แวร์ ผู้ถูกฟ้องไม่ถือว่าได้ยอมรับซอฟต์แวร์นี้

คำพิพากษาศาลจังหวัดโตเกียว วันที่ 23 มิถุนายน พ.ศ. 2553 (Heisei 16)

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

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

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

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

https://monolith.law/corporate/the-minutes-in-system-development[ja]

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

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

https://monolith.law/corporate/project-management-duties[ja]

รูปแบบการค้นพบข้อบกพร่องในขั้นตอนการตรวจรับ

อย่างไรก็ตาม ในขั้นตอนการตรวจรับ อาจจะพบข้อบกพร่องของระบบ (ในทางกฎหมายญี่ปุ่น มักใช้คำว่า “ข้อบกพร่อง” หรือ “瑕疵”) ในกรณีนี้ ปัญหาทางกฎหมายที่เกิดขึ้น โปรดอ่านรายละเอียดในบทความด้านล่างนี้

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

สรุป

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

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