MONOLITH LAW OFFICE+81-3-6262-3248Hari kerja 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Pengacara mantan Insinyur IT menjelaskan Kesamaan antara Pemeriksaan Kontrak dan Debugging

IT

Pengacara mantan Insinyur IT menjelaskan Kesamaan antara Pemeriksaan Kontrak dan Debugging

Inti dari pekerjaan yang disebut “pengacara penasihat perusahaan” adalah memeriksa dan memodifikasi kontrak yang perusahaan tanda tangani setiap hari dengan klien dan mitra bisnis. Dan pemeriksaan dan modifikasi ini hanya bisa dilakukan secara memadai oleh orang yang “mengerti hukum dan bidang kerja tersebut”. Saya akan menjelaskan mengapa ini penting.

Namun, penjelasan berikut mungkin sulit dipahami bagi mereka yang bukan insinyur atau tidak memiliki pengalaman dalam pemrograman. Monolith Law Office adalah firma hukum yang dipimpin oleh pengacara yang merupakan mantan insinyur IT dan memiliki pengalaman dalam manajemen perusahaan. Ini adalah artikel yang menjelaskan tentang pemeriksaan dan modifikasi kontrak, ditujukan untuk manajer yang memiliki pengalaman dalam teknik dan pemrograman, dari perspektif sebuah firma hukum yang dipimpin oleh mantan insinyur IT dan manajer perusahaan.

Dalam konteks ini, pemeriksaan dan modifikasi kontrak mirip dengan apa yang disebut “debugging”.

  1. Apa itu “bug”?
  2. Apa itu “debugging”?
  3. Bagaimana kontrak menentukan algoritma?
  4. Apa itu modifikasi kontrak?

Meskipun ini mungkin tampak seperti hal yang “jelas” bagi insinyur, saya akan menjelaskan dalam urutan ini.

Apa itu “Bug” dan “Debug”

“Bug” bukan “Kerusakan PC”

Ketika kita mendengar kata “bug”, mungkin ada yang membayangkan situasi di mana asap keluar dari mesin saat bekerja di PC dan layar menunjukkan tampilan yang aneh. Namun, pada dasarnya, PC hanya beroperasi “sesuai perintah”. Hal ini juga berlaku saat bug terjadi. Jadi, “bug” adalah,

  • Walaupun PC beroperasi sesuai perintah
  • Bagi pengguna, operasi tersebut adalah “perilaku yang tidak diharapkan”

fenomena tersebut.

Mengapa “Perilaku yang Tidak Diharapkan” Terjadi?

Misalnya, mari kita pikirkan tentang bug “tembus dinding” dalam game aksi tipe Mario.

Lompatan Mario adalah fungsi kuadrat. Akselerasi, kecepatan, koordinat. Namun, dalam game televisi, tidak mungkin membagi waktu menjadi tak terbatas kecil, karena layar hanya berubah sebanyak (misalnya) 30 kali per detik. Oleh karena itu, seolah-olah, Mario “melompat” 30 kali per detik.

Dalam hal ini, misalnya, jika “Mario melompat dan ada dinding di atas, dia akan memantul”, itu adalah kasus di mana

  1. Mario berada di udara pada saat sebelumnya
  2. Pada saat berikutnya, koordinat Mario berada di dalam dinding

itu adalah kasus tersebut.

Dalam kasus ini, kita dapat menentukan bahwa “Mario menabrak dinding di atas saat melompat”. Oleh karena itu, jika kita menulis program dalam bahasa alami,

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

Dengan menulis program seperti itu, kita dapat mewujudkan proses “Mario melompat dan ada dinding di atas, jadi dia memantul”.

※1 tampak benar selama kita menulis seperti di atas. Dan sebenarnya, proses ini benar “dalam kondisi tertentu”.

Namun, jika kita berpikir lebih dalam, ada kasus seperti di bawah ini (※2).

Dalam kasus ini, tidak ada momen di mana “koordinat Mario berada di dalam dinding”, sehingga proses pemantulan tidak terjadi, dan Mario akan menembus dinding.

Ini adalah contoh “bug”. Meskipun bug “tembus dinding” terjadi karena alasan ini, bukan berarti PC rusak. PC hanya beroperasi sesuai perintah, dan manusia yang menilai perilaku tersebut sebagai “tidak diharapkan” atau “bug”. Dan “bug” tersebut terjadi karena algoritma tidak tepat.

