Luật sư từng là kỹ sư IT giải thích sự tương đồng giữa việc kiểm tra hợp đồng và debug

Trọng tâm của công việc của “Luật sư tư vấn cho công ty” mà chúng ta thường nói, là việc kiểm tra và chỉnh sửa các hợp đồng mà công ty ký kết hàng ngày với khách hàng và đối tác kinh doanh. Và việc kiểm tra và chỉnh sửa này, không thể thực hiện đầy đủ nếu không phải là “người am hiểu cả về pháp luật và lĩnh vực kinh doanh đó”. Tôi sẽ giải thích lý do tại sao.

Tuy nhiên, có thể khá khó hiểu đối với những người không phải là kỹ sư hoặc không có kinh nghiệm lập trình. Văn phòng luật sư Monolith là một văn phòng luật sư do một luật sư có kinh nghiệm làm kỹ sư IT và quản lý doanh nghiệp đảm nhận vai trò đại diện. Đây là một bài viết giải thích về việc kiểm tra và chỉnh sửa hợp đồng, dành cho các nhà quản lý có kinh nghiệm về kỹ thuật và lập trình, từ góc nhìn của một văn phòng luật sư do một cựu kỹ sư IT và nhà quản lý doanh nghiệp đảm nhận vai trò đại diện.

Và trên cơ sở định vị này, việc kiểm tra và chỉnh sửa hợp đồng giống như công việc “debug” mà chúng ta thường nói.

1. Đầu tiên, “bug” là gì?
2. “Debug” là công việc như thế nào?
3. Hợp đồng quy định thuật toán như thế nào?
4. Việc chỉnh sửa hợp đồng là công việc như thế nào?

Tôi sẽ bắt đầu từ những điều “hiển nhiên” đối với các kỹ sư, và giải thích theo thứ tự trên.

「Bug」 và 「Debug」 là gì?

「Bug」 không phải là “hỏng hóc của máy tính”

Khi nói đến “Bug”, có thể có người tưởng tượng ra hình ảnh máy tính phát ra khói và màn hình hiển thị lỗi khi đang làm việc. Tuy nhiên, máy tính cơ bản chỉ “hoạt động theo lệnh”. Điều này cũng đúng khi xảy ra bug. Nói cách khác, “Bug” là:

• Máy tính vẫn hoạt động theo lệnh
• Nhưng hành vi đó là “hành vi không dự kiến” đối với người sử dụng

Đó là hiện tượng này.

Tại sao “hành vi không dự kiến” lại xảy ra?

Ví dụ, hãy xem xét về bug “đi xuyên qua tường” trong trò chơi hành động kiểu Mario.

Nhảy của Mario là một hàm bậc hai. Gia tốc, vận tốc, tọa độ. Tuy nhiên, nếu nó là một hàm bậc hai, ví dụ, “Y là gì khi X=1.76582?”, bạn có thể chia X thành các phần nhỏ vô hạn, nhưng trong trò chơi điện tử, bạn không thể chia thời gian thành các phần nhỏ vô hạn. Bởi vì màn hình chỉ chuyển đổi 30 lần mỗi giây (ví dụ). Do đó, nói cách khác, Mario đang “dịch chuyển” 30 lần mỗi giây.

Trên cơ sở này, ví dụ, “Khi Mario nhảy lên và gặp tường ở trên, anh ta sẽ bị đẩy lại”, trường hợp này là:

1. Mario đang ở trong không trung một phút trước
2. Phút tiếp theo, tọa độ của Mario nằm trong tường

Đó là trường hợp này.

Trong trường hợp này, “Mario đã va vào tường trên không khi đang nhảy” có thể được xác định. Do đó, nếu viết chương trình theo ngôn ngữ tự nhiên

Nếu tọa độ của Mario nằm trong tường, thực hiện xử lý đẩy lại (※1)

Thì có thể thực hiện xử lý “Khi Mario nhảy lên và gặp tường ở trên, anh ta sẽ bị đẩy lại”.

※1, miễn là viết như trên, nó có vẻ đúng. Và thực tế, “dưới một số điều kiện”, xử lý này là đúng.

Tuy nhiên, nếu bạn suy nghĩ kỹ, có thể có trường hợp như sau (※2).

