Ποια είναι τα κρίσιμα σημεία ελέγχου στα συμβόλαια ανάθεσης συστημάτων ανάπτυξης

Το Υπουργείο Οικονομίας, Εμπορίου και Βιομηχανίας (ΜΕΤΙ) παρουσιάζει μοντέλα ρητρών στις “Οδηγίες για την Αύξηση της Αξιοπιστίας των Πληροφοριακών Συστημάτων” για συμβάσεις ανάπτυξης ΙΤ συστημάτων. Με την εξάπλωση του Ίντερνετ, οι κοινωνικές επιπτώσεις από διακοπές ή μειωμένη λειτουργικότητα των πληροφοριακών συστημάτων λόγω προβλημάτων γίνονται όλο και πιο σοβαρές, καθιστώντας την αύξηση της αξιοπιστίας και ασφάλειας των συστημάτων ένα επείγον ζήτημα. Από την άλλη πλευρά, οι συμβάσεις ανάπτυξης ΙΤ συστημάτων συχνά παρουσιάζουν ασάφειες στο περιεχόμενο των συναλλαγών, γι’ αυτό οι ρήτρες αυτές επιδιώκουν την αποσαφήνιση και την καθοριστική διασαφήνιση της κατανομής των ρόλων και των σχέσεων ευθύνης. Σε αυτό το άρθρο, θα αναλύσουμε τα σημεία ελέγχου για τις συμβάσεις ανάπτυξης ΙΤ συστημάτων, όταν συνάπτεται μια σύμβαση εργολαβίας, αναφερόμενοι στις ρήτρες του μοντέλου συμβάσεων του ΜΕΤΙ.

Ανάπτυξη Συστημάτων και Συμβάσεις Έργου

Τι είναι η Σύμβαση Έργου

Η σύμβαση έργου ορίζεται στον Αστικό Κώδικα ως εξής:

Άρθρο 632
Η σύμβαση έργου προκύπτει όταν ο ένας εκ των δύο μερών υπόσχεται να ολοκληρώσει ένα συγκεκριμένο έργο, και το άλλο μέρος υπόσχεται να πληρώσει για το αποτέλεσμα αυτής της εργασίας.

Στη σύμβαση έργου, η υποχρέωση “να ολοκληρώσει ένα έργο” αποτελεί βασικό στοιχείο σύμφωνα με το νόμο. Για παράδειγμα, αν έχει συμφωνηθεί η δημιουργία ενός συγκεκριμένου συστήματος μέχρι μια καθορισμένη ημερομηνία, τότε η υποχρέωση του προμηθευτή είναι “να ολοκληρώσει το σύστημα μέχρι την προθεσμία”. Αν δεν καταφέρει να ολοκληρώσει το σύστημα μέχρι την υποσχεθείσα ημερομηνία, τότε μπορεί να κατηγορηθεί για καθυστέρηση στην εκπλήρωση των υποχρεώσεών του. Ωστόσο, αν το σύστημα ολοκληρωθεί και παραδοθεί εντός της προθεσμίας αλλά αργότερα βρεθούν ελλείψεις, τότε η υποχρέωση του προμηθευτή θεωρείται ότι έχει ήδη εκπληρωθεί και δεν τίθεται θέμα μη εκπλήρωσης υποχρεώσεων, αλλά ανακύπτει θέμα εγγύησης για τυχόν ελαττώματα. Στην ανάπτυξη συστημάτων, το πότε αναγνωρίζεται η “ολοκλήρωση ενός έργου” εξηγείται αναλυτικά στο παρακάτω άρθρο.

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

Διαφορές από τη Σύμβαση Εντολής

Στη σύμβαση έργου, ο προμηθευτής έχει την υποχρέωση ολοκλήρωσης του έργου και, σε περίπτωση που το παραδοθέν έργο παρουσιάζει ελαττώματα, φέρει την ευθύνη για την εγγύηση των ελαττωμάτων. Αντίθετα, στη σύμβαση εντολής δεν υπάρχει υποχρέωση ολοκλήρωσης του έργου, οπότε δεν υπάρχει ευθύνη για εγγύηση ελαττωμάτων όπως στη σύμβαση έργου. Ωστόσο, αν κατά τη διαδικασία εκτέλεσης της εργασίας αναγνωριστεί υποχρέωση επιμελούς διαχείρισης, τότε μπορεί να υπάρξει ευθύνη για αποζημίωση ζημιών ή άλλες μορφές ευθύνης για μη εκπλήρωση υποχρεώσεων. Το ποιες ευθύνες μπορεί να προκύψουν σε συμβάσεις ανάπτυξης συστημάτων εξηγείται αναλυτικά στο παρακάτω άρθρο.

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

