Là những điểm cần kiểm tra nào trong hợp đồng phát triển hệ thống theo hình thức nhận thầu?

Bộ Kinh tế, Thương mại và Công nghiệp Nhật Bản (Japanese Ministry of Economy, Trade and Industry) đã đưa ra các điều khoản mẫu trong hợp đồng phát triển hệ thống IT trong “Hướng dẫn về việc cải thiện độ tin cậy của hệ thống thông tin” (Japanese Guidelines on Improving the Reliability of Information Systems). Do sự phổ biến của Internet và các yếu tố khác, tác động xã hội của việc dừng hoạt động hoặc giảm chức năng do sự cố hệ thống thông tin đang ngày càng trở nên nghiêm trọng. Trong khi việc cải thiện độ tin cậy và an toàn của hệ thống đang trở thành một vấn đề cấp bách, loại hợp đồng phát triển hệ thống IT thường có nội dung giao dịch mơ hồ. Do đó, các điều khoản này nhằm mục đích làm rõ và phân chia rõ ràng các vai trò và mối quan hệ trách nhiệm. Trong bài viết này, chúng tôi sẽ giải thích các điểm cần kiểm tra trong hợp đồng khi ký kết hợp đồng dạng nhận thầu cho công việc phát triển hệ thống IT, dựa trên các điều khoản của hợp đồng mẫu của Bộ Kinh tế, Thương mại và Công nghiệp Nhật Bản.

Phát triển hệ thống và hợp đồng thầu

Hợp đồng thầu là gì?

Hợp đồng thầu được quy định trong luật dân sự Nhật Bản như sau:

Điều 632
Hợp đồng thầu có hiệu lực khi một bên cam kết hoàn thành một công việc nhất định, và bên kia cam kết trả tiền cho kết quả công việc đó.

Trong hợp đồng thầu, yêu cầu là “cam kết hoàn thành công việc”. Ví dụ, nếu mục tiêu của hợp đồng là xây dựng một hệ thống cố định trước ngày hết hạn, nghĩa vụ của bên nhà cung cấp là “hoàn thành hệ thống trước ngày hết hạn”. Nếu không thể hoàn thành hệ thống trước ngày hết hạn đã cam kết, có thể phải chịu trách nhiệm vì không thực hiện nghĩa vụ đúng hạn. Tuy nhiên, nếu sau khi hoàn thành và giao hệ thống trước ngày hết hạn mà phát hiện ra lỗi, vì nghĩa vụ của bên nhà cung cấp đã được thực hiện, vấn đề về việc không thực hiện nghĩa vụ không còn, và từ đó trở đi sẽ là vấn đề về trách nhiệm bảo đảm khuyết điểm. Trong phát triển hệ thống, chúng tôi đã giải thích chi tiết về khi nào “hoàn thành công việc” được công nhận trong bài viết dưới đây.

Sự khác biệt so với hợp đồng ủy quyền

Trong hợp đồng thầu, nhà cung cấp có nghĩa vụ hoàn thành công việc, vì vậy, nếu có lỗi trong sản phẩm đã giao, họ sẽ phải chịu trách nhiệm bảo đảm khuyết điểm. Ngược lại, trong hợp đồng ủy quyền, không có nghĩa vụ hoàn thành công việc, vì vậy, không phải chịu trách nhiệm bảo đảm khuyết điểm như trong hợp đồng thầu. Tuy nhiên, trong quá trình xử lý công việc, nếu có thể công nhận nghĩa vụ quản lý tốt, có thể phải chịu trách nhiệm không thực hiện nghĩa vụ như bồi thường thiệt hại. Chúng tôi đã giải thích chi tiết về trách nhiệm nào có thể trở thành vấn đề trong hợp đồng phát triển hệ thống trong bài viết dưới đây.

Mẫu điều khoản và điểm kiểm tra cho hợp đồng thầu

Hỗ trợ tạo định nghĩa yêu cầu

Định nghĩa yêu cầu là công việc tổng hợp các yêu cầu kỹ thuật của hệ thống mà người dùng muốn xây dựng. Trong quá trình định nghĩa yêu cầu, chúng ta sẽ xem xét hướng đi của việc xây dựng hệ thống và quyết định xây dựng hệ thống như thế nào. Do không thể tưởng tượng được cụ thể sản phẩm cuối cùng, hợp đồng mẫu của Bộ Kinh tế, Thương mại và Công nghiệp Nhật Bản (Japanese Ministry of Economy, Trade and Industry) quy định nó như một loại hợp đồng ủy quyền bán. Chi tiết được giải thích trong bài viết dưới đây.