Memeriksa Apakah “Perilaku yang Tidak Diharapkan” Terjadi

Namun, apakah “tembus dinding” terjadi dalam proses bermain game atau tidak, tidak jelas hanya dengan berpikir secara abstrak seperti di atas. Apakah “tembus dinding” dapat terjadi atau tidak tergantung pada,

  • Seberapa besar kekuatan lompatan Mario (kecepatan awal), apakah ada item seperti peningkatan kekuatan lompatan
  • Seberapa tebal dinding dalam kasus paling tipis

karena tergantung pada kondisi tersebut. Tergantung pada apakah kasus seperti ※2 mungkin terjadi atau tidak. Jika ※2 tidak mungkin, maka tidak ada masalah dengan program ※1.

Apa Itu “Debug”?

Oleh karena itu, untuk melakukan “debug”, yaitu, menemukan bug dan memperbaikinya, kita perlu,

  1. Membaca algoritma program apa (※1 adalah dalam bahasa alami, tetapi sebenarnya program ditulis dalam bahasa khusus, sehingga sulit untuk membacanya)
  2. Memeriksa di bawah kondisi apa program tersebut beroperasi (menyelidiki tentang kekuatan lompatan dan ketebalan dinding)
  3. Memeriksa apakah perilaku yang tidak diharapkan terjadi saat itu

proses seperti itu diperlukan.

Apa Itu Pekerjaan Memeriksa Kontrak?

Memeriksa kontrak memiliki sifat yang mirip dengan “debugging”

Memeriksa kontrak juga mirip dengan pekerjaan ini. Pada dasarnya, kontrak adalah alat yang mengatur hak dan kewajiban antara pihak-pihak yang terlibat, yaitu pihak A dan B, dengan mempertimbangkan kejadian yang mungkin terjadi di masa depan. Kontrak juga menentukan bagaimana kedua belah pihak harus bertindak sebagai hasil dari hak dan kewajiban tersebut. Dalam arti ini, kontrak dapat dianggap sebagai “program yang mengatur dunia nyata”. Misalnya,

Jika situasi ●● terjadi, pihak A harus membayar ganti rugi sebesar 1 juta yen kepada pihak B.

Kontrak yang mengatur aturan seperti ini mendefinisikan kondisi dan efek terkait dengan peristiwa yang mungkin terjadi di masa depan.

Lalu, pekerjaan memeriksa apakah ada masalah dengan “program yang mengatur dunia nyata” ini dan memperbaikinya jika ada masalah, sangat mirip dengan proses “debugging”.

Kontrak tidak mencakup seluruh algoritma

Namun, ada satu poin yang sangat penting dalam ‘kontrak’, yang mungkin sulit dipahami oleh mereka yang bukan ahli hukum. Poin tersebut adalah bahwa kontrak hanya menentukan ‘sebagian’ dari algoritma yang mengatur hubungan antara para pihak. Dengan kata lain, hanya dengan membaca kontrak, Anda tidak dapat mengetahui seluruh gambaran tentang bagaimana Anda dan pihak lain diatur di bawah algoritma apa.

Misalnya, ketika membeli CD bekas di toko, toko dan pelanggan tidak membuat ‘kontrak jual beli’, tetapi jika CD yang dibeli memiliki goresan yang membuatnya tidak dapat diputar di pemutar, Anda mungkin ingin mengeluh kepada toko, dan Anda akan berharap toko akan merespons. Ini bukan hanya masalah ‘karena ini adalah bisnis layanan’, tetapi secara teoritis,

  1. Meskipun tidak ada kontrak tertulis, kontrak jual beli telah disepakati
  2. Hukum Sipil Jepang (Japanese Civil Law) menentukan bahwa penjual memiliki tanggung jawab jaminan cacat pada kontrak jual beli barang tertentu (disebut ‘barang tertentu’)
  3. Oleh karena itu, algoritma yang ditentukan oleh Hukum Sipil Jepang berlaku antara toko dan pelanggan, dan toko memiliki tanggung jawab jaminan cacat

