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

MONOLITH LAW MAGAZINE

IT

Apakah Kontrak Pengembangan Sistem Dapat Dibentuk Tanpa Kontrak Tertulis?

IT

Apakah Kontrak Pengembangan Sistem Dapat Dibentuk Tanpa Kontrak Tertulis?

Dalam pengembangan sistem, tidak jarang pengembang melanjutkan pekerjaan sebelum membuat kontrak. Namun, alur kerja seperti ini sebenarnya ‘berbahaya’. Jika kontrak belum dibuat, ada risiko bahwa jika terjadi masalah nantinya, pemberi pesanan dapat mengatakan ‘kontrak belum disepakati, jadi tidak perlu membayar upah’. Dalam sengketa terkait pengembangan sistem yang sebenarnya, sering kali terjadi perselisihan tentang apakah kontrak telah disepakati, dan keputusan yang merugikan pengembang sering kali dibuat. Sebagai pengembang, ada risiko bahwa Anda tidak akan menerima pembayaran jika pemberi pesanan membatalkan proyek atau beralih ke perusahaan lain. Selain itu, seperti yang akan dijelaskan nanti, bahkan jika kontrak telah dibuat, ada kasus di mana kesepakatan kontrak ditolak.

Di sini, kami akan menjelaskan tentang keberhasilan dan kegagalan kontrak pengembangan sistem, dan struktur hukum untuk mengklaim uang jika kesepakatan kontrak tidak diakui.

Pembentukan Kontrak

Sebagai prinsip, kontrak dibentuk melalui kesepakatan antara kedua belah pihak mengenai elemen-elemen kontrak (kesesuaian antara penawaran dan penerimaan).

Ketika kontrak telah dibentuk, kedua belah pihak terikat oleh kontrak tersebut. Jika salah satu pihak tidak memenuhi isi kontrak, pihak lainnya dapat memaksa pelaksanaan melalui pengadilan atau mengajukan gugatan ganti rugi atas pelanggaran kontrak. “Elemen kontrak” harus ditentukan atau spesifik sampai tingkat yang dapat dipaksakan dan diakui sebagai pelanggaran.

Pembentukan kontrak adalah masalah yang sangat penting

Pembentukan Kontrak Pengembangan Sistem

Sifat kontrak pengembangan sistem adalah kontrak kerja dan kontrak kuasa. Kontrak kerja adalah janji untuk menyelesaikan pekerjaan dan membayar imbalan untuk itu. Kontrak kuasa adalah janji untuk melaksanakan tugas dan membayar imbalan untuk itu.

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

Oleh karena itu, jika ada kesepakatan antara pihak-pihak mengenai “isi pekerjaan atau tugas” dan “jumlah imbalan”, yang merupakan elemen kontrak, kontrak dianggap telah dibentuk.

Perlu dicatat bahwa kontrak dapat dibentuk hanya dengan janji lisan, dan tidak memerlukan kontrak tertulis.

Permintaan Uang Jika Kontrak Pengembangan Sistem Dibatalkan Setelah Pembentukan

Jika kontrak pengembangan sistem telah dibentuk dan pengguna secara sepihak membatalkannya, secara hukum dianggap sebagai pemberitahuan pembatalan kontrak.

Jika kontrak kerja telah dibentuk, vendor berhak untuk membatalkan kontrak kapan saja sebelum pekerjaan selesai, tetapi dalam hal ini, vendor berhak mendapatkan ganti rugi (Pasal 641 Hukum Sipil Jepang). Oleh karena itu, jika pengguna tidak memberikan ganti rugi, vendor dapat mengajukan klaim ganti rugi sebesar jumlah yang dikurangi dari biaya yang telah dikeluarkan oleh vendor dan jumlah imbalan yang seharusnya diterima, dikurangi biaya yang dapat dihemat karena pembatalan penyelesaian sistem.

Di sisi lain, jika kontrak kuasa telah dibentuk, penerima kuasa dapat mengajukan klaim imbalan berdasarkan proporsi pelaksanaan ketika kuasa berakhir di tengah jalan (Pasal 648 Ayat 3 Hukum Sipil Jepang yang telah diubah). Oleh karena itu, vendor dapat mengajukan klaim pembayaran untuk pekerjaan yang telah dilakukan.

Kesuksesan Kontrak Pengembangan Sistem

Spesifikasi Konten Sistem