Trong trường hợp này, không có thời điểm nào “tọa độ của Mario nằm trong tường”, do đó không có xử lý đẩy lại nào được thực hiện, và Mario sẽ đi xuyên qua tường.

Đây là một ví dụ về “bug”. Ngay cả khi “bug đi xuyên qua tường” xảy ra vì lý do này, máy tính không hỏng hóc. Máy tính chỉ thực hiện hành vi được yêu cầu, và việc đánh giá hành vi đó là “không dự kiến” hoặc “bug” là do con người. Và “bug” này xảy ra vì thuật toán không phù hợp.

Xem xét liệu “hành vi không dự kiến” có xảy ra hay không

Tuy nhiên, không rõ liệu “đi xuyên qua tường” có xảy ra trong quá trình chơi game thực tế hay không chỉ bằng cách suy nghĩ trừu tượng như trên. Liệu “đi xuyên qua tường” có thể xảy ra hay không phụ thuộc vào

• Lực nhảy của Mario (vận tốc ban đầu) là bao nhiêu, có vật phẩm tăng lực nhảy hay không
• Độ dày tối thiểu của tường là bao nhiêu

Phụ thuộc vào các điều kiện này. Tùy thuộc vào việc có thể có trường hợp như ※2 hay không. Nếu không có ※2, thì không có vấn đề gì với chương trình ※1.

Công việc “Debug” là gì?

Do đó, để thực hiện “Debug”, nghĩa là, tìm ra bug và sửa chữa nó, bạn cần

1. Đọc hiểu thuật toán của chương trình (※1 ở trên được viết bằng ngôn ngữ tự nhiên, nhưng thực tế, chương trình được viết bằng ngôn ngữ riêng, nên việc đọc hiểu là khó khăn)
2. Xem xét chương trình hoạt động dưới điều kiện nào (tìm hiểu về lực nhảy và độ dày của tường)
3. Xem xét liệu có xảy ra hành vi không dự kiến hay không

Đó là quy trình cần thiết.

Công việc kiểm tra hợp đồng là gì?

Công việc kiểm tra hợp đồng cũng tương tự như vậy. Hợp đồng là một công cụ để quy định các quyền và nghĩa vụ sẽ phát sinh cho các bên liên quan, A và B, trong tương lai dựa trên các sự kiện có thể xảy ra. Vì vậy, nó có thể được coi như một “chương trình điều chỉnh thế giới thực”. Ví dụ:

Nếu tình huống ●● xảy ra, A sẽ bồi thường cho B 1 triệu yên.

Hợp đồng quy định như trên định rõ điều kiện và hậu quả liên quan đến các sự kiện có thể xảy ra trong tương lai.

Và công việc kiểm tra xem có vấn đề gì với “chương trình điều chỉnh thế giới thực” này không, và nếu có vấn đề thì sửa chữa, chắc chắn sẽ giống với việc “gỡ lỗi”.

Không ghi rõ toàn bộ thuật toán trong hợp đồng

Tuy nhiên, có một điểm rất quan trọng trong “hợp đồng” mà những người không chuyên về luật pháp có thể khó hiểu. Đó là hợp đồng chỉ quy định “một phần” của thuật toán điều chỉnh quan hệ giữa các bên liên quan. Nói cách khác, chỉ đọc hợp đồng không đủ để hiểu rõ bạn và đối tác sẽ tuân theo thuật toán nào.

Ví dụ, khi mua CD đã qua sử dụng tại cửa hàng, khách hàng và cửa hàng không ký “hợp đồng mua bán”, nhưng nếu CD mua về có vết xước không thể phát lại trên máy nghe, bạn sẽ muốn phàn nàn với cửa hàng và hy vọng họ sẽ đáp ứng. Điều này không chỉ là câu chuyện ở cấp độ “vì đó là dịch vụ”, mà theo lý thuyết:

1. Ngay cả khi không có hợp đồng, hợp đồng mua bán vẫn được ký kết
2. Luật dân sự (Japanese Civil Code) quy định rằng người bán phải chịu trách nhiệm bảo hành khi bán hàng hóa đã qua sử dụng (gọi là “vật cụ thể”)
3. Do đó, thuật toán do Luật dân sự quy định đang được áp dụng giữa cửa hàng và khách hàng, và cửa hàng phải chịu trách nhiệm bảo hành

