Apa itu Tanggung Jawab Ketidaksesuaian Kontrak dalam Pengembangan Sistem dan Perangkat Lunak? Penjelasan tentang Poin Revisi

Jika terdapat kesalahan setelah sistem yang dipesan diserahkan, bagaimana cara mengatasinya dari segi hukum?

Metode operasional yang sulit, kecepatan pemrosesan yang lambat, fungsi yang dipesan tidak tersedia… Sebagai pemesan, Anda akan menuntut ‘Tanggung Jawab Ketidaksesuaian Kontrak’ kepada vendor yang melakukan pengembangan sistem terhadap masalah sistem seperti ini.

‘Tanggung Jawab Ketidaksesuaian Kontrak’ adalah hukum baru yang dibuat menggantikan ‘Tanggung Jawab Jaminan Cacat’ yang dihapus oleh revisi Hukum Sipil Jepang (Japanese Civil Law) pada tahun 2017 (Gregorian calendar year). Oleh karena itu, perlu diperhatikan bagaimana perubahan ini mempengaruhi pengembangan sistem dan perangkat lunak.

Masalah yang sering terjadi setelah penyerahan. Untuk menghindari masalah seperti ini, kami akan menjelaskan isi ‘Tanggung Jawab Ketidaksesuaian Kontrak’ dan dampak perubahannya.

Poin Perubahan Hukum Perdata Mengenai Tanggung Jawab Ketidaksesuaian Kontrak

Undang-undang yang mengubah sebagian dari ‘Hukum Perdata Jepang’ telah diumumkan pada tanggal 2 Juni 2017 (Tahun Heisei 29) dan mulai diberlakukan sejak 1 April 2020.

Bagian dari Hukum Perdata Jepang yang menetapkan aturan dasar terkait kontrak dan sejenisnya disebut ‘Hukum Kredit’.

Hukum Kredit ini sejak ditetapkan pada tahun 1896 (Tahun Meiji 29) hampir tidak pernah direvisi selama kurang lebih 120 tahun.

Oleh karena itu, revisi besar-besaran kali ini dilakukan untuk menyesuaikan dengan masyarakat saat ini.

Poin perubahan yang spesifik sangat beragam, namun di antaranya, penambahan konsep baru yaitu tanggung jawab ketidaksesuaian kontrak adalah salah satu poin utama perubahan ini.

Dengan ini, yang sebelumnya disebut ‘tanggung jawab jaminan cacat’ kini berubah menjadi ‘tanggung jawab ketidaksesuaian kontrak’.

Apa itu Ketidaksesuaian Kontrak

‘Ketidaksesuaian Kontrak’ adalah situasi di mana fungsi, kualitas, kinerja, atau kondisi yang seharusnya ada tidak tersedia sesuai dengan kesepakatan atau tujuan dan sifat kontrak antara pihak-pihak yang terlibat.

‘Ketidaksesuaian Kontrak’ ini diperkenalkan sebagai pengganti ‘Cacat’ yang sebelumnya ada, berdasarkan revisi Hukum Sipil Jepang (Hukum Sipil Jepang).

Dalam pengembangan sistem atau perangkat lunak, ‘Ketidaksesuaian Kontrak’ dapat terjadi jika sistem yang telah selesai tidak sesuai dengan spesifikasi yang telah ditentukan sebelumnya, atau jika sistem atau perangkat lunak tidak memiliki fungsi atau kinerja yang seharusnya dimiliki sesuai dengan sifatnya.

Dalam menentukan apakah ada ‘Ketidaksesuaian Kontrak’ atau tidak, kesepakatan antara pihak-pihak yang terlibat dan tujuan serta sifat kontrak menjadi faktor yang sangat penting.

Oleh karena itu, sangat penting untuk mencatat tujuan pengembangan sistem atau perangkat lunak dan latar belakang pemesanan, dan untuk menjelaskan apa harapan dan gambaran yang dimiliki oleh pemesan.

Kasus di mana kerusakan perangkat lunak dll. sesuai dengan “Ketidaksesuaian Kontrak”

Ketika ada gangguan pada perangkat lunak dan perbaikan tertunda

Pertama, kita dapat mempertimbangkan kasus di mana terjadi kerusakan yang tidak dapat dianggap sepele pada perangkat lunak, dan tidak dapat ditangani dengan cepat, seperti perlu meninjau kembali hingga tahap desain untuk perbaikannya.

Sebagai contoh, ada putusan pengadilan yang mengakui bahwa kasus di mana gangguan terjadi, seperti proses pencarian sistem pengecekan stok yang telah diterapkan membutuhkan waktu lebih dari 30 menit, dan harus menangani pertanyaan dari pelanggan dengan membuat buku stok tulisan tangan secara terpisah, sesuai dengan “cacat” dalam “Ketidaksesuaian Kontrak” saat ini (Putusan Pengadilan Distrik Tokyo, 22 April 2002 (Tahun Heisei 14)).