Μοντέλο Συμβατικών Ρητρών και Σημεία Ελέγχου για Έργα Ανάθεσης

Υποστήριξη Δημιουργίας Ορισμού Απαιτήσεων

Ο ορισμός απαιτήσεων είναι η διαδικασία συγκέντρωσης των προδιαγραφών απαιτήσεων για το σύστημα που επιθυμεί να κατασκευάσει ο χρήστης. Στο στάδιο του ορισμού απαιτήσεων, εξετάζεται η κατεύθυνση κατασκευής του συστήματος και αποφασίζεται ποιο σύστημα θα κατασκευαστεί, ενώ δεδομένου ότι το τελικό προϊόν δεν μπορεί να προσδιοριστεί συγκεκριμένα, το Ιαπωνικό Υπουργείο Οικονομίας, Εμπορίου και Βιομηχανίας ορίζει τα συμβόλαια μοντέλου ως εντολές εκ των προτέρων. Για περισσότερες λεπτομέρειες, δείτε το παρακάτω άρθρο.

https://monolith.law/corporate/system-development-contract-check-quasi-mandate[ja]

Υπηρεσίες Δημιουργίας Εξωτερικών Τεχνικών Εγγράφων

Άρθρο ○ (Εκτέλεση Εργασιών Δημιουργίας Εξωτερικού Σχεδιασμού)
Ο Β, μετά τη σύναψη της ατομικής σύμβασης που προβλέπεται στο άρθρο ○, θα εκτελέσει τις εργασίες δημιουργίας εξωτερικού σχεδιασμού για το εν λόγω λογισμικό, βάσει του εγγράφου προδιαγραφών που έχει καθοριστεί σύμφωνα με τις διατάξεις του άρθρου ○.

2. Κατά την εκτέλεση των εργασιών δημιουργίας εξωτερικού σχεδιασμού, ο Β μπορεί να ζητήσει την απαραίτητη συνεργασία από τον Α, και ο Α, όταν ζητηθεί η συνεργασία του από τον Β, θα πρέπει να ανταποκρίνεται εγκαίρως.

Η δημιουργία εξωτερικού σχεδιασμού αφορά την κατάρτιση της χρήσης τμημάτων όπως οι οθόνες και οι φόρμες, που σχετίζονται με τη διεπαφή. Στον εξωτερικό σχεδιασμό πρέπει καταρχήν να περιλαμβάνονται όλες οι πληροφορίες που θα επιτρέψουν στον προμηθευτή να αναπτύξει το πρόγραμμα. Ο εξωτερικός σχεδιασμός περιλαμβάνει λεπτομερειακό περιεχόμενο ως προς τη χρήση των φορμών, αλλά η δυνατότητα αλλαγής των απαιτήσεων προδιαγραφών ανήκει στον χρήστη που καθορίζει το περιεχόμενο της εργασίας. Ωστόσο, εάν το έγγραφο προδιαγραφών από την προηγούμενη φάση έχει καθορίσει σαφώς τις ανάγκες του χρήστη και το περιεχόμενο της εργασίας που θα ολοκληρώσει ο προμηθευτής, τότε μπορεί να συναφθεί συμβόλαιο για τη δημιουργία του εξωτερικού σχεδιασμού, με τον προμηθευτή να αναλαμβάνει τον κύριο ρόλο.

Το άρθρο 1 καθορίζει ότι αυτή η διαδικασία είναι εργολαβική, με τον προμηθευτή να είναι το κύριο υποκείμενο στην εκτέλεση της εργασίας. Παρόλο που η σύμβαση είναι εργολαβική, ο εξωτερικός σχεδιασμός σχετίζεται στενά με την επιβεβαίωση του περιεχομένου της εργασίας του χρήστη, γι’ αυτό απαιτείται η ενεργή συμμετοχή του χρήστη. Έτσι, το άρθρο 2 καθορίζει ότι ο προμηθευτής μπορεί να ζητήσει από τον χρήστη την απαραίτητη συνεργασία για την εξέταση και την απόφαση των προδιαγραφών του συστήματος, και ο χρήστης πρέπει να ανταποκρίνεται εγκαίρως, καθιστώντας την εξέταση των προδιαγραφών του συστήματος μια κοινή εργασία μεταξύ προμηθευτή και χρήστη.

(Σύναψη Ειδικής Σύμβασης για την Εκπόνηση Εξωτερικού Σχεδίου)
Άρθρο ○ Ο Α και ο Β θα συζητήσουν και θα αποφασίσουν για τους όρους συναλλαγής που αναφέρονται στο άρθρο ○, παράγραφο ○, και θα συνάψουν μια ειδική σύμβαση για την εκπόνηση εξωτερικού σχεδίου.

