Liệu có thể tăng thêm số tiền ước lượng sau khi phát triển hệ thống không?

Công việc phát triển hệ thống, vì cả hai bên đặt hàng và nhận đơn đều liên quan đến nhiều người, việc tiến hành dự án một cách đồng bộ không phải là điều dễ dàng. Không cần phải nói rằng, việc lập kế hoạch là một công việc cực kỳ quan trọng, nhưng đồng thời, liệu người đặt hàng có thể tổng hợp thông tin phù hợp và truyền đạt một cách ngắn gọn cho nhà cung cấp hay không, thực tế không phải như vậy. Khi quá trình phát triển tiến triển đến một mức độ nhất định, liệu có thể yêu cầu thay đổi thông số kỹ thuật sau khi công việc hoàn thành, thêm chức năng, và liệu có thể tính phí thêm vào số tiền ước tính ban đầu hay không, đây là điều rất quan trọng đối với bên nhận công việc.

Quyền lợi như vậy được công nhận trong trường hợp nào theo pháp luật? Và số tiền thưởng cho việc phát triển bổ sung, sửa chức năng sẽ được quyết định như thế nào? Trong bài viết này, chúng tôi sẽ sắp xếp các câu hỏi như vậy.

Vậy thì, khi nào mới có thể nói đến việc phát triển thêm và sửa chức năng?

Trong dự án phát triển hệ thống, loại hợp đồng thường được ký khi nhận công việc thường là hợp đồng thầu hoặc hợp đồng ủy quyền. Dù là loại hợp đồng nào, những việc cần làm (nghĩa vụ) và phần thưởng đi kèm (quyền lợi) sẽ được ghi rõ trong hợp đồng. Do đó, nếu có công việc không nằm trong phạm vi công việc ban đầu được thêm vào sau, có thể coi đó là việc phát triển thêm và sửa chức năng. Ngược lại, nếu công việc đó nằm trong phạm vi công việc ban đầu, nó sẽ được xem xét như là một phần của hợp đồng ban đầu.

Chúng tôi đã giải thích chi tiết về sự khác biệt giữa hợp đồng thầu và hợp đồng ủy quyền trong một bài viết khác.

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

Tuy nhiên, nếu bạn nói rằng mọi thứ, kể cả việc điều chỉnh nhỏ nhất trên màn hình, cũng cần được xác định trước trong thông số kỹ thuật, và tất cả chúng đều được coi là phát triển thêm, điều đó có thể cản trở đáng kể việc giao dịch một cách trơn tru. Do đó, việc đưa ra quyết định chung không phải lúc nào cũng dễ dàng khi xem xét đến những cuộc thảo luận chi tiết về thông số kỹ thuật. Tuy nhiên, nếu đưa ra một hướng dẫn chung,

• Khi thông số kỹ thuật đã được xác định, bạn được yêu cầu thêm chức năng
• Khi việc triển khai chương trình đã hoàn tất, bạn được yêu cầu sửa đổi nó

Trong những trường hợp như vậy, có thể nói rằng lập luận của bạn có khả năng được chấp nhận theo luật pháp.

Vụ kiện tranh chấp về việc có thể coi là phát triển thêm hoặc sửa chữa chức năng hay không

Ví dụ khẳng định: Trường hợp thay đổi yêu cầu thiết kế cơ bản sau khi đã thỏa thuận

Dưới đây là một ví dụ về việc thay đổi yêu cầu sau khi đã thỏa thuận.

Phát triển phần mềm bao gồm các bước: ① Xác định yêu cầu, ② Thiết kế bên ngoài, ③ Thiết kế bên trong, ④ Tạo chương trình nguồn (thiết kế chương trình, mã hóa), ⑤ Các loại kiểm thử (kiểm thử đơn vị, kiểm thử kết hợp, kiểm thử hệ thống). Yêu cầu ban đầu được thực hiện thông qua công việc từ thiết kế bên trong trở đi, và điều này được hiểu là phạm vi công việc liên quan đến quyền yêu cầu phí dựa trên hợp đồng phát triển được ủy thác này. Yêu cầu thay đổi được hiểu là đề nghị hợp đồng ủy thác công việc mới vượt quá phạm vi công việc dựa trên hợp đồng ban đầu của người ủy thác, và nếu người nhận ủy thác không đưa ra số tiền phí công việc bổ sung và hoàn thành công việc liên quan đến ủy thác bổ sung mà không có sự đồng ý về số tiền phí bổ sung, thì được hiểu là hợp đồng thầu mới đã được thành lập mà không có quy định về số tiền phí giữa người ủy thác và người nhận ủy thác, và nghĩa vụ thanh toán phí phát triển bổ sung hợp lý phát sinh.