Ketika kerusakan muncul secara bertahap

Selanjutnya, kita juga dapat mempertimbangkan kasus di mana meskipun setiap kerusakan adalah ringan dan tidak membutuhkan waktu lama untuk diperbaiki, kerusakan terus muncul berulang kali, dan membutuhkan waktu lama untuk memperbaiki semua kerusakan dan membuatnya berfungsi dengan normal.

Sebagai contoh, jika sistem pengecekan stok yang telah diterapkan terus mengalami kerusakan berulang kali, dan tidak jelas sejauh mana kerusakan akan terjadi di masa depan, dan berapa lama waktu yang dibutuhkan untuk memperbaikinya, dan jika tidak dapat melakukan operasi bisnis normal dengan menggunakan sistem, itu dapat dikatakan sebagai “Ketidaksesuaian Kontrak”.

Kasus di mana kerusakan perangkat lunak tidak termasuk dalam ‘Ketidaksesuaian Kontrak’

Jika diperbaiki tanpa penundaan atau jika tindakan penggantian telah diambil

Dalam putusan pengadilan, meskipun ada bug atau kerusakan lainnya yang ditunjukkan oleh pengguna, jika diperbaiki tanpa penundaan atau jika tindakan penggantian yang dianggap wajar setelah berdiskusi dengan pengguna telah diambil, ini tidak dianggap sebagai ‘cacat’ (Putusan Pengadilan Distrik Tokyo, 18 Februari 1997 (Tahun Heisei 9)).

Dalam pengembangan sistem atau perangkat lunak, tidak mungkin untuk memprogram sehingga tidak ada bug sama sekali, dan tidak dapat dihindari bahwa beberapa kerusakan akan terjadi.

Oleh karena itu, meskipun ada kerusakan, jika tindakan seperti perbaikan tanpa penundaan telah diambil, ini tidak seharusnya dianggap sebagai ‘cacat’.

Hal ini dapat dipikirkan dengan cara yang sama di bawah ‘Ketidaksesuaian Kontrak’ saat ini.

Perlu dicatat bahwa dasar untuk menentukan ‘tanpa penundaan’ dan sejenisnya adalah bukti seperti catatan rapat yang dibuat selama proses pengembangan sistem.

Artikel berikut menjelaskan secara detail tentang pentingnya ini.

Jika individu tertentu tidak dapat dengan mudah memahami cara operasi

Mengenai operabilitas dan kemudahan penggunaan, karena sebagian besar bergantung pada subjektivitas, jika tidak dapat digunakan oleh pengguna umum, ini akan dinilai sebagai ‘Ketidaksesuaian Kontrak’.

Hanya karena individu tertentu tidak dapat dengan mudah memahami cara operasi, ini tidak dapat dikatakan sebagai ‘Ketidaksesuaian Kontrak’.

Jika kerusakan terjadi karena alasan di luar pekerjaan vendor

Jika kerusakan terjadi karena alasan yang tidak ada hubungannya dengan pekerjaan pengembangan seperti pengembangan sistem atau perangkat lunak oleh vendor, ini tidak dapat dikatakan bahwa sistem atau perangkat lunak itu sendiri memiliki ‘Ketidaksesuaian Kontrak’.

Misalnya, jika kerusakan terjadi karena masalah perangkat keras yang bukan tanggung jawab vendor untuk memperolehnya, ini tidak akan dinilai sebagai ‘Ketidaksesuaian Kontrak’.

[Tambahan] Jika kerusakan terjadi karena instruksi pengguna

Jika kerusakan terjadi pada sistem atau perangkat lunak yang telah selesai karena instruksi yang salah dari pengguna, bahkan jika sistem dan sejenisnya diakui memiliki ‘Ketidaksesuaian Kontrak’, vendor pada prinsipnya tidak bertanggung jawab atas Ketidaksesuaian Kontrak.

Misalnya, dalam pengembangan sistem bisnis, jika penjelasan yang salah diberikan tentang situasi yang hanya diketahui oleh pengguna, dan kerusakan terjadi pada perangkat lunak yang dikembangkan berdasarkan spesifikasi yang disepakati dengan informasi yang salah ini, vendor tidak bertanggung jawab sama sekali.

Di balik keputusan ini, dapat dipikirkan bahwa ada pemikiran bahwa pengguna, sebagai pemesan pengembangan perangkat lunak, juga memiliki ‘kewajiban kerjasama’. Untuk detailnya, silakan lihat artikel berikut.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Hal-hal yang dapat diajukan oleh pemilik proyek/pembeli berdasarkan tanggung jawab ketidaksesuaian kontrak