Το πεδίο εφαρμογής και άλλες λεπτομέρειες της εκπόνησης εξωτερικού σχεδίου θα καθοριστούν σε μια ειδική σύμβαση, σύμφωνα με τους όρους συναλλαγής που έχουν οριστεί στην προηγούμενη διάταξη.

(Συνεδρίαση Εξωτερικού Σχεδιασμού)
Άρθρο ○: Ο Β θα πρέπει να διεξάγει συνεδριάσεις Εξωτερικού Σχεδιασμού (εφεξής σε αυτή την ενότητα αναφέρεται ως “Συνεδρίαση Εξωτερικού Σχεδιασμού”) με την απαιτούμενη συχνότητα για την αποσαφήνιση ή την επιβεβαίωση των θεμάτων που είναι απαραίτητα για τη δημιουργία του εξωτερικού σχεδιαγράμματος, σύμφωνα με το Άρθρο ○ που ορίζει την επικοινωνία και τη συνεργασία, και ο Α θα συμμετέχει σε αυτές.

2. Ο Α μπορεί επίσης να διοργανώσει μια Συνεδρίαση Εξωτερικού Σχεδιασμού όταν κρίνει απαραίτητο για τη δημιουργία του εξωτερικού σχεδιαγράμματος, και ο Β θα συμμετέχει σε αυτή.

3. Σε περίπτωση που ο Α επιθυμεί να αλλάξει το περιεχόμενο του εγγράφου ορισμού απαιτήσεων μέσω της συζήτησης στη Συνεδρίαση Εξωτερικού Σχεδιασμού και αυτό απαιτεί αλλαγή στις συνθήκες της ατομικής σύμβασης, όπως η περίοδος εργασίας, το κόστος ανάθεσης κ.λπ., θα ακολουθηθεί η διαδικασία που ορίζεται στο Άρθρο 33 (Αλλαγή του περιεχομένου της βασικής σύμβασης και των ατομικών συμβάσεων).

Για τη δημιουργία ενός εξωτερικού σχεδιαγράμματος που καθορίζει διεπαφές όπως οθόνες και φόρμες, η συνεργασία μεταξύ χρηστών και προμηθευτών είναι απαραίτητη. Επειδή αυτή η διαδικασία είναι επιχειρησιακή, το Άρθρο 1 ορίζει ότι ο προμηθευτής οργανώνει τις συνεδριάσεις και ο χρήστης συμμετέχει σε αυτές. Η αποσαφήνιση των θεμάτων που απαιτούνται για τη δημιουργία του εξωτερικού σχεδιαγράμματος γίνεται στη Συνεδρίαση Εξωτερικού Σχεδιασμού, και και οι δύο πλευρές δεσμεύονται από τα αποτελέσματα της συνεδρίασης.

Το Άρθρο 2 ορίζει ότι ο χρήστης μπορεί επίσης να διοργανώσει μια Συνεδρίαση Εξωτερικού Σχεδιασμού όταν το κρίνει απαραίτητο για την εκτέλεση της δημιουργίας του εξωτερικού σχεδιαγράμματος. Το Άρθρο 3 ορίζει ότι, αν ο χρήστης επιθυμεί να αλλάξει το περιεχόμενο του εγγράφου ορισμού απαιτήσεων μετά από συζήτηση, και αυτό επηρεάζει τις συνθήκες της ατομικής σύμβασης όπως η περίοδος εργασίας ή το κόστος ανάθεσης, θα πρέπει να ακολουθηθεί η διαδικασία που ορίζεται σε άλλο άρθρο για την αλλαγή του περιεχομένου της βασικής και των ατομικών συμβάσεων.

(Παράδοση του Εξωτερικού Σχεδίου)
Άρθρο ○: Ο Ανάδοχος θα πρέπει να παραδώσει στον Αναθέτοντα το Εξωτερικό Σχέδιο και το Έντυπο Αίτησης Επιθεώρησης Εξωτερικού Σχεδίου (που λειτουργεί και ως Παραστατικό Παράδοσης) μέχρι την ημερομηνία που ορίζεται στην εκάστοτε ξεχωριστή σύμβαση.

Δεδομένου ότι η παρούσα φάση αφορά σε σύμβαση εργολαβίας, ο προμηθευτής θα πρέπει να παραδώσει το Εξωτερικό Σχέδιο και τα σχετικά έγγραφα ως παραδοτέα έργα.