Phán quyết ngày 29 tháng 8 năm 2002 (năm 2002 theo lịch Gregory) của Tòa án quận Osaka

Việc nắm vững các từ khóa như “mối quan hệ giá cả”, “hợp đồng mới” sẽ là chìa khóa để hiểu sâu hơn về phán quyết này.

Ngoài ra, trong phán quyết trên, một điểm rất thú vị khác cũng được chỉ ra. Đó là việc điều chỉnh chi tiết nhỏ như vị trí của nút hoặc kiểu chữ không được coi là thay đổi yêu cầu. Đoạn liên quan như sau:

Tuy nhiên, trong phát triển phần mềm, do tính chất của nó, chi tiết như kiểu chữ hiển thị trên màn hình hoặc vị trí của nút không được quyết định ở giai đoạn thiết kế bên ngoài, và thông thường, sau khi xác nhận yêu cầu, một số chỉnh sửa sẽ được thực hiện thông qua cuộc họp giữa các bên liên quan. Do đó, việc yêu cầu chi tiết hóa yêu cầu như vậy cũng không hợp lý để coi là thay đổi yêu cầu.

Phán quyết ngày 29 tháng 8 năm 2002 (năm 2002 theo lịch Gregory) của Tòa án quận Osaka

Trong phán quyết, từ “chi tiết hóa yêu cầu” rất thú vị đã được sử dụng.

• Trường hợp đã quyết định từ trước nhưng sau đó bị thay đổi
• Trường hợp có thể quyết định trong quá trình làm việc nhưng đã tiếp tục mà không quyết định

Có thể nói rằng đây là một cách suy nghĩ cho rằng việc xử lý pháp lý nên khác nhau trong hai trường hợp trên.

Các ví dụ khẳng định khác

Ngoài ra, trong các vụ kiện được công nhận là phát triển thêm hoặc sửa chữa chức năng, có:

• Vụ kiện số lượng chương trình được giao tăng gấp đôi so với kế hoạch ban đầu (Phán quyết ngày 22 tháng 4 năm 2009 (năm 2009 theo lịch Gregory) của Tòa án quận Tokyo)
• Vụ kiện thời gian làm việc kéo dài gấp ba lần (Phán quyết ngày 22 tháng 1 năm 2010 (năm 2010 theo lịch Gregory) của Tòa án quận Tokyo)

Khi tổng hợp như vậy, có thể thấy rằng việc kéo dài thời gian làm việc cũng được coi là phát triển thêm theo nghĩa rộng và được nhận một số bảo vệ pháp lý.

“Thỏa thuận về phát triển thêm hoặc tăng phí” và “Thành lập hợp đồng ban đầu” là hai vấn đề khác nhau

Một điểm quan trọng liên quan đến những vấn đề này là:

1. “Liệu hợp đồng phát triển hệ thống (hợp đồng ban đầu) giữa hai công ty đã chính thức được thành lập hay chưa”
2. “Sau khi hợp đồng phát triển hệ thống đã chính thức được thành lập, liệu hợp đồng liên quan đến phát triển thêm đã được thành lập thêm hay không”

Thì tiêu chí đánh giá của tòa án sẽ khác nhau. Nói một cách ngắn gọn, tòa án:

• Có xu hướng nghiêm khắc với 1 (trong trường hợp không có hợp đồng, tòa án ít khi công nhận việc thành lập hợp đồng)
• Có xu hướng linh hoạt với 2 (ngay cả khi không có hợp đồng phát triển thêm, tòa án vẫn sẽ linh hoạt công nhận việc tăng phí)

Đối với 1, chúng tôi đã giải thích chi tiết trong một bài viết khác.

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

Ví dụ phủ định: Trường hợp được xem xét như là bao gồm trong nội dung ủy thác tương tự theo pháp luật

Tuy nhiên, cũng có những trường hợp mà việc tăng phí không được công nhận. Trong vụ kiện được trích dẫn dưới đây, việc liệu có thể tăng phí hay không đã được tranh chấp do nội dung công việc đã thay đổi sau khi đã ký kết hợp đồng phát triển hệ thống.

Vấn đề chính trong vụ này là (1) nội dung công việc mà nguyên đơn đã nhận ủy thác trong hợp đồng này là gì, (2) liệu có sự thỏa thuận giữa nguyên đơn và bị đơn về việc mở rộng quy mô và tăng phí cho công việc nhận ủy thác này hay không, (trích dẫn), và những điểm như vậy. (trích dẫn)