Itulah logikanya. Dan ‘kontrak’ adalah sesuatu yang menimpa algoritma yang ditentukan oleh hukum seperti Hukum Sipil Jepang. Misalnya, jika ada kontrak atau sejenisnya antara toko dan pelanggan yang menyatakan ‘kami tidak menerima klaim apa pun tentang cacat CD setelah fakta’, maka

  1. Kontrak jual beli telah disepakati
  2. Hukum Sipil Jepang menentukan bahwa penjual memiliki tanggung jawab jaminan cacat untuk kontrak tersebut
  3. Namun, berdasarkan ketentuan kontrak, prinsip 2 ditimpa, dan toko tidak memiliki tanggung jawab jaminan cacat

Itulah yang terjadi.

Kontrak adalah Dokumen yang ‘Menimpa’ Prinsip-Prinsip seperti Hukum Perdata

Membaca kontrak saja tidak cukup untuk memahami ‘algoritma’ secara keseluruhan

Hal ini juga berlaku dalam kasus kontrak yang disepakati antar perusahaan, seperti dalam pengembangan sistem. Misalnya, jika kontrak pengembangan sistem berdasarkan model kontrak kerja telah disepakati antara dua pihak,

  1. Dengan menandatangani kontrak tersebut, kontrak kerja secara jelas telah disepakati
  2. Dalam kasus kontrak kerja, tanggung jawab jaminan cacat akan muncul pada pihak yang menerima kontrak berdasarkan ketentuan Hukum Perdata
  3. Jika ada ketentuan tentang tanggung jawab jaminan cacat dalam kontrak, ketentuan tersebut akan menimpa prinsip Hukum Perdata nomor 2. Misalnya, jika ada ketentuan tanggung jawab jaminan cacat untuk periode yang lebih lama dari prinsip Hukum Perdata, ketentuan periode tersebut akan berlaku

Struktur ini berarti bahwa, misalnya, meskipun tidak ada ketentuan khusus tentang tanggung jawab jaminan cacat dalam kontrak, tanggung jawab jaminan cacat akan muncul.

Ini bukan hanya berlaku untuk kontrak kerja dan pengembangan sistem, tetapi juga berlaku secara umum untuk semua kontrak yang dilakukan oleh perusahaan, seperti transfer saham, penggalangan dana melalui utang (pinjaman konsumsi uang), pekerjaan, dan penerbitan saham.

Oleh karena itu, hanya dengan membaca kontrak, Anda tidak dapat memahami ‘algoritma’ yang mengatur hubungan antara perusahaan Anda dan pihak lain secara keseluruhan. Untuk memahami gambaran keseluruhan, Anda harus memahami ‘algoritma default’ yang ditetapkan oleh hukum seperti Hukum Perdata. Kontrak hanyalah dokumen yang menimpa ‘algoritma default’ tersebut.

Tidak dapat melakukan ‘debug’ jika tidak dapat mengantisipasi peristiwa yang mungkin terjadi di masa depan

Selain itu, hanya dengan memahami algoritma, kita tidak dapat memverifikasi apakah “tidak ada perilaku yang tidak diantisipasi dengan algoritma tersebut”. Sama seperti kasus ‘bug’ dalam game, algoritma adalah hal yang abstrak, dan jika kita tidak dapat mengantisipasi peristiwa apa yang akan terjadi di masa depan, kita tidak dapat memverifikasi “apakah tidak akan ada perilaku yang tidak diantisipasi jika peristiwa tersebut terjadi”.

Ini adalah masalah serius, terutama dalam kasus produk seperti aplikasi atau layanan baru, skema bisnis baru, dan sebagainya. Apa yang mungkin terjadi di masa depan ketika menjalankan bisnis dengan produk atau skema tersebut. Ini adalah sesuatu yang sulit untuk diantisipasi jika tidak memiliki pengetahuan tentang bidang tersebut. Selain itu, terutama dalam kasus kontrak antara perusahaan, baik perusahaan lawan maupun perusahaan kita sendiri, beroperasi di bawah rasionalitas ekonomi tertentu, sehingga diperlukan pemikiran teori game dalam manajemen bisnis untuk memprediksi peristiwa masa depan dan tindakan yang akan diambil oleh pihak lawan.

“Apakah di Luar Dugaan” Bergantung pada Pertimbangan Manajemen