“`html

(Έγκριση και Οριστικοποίηση του Εξωτερικού Σχεδίου)
Άρθρο ○ Ο Α’ θα ελέγξει εντός της περιόδου που ορίζεται στην ατομική σύμβαση (εφεξής αναφερόμενη ως “περίοδος ελέγχου του εξωτερικού σχεδίου”) εάν το εξωτερικό σχέδιο συμφωνεί με το έγγραφο ορισμού απαιτήσεων που έχει οριστικοποιηθεί σύμφωνα με το άρθρο ○ και τις αποφάσεις που έχουν ληφθεί στη συνεδρίαση εξωτερικού σχεδιασμού που ορίζεται στο άρθρο ○, καθώς και εάν δεν περιέχει λογικά λάθη, και θα εγκρίνει την αντιστοιχία και την απουσία λογικών λαθών ως απόδειξη έγκρισης, με την υπογραφή και σφράγιση του εγγράφου έγκρισης του εξωτερικού σχεδίου από τους υπεύθυνους και των δύο πλευρών. Ωστόσο, εάν κατά τον έλεγχο ανακαλυφθεί ότι το εξωτερικό σχέδιο δεν συμφωνεί με το έγγραφο ορισμού απαιτήσεων ή τις αποφάσεις της συνεδρίασης εξωτερικού σχεδιασμού, ή υπάρχουν λογικά λάθη, ο Β’ θα δημιουργήσει μια τροποποιημένη έκδοση εντός της προθεσμίας που έχει συμφωνηθεί μετά από διαβούλευση και θα την παρουσιάσει στον Α’, ο οποίος θα επαναλάβει τη διαδικασία ελέγχου και έγκρισης.

2. Εάν ο Α’ δεν εκφράσει γραπτώς συγκεκριμένους λόγους αντίρρησης εντός της περιόδου ελέγχου του εξωτερικού σχεδίου, θα θεωρηθεί ότι έχει εγκρίνει το εξωτερικό σχέδιο με τη λήξη της περιόδου ελέγχου.

3. Με την έγκριση του Α’, σύμφωνα με τις προηγούμενες δύο παραγράφους, το εξωτερικό σχέδιο θα θεωρηθεί ως οριστικοποιημένο.

Στη φάση του εξωτερικού σχεδιασμού, οριστικοποιούνται οι απαιτήσεις που είναι απαραίτητες για την εκτέλεση των επόμενων βημάτων, όπως η δημιουργία του εσωτερικού σχεδίου. Ωστόσο, εάν οι απαιτήσεις παραμείνουν ασαφείς, μπορεί να προκύψουν προβλήματα στην επόμενη φάση ανάπτυξης. Αυτό το άρθρο καθορίζει τη διαδικασία με την οποία ο χρήστης ελέγχει και εγκρίνει το εξωτερικό σχέδιο, θέτοντας τις βάσεις για την επόμενη φάση ανάπτυξης.

Το πρώτο εδάφιο καθορίζει ότι ο χρήστης θα ελέγξει την αντιστοιχία του εξωτερικού σχεδίου με το έγγραφο ορισμού απαιτήσεων και τα αποτελέσματα της συνεδρίασης εξωτερικού σχεδιασμού, καθώς και την απουσία λογικών λαθών. Το επόμενο μέρος του ίδιου εδαφίου προβλέπει τη διαδικασία για τις περιπτώσεις όπου απαιτείται διόρθωση κατά τον έλεγχο. Το δεύτερο εδάφιο προβλέπει ότι, ακόμα και αν δεν έχει ολοκληρωθεί η υπογραφή και σφράγιση για την έγκριση, εάν δεν υπάρξουν αντιρρήσεις από τον χρήστη εντός της καθορισμένης περιόδου, θα θεωρηθεί ότι έχει δοθεί η έγκριση. Αυτό στοχεύει στην αποφυγή της ασάφειας σχετικά με την έγκριση του χρήστη πριν την είσοδο στη φάση του εσωτερικού σχεδιασμού, πράγμα που θα μπορούσε να προκαλέσει μελλοντικές διαφορές.

Τέλος, το τρίτο εδάφιο ορίζει ότι με την έγκριση του χρήστη, το εξωτερικό σχέδιο θα θεωρηθεί ως οριστικοποιημένο.

“`

(Ευθύνη Εγγύησης Ελαττωμάτων)
Άρθρο ○ Μετά την επικύρωση του προηγούμενου άρθρου, εάν ανακαλυφθούν ασυμφωνίες ή λογικά λάθη (εφεξής σε αυτό το άρθρο αναφέρονται ως “ελαττώματα”) στα εξωτερικά σχεδιαστικά έγγραφα σε σχέση με τα έγγραφα ορισμού απαιτήσεων και τις αποφάσεις που λήφθηκαν στη συνεδρίαση εξωτερικού σχεδιασμού του άρθρου ○, ο ανάδοχος μπορεί να απαιτήσει από τον αναθέτοντα τη διόρθωση των ελαττωμάτων, και ο αναθέτων θα διορθώσει τα ελαττώματα. Ωστόσο, ο αναθέτων θα φέρει την ευθύνη διόρθωσης μόνο εάν ο ανάδοχος υποβάλει αίτημα εντός ○ μηνών μετά την επικύρωση του προηγούμενου άρθρου.

