Những tình huống áp dụng điều khoản chấp nhận giả định trong việc kiểm tra chấp nhận phát triển hệ thống

Trong quá trình phát triển hệ thống, vấn đề pháp lý thường xảy ra ở giai đoạn ‘kiểm tra và nghiệm thu’.

‘Kiểm tra và nghiệm thu’ là nghĩa vụ kiểm tra và kiểm định phát sinh ở phía người đặt hàng khi nhà thầu đã giao sản phẩm. Giả sử, nếu sau khi giao hàng mà người đặt hàng không tiến hành ‘kiểm tra và nghiệm thu’, nhà thầu sẽ rơi vào tình trạng pháp lý không ổn định.

Để giải quyết những vấn đề như vậy, hợp đồng thường bao gồm điều khoản ‘nghiệm thu tự động’.

Trong bài viết này, chúng ta sẽ giải thích khi nào ‘nghiệm thu tự động’ được áp dụng, dựa trên các ví dụ thực tế từ các vụ kiện.

Khái niệm “kiểm tra nghiệm thu” trong phát triển hệ thống là gì?

Đầu tiên, “kiểm tra nghiệm thu” trong dự án phát triển hệ thống là việc người dùng, là người đặt hàng, kiểm tra và kiểm tra xem liệu sản phẩm (trong trường hợp này là hệ thống IT) mà nhà cung cấp, là người nhận đơn hàng, đã cung cấp có phù hợp với mục đích đặt hàng hay không.

Nếu nhìn từ góc độ của nhà phát triển, có thể coi đó là “kiểm tra xem liệu sản phẩm đã hoàn thiện hay chưa”, và có thể xem đó là một phần của quy trình kiểm tra.

Công việc phát triển hệ thống IT, do bản chất của nó, có thể dẫn đến sự tự do lớn về phía nhà cung cấp, và có thể xảy ra tình huống khi sản phẩm thực tế và những gì người dùng yêu cầu không khớp nhau.

Nói một cách chung chung, việc vượt qua kiểm tra nghiệm thu có nghĩa là người dùng đã xác nhận rằng sản phẩm phù hợp với những gì họ yêu cầu (hoặc mục đích họ yêu cầu phát triển hệ thống) đã thực sự được cung cấp.

Thậm chí trong cách thức ký kết hợp đồng thực tế, dù có thể xảy ra tình huống khi lỗi trong hệ thống được phát hiện sau đó, nhưng có rất nhiều trường hợp đặt việc vượt qua kiểm tra nghiệm thu là điều kiện để thanh toán tiền thưởng.

Chú ý đến điều khoản chấp nhận tác động

Khi xảy ra rắc rối trong giai đoạn kiểm tra, cả người dùng và nhà cung cấp đều phải đối mặt với tình huống khó khăn.

Ví dụ, nhà cung cấp đã tạo ra sản phẩm và đã trình bày sản phẩm, nhưng nếu người dùng không chấp nhận kiểm tra do tình hình của người phụ trách phía người dùng, thì sẽ ra sao?

Để chuẩn bị cho trường hợp như vậy, trong hợp đồng phát triển hệ thống thường có điều khoản được gọi là “điều khoản chấp nhận tác động”.

Điều khoản chấp nhận tác động là gì?

(Kiểm tra phần mềm này) Điều 28
Với phần mềm này trong các sản phẩm giao hàng, bên A phải kiểm tra dựa trên thông số kỹ thuật kiểm tra của điều trước trong thời gian quy định trong hợp đồng riêng lẻ (dưới đây gọi là “thời gian kiểm tra”) và kiểm tra xem thông số kỹ thuật hệ thống và phần mềm này có phù hợp hay không.

2. Nếu phần mềm này phù hợp với kiểm tra của điều trước, bên A sẽ ký và dấu trên giấy chứng nhận kiểm tra và giao cho bên B. Ngoài ra, nếu phần mềm này không đạt kiểm tra của điều trước, bên A sẽ nhanh chóng giao cho bên B một văn bản chỉ rõ lý do cụ thể không đạt và yêu cầu sửa chữa hoặc bổ sung, và khi lý do không đạt được công nhận, bên B sẽ sửa chữa miễn phí và giao cho bên A trong thời hạn quy định sau khi thảo luận, và bên A sẽ tiến hành kiểm tra quy định trong điều trước trong phạm vi cần thiết.

