Sejauh Mana Fungsi yang Tidak Tercatat dalam Spesifikasi Pembangunan Sistem Harus Dilaksanakan Menurut Undang-Undang?

Projek pembangunan sistem IT yang digunakan dalam syarikat pada dasarnya dibuat mengikut spesifikasi yang telah ditentukan sebelumnya. Namun, jika kita mempertimbangkan makna vendor yang diberi tanggungjawab penuh sebagai pakar dalam pembangunan sistem, harapan pengguna mungkin tidak rendah hanya dengan melaksanakan apa yang ditulis dalam spesifikasi secara mekanikal. Dalam artikel ini, kita akan membincangkan sejauh mana kewajipan untuk melaksanakan program yang “tidak ditulis dalam spesifikasi, tetapi perlu dilaksanakan berdasarkan tujuan pembangunan”.

Masalah Undang-Undang yang Berkaitan dengan Pelaksanaan yang Tidak Dalam Spesifikasi

Budi Bicara Diperlukan dalam Tugas Vendor

Salah satu ciri utama kontrak yang berkaitan dengan projek pembangunan sistem dan berbagai masalah undang-undang yang menyertainya adalah vendor yang menerima pekerjaan memiliki budi bicara yang besar.

Artikel Berkaitan: Apa itu Tanggung Jawab Pengurusan Projek dalam Pembangunan Sistem[ja]

Namun, ‘budi bicara’ yang dimaksudkan di sini tidak semestinya berlaku untuk semua proses pembangunan sistem. Setelah mengenal pasti setiap proses dan memajukan pengenalpastian tugas yang lebih terperinci, pekerjaan yang hampir sama dengan kerja-kerja mudah mungkin bertambah. Namun, secara umumnya, semakin awal dalam proses, iaitu semakin awal dalam proses hulu, semakin sukar untuk melaksanakan tugas tanpa budi bicara yang besar. Ini juga sebab mengapa kontrak jenis kuasa wakil adalah lebih sesuai untuk proses hulu.

Artikel Berkaitan: Perbezaan dan Perbandingan antara Kontrak Kerja dan Kontrak Kuasa Wakil dalam Pembangunan Sistem[ja]

Budi Bicara Harus Diperlihatkan dalam Proses Pembangunan yang Ketat

Namun, walaupun vendor yang membangunkan sistem mempunyai budi bicara yang besar, menerima permintaan pelanggan secara sembarangan akan membawa kerugian besar kepada proses seterusnya. Satu sistem IT dibina daripada kumpulan komponen yang kecil, jadi walaupun perubahan pada penampilan luaran mungkin kecil, dari sudut pandang pembangun, perubahan yang besar mungkin diperlukan dalam masa kerja. Selain itu, terdapat artikel yang menjelaskan cara mengurus perubahan dalam spesifikasi pembangunan sistem dari sudut pandang undang-undang. Artikel berikut menjelaskan cara mengurus perubahan, tetapi juga membincangkan bagaimana perubahan dalam spesifikasi dapat memberi kesan besar kepada kerja dari sudut pandang jurutera.

Artikel Berkaitan: Cara Mengurus Perubahan dalam Pembangunan Sistem dari Sudut Pandang Undang-Undang[ja]

Apa yang Harus Dilakukan Sebagai Pakar, Tanpa Terikat pada Spesifikasi?

Untuk memajukan projek pembangunan sistem dengan lancar, penting untuk menentukan keperluan pembangunan terlebih dahulu dan melaksanakannya secara terancang mengikut keperluan tersebut. Namun, ada juga situasi di mana anda tidak dapat memainkan peranan anda sepenuhnya sebagai pakar pembangunan sistem hanya dengan melakukan apa yang diperintahkan mengikut keperluan yang telah ditentukan sebelumnya. Dalam dilema seperti ini, masalah “apa yang harus dilaksanakan walaupun tidak ditunjukkan dalam spesifikasi” menjadi jelas.

Kewajipan mengikut undang-undang ditentukan berdasarkan ‘tujuan’ spesifikasi dan kontrak

Kandungan yang perlu dilaksanakan, walaupun tidak tercatat dalam kontrak atau spesifikasi, tetap ditentukan berdasarkan ‘tujuan’ item yang tercatat dalam kontrak atau spesifikasi tersebut, iaitu, ‘apa maksud dan niatnya, dan mengapa perjanjian tersebut dibuat’. Mari kita lihat beberapa contoh kes mahkamah di bawah ini.

Contoh Kehakiman di mana Kewajipan Pelaksanaan Ditolak kerana Tiada Penyataan