2. Ανεξάρτητα από την προηγούμενη παράγραφο, εάν τα ελαττώματα είναι ασήμαντα και η διόρθωση των εξωτερικών σχεδιαστικών εγγράφων απαιτεί υπερβολικό κόστος, ο αναθέτων δεν θα φέρει την ευθύνη διόρθωσης που ορίζεται στην προηγούμενη παράγραφο.

3. Η διάταξη της παραγράφου 1 δεν ισχύει όταν τα ελαττώματα προκύπτουν από υλικό ή οδηγίες που παρέχονται από τον ανάδοχο, εκτός εάν ο αναθέτων γνώριζε ότι το υλικό ή οι οδηγίες ήταν ακατάλληλα και δεν το ανέφερε.

Το παρόν άρθρο καθορίζει την ευθύνη εγγύησης ελαττωμάτων σχετικά με τα εξωτερικά σχεδιαστικά έγγραφα. Η περίοδος εγγύησης ελαττωμάτων θα καθοριστεί μετά από διαβούλευση μεταξύ των μερών, λαμβάνοντας υπόψη το μέγεθος του πληροφοριακού συστήματος, την αντιστοιχία και άλλους παράγοντες, ώστε να θεωρηθεί εύλογη.

Το άρθρο 1 ορίζει ως ελαττώματα τις ασυμφωνίες ή τα λογικά λάθη στα εξωτερικά σχεδιαστικά έγγραφα σε σχέση με τα έγγραφα ορισμού απαιτήσεων και τις αποφάσεις της συνεδρίασης εξωτερικού σχεδιασμού.

Στο άρθρο 2, ακόμη και αν τα ελαττώματα είναι ασήμαντα, αν η διόρθωση των παραδοτέων απαιτεί υπερβολικό κόστος, θεωρείται αδικαιολόγητο να απαιτηθεί δωρεάν διόρθωση από τον προμηθευτή. Έτσι, προστατεύοντας τον προμηθευτή, η διάταξη αυτή συμμορφώνεται με το άρθρο 634 παράγραφος 1 του Ιαπωνικού Αστικού Κώδικα.

Το άρθρο 3 συμμορφώνεται με το άρθρο 636 του Ιαπωνικού Αστικού Κώδικα και ορίζει ότι, εάν τα ελαττώματα προκύπτουν από οδηγίες ή υλικό που παρέχεται από τον χρήστη, ο προμηθευτής δεν θα απαλλαγεί από την ευθύνη εγγύησης, εκτός εάν δεν είχε επισημάνει ότι το υλικό ή οι οδηγίες ήταν ακατάλληλα, παρόλο που το γνώριζε.

Επιπλέον, καθώς η ευθύνη εγγύησης ελαττωμάτων είναι προαιρετική, εάν δεν υπάρχει τέτοια ρύθμιση, η υπόθεση θα διευθετηθεί σύμφωνα με τις γενικές αρχές του Ιαπωνικού Αστικού Κώδικα. Η ευθύνη εγγύησης ελαττωμάτων έχει επηρεαστεί σημαντικά από τον αναθεωρημένο Ιαπωνικό Αστικό Κώδικα, ο οποίος τέθηκε σε ισχύ τον Απρίλιο του 2020 (Reiwa 2). Μετά την εφαρμογή του αναθεωρημένου Ιαπωνικού Αστικού Κώδικα, η διαχείριση αυτού του τομέα θα διαφέρει από το παρελθόν. Για περισσότερες λεπτομέρειες, δείτε το παρακάτω άρθρο.

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

Υπηρεσίες Ανάπτυξης Λογισμικού

Άρθρο Ο (Εκτέλεση Εργασιών Ανάπτυξης Λογισμικού)
Ο Β, μετά τη σύναψη ενός ατομικού συμβολαίου όπως ορίζεται στο Άρθρο 25, θα διεξάγει εργασίες ανάπτυξης λογισμικού ως το αντικείμενο της παρούσας εργασίας, από τον εσωτερικό σχεδιασμό μέχρι τη δοκιμή του συστήματος, βάσει των προδιαγραφών του συστήματος που έχουν καθοριστεί στις προηγούμενες ενότητες.

2. Κατά την εκτέλεση των εργασιών ανάπτυξης λογισμικού, ο Β μπορεί να ζητήσει την απαραίτητη συνεργασία από τον Α, και ο Α, όταν ζητηθεί η συνεργασία του από τον Β, θα ανταποκρίνεται εγκαίρως.

