Tentang Undang-Undang dan Kes Perbicaraan yang Berkaitan dengan Perbezaan Antara Penghantaran dan Kontrak dalam Industri IT

Dalam projek IT, sering kali kita melihat banyak tenaga kerja dari pelbagai syarikat dikerah untuk satu projek. Dalam situasi seperti ini, tempat kerja jurutera yang terlibat dalam projek sering kali berbeza dari lokasi syarikat yang mereka sertai. Ini merangkumi situasi seperti penempatan tetap di tempat pelanggan dan SES. Keadaan kerja dan kontrak jurutera yang bekerja di lapangan menjadi kabur boleh membawa risiko pertikaian mengenai hak pekerja di masa depan, dan juga boleh menjadi risiko kepada projek itu sendiri. Dalam artikel ini, kami akan menerangkan perbezaan antara penghantaran dan kontrak, yang sering kali menjadi kabur dalam praktik, dan bagaimana masalah sekitar kontrak ini boleh mempengaruhi kelancaran keseluruhan projek.

Perbezaan Antara Penghantaran dan Kontrak

Apabila syarikat yang menerima kerja (atau vendor yang diberi kontrak semula) dan syarikat yang memberi kerja berbeza, adalah biasa untuk menghantar tenaga kerja ke tempat kerja berdasarkan kontrak. Dengan kata lain, pihak yang menerima pesanan/vendor masuk dan menghantar jurutera ke tempat kerja. Untuk maklumat lanjut tentang apa itu kontrak, sila rujuk artikel di bawah.

https://monolith.law/corporate/system-development-contact-agreement[ja]

Artikel di atas menjelaskan bahawa “penyelesaian kerja” adalah syarat utama untuk melaksanakan kontrak. Juga, menjelaskan bahawa penting untuk menentukan syarat lulus pemeriksaan pada masa kontrak ditandatangani untuk mengelakkan masalah. Jika anda menghantar orang ke tempat kerja berdasarkan kontrak, ini adalah transaksi komersial antara syarikat dan syarikat, jadi tidak ada kewajipan untuk mematuhi undang-undang buruh bagi pihak yang menerima pesanan/tempat kerja. Walau bagaimanapun, sebagai gantinya, anda tidak dibenarkan memberi arahan langsung kepada jurutera tersebut. Jika anda tidak mempertimbangkan perkara ini, walaupun anda telah menandatangani kontrak, anda mungkin berisiko dituduh menjalankan perniagaan penyerahan pekerja yang tidak sah, atau “kontrak palsu”.

https://monolith.law/corporate/criteria-for-disguised-contract[ja]

Kes yang berkembang menjadi konflik kerana perbezaan antara penghantaran dan kontrak menjadi kabur

Untuk perbincangan umum mengenai “Kontrak Pengambilan”, “Pengambilan Palsu” dan sebagainya, kita akan merujuk kepada kandungan di atas. Apa yang akan kita bahas di bawah ini adalah kes di mana projek telah gagal kerana perbezaan antara penghantaran dan kontrak menjadi kabur. Keadaan di mana perbezaan ini menjadi kabur bukan sahaja boleh membawa kepada pelanggaran hak pekerja individu dan konflik antara pekerja dan majikan, tetapi juga boleh menjadi risiko kegagalan keseluruhan projek. Ini mungkin lebih mudah difahami jika anda memeriksa perkara berikut.

Keperluan Pelaksanaan Hutang Berbeza Secara Drastik Antara Penghantaran dan Kontrak

Penghantaran dan kontrak adalah serupa dalam hal syarikat memasukkan tenaga kerja ke dalam projek pembangunan. Namun, seperti yang telah disebutkan sebelum ini, dalam kontrak, pelaksanaan hutang secara prinsip tidak akan diakui kecuali ‘penyelesaian kerja’ diakui. Dalam kes yang dirujuk di bawah, isu utama adalah sama ada tuntutan bayaran dapat diterima apabila projek akhirnya gagal. Dalam kontrak, ‘penyelesaian kerja’ dikenakan sebagai syarat, manakala dalam penghantaran, upah kerja dapat dibenarkan hanya dengan prestasi sebenar seperti jam kerja.

Pihak yang menerima pesanan / vendor (plaintif) menegaskan bahawa kontrak penghantaran telah ditandatangani setelah fakta, dan tenaga kerja telah dihantar dalam bentuk penghantaran. Mereka menegaskan bahawa ‘penyelesaian kerja’ tidak dikenakan sebagai kewajipan. Namun, mahkamah menolak dakwaan tersebut (bahagian yang digarisbawahi dan tebal adalah tambahan oleh penulis).