Contoh kehakiman yang dipetik di bawah ini adalah tentang sistem yang dibangunkan oleh vendor, yang telah maju ke tahap operasi sementara, tetapi perkara ini telah berkembang menjadi pertikaian kerana meminta pembatalan kontrak kerana fungsi yang diperlukan tidak mencukupi. Fungsi yang dikatakan tidak mencukupi oleh pengguna adalah “fungsi kemas kini automatik data”, dan walaupun telah ditegaskan bahawa ini adalah salah satu titik jualan utama sistem ini, mahkamah tidak mengakui kewajipan pelaksanaan ini.

Seperti yang dikenalpasti di atas, dalam kontrak ini dan dalam dokumen reka bentuk asas dan reka bentuk terperinci, tidak ada pernyataan yang menunjukkan bahawa fungsi ③ adalah subjek pembangunan sistem ini.

Plaintif menegaskan bahawa fungsi ③ adalah salah satu titik jualan utama sistem ini kepada defendan, dan menekankan keperluan fungsi ini, tetapi jika dakwaan mereka adalah benar, seharusnya dinyatakan dalam kontrak ini dan sebagainya, dan adalah sukar untuk berfikir bahawa pembangunan fungsi ini telah dipersetujui tanpa itu.

Keputusan Mahkamah Tokyo, 18 Februari Heisei 21 (2009)

Memang, jika anda hanya mengambil kesimpulan dari keputusan ini secara ringkas, anda boleh mengatakan, “Jika tidak ada dalam dokumen reka bentuk, anda tidak perlu membuat apa yang tidak ada.” Tetapi lebih tepatnya, bukan fakta formal seperti sama ada ada dalam dokumen reka bentuk atau tidak, tetapi keputusan dibuat berdasarkan “maksud” pernyataan dalam dokumen reka bentuk dan kontrak. Dengan kata lain, “Mengingat sebab-sebab yang tidak dicatat dalam dokumen reka bentuk dan kontrak, adalah wajar untuk berfikir bahawa tidak ada persetujuan yang sesuai dengan catatan tersebut.”

Contoh Kehakiman yang Mengesahkan Kewajipan Pelaksanaan Walaupun Tidak Dinyatakan

Sebaliknya, walaupun tidak dinyatakan dalam kontrak atau dokumen spesifikasi, terdapat contoh kehakiman yang mengesahkan kewajipan untuk melaksanakan. Contoh kehakiman yang dipetik di bawah ini adalah berkaitan dengan pembangunan sistem untuk mengurus sejarah pengambilan ubat, di mana pengalihan data dari sistem sedia ada ke sistem baru tidak dapat dilakukan, dan penggunaan sistem baru tidak dapat dilakukan, menyebabkan pihak pengguna membatalkan kontrak. Namun, pihak vendor berpendapat bahawa pengalihan data bukan dalam skop kerja dan ini telah membawa kepada pertikaian.

Pembangunan sistem baru sering melibatkan penghapusan sistem sedia ada dan pengalihan data. Kepentingan kerja seperti ini dan isu-isu undang-undang yang berkaitan diterangkan dengan lebih terperinci dalam artikel di bawah.

Artikel Berkaitan: Isu Undang-Undang yang Berkaitan dengan Pengalihan dari Sistem Lama dalam Pembangunan Sistem[ja]

Data pesakit lebih dari 50,000 orang telah disimpan dalam sistem sedia ada, dan plaintif telah berusaha untuk meningkatkan kecekapan kerja dengan menggunakan data ini. Jika tidak dapat mengalihkan data pesakit dari sistem sedia ada ke sistem ini, adalah jelas bahawa ini akan mengganggu operasi farmasi di farmasi, dan dianggap bahawa wakil plaintif pasti menyedari hal ini. Sebelum kontrak ini ditandatangani, wakil plaintif bertanya kepada wakil defendan tentang kemungkinan pengalihan data, dan wakil defendan mengakui hal ini (omitted), dan dianggap bahawa wakil plaintif menyedari bahawa kemungkinan besar dia perlu memasukkan data pesakit lebih dari 50,000 orang secara manual, dan sukar untuk membayangkan bahawa dia telah memutuskan untuk memperkenalkan sistem ini dengan sengaja. Selain itu, seperti yang dinyatakan di atas (1) (i), defendan tidak dapat mengalihkan data sejarah ubat dari sistem sedia ada ke sistem ini, dan telah mencetak data ini pada kertas dan memprosesnya sebagai fail PDF, walaupun pengalihan data tidak diasumsikan dalam kontrak ini, adalah sukar untuk membayangkan bahawa defendan telah melakukan kerja yang memerlukan usaha ini sebagai perkhidmatan.

