Peguam bekas jurutera IT menerangkan persamaan antara pemeriksaan kontrak dan 'debugging

Tugas utama yang dikenali sebagai ‘Peguam Penasihat Syarikat’ adalah untuk memeriksa dan meminda kontrak yang ditandatangani oleh syarikat dengan pelanggan dan rakan kongsi perniagaan setiap hari. Dan pemeriksaan dan pemindaan ini hanya boleh dilakukan dengan cekap oleh ‘orang yang mahir dalam undang-undang dan bidang kerja tersebut’. Saya akan menjelaskan mengapa ini penting.

Walau bagaimanapun, penjelasan berikut mungkin sukar difahami oleh mereka yang bukan jurutera atau tidak mempunyai pengalaman dalam pengaturcaraan. Pejabat Guaman Monolith adalah sebuah firma undang-undang yang diterajui oleh seorang peguam yang juga bekas jurutera IT dan mempunyai pengalaman dalam pengurusan syarikat. Ini adalah artikel yang menjelaskan tentang pemeriksaan dan pemindaan kontrak, ditujukan khususnya kepada pengurus yang mempunyai pengalaman dalam kejuruteraan atau pengaturcaraan, dari perspektif sebuah firma undang-undang yang diterajui oleh bekas jurutera IT dan pengurus syarikat.

Dalam konteks ini, pemeriksaan dan pemindaan kontrak adalah kerja yang mirip dengan ‘debugging’.

1. Apa itu ‘bug’?
2. Bagaimana proses ‘debugging’?
3. Bagaimana kontrak menentukan algoritma?
4. Bagaimana proses pemindaan kontrak?

Walaupun ini mungkin merupakan sesuatu yang ‘jelas’ bagi jurutera, saya akan menjelaskannya dalam urutan seperti di atas.

Apa itu ‘Bug’ dan ‘Debug’

‘Bug’ bukanlah ‘Kerosakan PC’

Bila kita sebut tentang ‘bug’, mungkin ada yang membayangkan situasi di mana asap keluar dari mesin semasa bekerja dengan PC dan skrin menunjukkan paparan yang aneh. Walau bagaimanapun, pada dasarnya, PC hanya akan berfungsi ‘seperti yang diperintahkan’. Ini juga berlaku dalam kes bug. Jadi, ‘bug’ adalah,

• Walaupun PC berfungsi seperti yang diperintahkan,
• Perilaku tersebut adalah ‘perilaku yang tidak dijangka’ bagi pengguna

Itulah fenomena yang dimaksudkan.

Mengapa ‘Perilaku yang Tidak Dijangka’ Berlaku?

Misalnya, mari kita fikirkan tentang bug ‘tembusan dinding’ dalam permainan aksi jenis Mario.

Lompatan Mario adalah fungsi kuadrat. Pemecutan, kelajuan, koordinat. Walau bagaimanapun, walaupun ia adalah fungsi kuadrat, misalnya ‘Apa Y jika X=1.76582?’, kita boleh memisahkan X dengan sangat halus, tetapi dalam kes permainan video, kita tidak boleh memisahkan masa dengan sangat halus. Ini kerana skrin hanya bertukar sebanyak 30 kali setiap saat (misalnya). Oleh itu, secara tidak langsung, Mario ‘melompat’ sebanyak 30 kali setiap saat.

Dalam konteks ini, misalnya, dalam kes ‘Mario melompat dan terpantul kerana ada dinding di atas’, apa yang dimaksudkan adalah

1. Sekejap sebelum itu, Mario berada di udara
2. Sekejap kemudian, koordinat Mario berada di dalam dinding

Itulah situasinya.

Dalam kes seperti ini, kita boleh menentukan bahawa ‘Mario telah bertembung dengan dinding di atas semasa melompat’. Oleh itu, jika kita menulis program dalam bahasa semula jadi,

Jika koordinat Mario berada di dalam dinding, lakukan proses pantulan (※1)

Dengan menulis program seperti ini, kita boleh melaksanakan proses ‘Mario melompat dan terpantul kerana ada dinding di atas’.

※1, selama kita menulis seperti di atas, ia kelihatan betul. Dan sebenarnya, proses ini betul ‘dalam keadaan tertentu’.

Tetapi, jika kita fikirkan dengan teliti, ada juga kemungkinan seperti di bawah (※2).

