Sistem Geliştirmede Sözleşmenin Feshi Nasıl Yapılır?

Sistem geliştirme projeleri uzun süreli projeler olduğu için, ilerleme sürecinde “alevlenme” gibi durumların oluşması doğal olarak beklenir. Ve eğer kullanıcılar ve satıcılar her zaman aynı hızda ilerleyebilseydi iyi olurdu, ancak sözleşmenin ortasında iptalini düşünmek gibi durumları da öngörmekte fayda vardır.

Bu makalede, sözleşmenin “iptali” hakkındaki hukuki seçeneği, sistem geliştirme ile ilgili önemli noktalarla birlikte açıklıyor olacağız.

Sistem Geliştirme ve Fesih İlişkisi

Japon Medeni Kanunu’nda Fesih Nedir?

Yenilenmiş Japon Medeni Kanunu’nda, sözleşmenin “feshi” ile ilgili genel hükümler 540. maddeden 548. maddeye kadar olan maddelerde belirlenmiştir. Sözleşmeyi feshetmek, bir kez yapılan bir sözleşmenin etkisini sonradan ortadan kaldırmak anlamına gelir.

Kullanıcı ve satıcı ilişkisinden bahsedersek, genellikle bir kez sözleşme yapıldığında, satıcıya da bir sistem geliştirme yükümlülüğü getirilir ve kullanıcıya da bir ödeme yükümlülüğü getirilir. Ve bunların tersi, her iki tarafın “hakları” olur. Eğer bu feshedilirse, her iki tarafın da taşıdığı yükümlülükler ve sahip olduğu haklar, sözleşme yapılmadan önceki duruma döner. Dolayısıyla, eğer hala yerine getirilmemiş bir borç varsa, yerine getirme yükümlülüğü elbette ortadan kalkar ve sözleşme yapılmadan önceki durumu temel alarak, karşılıklı olarak eski durumuna dönme yükümlülüğü doğar. Bu “orijinal duruma dönme yükümlülüğü” olarak adlandırılır.

Not: Eğer aynı zamanda bir zarar oluşmuşsa, bunun için ayrıca tazminat ödenebilir.

Sistem Geliştirme Uygulaması ve Fesih İlişkisi

Sistem geliştirme ve benzeri iş çevrelerinde hukuki uygulamalarla tanışık olan kişiler için, sözleşmenin “feshi” denildiğinde, ilk akla gelen şey fesih bildirimi olabilir. Ancak, hukuki açıdan, sistem geliştirme bağlamında bile, temel alınan maddeler, fesih nedenine göre iki ana kategoriye ayrılır.

Borç İhlali (İcra Gecikmesi) Durumunda

(Örnek) Satıcının başlangıçta belirlediği teslim tarihini aştığı halde, teslimatı kabul etmemesi durumu vb.

Japon Medeni Kanunu 541. Madde: Bir tarafın borcunu yerine getirmediği durumda, diğer taraf makul bir süre belirleyerek icranın talep edilmesi ve bu süre içinde icranın yapılmaması durumunda, diğer taraf sözleşmeyi feshedebilir.

Sözleşme tipi sistem geliştirme durumunda, “taraflardan biri” olan satıcının taşıdığı “borç”, gereksinimlerin tanımlandığı bir sistemi tamamlayıp teslim etmektir. Dolayısıyla, teslim tarihini aştığı halde satıcının teslimatı yapmaması durumu, başka bir deyişle, teslim tarihine kadar satıcının işi tamamlamaması durumudur. Peki, “işin tamamlanması” sistem geliştirme sahnesinde, somut olarak ne anlama gelir? Bu konuda aşağıdaki makalede detaylı bir açıklama yapılmıştır.

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

Kusur Garanti Sorumluluğu Durumunda

(Örnek) Satıcıdan teslim alınan sistemde, çok sayıda hata veya veri uyumsuzluğu olduğu ve sonradan kullanıma uygun olmadığı anlaşıldığı durumlar vb.

Japon Medeni Kanunu 635. Madde: İşin nesnesinde bir kusur varsa ve bu nedenle sözleşme yapılan amaca ulaşılamıyorsa, sipariş veren, sözleşmeyi feshedebilir. Ancak, binalar ve diğer arazi yapıları için bu geçerli değildir.