Keputusan Mahkamah Tokyo, 18 November 2010 (Heisei 22)

Yang penting di sini adalah ‘maksud’ objektif kontrak dan perkara yang dinyatakan dalam kontrak. Jika kedua-dua pihak telah menandatangani kontrak dengan memahami bahawa pengalihan data bukan dalam skop kerja, mahkamah menunjukkan bahawa ini akan bermakna kedua-dua pihak pengguna dan vendor telah menandatangani kontrak dengan niat yang tidak wajar. Dengan kata lain, pengguna akan menerima sejumlah besar kerja manual, dan vendor akan menghadapi projek dengan pengetahuan bahawa ini akan mengganggu kerja pengguna di masa depan, yang merupakan cerita yang sangat tidak rasional.

Apa yang dapat kita fahami daripada kedua-dua keputusan ini?

Walaupun tidak ada catatan dalam kontrak atau dokumen spesifikasi mengenai migrasi data, kewajiban untuk melaksanakannya telah diterima. Salah satu sebabnya mungkin kerana ia melibatkan “data”, sesuatu yang tidak kelihatan pada skrin. Kekurangan “fungsi penting” yang disebutkan sebelum ini adalah sesuatu yang secara langsung dapat dilihat pada skrin atau antara muka sistem. Oleh itu, walaupun anda adalah orang awam dalam pembangunan sistem, mencari kekurangan dalam penulisan spesifikasi bukanlah sesuatu yang sukar. Sebaliknya, masalah migrasi data mempunyai ciri-ciri yang sukar untuk dikenalpasti oleh orang awam dalam pembangunan sistem, seperti kepentingan proses, kesukaran tugas, dan jumlah kerja yang diperlukan. Oleh itu, ada kemungkinan bahawa ia dianggap sebagai sesuatu yang harus dikelola dengan lancar oleh pihak vendor yang mempunyai kepakaran.

Jika kita memikirkan dalam cara ini, kekurangan dalam penulisan spesifikasi atau kontrak adalah masalah yang berkaitan rapat dengan “kewajiban kerjasama” pengguna. Dengan kata lain, soalannya adalah sama ada pengguna benar-benar telah memenuhi “kewajiban kerjasama” mereka dalam penandatanganan kontrak dan pembuatan dokumen spesifikasi. Untuk penjelasan umum tentang kewajiban undang-undang yang harus dipenuhi oleh pengguna dalam projek pembangunan sistem, sila rujuk artikel di bawah.

Artikel berkaitan: Apa itu kewajiban kerjasama yang harus dipikul oleh pengguna sebagai pemberi pesanan pembangunan sistem[ja]

Jika anda juga memeriksa artikel di atas, anda mungkin akan memahami bahawa dalam bidang seperti penentuan fungsi penting dan antara muka, permintaan kerjasama dari pengguna adalah besar, tetapi dalam hal kekurangan pertimbangan migrasi data, ceritanya sangat berbeza.

Bagaimanakah kita harus mempertimbangkan bayaran untuk pembangunan yang tidak termasuk dalam spesifikasi?

Salah satu isu yang mungkin menarik perhatian anda berkaitan dengan topik artikel ini adalah, apakah hukum membenarkan permintaan bayaran tambahan jika anda telah membuat sesuatu yang tidak termasuk dalam spesifikasi? Kami telah menjelaskan secara terperinci tentang kemungkinan penambahan bayaran dan cara mengira jumlah anggaran jika memang boleh, dalam artikel di bawah ini.

Artikel Berkaitan: Adakah Mungkin Untuk Menaikkan Anggaran Pembangunan Sistem Selepas Fakta?[ja]

Dalam artikel di atas, kami menjelaskan bahawa penting untuk menentukan sama ada terdapat tugas yang melebihi lingkup kerja yang berkaitan dengan bayaran dan balasan. Dalam konteks artikel ini, jika vendor menyetujui untuk melakukan pembangunan yang tidak termasuk dalam spesifikasi awal (dalam hal ini, contoh penafian), mereka boleh meminta bayaran tambahan.

Rumusan

Dalam pembangunan sistem, peranan yang harus dilakukan oleh vendor ditentukan sejauh mana ia mengikut isi kontrak dan dokumen spesifikasi. Namun, memandangkan mereka adalah pakar yang dipercayai untuk menjalankan tugas, realitinya bukan semata-mata ditentukan oleh formaliti. Walaupun begitu, dalam memahami hakikat sebenar, kita harus memahami bahawa undang-undang memainkan peranan yang penting.