3. Ngay cả khi giấy chứng nhận kiểm tra không được giao, nếu bên A không phản đối với lý do cụ thể bằng văn bản trong thời gian kiểm tra, phần mềm này sẽ được coi là đã vượt qua kiểm tra quy định trong điều này.

4. Kiểm tra quy định trong điều này sẽ hoàn thành việc kiểm tra phần mềm này.

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

Tuy nhiên, từ góc độ pháp lý, cụm từ “được coi là” trong điều 3 là một điểm đáng chú ý. Khi xem xét từ góc độ thuật ngữ pháp lý, “coi là” và “giả định” thực sự có ý nghĩa hoàn toàn khác nhau.

Coi là…
→ Ngay cả khi thực tế không phải là OO, nó sẽ được xử lý như là OO theo pháp luật

(Ví dụ) Trong quá trình kiểm tra, nếu bạn sử dụng điện thoại thông minh, nó sẽ được “coi là” gian lận
→ Dù việc sử dụng điện thoại thông minh có phải là gian lận hay không, cùng một biện pháp sẽ được áp dụng như trong trường hợp gian lận.

Giả định…
→ Trừ khi có bằng chứng phủ nhận sự thật là OO, OO sẽ được xử lý như là sự thật.

(Ví dụ) Trong quá trình kiểm tra, nếu bạn nhìn vào điện thoại thông minh, nó sẽ được “giả định” là gian lận
→ Nguyên tắc là sẽ được xem là đã gian lận, nhưng nếu bạn có thể chứng minh rằng nó được sử dụng cho mục đích khác gian lận, quyết định đó có thể bị đảo ngược sau cùng. (Tuy nhiên, bạn sẽ không nghe thấy thông báo như vậy tại địa điểm kiểm tra.)

Nói cách khác, “giả định” và “coi là” có ngưỡng để lật ngược hoàn toàn khác nhau. Ý nghĩa “được xử lý như đã vượt qua kiểm tra, bất kể việc đã vượt qua kiểm tra hay không” được bao gồm ở đây.

Các ví dụ vụ án liên quan đến quy định điều khoản chấp nhận tác động

Có những trường hợp trong quá khứ mà quy định điều khoản chấp nhận tác động đã có ý nghĩa quyết định trong việc xét xử. Ví dụ, trong bản án được trích dẫn dưới đây, người dùng đã nêu lên yêu cầu rằng chức năng cần thiết không được triển khai sau khi không chấp nhận kiểm tra trong thời gian quy định và đã trở thành một vụ kiện. Tuy nhiên, tòa án đã quyết định rằng việc giao hàng đã hoàn tất dựa trên quy định điều khoản chấp nhận tác động.

Trong hợp đồng này, công ty Y đã quy định rằng sau khi giao hệ thống này, họ sẽ kiểm tra ngay lập tức và thông báo bằng văn bản về việc kiểm tra trong vòng 10 ngày, và nếu không có thông báo trong thời hạn trên, nó sẽ được coi là đã vượt qua kiểm tra, và không thể công nhận rằng có thông báo về những điểm không phù hợp với kiểm tra trong trường hợp này, nên có thể xác nhận sự thật về việc giao hàng và kiểm tra.

Phán quyết ngày 29 tháng 2 năm 2012 (2012) của Tòa án quận Tokyo

Tuy nhiên, ngược lại, ngay cả khi quy định điều khoản chấp nhận tác động này được đặt ra, cũng có những ví dụ vụ án mà việc áp dụng này đã bị phủ nhận và vi phạm nghĩa vụ của nhà cung cấp đã được công nhận.

Trong trường hợp của bản án được trích dẫn dưới đây, điểm khác biệt so với ví dụ vụ án trước đó là rằng, ngay từ đầu, sự hợp tác của nhà cung cấp là cần thiết để tiến hành kiểm tra, nhưng nhà cung cấp đã bỏ qua sự hợp tác đó.