Not: Eğer bir sistem geliştirme projesi açısından bakarsak, satıcı tarafından bir sözleşme feshi beyanı yapıldığı durumlar pek yaygın değildir. Genellikle kullanıcının satıcıya karşı yaptığı durumları düşünmek daha iyidir.

Kusur garanti sorumluluğu hakkında aşağıdaki başka bir makalede detaylı bir açıklama yapılmıştır.

https://monolith.law/corporate/defect-warranty-liability[ja]

Fesih Bildirimi ve İlgili Hukuki Sorunlar

Fesih bildirimi, genellikle kullanıcıdan satıcıya, sözleşmenin feshedilmesi niyetini iletmek için kullanılan bir belgedir. İlgili madde olarak, aşağıdakine bakabilirsiniz.

Japon Medeni Kanunu’nun (Japanese Civil Code) 541. maddesi: Taraflardan biri borcunu yerine getirmezse, diğer taraf makul bir süre belirleyerek yerine getirilmesini talep edebilir ve bu süre içinde yerine getirilmezse, sözleşmeyi feshedebilir.

Sistem geliştirme belgeleri açısından bakıldığında, fesih bildiriminin özellikleri arasında, projenin sorunsuz ilerlemesini hedeflemek yerine, projeyi sonlandırmayı amaçlaması sayılabilir. Ayrıca, belgenin doğrudan belirli hukuki etkileri olmasını beklediği bir belge olması da önemli bir özelliktir.

Ancak, yukarıda belirtilen maddeye göre, sözleşme gibi belgelerden farklı olarak, belirli koşullar sağlandığında tek taraflı bir irade beyanı yeterlidir. Kullanıcıdan satıcıya bir fesih bildirimi sunulduğunda, bunu alan satıcı tarafındaki yetkili kişi için, “Fesih bildirimini okudum ama neden sözleşme feshedildiğini anlamıyorum” gibi bir sorun ortaya çıkabilir. Peki, kullanıcı bir fesih bildirimi oluştururken, fesih nedenini ne kadar ayrıntılı olarak belirtmeli?

Fesih Bildirimi Yazısında Fesih Nedeni Yazılmalı mı?

Bu konuda geçmişteki dava örneklerine bakıldığında, fesih bildirimi yazısında fesih nedenini belirtmenin, mutlaka fesih yapmak için gerekli olmadığı düşünülmektedir. Aşağıda alıntıladığımız dava örneği, teslim edilen sistemde bir hata olduğu için hukuki bir sorun haline gelen bir durumdur. Kullanıcı tarafından fesih niyetini belirtirken, hatanın içeriğini ne kadar ayrıntılı bir şekilde anlamak ve bunu ne kadar ayrıntılı bir şekilde belirtmek gerektiği gibi konular, sorun haline gelen noktalardır. Mahkeme, bu konuda aşağıdaki gibi bir karar vermiştir.

Fesih niyetini belirtirken, mutlaka fesih nedenini göstermek gerekmez, birden çok fesih nedeniyle fesih yapmak tek bir niyet beyanıyla mümkündür. Fesih niyetini belirtirken bir neden belirtse bile, özellikle başka bir nedenle fesih etmeyeceğini açıkça belirtmezse, bu niyet beyanı, fesih sırasında var olan tüm nedenlere dayanarak, sözleşmeyi tamamen sonlandırmak niyetinde olduğu düşünülebilir.

Tokyo District Court, 22 Aralık 2004 (Heisei 16)

“Birden çok fesih nedeniyle fesih yapmak tek bir niyet beyanıyla mümkündür” mahkemenin görüşüdür. Yani, sözleşmenin taraflarının fesih niyeti olup olmadığı önemli olan şeydir, detaylı nedenlerin ayrıntılı bir şekilde belirtilmesi gerekmez.