Công việc tạo tài liệu thiết kế bên ngoài

(Thực hiện công việc tạo tài liệu thiết kế bên ngoài)
Điều ○: Bên B, sau khi ký kết hợp đồng cá nhân quy định tại Điều ○, sẽ thực hiện công việc tạo tài liệu thiết kế bên ngoài cho phần mềm này như một phần của công việc này, dựa trên tài liệu định nghĩa yêu cầu đã được xác định theo quy định của Điều ○.

2. Khi thực hiện công việc tạo tài liệu thiết kế bên ngoài, Bên B có thể yêu cầu sự hợp tác cần thiết từ Bên A, và Bên A sẽ phản hồi kịp thời khi được Bên B yêu cầu hợp tác.

Việc tạo tài liệu thiết kế bên ngoài là công việc xác định việc sử dụng các phần liên quan đến giao diện như màn hình, biểu mẫu, v.v. Theo nguyên tắc, tất cả thông tin mà nhà cung cấp có thể phát triển chương trình dựa trên đó cần phải được ghi rõ trong tài liệu thiết kế bên ngoài. Tài liệu thiết kế bên ngoài bao gồm nội dung chi tiết hóa việc sử dụng mẫu, nhưng người có thể thay đổi yêu cầu đặc tả là người dùng, người quyết định nội dung công việc. Tuy nhiên, nếu tài liệu định nghĩa yêu cầu, kết quả của giai đoạn trước công việc tạo tài liệu thiết kế bên ngoài, có thể xác định rõ ràng nhu cầu của người dùng, và nội dung công việc mà nhà cung cấp hoàn thành rõ ràng, thì có thể ký kết hợp đồng với nhà cung cấp làm chủ thể trong việc tạo tài liệu thiết kế bên ngoài dưới hình thức gói thầu.

Điều khoản thứ nhất quy định rằng, do dự án này là dự án theo hình thức nhận thầu, nhà cung cấp (vendor) là chủ thể chính trong việc thực hiện công việc. Tuy nhiên, ngay cả khi là hợp đồng theo hình thức nhận thầu, việc thiết kế bên ngoài có liên quan lớn đến việc xác định nội dung công việc của người dùng, do đó, sự tham gia tích cực của người dùng là điều cần thiết. Do đó, điều khoản thứ hai quy định rằng, nhà cung cấp có thể yêu cầu sự hợp tác cần thiết từ người dùng trong việc xem xét và quyết định thông số kỹ thuật hệ thống, và người dùng phải đáp ứng yêu cầu này một cách kịp thời, làm rõ rằng việc xem xét thông số kỹ thuật hệ thống là công việc chung giữa nhà cung cấp và người dùng.

(Ký kết hợp đồng riêng liên quan đến công việc tạo tài liệu thiết kế bên ngoài)
Điều thứ ○: Bên A và Bên B sẽ thảo luận và quyết định các điều kiện giao dịch được ghi trong Điều thứ ○, Điểm thứ ○ liên quan đến công việc tạo tài liệu thiết kế bên ngoài, và ký kết hợp đồng riêng cho công việc này.

Về phạm vi công việc tạo tài liệu thiết kế bên ngoài, chúng tôi đã quy định rằng sẽ thỏa thuận trong hợp đồng riêng lẻ, tuân theo các điều kiện giao dịch đã quy định trong điều khoản trước đó.

(Hội thảo thảo luận thiết kế bên ngoài)
Điều ○: Bên B, để làm rõ hoặc xác nhận nội dung cần thiết cho việc tạo tài liệu thiết kế bên ngoài, sẽ tổ chức Hội thảo thảo luận thiết kế bên ngoài (gọi tắt là “Hội thảo thảo luận thiết kế bên ngoài” trong phần này) với tần suất được coi là cần thiết, và Bên A sẽ tham gia vào đó.

2. Khi A cho rằng cần thiết để tạo ra tài liệu thiết kế bên ngoài, A có thể tổ chức cuộc họp thảo luận thiết kế bên ngoài, và B sẽ tham gia vào cuộc họp này.