Biasanya, dalam transaksi antar perusahaan, terutama kontrak dengan jumlah besar, dokumen tertulis digunakan. Jika kontrak telah dibuat, kesepakatan kontrak akan lebih mudah diakui.

Sistem yang menjadi target pengembangan akan secara bertahap dikonkretkan melalui berbagai proses. Spesifikasi konten sistem, yang merupakan elemen kontrak kerja, dianggap cukup spesifik jika jangkauan dan garis besar sistem yang akan diubah menjadi sistem dapat dipahami.

Dalam kasus hukum, tidak ada perselisihan tentang penandatanganan kontrak dasar dan perjanjian kerahasiaan, dan kontrak dasar tersebut mencantumkan “dukungan teknologi bisnis e-commerce, dukungan pembangunan situs web, dan pekerjaan terkait lainnya”, tetapi tidak ada penjelasan tentang konten spesifik bisnis e-commerce atau jangkauan pekerjaan yang didelegasikan, atau jangkauan yang akan dikembangkan dan dirancang sebagai sistem, dan kesepakatan kontrak telah ditolak.

Meskipun Anda telah membuat kontrak dasar pengembangan sistem, jika konten pekerjaan atau pekerjaan terlalu abstrak dan tidak spesifik, kesepakatan kontrak mungkin sulit diakui. Kesepakatan kontrak dapat diakui jika kontrak yang mencantumkan konten pekerjaan atau pekerjaan dan jumlah kompensasi secara spesifik hingga tingkat yang dapat dipaksakan dan diakui sebagai pelanggaran.

Untuk informasi lebih lanjut tentang hal-hal yang perlu diperhatikan dalam kontrak antara insinyur individu dan perusahaan, lihat artikel di bawah ini.

Vendor Menyajikan Penawaran dan Spesifikasi, dan Pengguna Menyetujui dan Memesan

Biasanya, dalam transaksi antar perusahaan, dokumen tertulis digunakan. Jika kontrak belum dibuat, kesepakatan kontrak mungkin sulit diakui. Dalam pengembangan sistem, sering kali pekerjaan dimulai sebelum kontrak dibuat, tetapi bagaimana pemikiran tentang kesuksesan kontrak dalam kasus tersebut?

Dalam kasus hukum (Putusan Pengadilan Distrik Nagoya, 28 Januari 2004 (Tahun Heisei 16)), kesepakatan kontrak kerja pengembangan sistem dijelaskan sebagai berikut:

  • Setelah negosiasi konfirmasi spesifikasi, dll. antara vendor dan pengguna,
  • Vendor menyajikan spesifikasi dan penawaran, dll.,
  • Pengguna menyetujui dan memesan ini.

Dalam kasus ini, vendor, yang telah didelegasikan oleh otoritas lokal yang merupakan pengguna untuk memperkenalkan sistem akuntansi keuangan, dll., Menyajikan proposal dan penawaran sebagai tanggapan atas RFP berjudul “Tentang Pengajuan Proposal untuk Pengenalan Sistem Informasi Administrasi Umum (Permintaan)”, dan “Pemberitahuan Adopsi” telah diajukan oleh pengguna. Vendor, tanpa mempertimbangkan secara memadai tentang konten pekerjaan pengguna, dll. dengan berdiskusi dengan pengguna, dan fakta bahwa konten dan biaya kustomisasi telah dipertimbangkan secara spesifik di dalam pengguna tidak diakui, dan konten proposal vendor juga tidak spesifik, dan tidak jelas apa yang disetujui oleh pengguna, dan kesepakatan kontrak tidak diakui.

Saya akan menjelaskan lebih lanjut tentang kesepakatan kontrak yang dijelaskan dalam kasus hukum, dengan mempertimbangkan kasus hukum lainnya.

Setelah Negosiasi Konfirmasi Spesifikasi, dll. Antara Vendor dan Pengguna

Dari kata-kata “setelah negosiasi”, jika konten sistem dan jumlah kompensasi, yang merupakan elemen kontrak, “sedang dinegosiasikan”, kesepakatan kontrak mungkin sulit diakui karena belum ada kesepakatan.

Namun, dalam kontrak kerja, Anda juga dapat menentukan harga pasar sebagai kompensasi, dan ada kasus hukum di mana kontrak kerja diakui dengan kompensasi yang setara dengan harga pasar karena pengguna telah menyetujui konten sistem dan “jumlah kompensasi yang kasar”.