Dalam kes ini, tidak ada saat di mana ‘koordinat Mario berada di dalam dinding’, oleh itu, proses pantulan tidak akan berlaku, dan Mario akan melalui dinding.

Ini adalah contoh ‘bug’. Walaupun bug ‘tembusan dinding’ berlaku kerana sebab-sebab seperti ini, bukan berarti PC rosak. PC hanya melakukan perilaku seperti yang diperintahkan, dan manusia yang menilai perilaku itu sebagai ‘tidak dijangka’ atau ‘bug’. Dan ‘bug’ itu berlaku kerana algoritma tidak sesuai.

Menimbang ‘Sama ada Perilaku yang Tidak Dijangka akan Berlaku’

Walau bagaimanapun, sama ada ‘tembusan dinding’ akan berlaku dalam proses bermain permainan sebenar atau tidak, tidak dapat ditentukan hanya dengan berfikir secara abstrak seperti di atas. Sama ada ‘tembusan dinding’ boleh berlaku atau tidak bergantung pada,

• Sejauh mana kekuatan lompatan Mario (kelajuan awal), adakah ada item seperti peningkatan kekuatan lompatan
• Seberapa tebal dinding dalam keadaan paling nipis

bergantung pada keadaan ini. Bergantung pada sama ada keadaan seperti ※2 boleh berlaku atau tidak. Jika ※2 tidak mungkin, maka tidak ada masalah dengan program ※1.

Apa Itu ‘Debug’?

Oleh itu, untuk melakukan ‘debug’, iaitu, untuk mencari dan membetulkan bug,

1. Membaca dan memahami algoritma program (※1 adalah dalam bahasa semula jadi, tetapi sebenarnya program ditulis dalam bahasa khusus, jadi membaca itu sendiri adalah sukar)
2. Menimbang dalam keadaan apa program itu berfungsi (mengkaji tentang kekuatan lompatan dan ketebalan dinding)
3. Menimbang sama ada perilaku yang tidak dijangka akan berlaku dalam proses itu

proses seperti ini diperlukan.

Apa yang dimaksudkan dengan pemeriksaan kontrak?

Pemeriksaan kontrak juga serupa dengan proses ini. Sebenarnya, kontrak adalah alat yang digunakan untuk mengatur hak dan kewajiban pihak-pihak yang terlibat, iaitu pihak A dan B, berdasarkan peristiwa yang mungkin berlaku di masa depan. Ia juga menentukan bagaimana kedua-dua pihak akan bertindak sebagai hasilnya. Dalam erti kata lain, ia boleh dianggap sebagai ‘program yang mengatur dunia nyata’. Sebagai contoh,

Jika situasi ●● berlaku, pihak A akan membayar pampasan sebanyak 1 juta yen kepada pihak B.

Kontrak yang mengatur peraturan seperti ini mendefinisikan syarat dan kesan berkenaan dengan peristiwa yang mungkin berlaku di masa depan.

Proses memeriksa ‘program yang mengatur dunia nyata’ ini untuk sebarang masalah dan membuat pembetulan jika perlu, sangat mirip dengan proses ‘debugging’.

Algoritma penuh tidak dinyatakan dalam kontrak

Walau bagaimanapun, ada satu titik yang sangat penting dalam ‘kontrak’, yang mungkin sukar difahami oleh mereka yang bukan pakar undang-undang. Kontrak hanya menentukan ‘sebahagian’ daripada algoritma yang mengatur antara pihak-pihak yang terlibat. Dengan kata lain, hanya dengan membaca kontrak, anda tidak dapat mengetahui gambaran penuh tentang bagaimana anda dan pihak lain diatur di bawah algoritma apa.

Sebagai contoh, apabila anda membeli CD terpakai di kedai, kedai dan pelanggan tidak membuat ‘kontrak jual beli’, tetapi jika ada calar yang tidak dapat diputar pada pemain pada permukaan CD yang dibeli, anda mungkin ingin mengadu kepada kedai, dan anda akan mengharapkan kedai itu akan merespon. Ini bukan hanya soal ‘perkhidmatan’, tetapi secara teori,