3. Trong trường hợp A muốn thay đổi nội dung của tài liệu định nghĩa yêu cầu thông qua việc thảo luận tại Hội nghị Thảo luận Thiết kế Bên ngoài và cần phải thay đổi điều kiện của hợp đồng cá nhân như thời gian làm việc, phí ủy thác, v.v., điều này sẽ được thực hiện theo quy trình của Điều 33 (Thay đổi nội dung Hợp đồng này và Hợp đồng cá nhân).

Để tạo tài liệu thiết kế bên ngoài quyết định giao diện như màn hình, biểu mẫu, việc hợp tác giữa người dùng và nhà cung cấp là điều bắt buộc. Do quy trình này được thực hiện theo hình thức nhận thầu, điều khoản thứ nhất quy định rằng nhà cung cấp sẽ tổ chức cuộc họp thảo luận, và người dùng sẽ tham gia vào cuộc họp này. Việc làm rõ hoặc xác nhận nội dung cần thiết để tạo tài liệu thiết kế bên ngoài sẽ được thực hiện tại cuộc họp thảo luận thiết kế bên ngoài, và cả nhà cung cấp và người dùng sẽ bị ràng buộc bởi kết quả thảo luận tại cuộc họp.

Điều khoản thứ 2 quy định rằng, khi cần thiết cho việc thực hiện công việc tạo tài liệu thiết kế bên ngoài, người dùng cũng có thể tổ chức hội thảo thảo luận về thiết kế bên ngoài.
Điều khoản thứ 3 quy định rằng, nếu người dùng thay đổi nội dung của tài liệu định nghĩa yêu cầu thông qua thảo luận, vì có khả năng ảnh hưởng đến thời gian làm việc, phí ủy thác, v.v. được quy định trong hợp đồng riêng lẻ, họ phải tuân theo phương pháp thay đổi nội dung của hợp đồng này và hợp đồng riêng lẻ được quy định trong điều khoản khác.

(Giao nộp Tài liệu thiết kế bên ngoài)
Điều thứ ○: Bên B sẽ giao Tài liệu thiết kế bên ngoài và Đơn yêu cầu kiểm tra Tài liệu thiết kế bên ngoài (cùng với Phiếu giao hàng) cho Bên A trước ngày quy định trong Hợp đồng riêng lẻ.

Do dự án này là dự án theo hình thức đấu thầu, nhà cung cấp sẽ phải cung cấp các sản phẩm như bản thiết kế bên ngoài và các tài liệu tương tự.

(Phê duyệt và xác định Sơ đồ thiết kế bên ngoài)
Điều ○: Bên A sẽ kiểm tra xem Sơ đồ thiết kế bên ngoài có tuân thủ các yêu cầu đã được xác định theo quy định của Điều ○ trong Sổ định nghĩa yêu cầu và các vấn đề quyết định tại Hội nghị thảo luận thiết kế bên ngoài theo Điều ○, cũng như xem có lỗi logic nào không, trong khoảng thời gian quy định trong Hợp đồng riêng lẻ (sau đây gọi là “Thời gian kiểm tra Sơ đồ thiết kế bên ngoài”). Cả hai bên A và B sẽ ký và đóng dấu vào Phiếu phê duyệt Sơ đồ thiết kế bên ngoài như một bằng chứng cho việc phê duyệt sự tuân thủ và không có lỗi logic. Tuy nhiên, nếu kết quả kiểm tra cho thấy Sơ đồ thiết kế bên ngoài không tuân thủ các yêu cầu đã được xác định theo quy định của Điều ○ trong Sổ định nghĩa yêu cầu hoặc có lỗi logic, Bên B sẽ tạo ra phiên bản sửa đổi và trình bày cho Bên A trong thời hạn đã thỏa thuận sau khi thảo luận, và Bên A sẽ tiến hành lại quy trình kiểm tra và phê duyệt nêu trên.

2. Trong trường hợp A không phản đối bằng văn bản với lý do cụ thể trong thời gian kiểm tra tài liệu thiết kế bên ngoài, thì khi kết thúc thời gian kiểm tra tài liệu thiết kế bên ngoài, A sẽ được coi là đã chấp thuận tài liệu thiết kế bên ngoài.

3. Với sự chấp thuận của bên A theo 2 điều trước, Tài liệu thiết kế bên ngoài sẽ được xem là đã được xác định.