Di sini, kami akan menjelaskan tentang isi tanggung jawab ketidaksesuaian kontrak yang berkaitan dengan pengembangan sistem dan perangkat lunak, termasuk perubahan yang dihasilkan dari revisi.

Permintaan Perbaikan

Jika kerusakan dinilai sebagai ketidaksesuaian kontrak, permintaan perbaikan dapat diajukan oleh pemberi pesanan.

Sebelum revisi, permintaan perbaikan tidak dapat diajukan jika cacat yang menjadi masalah tidak penting dan memerlukan biaya yang berlebihan untuk perbaikan. Namun, batasan ini telah dihapus dengan revisi.

Namun, bahkan setelah revisi, jika “ketidaksesuaian kontrak tidak penting dan memerlukan biaya yang berlebihan untuk perbaikan”, permintaan perbaikan mungkin tidak diakui karena perbaikan tidak mungkin dilakukan.

Permintaan Ganti Rugi

Jika sistem atau perangkat lunak yang bermasalah menyebabkan tidak dapat melakukan bisnis normal atau mengeluarkan biaya tambahan, permintaan ganti rugi dapat diajukan oleh pemberi pesanan.

Sebelum revisi, permintaan ganti rugi dapat diajukan tanpa mempertimbangkan adanya kelalaian kecuali ada perjanjian khusus.

Namun, dengan revisi, jika ada alasan pembebasan (alasan yang tidak dapat diatribusikan kepada debitur) bagi pelaksana, permintaan ganti rugi tidak dapat diajukan.

Oleh karena itu, jika vendor dapat membuktikan alasan pembebasan, mereka tidak akan bertanggung jawab atas ganti rugi.

Pembatalan Kontrak

Kontrak pengembangan dapat dibatalkan dengan alasan ketidaksesuaian kontrak sistem atau perangkat lunak.

Dalam kasus yang telah kami perkenalkan, ada kerusakan yang menyebabkan waktu pemrosesan pencarian sistem konsultasi stok lebih dari 30 menit dan waktu pemrosesan terlalu lama, dan ada juga gangguan yang membuat penggunaan terminal itu sendiri tidak mungkin, sehingga mereka harus menyerah pada penggunaan sistem yang telah diterapkan, dan pembatalan kontrak diakui (Putusan Pengadilan Distrik Tokyo, 22 April 2002 (Tahun Heisei 14)).

Sebelum revisi, kontrak dapat dibatalkan hanya jika “tujuan kontrak tidak dapat dicapai” karena cacat. Namun, batasan ini telah dihapus dengan revisi.

Namun, perlu diperhatikan bahwa bahkan di bawah hukum revisi, pembatalan tidak diakui jika tingkat ketidaksesuaian kontrak “ringan”.

Permintaan Pengurangan Biaya

Hak untuk meminta pengurangan biaya telah ditambahkan dengan revisi.

Jika ada masalah dengan sistem dan pemberi pesanan meminta perbaikan, tetapi perbaikan tidak dilakukan meskipun waktu yang cukup telah berlalu, permintaan pengurangan biaya dapat diajukan oleh pemberi pesanan.

Periode Tanggung Jawab

• Permintaan Perbaikan
• Permintaan Ganti Rugi
• Pembatalan Kontrak
• Permintaan Pengurangan Biaya

Ada batasan waktu untuk melaksanakan hak-hak ini.

Secara khusus, hak dapat dilaksanakan hanya jika pemberi pesanan memberi tahu vendor tentang adanya ketidaksesuaian kontrak dalam sistem atau perangkat lunak “dalam waktu satu tahun sejak mengetahuinya”.

Sebelum revisi, periode pelaksanaan hak dibatasi “dalam waktu satu tahun sejak sistem atau perangkat lunak diserahkan”. Oleh karena itu, dapat dikatakan bahwa periode di mana hak dapat dilaksanakan telah diperpanjang dengan revisi.

Selain itu, selain batasan waktu ini, hak yang diakui berdasarkan tanggung jawab ketidaksesuaian kontrak juga diterapkan pada ketentuan preskripsi pemusnahan.

Oleh karena itu, misalnya, jika Anda pertama kali mengetahui adanya kerusakan 11 tahun setelah menerima pengiriman sistem atau perangkat lunak, hak seperti hak klaim ganti rugi telah melewati periode preskripsi pemusnahan “sepuluh tahun”, sehingga Anda tidak dapat melaksanakan hak, terlepas dari apakah Anda memberi tahu tentang ketidaksesuaian kontrak “dalam waktu satu tahun sejak mengetahuinya”.

Penolakan Pembayaran Biaya