Plaintif, setelah kegagalan pengembangan program sistem ini oleh plaintif telah ditentukan, pada 1 April tahun Showa 61 (1986), antara plaintif dan defendan, mengenai kos pengembangan, dua bahagian dan elaun pelaksanaan perkhemahan sejumlah 710,600 yen dikurangkan menjadi 550,000 yen dan defendan akan membayar kepada plaintif dengan segera, dan defendan akan mengambil alih kerja plaintif sejak 1 April, dan mengenai pengembangan sistem informasi teks oleh defendan, ia akan dilaksanakan dengan menghantar tenaga kerja dalam bentuk penghantaran tenaga kerja dari plaintif, dan tenaga kerja yang dihantar adalah tiga orang, dan harga adalah 55,000 yen untuk dua orang, dan 30,000 yen untuk satu orang, dan mereka bersetuju, dan hasil soal siasat wakil plaintif adalah konsisten dengan ini.
Namun, defendan menafikan bahawa perjanjian seperti itu telah dibuat, dan plaintif, pada asalnya, telah mengambil kontrak dari defendan untuk membuat program sistem ini, dan mereka mempunyai kewajipan untuk menyelesaikannya, dan orang yang berada dalam kedudukan seperti itu tidak dapat menyelesaikan dan tidak dapat menyerahkan program, defendan, yang adalah pemesan, menegaskan bahawa tidak mungkin untuk melakukan perkara yang tidak masuk akal seperti membebaskan plaintif dari kewajipan pembuatan selanjutnya dan membayar kos yang diperlukan oleh plaintif dalam tempoh tersebut. Memang, jika plaintif mempunyai kewajipan untuk menyelesaikan program, apa yang defendan dakwa adalah benar.
Oleh itu, pertama-tama, dalam kontrak pengembangan program sistem ini, sama ada plaintif mempunyai kewajipan untuk menyelesaikannya atau tidak akan diperiksa.
(Omitted) Melihat bukti, dalam kontrak ini, tidak dapat menemui bukti yang dapat mengakui bahawa plaintif tidak mempunyai kewajipan untuk menyelesaikan program ini. (Omitted) Dan, dalam hasil soal siasat wakil plaintif, kontrak ini adalah kontrak serentak, dan program akan dibangunkan di dalam syarikat plaintif, dan plaintif, mengandaikan bahawa mereka mempunyai kewajipan untuk menyelesaikan program ini, dan mereka tidak pernah menafikan bahawa mereka mempunyai kewajipan tersebut, jelas. Melihat bukti tulisan, tidak ada pertikaian tentang pembentukan (omitted) jadual kerja, dan ia adalah sesuatu yang mengandaikan bahawa plaintif mempunyai kewajipan untuk menyelesaikan program ini, dan menyatakan jadual hingga penyelesaiannya, oleh itu, menurut ini, sebaliknya, dapat diakui bahawa plaintif mempunyai kewajipan untuk menyelesaikan program berdasarkan kontrak. (Omitted)
Selain itu, tidak ada bukti yang bertentangan dengan pengakuan bahawa plaintif mempunyai kewajipan untuk menyelesaikan program ini.
Jika demikian, seperti yang defendan dakwa, orang yang tidak membuat program yang mereka mempunyai kewajipan untuk menyelesaikan, mempunyai tanggungjawab untuk tidak melaksanakan hutang, dan tidak dapat meminta pembayaran kontrak, adalah semestinya, dan kecuali ada keadaan khusus, tidak mungkin bagi pemesan untuk membebaskan mereka dari kewajipan kontrak tanpa syarat, dan lebih lagi, untuk membayar kos yang mereka perlukan hingga saat itu. Wakil plaintif, dalam hasil soal siasatnya, mengatakan bahawa walaupun program tidak selesai, jika mereka bekerja mengikut arahan pemesan, mereka telah mematuhi janji mereka untuk melakukan kerja dalam lingkup yang ditunjukkan dalam tempoh tersebut, jadi mereka boleh meminta bayaran perisian komputer untuk kerja yang mereka lakukan, tetapi ini adalah pernyataan yang bertentangan dengan pengetahuan umum tentang kontrak, dan dalam industri plaintif dan defendan yang mengembangkan perisian, tidak dapat diakui bahawa ada kebiasaan untuk membayar upah walaupun tidak ada penyelesaian kerja, berbeza dengan pengetahuan umum, dalam kontrak, oleh itu, hasil soal siasat wakil plaintif adalah pandangan uniknya, dan tidak dapat diterima.

Keputusan Mahkamah Tokyo, 22 Februari tahun Heisei 23 (2011)

Apa yang dapat kita baca dari kes mahkamah di atas

Yang patut diberi perhatian dalam kes mahkamah di atas adalah,