Trong quá trình thiết kế bên ngoài, chúng tôi xác định các yêu cầu cần thiết để thực hiện các công việc như việc tạo tài liệu thiết kế bên trong sau này. Tuy nhiên, nếu việc xác định yêu cầu mơ hồ, có thể gây ra vấn đề trong quá trình phát triển sau này. Điều này quy định quy trình mà người dùng kiểm tra tài liệu thiết kế bên ngoài, là tiền đề cho công việc phát triển sau này, và xác định chúng thông qua sự chấp thuận của người dùng.

Điều khoản thứ nhất quy định rằng người dùng phải kiểm tra sự phù hợp với kết quả thảo luận tại cuộc họp thảo luận thiết kế bên ngoài và tài liệu định nghĩa yêu cầu đã được xác định trong các điều khoản khác, cũng như việc không có lỗi logic. Có trường hợp cần phải sửa đổi trong quá trình kiểm tra để phê duyệt tài liệu thiết kế bên ngoài, và điều khoản này cũng quy định về quy trình trong trường hợp này.
Điều khoản thứ hai là quy định cho rằng nếu người dùng không phản hồi trong một khoảng thời gian nhất định, ngay cả khi việc ký tên và đóng dấu phê duyệt chưa hoàn tất, thì sẽ coi như người dùng đã phê duyệt. Việc chuyển vào thiết kế nội bộ khi việc phê duyệt từ người dùng vẫn còn mơ hồ có thể gây ra rắc rối sau này, vì vậy điều khoản này nhằm mục đích ngăn chặn vấn đề này.

Và điều khoản thứ 3 quy định rằng, bản thiết kế bên ngoài sẽ được xác định dựa trên sự chấp thuận của người dùng.

（Trách nhiệm bảo đảm khuyết điểm）
Điều ○ Sau khi xác định điều trước, nếu phát hiện sự không khớp hoặc lỗi logic (được gọi là “khuyết điểm” trong điều này) giữa tài liệu định nghĩa yêu cầu và các vấn đề quyết định tại cuộc họp thảo luận thiết kế bên ngoài theo quy định của Điều ○, bên A có thể yêu cầu bên B sửa chữa khuyết điểm đó, và bên B sẽ sửa chữa khuyết điểm đó. Tuy nhiên, bên B chỉ có trách nhiệm sửa chữa nếu bên A yêu cầu trong vòng ○ tháng sau khi xác định điều trước.

2. Tuy nhiên, nếu lỗi chỉ là nhỏ và việc sửa đổi tài liệu thiết kế bên ngoài đòi hỏi chi phí quá mức, thì Bên B không phải chịu trách nhiệm sửa đổi như quy định trong khoản trước.

3. Quy định của khoản 1 không áp dụng khi lỗi phát sinh do tài liệu hoặc chỉ dẫn mà bên A cung cấp. Tuy nhiên, điều này không áp dụng nếu bên B biết rằng tài liệu hoặc chỉ dẫn đó không phù hợp mà không thông báo.

Điều này quy định về trách nhiệm bảo đảm khiếm khuyết liên quan đến tài liệu thiết kế bên ngoài. Thời gian bảo hành khiếm khuyết sẽ được xác định dựa trên thảo luận giữa các bên, xem xét quy mô của hệ thống thông tin, giá trị và các yếu tố khác, để xác định một khoảng thời gian hợp lý.

Điều khoản thứ nhất, xem xét sự không khớp hoặc lỗi logic trong tài liệu thiết kế bên ngoài và tài liệu định nghĩa yêu cầu cũng như các quyết định tại hội thảo thảo luận thiết kế bên ngoài như là lỗi.

Ở khoản 2, ngay cả khi lỗi là nhỏ, việc yêu cầu nhà cung cấp sửa chữa miễn phí trong trường hợp việc sửa chữa mặt hàng giao hàng đòi hỏi chi phí quá mức là quá đáng, do đó, chúng tôi đang cố gắng bảo vệ nhà cung cấp theo điều 634 khoản 1 của ‘Bộ luật dân sự Nhật Bản’.