Và “hợp đồng” là để ghi đè lên thuật toán mà Luật dân sự và các luật pháp khác định rõ. Ví dụ, nếu có hợp đồng giữa cửa hàng và khách hàng rằng “cửa hàng không chấp nhận khiếu nại về bất kỳ lỗi nào của CD sau khi mua”:

1. Hợp đồng mua bán đã được ký kết
2. Luật dân sự quy định rằng người bán phải chịu trách nhiệm bảo hành cho hợp đồng này
3. Tuy nhiên, theo quy định của hợp đồng, nguyên tắc 2 đã bị ghi đè và cửa hàng không phải chịu trách nhiệm bảo hành

Đó là lý do.

Hợp đồng là thứ ‘ghi đè’ lên các nguyên tắc như Luật dân sự

Điều này cũng đúng trong trường hợp các hợp đồng được ký kết giữa các doanh nghiệp, như phát triển hệ thống. Ví dụ, nếu có hợp đồng phát triển hệ thống theo hình thức nhận thầu giữa hai bên:

1. Rõ ràng là hợp đồng nhận thầu đã được ký kết thông qua việc ký hợp đồng này
2. Trong trường hợp hợp đồng nhận thầu, trách nhiệm bảo đảm khuyết điểm sẽ phát sinh theo quy định của Luật dân sự
3. Nếu có quy định về trách nhiệm bảo đảm khuyết điểm trong hợp đồng, quy định đó sẽ ghi đè lên nguyên tắc số 2 của Luật dân sự. Ví dụ, nếu thiết lập điều khoản trách nhiệm bảo đảm khuyết điểm trong một thời gian dài hơn nguyên tắc của Luật dân sự, quy định về thời gian đó sẽ có hiệu lực

Đó là cấu trúc của nó. Nói cách khác, ngay cả khi không có quy định cụ thể về trách nhiệm bảo đảm khuyết điểm trong hợp đồng, trách nhiệm bảo đảm khuyết điểm vẫn sẽ phát sinh.

Điều này không chỉ giới hạn ở việc nhận thầu hay phát triển hệ thống, mà còn là lý thuyết chung về tất cả các hợp đồng mà doanh nghiệp thực hiện, như chuyển nhượng cổ phiếu, gọi vốn qua nợ (khoản vay tiêu dùng), việc làm, phát hành cổ phiếu, v.v.

Do đó, chỉ đọc hợp đồng không thể nắm bắt được toàn bộ ‘thuật toán’ điều chỉnh mối quan hệ giữa đối tác và công ty của bạn. Để nắm bắt toàn bộ, bạn phải hiểu ‘thuật toán mặc định’ mà Luật dân sự và các luật khác quy định. Hợp đồng chỉ là thứ ‘ghi đè’ lên ‘thuật toán mặc định’ đó.

Nếu không thể dự đoán được sự kiện có thể xảy ra trong tương lai, bạn sẽ không thể “gỡ lỗi”

Ngoài việc hiểu thuật toán, bạn không thể kiểm tra xem “có hành vi ngoại lệ nào xảy ra với thuật toán đó không”. Giống như trường hợp “lỗi” trong trò chơi, thuật toán chỉ là một thứ trừu tượng, nếu bạn không dự đoán được sự kiện nào sẽ xảy ra trong tương lai, bạn sẽ không thể kiểm tra xem “nếu sự kiện đó xảy ra, liệu có phát sinh hành vi ngoại lệ không”.

Điều này đặc biệt là vấn đề lớn trong trường hợp các sản phẩm mới như ứng dụng, dịch vụ, hoặc các kế hoạch kinh doanh mới. Nếu bạn mở rộng doanh nghiệp với những sản phẩm hoặc kế hoạch đó, điều gì có thể xảy ra trong tương lai? Điều này khó mà dự đoán nếu bạn không có kiến thức về lĩnh vực đó. Đặc biệt, trong trường hợp hợp đồng giữa các công ty, cả công ty đối tác và công ty của bạn đều hoạt động dưới sự hợp lý về kinh tế, vì vậy, để dự đoán sự kiện trong tương lai và hành động của đối tác dẫn đến sự kiện đó, bạn cũng cần phải có tư duy theo lý thuyết trò chơi trong quản lý doanh nghiệp.