Đầu tiên, hợp đồng này là hợp đồng thầu, trong đó nguyên đơn đã thỏa thuận về việc sử dụng số tiền hợp đồng làm giá cố định cho công việc nhận ủy thác (thầu), và số bước, đơn giá, v.v. chỉ là tài liệu nội bộ được sử dụng bởi nguyên đơn khi tính toán số tiền hợp đồng, và việc tăng số bước, v.v. không liên quan gì đến số tiền hợp đồng. (trích dẫn)

Theo như đã xác nhận, công việc nhận ủy thác của nguyên đơn đã được thay đổi vào ngày 25 tháng 2 năm 1987, và chỉ giới hạn ở quản lý hệ thống, tính toán chi phí công trình thầu và một phần của tiện ích, phần còn lại do bị đơn chịu trách nhiệm. Tuy nhiên, công việc của nguyên đơn sau khi thay đổi vẫn nằm trong phạm vi công việc phát triển theo hợp đồng ban đầu, và phí cho công việc này đã được bao gồm trong số tiền hợp đồng đã được thỏa thuận làm giá cố định khi ký kết hợp đồng.

Phán quyết ngày 12 tháng 6 năm 1995 (năm 1995 theo lịch Gregory) của Tòa án quận Tokyo

Trong phán quyết này, ngay cả khi nội dung công việc được ủy thác cho nhà cung cấp đã thay đổi, nếu nội dung phát triển vẫn nằm trong phạm vi nội dung hợp đồng ban đầu, thì nó sẽ được xem là nằm trong số tiền phí đã được thỏa thuận ban đầu.

Cuối cùng, việc xem xét liệu công việc nào không nằm trong số tiền phí đã thỏa thuận ban đầu sẽ được thực hiện dựa trên việc xem xét liệu số tiền phí đã được quyết định dựa trên việc thực hiện công việc nào.

Và việc xác định số tiền phí đã được quyết định dựa trên việc thực hiện công việc nào không chỉ dựa vào hợp đồng mà còn dựa vào biên bản họp và các bằng chứng khác. Chúng tôi đã giải thích chi tiết về tầm quan trọng của biên bản họp trong bài viết dưới đây.

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

Cách xác định mức thù lao cho việc phát triển bổ sung và sửa chức năng

Trong lĩnh vực phát triển hệ thống, việc thay đổi yêu cầu đã được xác định từ trước không phải là hiếm. Việc chuẩn bị hợp đồng bằng văn bản mới mỗi khi có sự thay đổi như vậy và tiến hành các thủ tục hợp đồng không phải lúc nào cũng thực tế. Trong trường hợp dự án bị đình trệ mà không thể tiến hành các thủ tục như vậy, làm thế nào để xác định mức thù lao cho các vấn đề cần được bổ sung hoặc sửa đổi?

Điều khoản cần tham khảo trong trường hợp này là Điều 512 của Luật Thương mại Nhật Bản (được tô đậm bởi tác giả).

Điều 512 Luật Thương mại Nhật Bản: Khi một doanh nhân hành động vì lợi ích của người khác trong phạm vi kinh doanh của mình, họ có thể yêu cầu một khoản thù lao hợp lý.

Vấn đề ở đây là “khoản thù lao hợp lý” trong điều khoản này sẽ là bao nhiêu trong tình huống cụ thể. Xem xét các ví dụ vụ án trong quá khứ, có vẻ như phương pháp tiếp cận là phải chịu chi phí tương ứng với số giờ làm việc, số lượng công việc hoặc thời gian. Điều này có thể do việc phát triển hệ thống là một loại dịch vụ và chi phí gốc chủ yếu là chi phí nhân công.

Do đó, mặc dù “khoản thù lao hợp lý” theo Luật Thương mại có độ trừu tượng, việc ước lượng mức thù lao bổ sung trong ngữ cảnh này không đòi hỏi phải thực hiện các phép tính phức tạp. Hãy xem một số ví dụ vụ án dưới đây.

Trường hợp 1: Ví dụ về việc công nhận thù lao bổ sung tương ứng với số giờ làm việc tăng

Số giờ làm việc phát triển dựa trên việc thay đổi yêu cầu trong trường hợp này là tổng số giờ làm việc nêu trên, tức là 257,5 người/ngày, là hợp lý. Nếu chúng ta chuyển đổi số này thành chi phí phát triển hàng ngày cho mỗi người là 32.500 yên (trong Hợp đồng 3, đơn giá là 650.000 yên/người/tháng, nếu số ngày làm việc trong một tháng là 20 ngày, thì chi phí phát triển hàng ngày cho mỗi người sẽ là 32.500 yên.), thì chi phí phát triển bổ sung dựa trên yêu cầu thay đổi yêu cầu trong trường hợp này sẽ là 8.368.750 yên.