Điều khoản thứ 3, tuân theo điều 636 của ‘Bộ luật dân sự Nhật Bản’, quy định rằng nếu lỗi phát sinh từ hướng dẫn hoặc tài liệu cung cấp bởi người dùng, nhà cung cấp sẽ không thoát khỏi trách nhiệm bảo hành nếu họ biết rằng hướng dẫn hoặc tài liệu từ người dùng là không phù hợp mà không chỉ ra.

Tuy nhiên, vì trách nhiệm bảo hành khiếm khuyết là quy định tùy ý, nếu không đặt quy định như vậy, việc xử lý sẽ tuân theo nguyên tắc chung của Luật dân sự Nhật Bản. Trách nhiệm bảo hành khiếm khuyết bị ảnh hưởng lớn bởi sửa đổi Luật dân sự Nhật Bản, được thực thi từ tháng 4 năm 2020 (năm 2020 theo lịch Gregory). Sau khi sửa đổi Luật dân sự Nhật Bản được thực thi, đây sẽ là lĩnh vực có cách xử lý khác so với trước đây. Chi tiết được giải thích trong bài viết dưới đây.

Dịch vụ phát triển phần mềm

Phần sau đây quy định các điều khoản khi nhà cung cấp phần mềm thực hiện dự án theo hình thức nhận thầu.

（Thực hiện công việc phát triển phần mềm）
Điều thứ 〇: Bên B, sau khi ký kết hợp đồng cá nhân quy định tại Điều 25, sẽ thực hiện công việc phát triển phần mềm từ thiết kế nội bộ đến kiểm thử hệ thống, dựa trên tài liệu đặc tả hệ thống đã được xác định theo các mục trước đó trong khuôn khổ công việc này.

2. Khi thực hiện công việc phát triển phần mềm, Bên B có thể yêu cầu sự hợp tác cần thiết từ Bên A, và Bên A sẽ phản hồi kịp thời khi được Bên B yêu cầu hợp tác.

Trong phần sau đây, chúng tôi sẽ quy định về các điều khoản khi nhà cung cấp phần mềm thực hiện phát triển dưới hình thức nhận thầu. Trong quá trình thiết kế nội bộ hệ thống, thông thường đối tượng phát triển và thông số kỹ thuật đã được xác định từ các công việc ở giai đoạn trước, do đó, trong hợp đồng mẫu của Bộ Kinh tế, Thương mại và Công nghiệp Nhật Bản, chúng tôi quy định dưới hình thức nhận thầu.

(Ký kết hợp đồng riêng liên quan đến công việc phát triển phần mềm)
Điều thứ 〇: Bên A và Bên B sẽ thảo luận và quyết định về các điều kiện giao dịch được ghi trong Điều thứ 〇, Điểm thứ 〇 liên quan đến công việc phát triển phần mềm, và sẽ ký kết hợp đồng riêng cho công việc phát triển phần mềm.

Về phạm vi công việc phát triển phần mềm, chúng tôi đã quy định rằng sẽ thỏa thuận trong hợp đồng riêng lẻ theo các điều kiện giao dịch đã định trước.

(Giao hàng)
Điều 〇: Bên B sẽ giao hàng cho Bên A, cùng với Phiếu Yêu Cầu Kiểm Định (kèm Phiếu Giao Hàng), trước ngày quy định trong Hợp Đồng Riêng Lẻ.
2. Bên A, khi nhận được hàng, sẽ tiến hành kiểm định dựa trên Quy Định Kiểm Định trong điều tiếp theo, tuân theo quy định tại Điều 〇 (Kiểm định phần mềm này).
3. Bên B, khi giao hàng, có thể yêu cầu Bên A hỗ trợ nếu cần thiết, và Bên A sẽ phải đáp ứng yêu cầu này một cách nhanh chóng.
4. Rủi ro mất mát, hư hỏng, v.v. của hàng hóa, trước khi giao hàng sẽ do Bên B chịu, sau khi giao hàng sẽ do Bên A chịu.

Do vì dự án này là dự án theo hình thức nhận thầu, nên phần mềm đã hoàn thành và các thành phẩm khác sẽ được giao như là các sản phẩm cần kiểm tra. Điều khoản thứ nhất quy định việc giao các sản phẩm cùng với Phiếu yêu cầu kiểm tra (cũng là Phiếu giao hàng).

