Yazılım Geliştirmede Tedarikçiden Kullanıcıya Özürün Hukuki Anlamı Nedir?
Sistem geliştirmenin yanı sıra, hizmet sektörü olarak adlandırılan iş kolu içerisinde, müşterilerden gelen şikayetlere yanıt vermek önemlidir. Sistem geliştirme konusunda da bu durum bir istisna değildir ve teknik hizmet sağlayıcısı olan tedarikçinin, müşteri olan kullanıcılardan gelen şikayetlere yanıt vermesi gereken durumlar sıkça karşımıza çıkar.
Her iki tarafın da iletişimini sağlıklı bir şekilde sürdürmeye önem verilirse, karşı tarafın söylediklerini dinleyip özür dilemek bazen mantıklı olabilir. Ancak, sözlü olarak özür dilediğinizde veya yazılı bir özür metni sunduğunuzda, kullanıcı tarafının haksız iddialarının gerçekmiş gibi kabul edilmesi endişesi taşıyan kişiler de olabilir.
Bu makalede, “tedarikçiden kullanıcıya yapılan özür” konusuna odaklanarak, bunun hukuki açıdan ne anlama geldiği ve nasıl anlaşılması gerektiği hakkında bilgi verilecektir.
Sistem Geliştirme Alanında Neden ‘Özür’ Bir Sorun Haline Gelir?
Sistem Geliştirme Bir Hizmet Sektörüdür
Öncelikle, sistem geliştirme işi, dış tedarikçilerin dış kaynak kullanımı şeklinde dahil olduğu durumlarda, bu işin bir tür ‘kurumsal hizmet sektörü’ olduğunu söyleyebiliriz. Hukuki terimleri kullanmak gerekirse, genellikle sözleşmeler, taahhüt sözleşmesi veya yarı vekalet sözleşmesi şeklinde yapılır. Taahhüt sözleşmesi ve yarı vekalet sözleşmesi arasındaki fark hakkında aşağıdaki makalede detaylı bir açıklama yapılmıştır.
https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]
Konunun özü, hangi tür sözleşme olursa olsun, işi alan tedarikçi şirketin teknik yetenekleri ve iş gücü (ve bu yeteneklerle üretilen ürünler) üzerinden gelir elde ettiği gerçeği değişmez. Tedarikçiye ait ‘insan’ gücü tarafından sağlanan hizmetler ve buna karşılık gelen ödeme değişimi, ticari işlemlerin amacıdır. Bu nedenle, IT sistemlerinin geliştirilmesi işi, prensip olarak, bir hizmet sektörüdür.
Kullanıcıların ‘Müşteri’ Olması Nedeniyle Özür Talep Edilir
Sistem geliştirme bir hizmet sektörü olduğundan, kullanıcılardan şikayetler ve taleplerin gelmesi de tabii ki beklenir. Aynı zamanda, bu tür taleplere doğru bir şekilde yanıt verme yeteneği de tedarikçiden beklenir. Gerçekten de, tedarikçinin çeşitli talep ve şikayetlere karşı özür gibi bir yanıt vermesi durumunda, tekrar işbirliği yapılır ve proje başarıya ulaşır.
Ancak, eğer proje daha sonra gerçekten başarısız olursa ve durum mahkemeye kadar giderse, kullanıcıların tedarikçiden özür almayı gerekçe göstererek, ‘tedarikçi de kusurlu olduğunu kabul ediyor’ şeklinde iddialarda bulunabileceğini düşünelim.
Aslında Kullanıcıların Müşteri Olarak Ne Kadar Kalabileceği Sorunu
Sistem geliştirme projesi, belirli bir yönüyle, ‘müşteri’ olarak kullanıcılar ve ‘dış tedarikçi’ olarak tedarikçiler arasında gerçekleşen ticari işlemlerdir. Ancak, sistem geliştirme sözleşmelerinin özelliği, bu ilişkinin ötesinde karmaşıklığa sahip olmasıdır. Yani, müşteri olan kullanıcıların da projenin tamamlanabilmesi için tedarikçinin görevlerine yardımcı olması gerekmektedir. Kullanıcıların da belirli bir işbirliği yükümlülüğü vardır ve her iki tarafın işbirliği içinde projeyi ilerletmesi gerektiği, geçmiş mahkeme kararlarında da belirtilmiştir.
https://monolith.law/corporate/user-obligatory-cooporation[ja]
Tedarikçinin kullanıcıya ‘özür’ konusunu hukuki bir sorun olarak ele alırken, bu karmaşık ilişkiyi anlamak önemlidir. Kullanıcı ve tedarikçi arasındaki ilişki, sağlıklı bir ortaklık olarak gelişebilir veya ‘birçok tedarikçiden biri’ olarak görülebilir. Kullanıcıların da işbirliği yapması ve projenin başarısını hedeflemesi hukuki bir yükümlülüktür. Bu temel gerçeğin unutulduğu zamanlar genellikle haksız özür talepleri sorunu ortaya çıkar. Bu konu, diğer hizmet sektörlerinde pek görülmeyen, sistem geliştirme işine özgü bir özelliktir.
Mahkemeler ‘Özür’ Konusunu Nasıl Değerlendiriyor?
Şimdi gerçekten, sistem geliştirme ile ilgili davalarda, tedarikçinin özrünün hukuki olarak ne kadar anlam taşıdığını aşağıda inceleyelim.
Özürle İlgili Dava Örneği 1: Kullanıcıdan Diz Çökme Talebi
Bu durumda, gece boyu çalıştıktan sonra kullanıcının yanına gittiğinde, verilerin silindiği iddiasıyla suçlandı ve diz çöktürüldükten sonra, kullanıcının görüşlerine göre bir özür mektubu sundu. Ancak mahkeme, bu özür mektubunda gerçek bir niyet olmadığı görüşünü belirtti.
H, bu konuda belirtilen bir özür mektubu hazırladı, ancak bu, gece boyu çalıştıktan sonra, 2001 (Heisei 13) yılında 4 Ekim’de, davacının ofisini ziyaret ettiğinde, tek taraflı olarak sert bir şekilde suçlandı, diz çöktürüldükten sonra, davacının taleplerine uygun olarak, öncelikle davacının yöneticilerinin öfkesini yatıştırmak için, onların görüşlerine göre hazırlanan bir şeydi ve H’nin gerçek niyeti değildi, aynı şekilde N’nin hazırladığı özür mektubunun amacı da N’nin gerçek niyeti değildi.
Tokyo District Court, 23 Nisan 2004 (Heisei 16)
Suçlamanın “tek taraflı” olduğu, “öfkeyi yatıştırma”, “gerçek niyet olmama” gibi ifadelerle, tarafların duygusal durumunu dikkate alan bir karar verildiği belirtilebilir.
Özürle İlgili Dava Örneği 2: Özür Mektubu Yazma veya 20 Milyon Yen Ödeme Seçeneği
Aşağıdaki durumda, son kullanıcıya verilen zarar hakkında, tedarikçinin bir özür mektubu yazmayı kabul etmesine rağmen, hukuki sorumluluğun tedarikçiye atfedilmesi gereken bir konu olup olmadığı ayrılmalıdır, şeklinde bir karar verildi.
Davacının temsilcisi, bu raporu aldıktan sonra, “Bu, E şirketinin suçlu olduğunu açıkça gösteriyor, bu yüzden bir özür mektubu yazın veya yazılım geliştirme maliyeti olan 20 milyon yen ödeyin.” şeklinde bir şey söyledi. Davalı, bu talebe uyarak, aynı yıl 19 Ocak tarihinde, bu arızanın oluşması nedeniyle davacıya rahatsızlık verdiği için özür dileyen bir “özür mektubu” hazırladı ve bunu davacıya verdi.
(…)
E şirketinin ürününün satıcısı olarak mümkün olan en iyi yanıtı verdi ve bu nedenle, davalının bu temel satış sözleşmesine dayalı davalının borcunu ihmal ettiği söylenemez.
Tokyo District Court, 11 Temmuz 1996 (Heisei 8)
Formal bir özür mektubunun adresini kimin belirleyeceği gibi konular yerine, iş uygulamalarının nasıl olması gerektiğine odaklanarak sorumluluğu belirlemek şeklinde bir yaklaşımın karar metninden de okunabileceği görülüyor.
Yukarıdaki Dava Örneklerinde Ortak Olan Şey
Yukarıdaki dava örneklerinden çıkarılacak sonuç, tedarikçinin formal olarak özür talebine yanıt vermiş olmasına rağmen, bu durumun gerçek bir davada mutlaka belirleyici bir anlam taşımadığıdır. Özürlerin genellikle iş üzerinde, işleri ilerletmek için sadece bir kolaylık olduğu, bu durumun mahkemede de tam olarak dikkate alınan bir durum olduğu düşünülebilir. Aslında, bu tür formal özürlerin varlığından ziyade, özürlerin nasıl yapıldığı, özür mektubunun nasıl yazıldığı ve kullanıcı ile tedarikçi arasında ne tür bir insan ilişkisi kurulduğu gibi faktörler de dikkate alınarak genel bir değerlendirme yapılması gerektiği, mahkemenin duruşu olarak görülebilir.
Sistem geliştirmede, kullanıcının da tedarikçiye işbirliği yapma yükümlülüğü olduğu, zaten mahkemenin belirttiği bir görüştür. Kullanıcının tedarikçiye işbirliği yapma konusunda zor olduğu söylenebilecek bir baskın ve baskıcı ilişkinin olduğu durumlarda, özürlerin sadece formal bir şey olarak ele alınması daha olasıdır.
Özür Dilemek Kolay Değil, Dikkatli Olun
Yine de, bir dava durumunda, özrün tek başına belirleyici bir kanıt olma olasılığının düşük olması, özür dilemenin kolay olduğu anlamına gelmez. Hafif bir özür, müzakere aşamasında bile, kullanıcıdan inatçı bir tutum çıkarma riski oluşturabilir. Ayrıca, davanın başlangıç aşamasında, hakimin özür mektubuna dayanarak bir izlenim oluşturması durumunda, yanılgıyı düzeltmek için çok fazla çaba ve zaman gerekebilir, bu da dikkate alınmalıdır. Dahası, sadece özür dileme niyetini göstermekle kalmayıp, özür içeriği veya özür mektubunun içeriğinin tedarikçinin kusurunu ayrıntılı bir şekilde belirttiği durumlarda, gerçeklerin kabul edilmesi aşamasında dezavantajlı bir yorum yapılabilir.
Her durumda, şikayetlerin ve taleplerin yönetilmesi gibi sorunların da hukuki bir sorun olduğunu kabul ederek, özür dileme konusunda nasıl bir yaklaşım sergileyeceğimiz konusunda, dış uzmanların kullanımını aktif olarak düşünmeliyiz.
Category: IT
Tag: ITSystem Development