Στα παρακάτω άρθρα, καθορίζονται οι όροι για την ανάπτυξη λογισμικού από έναν προμηθευτή σε μορφή εργολαβίας. Στο στάδιο του εσωτερικού σχεδιασμού του συστήματος, είναι συνήθως ορισμένοι οι στόχοι ανάπτυξης και οι προδιαγραφές από τα προηγούμενα στάδια της εργασίας, γι’ αυτό το Υπουργείο Οικονομίας, Εμπορίου και Βιομηχανίας (ΜΕΤΙ) παρέχει ένα πρότυπο συμβόλαιο για την εργολαβία.
Άρθρο Ο (Σύναψη Ειδικής Σύμβασης για Εργασίες Ανάπτυξης Λογισμικού)
Ο Α και ο Β θα συζητήσουν και θα αποφασίσουν για τους όρους συναλλαγής που αναφέρονται στο Άρθρο Ο, Παράγραφος Ο, και θα συνάψουν μια ειδική σύμβαση για τις εργασίες ανάπτυξης λογισμικού.

Το πεδίο των εργασιών ανάπτυξης λογισμικού και άλλες λεπτομέρειες θα καθοριστούν σύμφωνα με τους όρους συναλλαγής που έχουν ήδη καθοριστεί και θα συμφωνηθούν μέσω της ειδικής σύμβασης.

(Παράδοση των Παραδοτέων)
Άρθρο 〇: Ο Β θα πρέπει να παραδώσει στον Α τα παραδοτέα που ορίζονται στην ατομική σύμβαση, μαζί με το αίτημα παραλαβής (που λειτουργεί και ως παραστατικό παράδοσης), μέχρι την προθεσμία που καθορίζεται στην ατομική σύμβαση.
2. Ο Α, σε περίπτωση παράδοσης, θα διενεργήσει έλεγχο βάσει των προδιαγραφών ελέγχου του επόμενου άρθρου, σύμφωνα με τις διατάξεις του άρθρου 〇 (Παραλαβή του εν λόγω λογισμικού).
3. Ο Β μπορεί να ζητήσει την απαραίτητη συνεργασία από τον Α κατά την παράδοση των παραδοτέων, και ο Α θα πρέπει να ανταποκριθεί άμεσα σε τέτοια αίτημα συνεργασίας.
4. Ο κίνδυνος απώλειας ή καταστροφής των παραδοτέων θα βαρύνει τον Β πριν την παράδοση και τον Α μετά την παράδοση.

Δεδομένου ότι αυτή η διαδικασία αφορά ένα συμβόλαιο ανάθεσης έργου, το ολοκληρωμένο λογισμικό και άλλα αποτελέσματα θα πρέπει να παραδοθούν ως αντικείμενα ελέγχου. Το πρώτο εδάφιο καθορίζει την παράδοση των παραδοτέων μαζί με το αίτημα παραλαβής (που λειτουργεί και ως παραστατικό παράδοσης).

Το δεύτερο εδάφιο αναφέρεται στη διενέργεια ελέγχου από τον χρήστη.
Το τρίτο εδάφιο καθορίζει την υποχρέωση συνεργασίας του χρήστη σε περιπτώσεις όπου απαιτείται η συνεργασία του για την παράδοση στον τόπο που ορίζεται στην ατομική σύμβαση (όπως σε περιπτώσεις παράδοσης στο γραφείο του χρήστη ή σε περιπτώσεις παράδοσης σε λειτουργικό περιβάλλον του χρήστη).
Το τέταρτο εδάφιο αφορά τη ρήτρα κινδύνου απώλειας ή καταστροφής των παραδοτέων, διαχωρίζοντας την χρονική στιγμή μεταφοράς του κινδύνου με βάση την φυσική κατάκτηση του ελέγχου.

Άρθρο 〇 (Παραλαβή του Συγκεκριμένου Λογισμικού)
Στο πλαίσιο των παραδοτέων, ο ανάδοχος πρέπει να ελέγξει το συγκεκριμένο λογισμικό εντός της περιόδου που ορίζεται στην ατομική σύμβαση (εφεξής αναφερόμενη ως “περίοδος ελέγχου”) βάσει του προηγούμενου άρθρου της προδιαγραφής ελέγχου και να διαπιστώσει αν το λογισμικό συμφωνεί με τις προδιαγραφές του συστήματος.