Yani, teslim edilmiş olsa bile, tamamlanmamış olduğu için böyle bir muamele yapılması gerekip gerekmeyeceği, ciddi bir kusuru olduğu için kusur garantisi sorumluluğu meselesi olup olmadığı gibi konular, fesih niyetini belirtme aşamasında sorun olmamalıdır. Bu tür hassas konuları bir kenara bırakıp önce fesih niyetini belirtirsek, eğer daha sonra dava haline gelirse, daha sonra ifa gecikmesi veya kusur garantisi sorumluluğunu fesih gerekçesi olarak ileri sürme hakkımız olur.

• Teslim edilen şey tamamlanmamış… → Borcun ifa edilmemesi
• Ciddi bir kusuru olan bir şey teslim edildi… → Kusur garantisi sorumluluğu

Nedeni ayrıntılı bir şekilde belirtmeseniz bile, fesih niyetini belirtmek, fesih niyetini belirtme olarak geçerlidir.

Yine de, fesih nedenini ayrıntılı bir şekilde belirttikten sonra fesih bildirimi yazısını sunmanın, eğer satıcı ile iletişimde bir yanlış anlama veya algıda bir uyuşmazlık varsa, bunu açığa çıkarabilme gibi avantajları da vardır. Ayrıca, fesih bildirimi yazısını alan taraf için de, eğer nedeni düşünüyorsa, daha sonra bir anlaşmazlık çıkma endişesi de azalır. Dolayısıyla, mümkün olduğunca fesih nedenini açıkça belirtmek daha iyi olacaktır.

“Uygun bir süre” belirlenen ihbar ne kadar süre olmalıdır?

Ayrıca, düşünülebilecek bir diğer nokta, Japon Medeni Kanunu’nun 541. maddesinde belirtilen “uygun bir süre”nin ne kadar olacağıdır. Ancak, bu konuda çok fazla endişelenmeye gerek olmadığını düşünüyorum. Çünkü, ihbarı yapana kadar “uygun bir süre” belirlenmemiş olsa bile, ihbardan sonra uygun bir süre geçmişse, sonuç olarak sözleşmenin feshi mümkün olacaktır. Ayrıca, ihbara kadar geçen süre “uygun bir süre” olmasa bile, sonuç olarak uygun bir süre geçtikten sonra sözleşmenin feshi mümkün olacağı, emsal hukukta da açıkça belirtilmiştir.

Sistem geliştirme projelerinde, bir kez ifa gecikmesi veya kusur garantisi sorumluluğu gibi “alevlenme” durumlarına karşı “uygun bir süre” belirleyerek ihbar yapılsa bile, teslimatın veya kusurun düzeltilmesi genellikle gerçekleşmez. Bu noktaları göz önünde bulundurarak, pratikte, “uygun bir süre” konusunda ciddi bir anlaşmazlık çıkması pek olası görünmüyor.

Sistem geliştirmede ifa gecikmesinin tanımı hakkında, başka bir makalede açıklama yapılmıştır.

https://monolith.law/corporate/performance-delay-in-system-development[ja]

Fesih Bildirimi Nasıl Yapılır?

Fesih bildiriminin hangi yöntemle yapılması gerektiği konusunda, sonuç olarak bildirimin ulaştığı sürece (daha da ileri gidersek, bildirimin kesinlikle ulaştığını sonradan kanıtlayabilecek bir yöntemle) hangi yöntemi kullanırsanız kullanın bir sorun olmaz.

Dolayısıyla, prosedür konusunda çok titiz olmanıza gerek yok. Elbette, pratikte, “söyledim-söylemedim” tartışmalarını önlemek için, içerik belgeli posta gibi yöntemler tercih edilir. Ancak, bildirimin karşı tarafa ulaştığını doğrulayabiliyorsanız, FAX veya e-posta gibi basit yöntemlerle de sorun olmaz. Ancak sonuçta, bir dava durumunda, “karşı tarafa ulaştı” demeniz gerektiğinde, içerik belgesinin güvenli olduğunu söyleyebiliriz.

Özet

Bu makalede, sistem geliştirme bağlamında, sözleşmenin feshi hakkında bir düzenleme yaptık. Fesih işleminin nasıl yapılacağına dair pratik bilgilerin yanı sıra, aynı zamanda hukuki olarak geçerli bir irade beyanının nasıl yapılacağı konusunu da anlarsanız, bu bilgiyi uygulamada kullanmanız daha kolay olacaktır.