Lebih lanjut, sama seperti bukan PC tetapi manusia yang menentukan apakah suatu peristiwa adalah “bug”, apakah suatu hasil yang dihasilkan oleh kontrak adalah “di luar dugaan” juga bukan hanya masalah hukum murni, tetapi juga masalah pertimbangan manajemen.

Sebagai contoh, mungkin ada kasus di mana algoritma “sesuai dengan prinsip Hukum Sipil Jepang” tidak dapat diterima dalam bisnis tertentu dari suatu perusahaan. Meskipun ini berbeda dari contoh sebelumnya, misalnya, Hukum Sipil Jepang menetapkan algoritma default bahwa “penugasan ulang oleh penerima tugas adalah pelanggaran kontrak”. Namun, misalnya, mungkin ada kasus di mana “untuk suatu perusahaan, suatu bisnis diharapkan secara alami menggunakan perusahaan subkontrak”. Dalam kasus seperti itu, kontrak yang tidak memungkinkan penugasan ulang, yaitu

  • Tidak ada yang secara eksplisit menyatakan apakah penugasan ulang diperbolehkan atau tidak (dalam hal ini, seperti yang disebutkan di atas, prinsip Hukum Sipil Jepang berlaku)
  • Dinyatakan secara eksplisit bahwa penugasan ulang tidak diperbolehkan

tidak seharusnya dapat diterima, bahkan jika itu “sesuai dengan prinsip Hukum Sipil Jepang”.

Selain itu, dalam manajemen, selalu ada risiko “akan bertanggung jawab jika suatu kejadian tertentu terjadi”. Tidak ada kontrak yang “tidak berisiko” bagi perusahaan Anda. Apakah menerima risiko tersebut atau tidak pada akhirnya adalah pertimbangan manajemen. Orang yang membuat pertimbangan manajemen adalah manajer, bukan konsultan seperti pengacara, tetapi konsultan harus menyajikan informasi yang cukup dan diperlukan untuk manajer membuat pertimbangan manajemen, seperti

  • Risiko yang tidak perlu ditunjukkan setiap saat
  • Risiko yang penerimaannya merupakan keputusan penting bagi perusahaan tersebut, dan mungkin memerlukan pertemuan, dll.

Harus ditunjukkan dengan gradasi. Untuk menetapkan “gradasi” ini, seperti halnya konsultan di bidang lain, pengacara yang memeriksa kontrak juga memerlukan pemahaman tentang “manajemen” hingga tingkat tertentu.

Kesimpulan

Dengan demikian, pengecekan dan perbaikan kontrak dapat dikatakan sebagai pekerjaan yang secara umum melibatkan langkah-langkah berikut:

  1. Memahami bagaimana prinsip-prinsip dalam Hukum Sipil Jepang dan lainnya ditimpa oleh kontrak, dan hasilnya menjadi algoritma seperti apa
  2. Mempertimbangkan apa saja peristiwa yang mungkin terjadi di masa depan berdasarkan algoritma tersebut
  3. Mempertimbangkan apakah ada perilaku yang tidak terduga yang mungkin terjadi

Setiap langkah di atas memerlukan:

  1. Orang yang memahami hukum, jika tidak, pekerjaan ini akan sulit
  2. Orang yang memahami konten bisnis yang diatur oleh kontrak tersebut, seperti aplikasi atau layanan web, jika tidak, pekerjaan ini akan sulit
  3. Orang yang memiliki pemahaman yang cukup tentang perusahaan dan konten bisnis, serta intuisi bisnis, jika tidak, pekerjaan ini akan sulit

Itulah sebabnya.

Pengecekan dan perbaikan kontrak adalah pekerjaan yang sangat ‘spesialis’ karena alasan ini.

Panduan Membuat dan Meninjau Kontrak oleh Kantor Kami

Di Kantor Hukum Monolis, sebagai firma hukum yang memiliki keahlian di bidang IT, Internet, dan Bisnis, kami menawarkan layanan seperti pembuatan dan peninjauan berbagai jenis kontrak kepada perusahaan klien dan perusahaan yang menjadi konsultan kami.

Jika Anda tertarik, silakan lihat detailnya di bawah ini.

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

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Kembali ke atas