1. Walaupun tiada kontrak, kontrak jual beli telah ditandatangani
2. Undang-Undang Sivil Jepun (Japanese Civil Code) menentukan bahawa penjual mempunyai tanggungjawab jaminan cacat untuk kontrak jual beli barang tertentu (disebut ‘barang tertentu’)
3. Oleh itu, algoritma yang ditentukan oleh Undang-Undang Sivil Jepun berlaku di antara kedai dan pelanggan, dan kedai mempunyai tanggungjawab jaminan cacat

Itulah logiknya. Dan ‘kontrak’ adalah sesuatu yang menulis semula algoritma yang ditentukan oleh undang-undang seperti Undang-Undang Sivil Jepun. Sebagai contoh, jika ada kontrak atau seumpamanya antara kedai dan pelanggan yang mengatakan ‘kedai kami tidak akan menerima sebarang aduan tentang kecacatan CD selepas fakta’,

1. Kontrak jual beli telah ditandatangani
2. Undang-Undang Sivil Jepun menentukan bahawa penjual mempunyai tanggungjawab jaminan cacat untuk kontrak tersebut
3. Walau bagaimanapun, berdasarkan peruntukan kontrak, prinsip 2 ditulis semula, dan kedai tidak mempunyai tanggungjawab jaminan cacat

Itulah yang berlaku.

Perjanjian adalah sesuatu yang ‘menulis semula’ prinsip seperti Undang-Undang Sivil Jepun (Japanese Civil Law)

Ini juga berlaku dalam kes perjanjian antara syarikat, seperti pembangunan sistem. Sebagai contoh, jika perjanjian pembangunan sistem berdasarkan kontrak telah ditandatangani antara dua pihak,

1. Perjanjian tersebut jelas menunjukkan bahawa kontrak telah ditandatangani
2. Dalam kes kontrak, tanggungjawab jaminan cacat timbul berdasarkan peruntukan Undang-Undang Sivil
3. Jika perjanjian tersebut mengandungi peruntukan tentang tanggungjawab jaminan cacat, peruntukan tersebut akan menulis semula prinsip Undang-Undang Sivil yang kedua. Sebagai contoh, jika terdapat klausa tanggungjawab jaminan cacat untuk tempoh yang lebih lama daripada prinsip Undang-Undang Sivil, peruntukan tempoh tersebut akan berlaku

Ini adalah struktur yang ada. Jadi, misalnya, walaupun perjanjian tidak mengandungi peruntukan khusus tentang tanggungjawab jaminan cacat, tanggungjawab jaminan cacat akan timbul.

Ini bukan hanya terhad kepada kontrak dan pembangunan sistem, tetapi juga berlaku untuk pemindahan saham, pengumpulan dana melalui hutang (pinjaman penggunaan wang), pekerjaan, pengeluaran saham, dan sebagainya, yang merupakan teori umum tentang semua perjanjian yang dilakukan oleh syarikat.

Oleh itu, hanya membaca perjanjian tidak mencukupi untuk memahami ‘algoritma’ yang mengatur hubungan antara pihak lain dan syarikat anda secara keseluruhan. Untuk memahami gambaran keseluruhan, anda perlu memahami ‘algoritma lalai’ yang ditetapkan oleh undang-undang seperti Undang-Undang Sivil. Ini kerana perjanjian hanyalah sesuatu yang menulis semula ‘algoritma lalai’ tersebut.

Tidak dapat ‘debug’ jika tidak dapat mengandaikan peristiwa yang mungkin berlaku di masa depan

Selain itu, hanya memahami algoritma tidak mencukupi untuk memeriksa sama ada “perilaku yang tidak dijangka tidak akan berlaku dengan algoritma tersebut”. Sama seperti kes ‘bug’ dalam permainan, algoritma adalah abstrak, dan jika kita tidak dapat mengandaikan apa yang akan berlaku di masa depan, kita tidak dapat memeriksa “sama ada perilaku yang tidak dijangka akan berlaku jika peristiwa tersebut berlaku”.

Ini adalah isu yang sangat penting, terutama dalam kes produk seperti aplikasi atau perkhidmatan baru, skema perniagaan baru, dan sebagainya. Apa yang mungkin berlaku di masa depan jika kita melancarkan perniagaan dengan produk atau skema tersebut? Ini adalah sesuatu yang sukar untuk diandaikan jika tidak ada pengetahuan tentang bidang tersebut. Selain itu, terutama dalam kes kontrak antara syarikat, kedua-dua pihak, termasuk syarikat kita sendiri, bertindak atas dasar rasionaliti ekonomi tertentu, jadi untuk meramalkan peristiwa masa depan dan tindakan pihak lain yang akan membawa kepada peristiwa tersebut, kita juga perlu pemikiran teori permainan yang berkaitan dengan pengurusan perniagaan.