Điều khoản thứ 2 quy định về việc thực hiện kiểm tra do người dùng tiến hành.
Điều khoản thứ 3, trong trường hợp cần sự hợp tác của người dùng đối với việc giao hàng tại nơi giao hàng đã quy định trong hợp đồng riêng lẻ (trường hợp giao hàng bằng cách vận chuyển vào văn phòng của người dùng, giao hàng trong tình trạng có thể hoạt động trong môi trường vận hành thực tế của người dùng, v.v.), điều này quy định nghĩa vụ hợp tác của người dùng.
Điều khoản thứ 4 là điều khoản liên quan đến rủi ro mất mát / hủy hoại phát sinh từ hàng hóa được giao, và thời điểm chuyển nhượng rủi ro được phân chia dựa trên việc chuyển giao quyền kiểm soát vật lý.

(Việc kiểm tra phần mềm trong vụ việc này)
Điều thứ 〇 Trong số các mặt hàng giao nhận, đối với phần mềm trong vụ việc này, bên A phải kiểm tra dựa trên bảng đặc tả kiểm tra của điều trước trong khoảng thời gian quy định trong hợp đồng riêng lẻ (sau đây gọi là “thời gian kiểm tra”) và phải kiểm tra xem liệu bảng đặc tả hệ thống và phần mềm trong vụ việc 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 nêu trên, bên A sẽ ký và đóng dấu lên giấy chứng nhận kiểm tra đạt yêu cầu và giao nó cho bên B. Ngoài ra, nếu phần mềm này không đạt kiểm tra nêu trên, bên A sẽ nhanh chóng cung cấp cho bên B một văn bản rõ ràng về lý do cụ thể không đạt và yêu cầu sửa chữa hoặc bổ sung. Khi lý do không đạt được chấp nhận, bên B sẽ sửa chữa miễn phí và giao nó cho bên A trong thời hạn đã thỏa thuận, và bên A sẽ tiến hành lại kiểm tra theo quy định trên trong phạm vi cần thiết.

3. Ngay cả khi không được cấp Giấy chứng nhận kiểm định (Japanese 検査合格書), nếu trong thời gian kiểm định, bên A không phản đối bằng văn bản với lý do cụ thể, thì phần mềm này sẽ được coi là đã vượt qua kiểm định theo quy định của điều này.

4. Việc hoàn thành kiểm tra đạt yêu cầu theo điều này sẽ được coi là việc hoàn tất nghiệm thu phần mềm này.

Do vì dự án này là dự án theo hình thức đấu thầu, điều này quy định về quy trình kiểm tra phần mềm đã được giao trong điều khoản này.

Điều khoản thứ nhất quy định việc kiểm tra phần mềm này trong suốt thời gian kiểm tra dựa trên tài liệu đặc tả kiểm tra, và kiểm tra xem liệu tài liệu đặc tả hệ thống và phần mềm này có phù hợp không.
Điều khoản thứ hai yêu cầu nhà cung cấp phải sửa chữa nếu phát hiện phần mềm này không phù hợp với tài liệu đặc tả hệ thống, và cung cấp phiên bản đã sửa cho người dùng.
Điều khoản thứ ba nhằm ngăn chặn việc kéo dài thời gian kiểm tra do sự thuận tiện của người dùng, bằng cách đưa ra quy định về việc chấp nhận kiểm tra mặc định.
Điều khoản thứ tư rõ ràng nêu rằng việc hoàn thành kiểm tra sẽ được coi là hoàn tất việc kiểm tra phần mềm này.

(Trách nhiệm bảo đảm không có lỗi)
Điều thứ 〇 Sau khi hoàn thành việc kiểm tra theo điều trước, nếu phát hiện sự không khớp giữa sản phẩm giao hàng và tài liệu đặc tả hệ thống (bao gồm cả lỗi. Trong điều này, gọi là “lỗi”.), bên A có thể yêu cầu bên B sửa lỗi đó, và bên B sẽ phải sửa lỗi đó. Tuy nhiên, bên B chỉ có trách nhiệm sửa lỗi nếu bên A yêu cầu trong vòng ○ tháng sau khi hoàn thành việc kiểm tra theo điều trước.
2. Bất chấp điều trên, nếu lỗi là nhỏ và việc sửa chữa sản phẩm giao hàng đòi hỏi chi phí quá mức, bên B không phải chịu trách nhiệm sửa chữa quy định trong điều trên.
3. Quy định của điều 1 không áp dụng khi lỗi phát sinh do tài liệu hoặc chỉ dẫn mà bên A cung cấp. Tuy nhiên, điều này không áp dụng nếu bên B không thông báo mặc dù biết rằng tài liệu hoặc chỉ dẫn đó không phù hợp.