Phán quyết ngày 29 tháng 8 năm 2002 (2002) của Tòa án quận Osaka

“Mỗi người/mỗi ngày” là từ khóa. Nó cho thấy việc sử dụng số giờ làm việc làm cơ sở để tính toán thù lao bổ sung.

Trường hợp 2: Ví dụ về việc công nhận thù lao bổ sung tương ứng với số lượng chương trình

Khi xem xét mức thù lao hợp lý bao gồm phần bổ sung trong trường hợp này, phần lớn chi phí gốc của việc phát triển hệ thống máy tính là chi phí nhân công của kỹ sư, và chi phí nhân công này thường tương ứng với số lượng chương trình được tạo ra, vì vậy, chúng tôi xác định mức thù lao hợp lý là 46.725.728 yên (23.250.000 ÷ 206 × 414 = 46.725.728), là số tiền thu được khi chia số tiền hợp đồng ban đầu là 23.250.000 yên cho số lượng chương trình hoàn thành đến lần kiểm tra thứ hai là 206 và nhân số tiền đơn giá cho mỗi chương trình với số lượng chương trình đã qua lần kiểm tra thứ ba là 414.

Phán quyết ngày 22 tháng 4 năm 2005 (2005) của Tòa án quận Tokyo

Có rất nhiều số liệu, nhưng nếu bạn đọc một cách bình tĩnh, bạn sẽ thấy rằng không có phép tính phức tạp nào được thực hiện. Dựa trên nội dung hợp đồng ban đầu, họ chỉ đơn giản là xác nhận “đơn giá cho mỗi chương trình là bao nhiêu” và thực hiện phép nhân đơn giản là “đơn giá × số lượng”.

Trường hợp 3: Ví dụ về việc công nhận thù lao bổ sung tương ứng với độ dài thời gian

Trong Hợp đồng 3, mức thù lao cho công việc của nguyên đơn từ tháng 1 đến tháng 3 năm 2005 trong vòng 3 tháng được xác định là 60 triệu yên, trong khi công việc từ tháng 4 trở đi bao gồm công việc được thực hiện miễn phí, nhưng giống như năm trước, số lượng công việc tăng lên sau tháng 3 so với thời gian trước đó do bắt đầu học kỳ mới và hệ thống đăng ký học phần, v.v., được hoạt động từ tháng 4 trở đi. Dựa trên những điều này, mức thù lao cho công việc trong vòng 3 tháng đã được xác định là 60 triệu yên, và mức thù lao cho công việc từ tháng 4 đến tháng 9 năm 2005 của nguyên đơn là hợp lý nếu xác định là 120 triệu yên.

Phán quyết ngày 22 tháng 1 năm 2010 (2010) của Tòa án quận Tokyo

Phán quyết trên cho thấy việc tính toán thù lao bổ sung cho thời gian kéo dài dựa trên phép tính tương ứng đơn giản.

Tóm tắt

Như đã trình bày ở trên thông qua một số ví dụ vụ án, chúng ta có thể nhận thấy một số quy luật và điểm chung về cách xử lý pháp lý đối với khoản thưởng thêm cho công việc của lập trình viên và kỹ sư. Cụ thể, theo nguyên tắc, chúng ta có thể thấy rằng có xu hướng tính toán một cách đơn giản dựa trên các chỉ số có tính khách quan cao như số giờ làm việc, số lượng công việc hình thức (như chương trình đã giao), thời gian và thời hạn làm việc.

Nếu xem xét từ góc độ việc thất bại trong việc ước lượng chính xác số giờ làm việc hoặc thủ tục hóa một cách chính xác, dẫn đến việc phát sinh các công việc phát triển bổ sung hoặc sửa chữa chức năng, việc nhận thêm tiền thưởng chỉ dựa trên số lượng người làm, số lượng công việc hình thức hoặc thời gian làm việc có thể không có gì đặc biệt. Tuy nhiên, nếu nhìn từ góc độ của người nhận thầu, ngay cả khi họ cố gắng ưu tiên lợi ích của khách hàng trong việc thực hiện công việc, việc những quyền lợi này có khả năng được công nhận theo pháp luật có thể có ý nghĩa như một vấn đề quản lý khủng hoảng.