Pemberi pesanan dapat menolak pembayaran biaya penuh sampai pengembang melakukan perbaikan atau ganti rugi.

Poin-Poin dalam Ketentuan Kontrak dengan Pertimbangan Ketidaksesuaian Kontrak

Ketentuan tentang tanggung jawab ketidaksesuaian kontrak adalah ketentuan opsional, dan dengan perjanjian khusus antara para pihak, dapat membatasi isi tanggung jawab atau memperpendek periode pelaksanaan hak.

Oleh karena itu, di sini kami akan menjelaskan ketentuan kontrak yang harus diperhatikan dalam hubungannya dengan tanggung jawab ketidaksesuaian kontrak dalam pengembangan sistem dan perangkat lunak.

Poin 1: Peristiwa dan Ruang Lingkup yang Menjadi Subjek Ketidaksesuaian Kontrak

Jika ada ketidakpuasan dengan sistem atau perangkat lunak, pemesan mungkin ingin menuntut tanggung jawab ketidaksesuaian kontrak kepada vendor.

Namun, sebagai vendor, tidak dapat diterima jika dituntut tanggung jawab ketidaksesuaian kontrak hanya karena mereka tidak menyukai sesuatu yang hanyalah spesifikasi.

Selain itu, vendor mungkin akan meningkatkan perkiraan secara signifikan untuk mempersiapkan penuntutan tanggung jawab ketidaksesuaian kontrak yang tidak adil, yang merugikan pemesan.

Oleh karena itu, penting untuk menunjukkan secara tertulis tujuan apa yang dimiliki pemesan, sistem apa yang ingin mereka implementasikan dengan fungsi apa, dll., untuk menjelaskan peristiwa dan ruang lingkup yang menjadi subjek ketidaksesuaian kontrak, dan untuk mencerminkannya dengan pasti dalam spesifikasi.

Juga, dapat dipertimbangkan untuk menjelaskan bahwa jika sistem atau perangkat lunak yang sesuai dengan item yang ditentukan dalam spesifikasi diserahkan, itu tidak akan menjadi ketidaksesuaian kontrak meskipun ada beberapa ketidaknyamanan dalam spesifikasi.

Dengan ketentuan ini, Anda dapat mencegah dituntut tanggung jawab ketidaksesuaian kontrak karena preferensi pemesan meskipun Anda telah mengembangkan sesuai dengan spesifikasi.

Poin 2: Penjelasan tentang Periode Garansi

Periode pelaksanaan hak tanggung jawab ketidaksesuaian kontrak dihitung “dari saat mengetahui” ketidaksesuaian kontrak, bukan “saat penyerahan” produk.

Selain itu, bahkan jika batas waktu pemusnahan diterapkan secara terpisah, periode tersebut adalah “sepuluh tahun” pada maksimumnya, dan berlangsung dalam jangka waktu yang lama.

Bagi vendor, tergantung pada situasinya, menjadi beban besar untuk harus memberikan garansi gratis selama “sepuluh tahun”, dan mereka harus menambahkannya pada tahap perkiraan.

Sebagai pemesan, tergantung pada periode penggunaan sistem atau perangkat lunak, mungkin lebih menguntungkan dari segi biaya untuk menetapkan periode garansi dengan fleksibilitas.

Oleh karena itu, dapat dipertimbangkan untuk menetapkan periode garansi dengan fleksibilitas sesuai dengan konten sistem, dll.

Poin 3: Penanganan Ketika Ketidaksesuaian Kontrak Terjadi

Ketika ketidaksesuaian kontrak terjadi, Anda dapat membatasi hak yang dapat dilakukan, seperti klaim ganti rugi atau pembatalan, yang diakui oleh hukum sipil, hanya pada beberapa bagian dengan persetujuan antara para pihak.

Sebagai pemesan, Anda perlu memahami dengan baik apa jenis pembatasan yang diterapkan dalam kontrak.

Kesimpulan: Konsultasikan dengan pengacara saat membuat kontrak yang mencakup ‘Tanggung Jawab Ketidaksesuaian Kontrak’

Perubahan dalam Hukum Sipil Jepang telah memberikan dampak besar pada aspek hukum pengembangan sistem dan perangkat lunak.

Jika terjadi masalah pada sistem yang telah diserahkan, apakah ini termasuk dalam ‘Ketidaksesuaian Kontrak’, dan tanggung jawab apa yang dapat dipertanyakan, tidak dapat dikatakan secara pasti.

Selain itu, untuk mencegah konflik sebelum terjadi, sangat penting untuk melakukan diskusi yang cukup antara pemesan dan vendor pada tahap kontrak pengembangan.

Jika Anda memiliki kekhawatiran tentang pembuatan kontrak, jangan ragu untuk berkonsultasi dengan pengacara yang berpengalaman.