2. Εάν το συγκεκριμένο λογισμικό περάσει τον έλεγχο του προηγούμενου εδαφίου, ο ανάδοχος θα υπογράψει και θα σφραγίσει το πιστοποιητικό επιτυχούς ελέγχου και θα το παραδώσει στον αναθέτοντα. Επιπλέον, εάν το λογισμικό δεν περάσει τον έλεγχο, ο ανάδοχος θα πρέπει να παραδώσει άμεσα στον αναθέτοντα ένα έγγραφο που θα αναφέρει τους συγκεκριμένους λόγους της αποτυχίας και να ζητήσει διορθώσεις ή προσθήκες. Εάν οι λόγοι αποτυχίας είναι αποδεκτοί, ο αναθέτων θα πρέπει να διορθώσει το λογισμικό δωρεάν εντός της συμφωνηθείσας προθεσμίας και να το παραδώσει στον ανάδοχο, ο οποίος θα πρέπει να επαναλάβει τον απαιτούμενο έλεγχο στο βαθμό που είναι απαραίτητο.

3. Ακόμη και αν δεν παραδοθεί πιστοποιητικό επιτυχούς ελέγχου, εάν ο ανάδοχος δεν εκφράσει γραπτώς και με συγκεκριμένους λόγους τις αντιρρήσεις του εντός της περιόδου ελέγχου, το συγκεκριμένο λογισμικό θα θεωρηθεί ότι έχει περάσει τον έλεγχο που ορίζεται σε αυτό το άρθρο.

4. Η επιτυχής ολοκλήρωση του ελέγχου που ορίζεται σε αυτό το άρθρο θα θεωρηθεί ως η πλήρης παραλαβή του συγκεκριμένου λογισμικού.

Δεδομένου ότι αυτή η διαδικασία αφορά ένα συμβόλαιο ανάθεσης, το παρόν άρθρο καθορίζει τη διαδικασία παραλαβής του παραδοτέου λογισμικού.

Το πρώτο εδάφιο καθορίζει ότι ο ανάδοχος πρέπει να ελέγξει το λογισμικό εντός της περιόδου ελέγχου βάσει της προδιαγραφής ελέγχου και να διαπιστώσει αν συμφωνεί με τις προδιαγραφές του συστήματος.
Το δεύτερο εδάφιο υποχρεώνει τον προμηθευτή να διορθώσει το λογισμικό σε περίπτωση που δεν συμφωνεί με τις προδιαγραφές του συστήματος και να παραδώσει τη διορθωμένη έκδοση στον χρήστη.
Το τρίτο εδάφιο προβλέπει την περίπτωση της θεωρούμενης επιτυχούς παραλαβής για να αποτρέψει την καθυστέρηση της παραλαβής λόγω της διαθεσιμότητας του χρήστη.
Το τέταρτο εδάφιο δηλώνει ότι η επιτυχής παραλαβή του ελέγχου θα θεωρηθεί ως η πλήρης παραλαβή του λογισμικού.

(Εγγύηση Ελαττωμάτων)
Άρθρο 〇 Μετά την ολοκλήρωση του ελέγχου του προηγούμενου άρθρου, εάν ανακαλυφθούν ασυμφωνίες (συμπεριλαμβανομένων των σφαλμάτων, εφεξής αναφερόμενα σε αυτό το άρθρο ως “ελαττώματα”) στα παραδοτέα σε σχέση με τις προδιαγραφές του συστήματος, ο ανάδοχος μπορεί να απαιτήσει από τον αναθέτοντα τη διόρθωση των εν λόγω ελαττωμάτων, και ο αναθέτων πρέπει να διορθώσει τα ελαττώματα. Ωστόσο, ο αναθέτων θα φέρει την ευθύνη διόρθωσης μόνο εάν ο ανάδοχος έχει ζητήσει τη διόρθωση εντός ○ μηνών μετά την ολοκλήρωση του ελέγχου του προηγούμενου άρθρου.
2. Ανεξάρτητα από την προηγούμενη παράγραφο, εάν τα ελαττώματα είναι ασήμαντα και η διόρθωση των παραδοτέων απαιτεί υπερβολικό κόστος, ο αναθέτων δεν θα φέρει την ευθύνη διόρθωσης που ορίζεται στην προηγούμενη παράγραφο.
3. Η διάταξη της πρώτης παραγράφου δεν ισχύει όταν τα ελαττώματα προκύπτουν από υλικό ή οδηγίες που παρέχονται από τον ανάδοχο, εκτός εάν ο αναθέτων γνώριζε ότι το υλικό ή οι οδηγίες ήταν ακατάλληλα και δεν το ανέφερε.