Nguyên đơn (nhà cung cấp) cho rằng, do bị đơn (người dùng) không thông báo kết quả kiểm tra trong vòng 10 ngày kể từ ngày giao hàng sản phẩm, theo điều 9, khoản 4 của hợp đồng phát triển phần mềm này, sản phẩm được coi là đã được kiểm tra. Tuy nhiên, để có kết quả như vậy, sự hợp tác của nguyên đơn là cần thiết, và nguyên đơn đã không hợp tác với bị đơn để tiến hành kiểm tra như vậy, vì vậy, trong trường hợp này, ngay cả khi bị đơn không thông báo kết quả kiểm tra trong vòng 10 ngày kể từ ngày giao hàng sản phẩm, theo điều 9, khoản 4 của hợp đồng phát triển phần mềm này, bị đơn không được coi là đã kiểm tra phần mềm này.

Phán quyết ngày 23 tháng 6 năm 2004 (2004) của Tòa án quận Tokyo

Điều khoản chấp nhận tác động được cho là có mục đích giải phóng nhà cung cấp khỏi tình trạng không ổn định như “tôi muốn tiến hành kiểm tra sớm nhưng do hoàn cảnh một phía của người dùng, tôi không thể tiến triển và công việc bị trì hoãn” và giữ cho mối quan hệ giữa cả hai bên công bằng.

Vì vậy, nó không thể trở thành một câu chuyện như “sử dụng điều khoản chấp nhận tác động làm lá chắn, cố gắng trì hoãn kiểm tra càng lâu càng tốt và cuối cùng đẩy sản phẩm kém chất lượng vào”.

Khi sản phẩm được “coi là” đã vượt qua kiểm tra, người dùng phải trả tiền cho việc phát triển hệ thống như một giá cả. Tòa án đã nhằm mục đích đưa ra một quyết định công bằng bằng cách xem xét cả tình hình hợp tác của nhà cung cấp trong khi xem xét tính nghiêm trọng như vậy.

Biên bản họp theo tiến độ phát triển hệ thống có thể trở thành bằng chứng quan trọng để hỗ trợ quyết định như vậy. Chi tiết về điều này được giải thích chi tiết trong bài viết dưới đây.

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

Ngoài ra, về nghĩa vụ mà nhà cung cấp phải chịu như một chuyên gia phát triển hệ thống đối với dự án một cách toàn diện, hãy tham khảo bài viết dưới đây.

Ngay cả khi việc kiểm tra nên được thực hiện bởi người dùng theo nguyên tắc, nhà cung cấp cũng nên hợp tác với việc kiểm tra theo nhiều cách như một chuyên gia phát triển hệ thống. Điều này sẽ tự nhiên được chấp nhận khi xem xét nội dung của bài viết dưới đây.

Mô hình phát hiện lỗi trong quá trình kiểm tra

Tuy nhiên, cũng có thể xảy ra tình huống phát hiện ra lỗi hệ thống (trong pháp luật, chúng ta thường sử dụng từ “lỗi” để mô tả) trong quá trình kiểm tra. Đối với vấn đề pháp lý trong trường hợp này, vui lòng tham khảo bài viết chi tiết dưới đây.

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

Tóm tắt

Trong phát triển hệ thống, “kiểm tra nghiệm thu” nguyên tắc là biểu thị sự hoàn thành nhiệm vụ của bên nhà cung cấp, do đó, có thể nói rằng đây là điều rất quan trọng đối với cả bên người dùng và bên nhà cung cấp. Để không gặp phải rắc rối nghiêm trọng tại đây, cả bên đặt hàng và bên nhận đặt hàng đều nên hiểu rõ về “điều khoản nghiệm thu giả định”.

Và, trong trường hợp nghiệm thu không diễn ra suôn sẻ, cả hai bên cần phải thống nhất ý thức về các quy định liên quan đến nghiệm thu từ giai đoạn hợp đồng trước, đặc biệt là việc thực hiện việc điều chỉnh ý thức một cách tỉ mỉ.