Agar dapat dikatakan bahwa “negosiasi telah dilakukan”, vendor harus mencatat bahwa mereka telah mempertimbangkan secara memadai tentang konten pekerjaan pengguna, konten sistem, dll. dengan berdiskusi dengan pengguna, dll. dalam email atau catatan rapat, dll.

Vendor Menyajikan Spesifikasi dan Penawaran, dll., dan Pengguna Menyetujui dan Memesan

  • Jika pengguna mengeluarkan pesanan atau pesanan, kesepakatan kontrak akan lebih mudah diakui. Jika vendor mengajukan permintaan atau melakukan pekerjaan berdasarkan pesanan, dll., Kesepakatan kontrak akan lebih mudah diakui karena ada “kesepakatan”.
  • Surat internal pengguna sering berisi konten tentang rencana penandatanganan kontrak di masa depan, dan kesepakatan kontrak mungkin sulit diakui. Namun, jika tidak ada catatan seperti itu dan elemen kontrak seperti konten pengembangan sistem dan jumlah kompensasi dicantumkan secara spesifik sebisa mungkin, itu akan berfungsi untuk mengakui kesepakatan kontrak.
  • Jika memorandum, perjanjian, atau surat konfirmasi diasumsikan untuk menandatangani kontrak terpisah atau berisi konten abstrak, kesepakatan kontrak mungkin sulit diakui.
  • Jika stempel tidak ditekan pada draf kontrak, artinya penandatanganan dengan stempel, dan kesepakatan kontrak mungkin sulit diakui.
  • Penawaran adalah bukti untuk mengakui jumlah kompensasi yang disepakati antara para pihak.

Untuk detail tentang apakah Anda dapat mengajukan klaim tambahan atas jumlah perkiraan awal jika Anda diminta untuk mengubah spesifikasi atau menambahkan fungsi setelah proses pengembangan sistem telah maju sejauh ini, lihat artikel di bawah ini.

https://monolith.law/corporate/increase-of-estimate[ja]

Kesepakatan Penyelesaian

Jika Anda melakukan pekerjaan berdasarkan instruksi dari pengguna dengan asumsi penandatanganan kontrak, “kesepakatan penyelesaian” untuk menyelesaikan kompensasi untuk pekerjaan hingga saat itu mungkin diakui ketika pekerjaan dihentikan. Untuk membuat kesepakatan ini lebih mudah diakui, Anda harus mendapatkan pengguna untuk mencatat metode penyelesaian kompensasi jika kontrak tidak ditandatangani dalam surat internal, dll., atau mendapatkan persetujuan dari orang yang berwenang pengguna untuk dokumen yang dibuat oleh vendor.

Konstruksi Hukum untuk Mengklaim Uang Jika Kontrak Tidak Dapat Dibentuk

Apa yang terjadi jika kontrak tidak dapat dibentuk?

Kesalahan dalam Pembentukan Kontrak

Ketika negosiasi dimulai untuk membentuk kontrak, kedua belah pihak memiliki kewajiban berdasarkan prinsip kepercayaan (Pasal 1 Ayat 2 dari Hukum Sipil Jepang) untuk berusaha tidak merusak properti pihak lain. Jika kontrak tidak dapat dibentuk, Anda dapat mengajukan klaim ganti rugi jika ada keadaan objektif yang membuat pihak lain berharap kontrak akan dibentuk dan ada kesalahan. Ini disebut kesalahan dalam pembentukan kontrak.

Berikut adalah ringkasan kasus di mana kesalahan dalam pembentukan kontrak diakui dalam putusan pengadilan.

  • Vendor telah menyelesaikan definisi persyaratan atas permintaan pengguna dan telah melaksanakan sebagian dari desain dasar dan detail. Meskipun dijelaskan bahwa tindakan mengundang perusahaan lain untuk mengajukan penawaran adalah formalitas untuk mendapatkan persetujuan dari presiden, perusahaan lain dipilih tepat sebelum kontrak ditandatangani dan kontrak tidak dapat dibentuk.
  • Vendor telah melanjutkan pekerjaan atas permintaan pengguna untuk mematuhi tenggat waktu, dan tanggal penandatanganan kontrak juga telah ditentukan. Meskipun persiapan untuk pengembangan internal sedang dilakukan di dalam perusahaan pengguna, hal ini disembunyikan dan kontrak tidak dapat dibentuk.
  • Vendor telah diberitahu oleh pengguna bahwa mereka telah memilih kontraktor pembangunan, dan tidak ada pertanyaan tentang penawaran, dan pekerjaan seperti penentuan spesifikasi berdasarkan pertemuan dengan pengguna telah dilakukan, dan pengguna juga menyadari tentang pengeluaran biaya. Namun, penandatanganan kontrak ditolak dengan alasan bahwa jumlah penawaran tidak dapat disepakati.