Do vì dự án này là dự án theo hợp đồng, điều này quy định trách nhiệm bảo đảm khi có lỗi liên quan đến sản phẩm giao hàng. Việc xác định ranh giới giữa trách nhiệm vi phạm nợ khi công việc chưa được hoàn thành và trách nhiệm bảo đảm khi có lỗi sau khi công việc đã hoàn thành là khá khó khăn trong thực tế. Có một phán quyết (Tòa án Tokyo, ngày 22 tháng 4 năm Heisei 14 (2002)) cho rằng, đối với phát triển hệ thống, việc xác định hệ thống đã hoàn thành hay chưa nên dựa trên việc công việc đã hoàn thành đến giai đoạn cuối cùng dự kiến trong hợp đồng ban đầu hay chưa. Nếu phát hiện lỗi sau khi hoàn thành giai đoạn cuối cùng dự kiến của phần mềm và sau khi giao hàng và kiểm tra đạt yêu cầu, nguyên tắc là trách nhiệm bảo đảm khi có lỗi sẽ được áp dụng.

Điều khoản thứ nhất xác định ‘sự không khớp nhau giữa hệ thống và bản đặc tả hệ thống’ phát sinh trong quá trình phát triển phần mềm là lỗi. Về những thiếu sót về chức năng phát sinh ở giai đoạn thiết kế bên ngoài, trách nhiệm sẽ được xác định không phải theo điều khoản này mà theo các quy định về trách nhiệm bảo đảm lỗi ở giai đoạn thiết kế bên ngoài. Thời gian bảo hành lỗi sẽ được xác định dựa trên sự thỏa thuận giữa các bên, sau khi xem xét quy mô hệ thống thông tin và giá trị tương ứng, trong một khoảng thời gian được coi là hợp lý.

Ở khoản 2, ngay cả khi lỗi là nhỏ, việc yêu cầu nhà cung cấp sửa chữa miễn phí trong trường hợp việc sửa chữa mặt hàng giao hàng đòi hỏi chi phí quá mức là quá đáng, do đó, chúng tôi đã thiết lập quy định tương tự như điều 634 khoản 1 của Bộ luật Dân sự Nhật Bản.

Điều khoản thứ 3, tương ứng với điều 636 của Bộ luật Dân sự Nhật Bản, quy định rằng nếu lỗi phát sinh từ hướng dẫn hoặc tài liệu cung cấp bởi người dùng, nhà cung cấp không phải chịu trách nhiệm bảo hành. Tuy nhiên, nếu nhà cung cấp biết rằng tài liệu hoặc hướng dẫn từ người dùng không phù hợp mà không chỉ ra, họ không thể trốn tránh trách nhiệm bảo hành.

Trường hợp nào được công nhận là có khiếm khuyết, và nội dung trách nhiệm cụ thể khi được công nhận như vậy, chúng tôi đã giải thích chi tiết trong bài viết dưới đây.

Dịch vụ hỗ trợ chuẩn bị và chuyển đổi phần mềm

Ở giai đoạn tiếp nhận và triển khai hệ thống, người dùng thường là người chủ động thực hiện, do đó, trong hợp đồng mẫu của Bộ Kinh tế, Thương mại và Công nghiệp Nhật Bản (METI), người dùng là chủ thể, và nhà cung cấp (vendor) hỗ trợ theo hình thức đại lý phụ.

Quyết định tính chất của hợp đồng

Để xác định tính chất của hợp đồng, chúng ta cần xem xét toàn bộ hợp đồng, từ mục tiêu của nó, liệu mục tiêu đó có phải là “cung cấp sản phẩm hoàn thiện” hay không, hay nhà cung cấp có “thực hiện công việc một cách hợp lý” hay không. Một chỉ dẫn tổng quát là liệu nội dung của sản phẩm cần hoàn thiện đã được xác định cụ thể đến một mức độ nào đó và dự án đã tiến triển theo hướng đó hay chưa. Về việc chúng ta cần chú ý đến những điểm cụ thể nào, chúng tôi đã giải thích chi tiết trong bài viết dưới đây.