Việc có phải là “ngoài dự kiến” hay không cũng dựa trên quyết định quản lý

Hơn nữa, giống như việc quyết định xem một sự kiện có phải là “lỗi” không không phải do máy tính mà do con người, việc quyết định xem một kết quả mà hợp đồng mang lại có phải là “ngoài dự kiến” hay không cũng không chỉ là vấn đề thuộc về pháp luật mà còn là vấn đề quản lý.

Ví dụ, có thể có trường hợp mà thuật toán “theo nguyên tắc của Luật dân sự Nhật Bản” không thể chấp nhận được trong một doanh nghiệp cụ thể. Mặc dù câu chuyện sẽ thay đổi từ ví dụ trước đây, nhưng Luật dân sự Nhật Bản quy định một thuật toán mặc định rằng “việc giao lại hợp đồng bởi người nhận ủy thác sẽ vi phạm hợp đồng”. Tuy nhiên, có thể có trường hợp mà “đối với một công ty cụ thể, một dự án cụ thể, việc sử dụng các công ty thầu phụ là điều dự kiến”. Trong những trường hợp như vậy, việc chấp nhận một hợp đồng không thể giao lại, tức là

• Không có gì được ghi rõ về việc có thể giao lại hay không (trong trường hợp này, như đã nói ở trên, nguyên tắc của Luật dân sự Nhật Bản sẽ được áp dụng)
• Việc không thể giao lại được ghi rõ

Ngay cả khi nó “theo nguyên tắc của Luật dân sự Nhật Bản”, bạn không thể chấp nhận hợp đồng đó.

Ngoài ra, trong quản lý, luôn có rủi ro là “nếu một sự kiện cụ thể xảy ra, bạn sẽ phải chịu trách nhiệm”. Không có hợp đồng nào “không có rủi ro” đối với công ty của bạn. Việc chấp nhận rủi ro hay không cuối cùng là quyết định quản lý. Người quản lý là người ra quyết định quản lý, không phải là người tư vấn như luật sư tư vấn, nhưng tư vấn phải cung cấp thông tin cần thiết và đủ cho người quản lý để ra quyết định quản lý, bao gồm:

• Rủi ro không cần phải chỉ ra mỗi lần
• Rủi ro cần phải chấp nhận, có thể cần họp hoặc các biện pháp khác, là quyết định quan trọng cho công ty

Luật sư kiểm tra hợp đồng cũng cần có một mức độ nhận thức về “quản lý” để thiết lập “độ mạnh yếu” này, giống như trong trường hợp của tư vấn trong các lĩnh vực khác.

Tóm tắt

Như vậy, việc kiểm tra và chỉnh sửa hợp đồng có thể được mô tả như các công việc chính sau đây:

1. Hiểu rõ cách mà các nguyên tắc của ‘Bộ luật dân sự Nhật Bản’ và các luật pháp khác được ghi đè bởi hợp đồng, và kết quả là thuật toán nào được tạo ra
2. Xem xét những sự kiện nào có thể xảy ra trong tương lai dưới thuật toán này
3. Xem xét liệu có hành vi ngoài dự kiến nào xảy ra không

Và mỗi công việc trên đều:

1. Khó khăn nếu không có người hiểu về luật pháp
2. Khó khăn nếu không có người hiểu về nội dung của doanh nghiệp mà hợp đồng đang quản lý, chẳng hạn như ứng dụng hoặc dịch vụ web, hoặc không hiểu về cơ chế kinh doanh
3. Khó khăn nếu không có người hiểu một phần nào đó về nội dung của công ty hoặc doanh nghiệp, hoặc không có cảm nhận về quản lý kinh doanh

Đó là lý do.

Việc kiểm tra và chỉnh sửa hợp đồng vì những lý do trên mà trở nên “chuyên môn” hóa.

Thông tin về việc tạo và xem xét hợp đồng do văn phòng luật sự của chúng tôi cung cấp

Văn phòng luật sự Monolis, với ưu điểm trong lĩnh vực IT, Internet và kinh doanh, chúng tôi cung cấp các dịch vụ như tạo và xem xét hợp đồng cho các công ty khách hàng và công ty tư vấn của chúng tôi.

Nếu quý vị quan tâm, xin vui lòng xem chi tiết dưới đây.

https://monolith.law/contractcreation[ja]