Sebaliknya, ada kasus di mana kesalahan dalam pembentukan kontrak tidak diakui dalam putusan pengadilan, seperti ketika kemungkinan pemilihan perusahaan lain dan kondisi untuk membentuk kontrak telah dinyatakan secara eksplisit.

Jika Anda telah melanjutkan pekerjaan atas permintaan pengguna, dan tanpa diberitahu tentang kemungkinan pemilihan perusahaan lain atau kondisi kesepakatan, negosiasi kontrak dibatalkan secara mendadak dengan alasan tersebut, Anda mungkin dapat mengajukan klaim ganti rugi.

Tidak ada perselisihan bahwa biaya yang telah dikeluarkan hingga saat itu termasuk dalam “kerugian” dalam hal ini. Selain itu, ada putusan pengadilan yang menyatakan bahwa keuntungan dari pekerjaan yang sebenarnya dilakukan juga termasuk. Juga, jika Anda dapat memberikan bukti bahwa Anda telah menderita kerugian setara dengan keuntungan yang akan diperoleh jika Anda telah menolak aplikasi dari perusahaan lain dan melanjutkan pekerjaan setelah itu, itu juga dapat termasuk.

Pasal 512 Hukum Dagang Jepang

Jika vendor telah melakukan tindakan terkait pengembangan sistem untuk pengguna, mereka dapat mengklaim kompensasi yang wajar berdasarkan Pasal 512 dari Hukum Dagang Jepang.

Ketika Anda mulai bernegosiasi tentang pengembangan sistem, Anda harus saling mengakui konten sistem dan jumlah kompensasi menggunakan email atau catatan rapat, dan meninggalkan bukti yang mengakui bahwa keadaan yang membuat Anda yakin bahwa kontrak akan dibentuk dan elemen kontrak telah dikonkretkan.

Bahkan jika pembayaran ditolak dengan alasan seperti tidak ada kontrak yang ditandatangani, Anda mungkin masih dapat mengklaim uang seperti yang dijelaskan di atas.

Kesimpulan

Dengan demikian, dapat dikatakan bahwa pengadilan cenderung membuat penilaian yang ‘negatif’ terhadap hubungan kontrak ketika tidak ada dokumen kontrak, setidaknya dibandingkan dengan persepsi perusahaan yang menerima tugas. Dari sudut pandang perusahaan yang menerima tugas, mereka mungkin ingin mengatakan, “Saya seharusnya bisa menandatangani kontrak setelah saya mulai bekerja, dan kontrak itu sendiri sudah ada,” namun argumen ini tidak selalu diterima.

Juga, jika pembentukan kontrak ditolak, ada kasus di mana Anda dapat meminta uang berdasarkan konstitusi hukum seperti kelalaian dalam pembentukan kontrak dan Pasal 512 dari Hukum Dagang Jepang, tetapi ini juga bukan hal yang ‘pasti’.

Jika Anda harus memulai pekerjaan sebelum menandatangani kontrak, Anda perlu:

  • Mempertimbangkan apakah Anda harus menggunakan waktu untuk proyek tersebut, meskipun itu adalah tindakan berisiko dan Anda mempertimbangkan risiko tersebut (terutama dalam kasus perusahaan kecil dan menengah dan startup, ada situasi di mana Anda harus membuat keputusan bisnis untuk ‘bergerak lebih dulu’ untuk mendapatkan rekam jejak transaksi dengan perusahaan besar. Jika risiko tersebut telah diperhitungkan, ini adalah keputusan bisnis yang mungkin.)
  • Mempertimbangkan apakah Anda dapat menandatangani perjanjian penyelesaian atau sejenisnya jika kontrak tidak terbentuk

Dapat dikatakan bahwa Anda perlu melakukan pemikiran seperti ini.

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