Penentuan “Luar Jangkaan” Bergantung pada Penghakiman Pengurusan

Lebih lanjut, sama seperti manusia, bukan PC, yang menentukan sama ada suatu peristiwa adalah “bug”, sama ada kesimpulan yang dibawa oleh kontrak adalah “luar jangkaan” juga bukan hanya masalah undang-undang murni, tetapi juga masalah penghakiman pengurusan.

Sebagai contoh, mungkin ada kes di mana algoritma “mengikut prinsip Undang-Undang Sivil Jepun” tidak dapat diterima dalam bisnes tertentu syarikat. Walaupun ini berbeza dari contoh sebelumnya, Undang-Undang Sivil Jepun, misalnya, menetapkan algoritma lalai yang mengatakan “penggantian kontrak oleh penerima adalah pelanggaran kontrak”. Namun, mungkin ada kes di mana “untuk syarikat tertentu, dijangka bahawa bisnes tertentu akan menggunakan syarikat subkontraktor secara semulajadi”. Dalam kes seperti itu, kontrak yang tidak membolehkan penggantian, iaitu

• Tidak ada penjelasan tentang sama ada penggantian diperbolehkan (dalam kes ini, prinsip Undang-Undang Sivil Jepun diterapkan seperti yang dinyatakan di atas)
• Dinyatakan secara jelas bahawa penggantian tidak mungkin

tidak boleh diterima, walaupun ia “mengikut prinsip Undang-Undang Sivil Jepun”.

Selain itu, dalam pengurusan, selalu ada risiko “akan bertanggungjawab jika sesuatu berlaku”. Tidak ada kontrak yang “tidak ada risiko” bagi syarikat kita. Sama ada menerima risiko ini atau tidak adalah penghakiman pengurusan akhir. Penghakiman pengurusan dilakukan oleh pengurus, bukan oleh penasihat hukum atau orang lain dalam peranan konsultatif, tetapi konsultan harus memberikan maklumat yang cukup untuk pengurus membuat penghakiman pengurusan,

• Risiko yang tidak perlu ditekankan
• Risiko yang menerima akan menjadi keputusan penting bagi syarikat tersebut, dan mungkin memerlukan mesyuarat, dll.

harus ditekankan dengan intensiti yang berbeza. Untuk menetapkan “intensiti” ini, seperti dalam kes konsultan dalam bidang lain, peguam yang memeriksa kontrak juga memerlukan pemahaman tentang “pengurusan” hingga tahap tertentu.

Rumusan

Seperti yang dinyatakan, pemeriksaan dan pengubahsuaian kontrak adalah kerja yang melibatkan aspek-aspek berikut:

1. Memahami bagaimana prinsip-prinsip seperti Undang-Undang Sivil Jepun (Japanese Civil Law) ditulis semula oleh kontrak dan bagaimana ia menjadi algoritma sebagai hasilnya
2. Menyiasat kemungkinan kejadian masa depan di bawah algoritma tersebut
3. Menyiasat sama ada terdapat sebarang tingkah laku yang tidak dijangka

Setiap aspek di atas adalah:

1. Kerja yang sukar dilakukan tanpa pemahaman undang-undang
2. Kerja yang sukar dilakukan tanpa pemahaman tentang kandungan perniagaan seperti aplikasi atau perkhidmatan web yang dikawal oleh kontrak tersebut, atau skema perniagaan
3. Kerja yang sukar dilakukan tanpa pemahaman yang cukup tentang kandungan syarikat atau perniagaan, atau intuisi pengurusan

Itulah sebabnya.

Pemeriksaan dan pengubahsuaian kontrak adalah sangat “profesional” kerana alasan ini.

Panduan Mengenai Penyediaan dan Ulasan Kontrak oleh Firma Kami

Di Firma Guaman Monolis, sebagai firma guaman yang mempunyai kelebihan dalam IT, Internet dan perniagaan, kami menyediakan perkhidmatan seperti penyediaan dan ulasan kontrak kepada syarikat-syarikat pelanggan dan klien kami.

Sesiapa yang berminat, sila lihat butiran lanjut di bawah.

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