1. Bukan melepaskan tanggungjawab ‘penyelesaian kerja’ vendor berdasarkan penandatanganan kontrak penghantaran yang permukaan dan formal, tetapi berdasarkan kandungan janji konkrit kedua-dua pihak tentang ‘penyelesaian kerja’, mereka mengharapkan penyelesaian pertikaian yang adil secara substansial.
2. Dari sudut pandang yang menganggap ‘penyelesaian kerja’ sebagai syarat pelaksanaan hutang, kontrak tersebut dianggap sebagai kontrak perolehan, dan dalam isu lain juga, keputusan harus dibuat berdasarkan adat perdagangan dalam industri yang berkaitan dengan kontrak perolehan.

Ini adalah beberapa poin yang boleh dipertimbangkan.

Jika kita ringkaskan kedua-dua poin ini secara ringkas, lebih daripada tajuk kontrak permukaan, persetujuan substansial antara kedua-dua pihak diberi penekanan dalam perbicaraan. Selain itu, setelah substansi kontrak dianggap sebagai kontrak perolehan, penyelesaian berdasarkan adat perdagangan dalam industri yang berkaitan dengan kontrak perolehan diharapkan untuk isu lain. Penolakan tuntutan pihak yang menerima pesanan / vendor dengan menggunakan frasa seperti “pernyataan yang bertentangan dengan pengetahuan umum tentang kontrak perolehan”, “pandangan sendiri” menunjukkan hal ini secara ringkas dan sangat khas. Adalah penting untuk memberi perhatian kepada fakta bahawa norma sosial dan konsep sosial dipantulkan dalam interpretasi undang-undang dan dapat mempengaruhi amalan undang-undang. By the way, konsep ‘penyelesaian kerja’ yang sangat penting dalam penghakiman ini dijelaskan secara terperinci dalam artikel berikut dengan mempertimbangkan konteks pembangunan sistem.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

Mengingat bahawa kontrak perolehan sering digunakan dalam amalan projek pembangunan sistem dan elemen asasnya adalah ‘penyelesaian kerja’, anda harus memahaminya dengan mendalam.

Pemahaman mengenai Tanggungjawab Pengurusan Projek juga ditanya sebagai prasyarat

Selain itu, keputusan ini juga berkaitan erat dengan ‘Tanggungjawab Pengurusan Projek’ yang harus dipikul oleh pihak vendor yang merupakan pakar dalam pembangunan sistem. Penjelasan umum mengenai tanggungjawab ini telah dibuat dalam artikel berikut.

https://monolith.law/corporate/project-management-duties[ja]

Mengambil kira kandungan artikel di atas, jelas bahawa tanggungjawab vendor yang menerima kerja dalam kedudukan sebagai pakar projek pembangunan sistem bukanlah sesuatu yang ringan. Memang benar, ada beberapa situasi di mana kerjasama dari pihak pengguna diperlukan untuk kelancaran projek. Namun, adalah sukar untuk membayangkan bahawa tanggungjawab ini akan dikecualikan tanpa usaha seperti meminta kerjasama yang diperlukan dari pengguna pada masa yang sesuai. Adalah sukar untuk menyalahkan pihak pengguna jika projek gagal dari perspektif ini. Keabsahan keputusan di atas mungkin lebih mudah dirasai jika pemahaman mengenai pengurusan projek ini adalah prasyarat. Sebaliknya, mungkin ada beberapa aspek yang membuat struktur teori yang menganggap realiti transaksi bukan sebagai penghantaran tetapi sebagai perolehan lebih mudah diterima untuk mencapai kesesuaian dengan kesimpulan yang wajar yang diperoleh dari perspektif ini.

Rumusan

Sebagai kesimpulan, kami telah menerangkan tentang konflik projek yang mungkin berlaku apabila perbezaan antara penghantaran dan kontrak adalah kabur. Dalam kes-kes tersebut, lebih penting untuk memberi tumpuan kepada substansi seperti janji-janji konkrit yang telah dipertukarkan antara kedua-dua pihak dan adat kebiasaan dalam industri daripada tajuk formal kontrak. Selain itu, bukan sahaja perbincangan undang-undang mengenai jenis kontrak yang telah ditandatangani secara individu, sama ada ia adalah penghantaran atau kontrak, tetapi juga pengetahuan tentang “Tanggungjawab Pengurusan Projek” yang mendasari semua ini tampaknya penting. Dalam projek IT, penggunaan tenaga kerja melalui kaedah seperti penghantaran dan kontrak, serta penempatan dan kuasa wakil adalah biasa. Untuk perbezaan dan perbezaan umum yang mengambil kira semua ini, sila rujuk artikel di bawah untuk penjelasan terperinci.

https://monolith.law/corporate/difference-contract-dispatch-loan-labor-supply[ja]

Perbezaan antara penghantaran dan kontrak bukan sahaja, tetapi juga variasi konflik yang bermula dari kekaburan jenis kontrak dapat dijangka. Walau bagaimanapun, walaupun kes yang perlu ditangani adalah yang tidak diketahui, apa yang penting adalah pengetahuan tentang perkara-perkara asas seperti “Tanggungjawab Pengurusan Projek”.