Δεδομένου ότι αυτή η διαδικασία είναι μια σύμβαση εργολαβίας, το παρόν άρθρο καθορίζει την εγγύηση για ελαττώματα σχετικά με τα παραδοτέα. Στην πράξη, είναι δύσκολο να κριθεί το όριο μεταξύ της ευθύνης για μη εκπλήρωση των υποχρεώσεων όταν η εργασία δεν έχει ολοκληρωθεί και της εγγύησης για ελαττώματα μετά την προσωρινή ολοκλήρωση της εργασίας. Υπάρχει νομολογία (Απόφαση του Δικαστηρίου του Τόκιο, 22 Απριλίου 2002 (Heisei 14)) που ορίζει ότι η απόφαση για το αν ένα σύστημα θεωρείται ολοκληρωμένο πρέπει να βασίζεται στο αν η εργασία έχει ολοκληρωθεί μέχρι το τελευταίο στάδιο που προβλεπόταν στην αρχική σύμβαση εργολαβίας. Όταν ανακαλύπτονται ελαττώματα μετά την ολοκλήρωση και την παράδοση του λογισμικού καθώς και την επιτυχή έλεγχο, τότε καταρχήν εφαρμόζεται η εγγύηση για ελαττώματα.

Το πρώτο εδάφιο ορίζει ως ελαττώματα τις “ασυμφωνίες με τις προδιαγραφές του συστήματος” που προκύπτουν κατά την ανάπτυξη λογισμικού. Οι ελλείψεις λειτουργικότητας που προκύπτουν κατά το στάδιο του εξωτερικού σχεδιασμού δεν καλύπτονται από αυτό το άρθρο, αλλά από διατάξεις που αφορούν την εγγύηση για ελαττώματα στο στάδιο του εξωτερικού σχεδιασμού. Η περίοδος εγγύησης για ελαττώματα θα καθοριστεί με διαπραγμάτευση μεταξύ των μερών, λαμβάνοντας υπόψη το μέγεθος του πληροφοριακού συστήματος, την αντιστάθμιση και άλλους παράγοντες, για να καθοριστεί μια περίοδος που θεωρείται κατάλληλη.

Το δεύτερο εδάφιο προβλέπει ότι, ακόμη και αν τα ελαττώματα είναι ασήμαντα, δεν είναι δίκαιο να απαιτείται από τον προμηθευτή να διορθώσει τα παραδοτέα χωρίς χρέωση εάν αυτό απαιτεί υπερβολικό κόστος, επομένως έχει θεσπιστεί μια διάταξη σύμφωνα με το άρθρο 634 παράγραφος 1 του Αστικού Κώδικα.

Το τρίτο εδάφιο ακολουθεί το άρθρο 636 του Αστικού Κώδικα, ορίζοντας ότι ο προμηθευτής δεν φέρει ευθύνη για ελαττώματα που προκύπτουν από οδηγίες ή υλικό που παρέχεται από τον χρήστη, εκτός εάν ο προμηθευτής γνώριζε ότι το υλικό ή οι οδηγίες ήταν ακατάλληλα και δεν το ανέφερε, σε αυτή την περίπτωση δεν απαλλάσσεται από την ευθύνη.

Για περαιτέρω λεπτομέρειες σχετικά με το πότε αναγνωρίζεται ένα ελάττωμα και τι ακριβώς περιλαμβάνει η ευθύνη σε περίπτωση που αναγνωριστεί, δείτε το παρακάτω άρθρο.

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

Υποστήριξη Προετοιμασίας και Μετάβασης σε Λειτουργία Λογισμικού

Στο στάδιο της παραλαβής και εισαγωγής ενός συστήματος, είναι συνήθως ο χρήστης που αναλαμβάνει την κύρια δράση, γι’ αυτό και τα μοντέλα συμβάσεων του Ιαπωνικού Υπουργείου Οικονομίας, Εμπορίου και Βιομηχανίας (METI) ορίζουν ότι ο χρήστης είναι ο κύριος ενεργός παράγοντας, με τον προμηθευτή να παρέχει υποστήριξη σε αυτή τη διαδικασία, σε μια μορφή παρόμοια με την εντολή.

Καθορισμός της Φύσης της Σύμβασης

Για να καθορίσουμε τη φύση μιας σύμβασης, πρέπει να εξετάσουμε το σύνολο της σύμβασης και να διαπιστώσουμε εάν ο σκοπός της είναι η «παροχή ενός ολοκληρωμένου αποτελέσματος» ή εάν βασίζεται στην «λογική εκτέλεση των εργασιών» από τον προμηθευτή. Ένας γενικός κανόνας είναι κατά πόσο το περιεχόμενο του αντικειμένου που πρέπει να ολοκληρωθεί έχει καθοριστεί σε κάποιο βαθμό συγκεκριμένα και εάν το έργο έχει προχωρήσει προς αυτή την κατεύθυνση. Για το ποια συγκεκριμένα σημεία θα πρέπει να εστιάσουμε, παρέχουμε λεπτομερή ανάλυση στο παρακάτω άρθρο.