สัญญาการพัฒนาระบบสามารถเป็นไปได้หรือไม่ ถ้าไม่มีเอกสารสัญญา

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

ที่นี่เราจะอธิบายเกี่ยวกับการทำสัญญาการพัฒนาระบบ และโครงสร้างทางกฎหมายในการเรียกเก็บเงินในกรณีที่ไม่ยอมรับการทำสัญญา

การทำสัญญา

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

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

การทำสัญญาการพัฒนาระบบ

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

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

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

อย่างไรก็ตาม สัญญาสามารถทำขึ้นได้ด้วยการสัญญาด้วยปากเท่านั้น ไม่จำเป็นต้องมีสัญญาเป็นลายลักษณ์อักษร

การเรียกเก็บเงินในกรณีที่สัญญาการพัฒนาระบบถูกยกเลิกหลังจากที่สัญญาเป็นผลบังคับใช้

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

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

นอกจากนี้ หากสัญญาแทนฝ่ายที่รับมอบหมายถูกทำขึ้น ผู้รับมอบหมายสามารถเรียกเก็บค่าตอบแทนตามสัดส่วนการปฏิบัติงาน (ตามมาตรา 648 ข้อ 3 ของประมวลกฎหมายแพ่งที่ได้รับการแก้ไข) ดังนั้น ผู้ขายสามารถเรียกเก็บค่าตอบแทนสำหรับงานที่ได้ทำแล้ว

ความสำเร็จหรือความล้มเหลวของสัญญาการพัฒนาระบบ

ความเฉพาะเจาะจงของระบบ

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

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

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

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

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

https://monolith.law/corporate/engineer-joint-enterprise-contract[ja]

ผู้ขายนำใบเสนอราคาและเอกสารข้อกำหนดเป็นต้นมาเสนอ และผู้ใช้งานอนุมัติและสั่งซื้อ

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

ตามตัวอย่างคดี (คำพิพากษาศาลชั้นต้น Nagoya วันที่ 28 มกราคม ปี Heisei 16 (2004)) ในเรื่องของการทำสัญญาเพื่อพัฒนาระบบ ได้กล่าวว่า:

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

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

เราจะเพิ่มเติมคำอธิบายเกี่ยวกับการทำสัญญาตามที่ได้กล่าวในตัวอย่างคดี โดยพิจารณาตัวอย่างคดีอื่น ๆ ด้วย

หลังจากการต่อรองเกี่ยวกับรายละเอียดของระบบระหว่างผู้ขายและผู้ใช้

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

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

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

เมื่อมีการนำเสนอเอกสารที่ระบุลักษณะและใบเสนอราคาจากผู้ขาย และผู้ใช้ได้รับการอนุมัติและสั่งซื้อ

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

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

https://monolith.law/corporate/increase-of-estimate[ja]

ข้อตกลงการคำนวณสุทธิ

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

การสร้างโครงสร้างทางกฎหมายเพื่อเรียกร้องเงินในกรณีที่ไม่ยอมรับการทำสัญญา

ความผิดทางกฎหมายในการทำสัญญา

เมื่อเริ่มต้นการเจรจาเพื่อทำสัญญา, ทั้งสองฝ่ายจะต้องรับผิดชอบตามหลักศีลธรรมที่ต้องพยายามไม่ทำให้เกิดความเสียหายต่อทรัพย์สินของฝ่ายตรงข้าม (มาตรา 1 ข้อ 2 ของ “Japanese Civil Code”). หากไม่สามารถทำสัญญาได้, ฝ่ายตรงข้ามสามารถยื่นคำร้องขอค่าเสียหายหากมีสถานการณ์ที่ทำให้คาดหวังว่าสัญญาจะสมบูรณ์แน่นอนและมีความผิด. นี่เรียกว่าความผิดทางกฎหมายในการทำสัญญา.

ขอแนะนำรายละเอียดของกรณีที่ศาลยอมรับความผิดทางกฎหมายในการทำสัญญา.

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

ในทางกลับกัน, มีกรณีที่ศาลไม่ยอมรับความผิดทางกฎหมายในการทำสัญญา เช่น การเปิดเผยความเป็นไปได้ในการเลือกบริษัทอื่นหรือเงื่อนไขในการทำสัญญา.

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

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

มาตรา 512 ของกฎหมายการค้าญี่ปุ่น (Japanese Commercial Code)

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

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

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

สรุป

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

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

ในกรณีที่ต้องเริ่มงานก่อนที่จะทำสัญญา

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

สรุปแล้ว ควรมีการคิดค้นในทางนี้