Was sind die wichtigsten Punkte, die in Verträgen für auftragsbasierte Systementwicklung zu beachten sind?

Das japanische Ministerium für Wirtschaft, Handel und Industrie (METI) hat in seinen “Leitlinien zur Verbesserung der Zuverlässigkeit von Informationssystemen” (Japanische Leitlinien zur Verbesserung der Zuverlässigkeit von Informationssystemen) Musterklauseln für IT-Systementwicklungsverträge vorgestellt. Mit der zunehmenden Verbreitung des Internets nimmt die gesellschaftliche Auswirkung von Betriebs- und Dienstleistungsunterbrechungen oder Leistungseinbußen durch Störungen in Informationssystemen stetig zu. Während die Verbesserung der Zuverlässigkeit und Sicherheit von Systemen eine dringende Aufgabe darstellt, neigen Verträge über IT-Systementwicklung dazu, unklar zu sein, was den Inhalt der Transaktionen betrifft. Diese Klauseln zielen darauf ab, die Transparenz zu erhöhen und die Rollenverteilung und Verantwortlichkeiten zu klären. In diesem Artikel werden wir die Checkpunkte für Verträge bei der Vergabe von IT-Systementwicklungsaufträgen unter Bezugnahme auf die Klauseln des METI-Mustervertrags erläutern.

Systementwicklung und Werkvertrag

Was ist ein Werkvertrag?

Ein Werkvertrag ist im japanischen Zivilgesetzbuch (Bürgerliches Gesetzbuch) wie folgt definiert:

Artikel 632
Ein Werkvertrag entsteht, wenn eine Partei verspricht, eine bestimmte Arbeit zu vollenden, und die andere Partei verspricht, für das Ergebnis dieser Arbeit zu bezahlen.

Im Werkvertrag ist es eine Voraussetzung, dass “eine bestimmte Arbeit vollendet wird”. Wenn zum Beispiel das Ziel des Vertrags darin besteht, ein bestimmtes System bis zu einem bestimmten Datum zu erstellen, besteht die Verpflichtung des Anbieters darin, “das System bis zu diesem Datum zu vollenden”. Wenn das System nicht bis zum vereinbarten Datum fertiggestellt werden kann, kann die Verantwortung für die Nichterfüllung der Verpflichtung aufgrund von Verzögerungen auferlegt werden. Allerdings, wenn nach der Fertigstellung und Lieferung des Systems Mängel gefunden werden, ist die Verpflichtung des Anbieters bereits erfüllt, so dass die Nichterfüllung der Verpflichtung kein Problem darstellt, und es wird eine Frage der Gewährleistung für Mängel. In Bezug auf die Systementwicklung wird im folgenden Artikel ausführlich erläutert, unter welchen Umständen die “Vollendung der Arbeit” anerkannt wird.

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

Unterschiede zum Auftragsvertrag

Im Werkvertrag hat der Anbieter die Pflicht, die Arbeit zu vollenden, so dass er im Falle von Mängeln in den gelieferten Ergebnissen die Gewährleistung für Mängel übernimmt. Im Gegensatz dazu hat ein Auftragsvertrag keine Pflicht zur Vollendung der Arbeit, so dass er keine Gewährleistung für Mängel wie ein Werkvertrag übernimmt. Allerdings kann, wenn im Prozess der Geschäftsabwicklung eine Sorgfaltspflicht anerkannt wird, eine separate Verantwortung für die Nichterfüllung der Verpflichtung, wie Schadenersatz, übernommen werden. Welche Verantwortung in einem Systementwicklungsvertrag ein Problem darstellt, wird im folgenden Artikel ausführlich erläutert.

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

Vertragsmuster und Checkpunkte für Auftragsmodelle

Unterstützung bei der Erstellung von Anforderungsdefinitionen

Die Anforderungsdefinition ist ein Prozess, in dem die Benutzeranforderungen für das zu erstellende System zusammengefasst werden. Im Rahmen der Anforderungsdefinition wird die Ausrichtung des Systemaufbaus geprüft und entschieden, welches System erstellt werden soll. Da die Ergebnisse nicht konkret vorhersehbar sind, definiert das japanische Ministerium für Wirtschaft, Handel und Industrie (METI) den Modellvertrag als quasi-mandatiert. Weitere Details werden im folgenden Artikel erläutert.

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

Erstellung von externen Design-Dokumenten

(Durchführung der Erstellung von externen Design-Dokumenten)
Artikel ○ Der Auftragnehmer führt, nach Abschluss des im Artikel ○ festgelegten Einzelvertrags, die Erstellung von externen Design-Dokumenten für die betreffende Software gemäß den Anforderungen des im Artikel ○ festgelegten Anforderungsdokuments durch.

2. Bei der Durchführung der Erstellung von externen Design-Dokumenten kann der Auftragnehmer vom Auftraggeber die notwendige Zusammenarbeit verlangen, und der Auftraggeber wird auf diese Anforderung rechtzeitig reagieren.

Die Erstellung von externen Design-Dokumenten ist eine Aufgabe, die die Nutzung von Schnittstellen wie Bildschirmen und Formularen festlegt. In den externen Design-Dokumenten sollten grundsätzlich alle Informationen enthalten sein, die ein Anbieter benötigt, um ein Programm zu entwickeln. Obwohl die externen Design-Dokumente detaillierte Informationen über die Verwendung von Formaten enthalten, kann nur der Benutzer, der die Geschäftsanforderungen festlegt, die Anforderungsspezifikationen ändern. Allerdings, wenn das Anforderungsdokument, das das Ergebnis der vorherigen Phase der Erstellung von externen Design-Dokumenten ist, die Bedürfnisse des Benutzers klar definiert und die Arbeit, die der Anbieter abschließen muss, klar ist, kann der Vertrag in einer Form abgeschlossen werden, in der der Anbieter die Hauptrolle bei der Erstellung der externen Design-Dokumente spielt.

Der erste Absatz legt fest, dass der Anbieter die Hauptrolle bei der Durchführung der Arbeit hat, da dieser Prozess auf Vertragsbasis durchgeführt wird. Allerdings, auch wenn es sich um einen Vertrag handelt, da das externe Design einen großen Einfluss auf die Festlegung der Geschäftsanforderungen des Benutzers hat, ist eine aktive Beteiligung des Benutzers erforderlich. Daher klärt der zweite Absatz, dass der Anbieter den Benutzer um die notwendige Zusammenarbeit bei der Prüfung und Festlegung der Systemspezifikationen bitten kann und dass der Benutzer rechtzeitig darauf reagieren wird, was die Prüfung der Systemspezifikationen zu einer gemeinsamen Aufgabe von Anbieter und Benutzer macht.

(Abschluss eines Einzelvertrags für die Erstellung von externen Design-Dokumenten)
Artikel ○ Der Auftraggeber und der Auftragnehmer legen die im Artikel ○ Absatz ○ aufgeführten Handelsbedingungen durch Verhandlungen fest und schließen einen Einzelvertrag für die Erstellung von externen Design-Dokumenten ab.

Der Umfang der Erstellung von externen Design-Dokumenten wird gemäß den in den vorherigen Klauseln festgelegten Handelsbedingungen in einem Einzelvertrag festgelegt.

(Externe Design-Review-Sitzung)
Artikel ○ Der Auftragnehmer führt in der erforderlichen Häufigkeit externe Design-Review-Sitzungen (im Folgenden in diesem Abschnitt “externe Design-Review-Sitzungen” genannt) gemäß den im Artikel ○ festgelegten Kommunikations- und Beratungsverfahren durch, um die Klärung oder Bestätigung von Angelegenheiten, die für die Erstellung von externen Design-Dokumenten erforderlich sind, durchzuführen, und der Auftraggeber nimmt daran teil.

2. Der Auftraggeber kann auch externe Design-Review-Sitzungen abhalten, wenn er dies für die Erstellung von externen Design-Dokumenten für notwendig hält, und der Auftragnehmer nimmt daran teil.

3. Wenn der Auftraggeber aufgrund der Diskussionen in der externen Design-Review-Sitzung den Inhalt des Anforderungsdokuments ändern möchte und dies eine Änderung der Bedingungen des Einzelvertrags, wie z.B. die Arbeitszeit und die Vergütung, erfordert, erfolgt dies gemäß dem Verfahren des Artikels 33 (Änderung des Inhalts dieses Vertrags und des Einzelvertrags).

Für die Erstellung von externen Design-Dokumenten, die die Schnittstellen wie Bildschirme und Formulare festlegen, ist eine Zusammenarbeit zwischen Benutzer und Anbieter unerlässlich. Da dieser Prozess auf Vertragsbasis durchgeführt wird, legt Absatz 1 fest, dass der Anbieter die Sitzungen leitet und der Benutzer daran teilnimmt. Die Klärung oder Bestätigung von Angelegenheiten, die für die Erstellung von externen Design-Dokumenten erforderlich sind, erfolgt alle in der externen Design-Review-Sitzung, und der Anbieter und der Benutzer sind an die Ergebnisse der Diskussion in der Sitzung gebunden.

Absatz 2 legt fest, dass der Benutzer auch externe Design-Review-Sitzungen abhalten kann, wenn er dies für die Durchführung der Erstellung von externen Design-Dokumenten für notwendig hält.
Absatz 3 legt fest, dass, wenn der Benutzer aufgrund der Diskussionen den Inhalt des Anforderungsdokuments ändern möchte und dies eine Änderung der Bedingungen des Einzelvertrags, wie z.B. die Arbeitszeit und die Vergütung, erfordert, dies gemäß dem Verfahren eines anderen Artikels erfolgt, der die Änderung des Inhalts dieses Vertrags und des Einzelvertrags regelt.

(Lieferung der externen Design-Dokumente)
Artikel ○ Der Auftragnehmer liefert die externen Design-Dokumente und das Anforderungsformular für die Abnahme der externen Design-Dokumente (auch Lieferformular) bis zum im Einzelvertrag festgelegten Datum an den Auftraggeber.

Da dieser Prozess auf Vertragsbasis durchgeführt wird, liefert der Anbieter die externen Design-Dokumente usw. als Ergebnis.

(Genehmigung und Bestätigung der externen Design-Dokumente)
Artikel ○ Der Auftraggeber prüft innerhalb des im Einzelvertrag festgelegten Zeitraums (im Folgenden “Prüfungszeitraum für externe Design-Dokumente” genannt), ob die externen Design-Dokumente den im Artikel ○ festgelegten Anforderungen des Anforderungsdokuments und den im Artikel ○ festgelegten Entscheidungen der externen Design-Review-Sitzung entsprechen und ob es keine logischen Fehler gibt, und genehmigt, dass sie entsprechen und es keine logischen Fehler gibt, indem die Verantwortlichen beider Parteien das Genehmigungsformular für externe Design-Dokumente unterzeichnen und stempeln. Wenn jedoch bei der Prüfung festgestellt wird, dass die externen Design-Dokumente den im Artikel ○ festgelegten Anforderungen des Anforderungsdokuments und den Entscheidungen der externen Design-Review-Sitzung nicht entsprechen oder logische Fehler enthalten, erstellt der Auftragnehmer innerhalb einer vereinbarten Frist eine korrigierte Version und legt sie dem Auftraggeber vor, und der Auftraggeber führt erneut die oben genannte Prüfung und Genehmigungsverfahren durch.

2. Wenn der Auftraggeber innerhalb des Prüfungszeitraums für externe Design-Dokumente keine Einwände mit konkreten Gründen schriftlich vorbringt, wird davon ausgegangen, dass der Auftraggeber die externen Design-Dokumente mit Ablauf des Prüfungszeitraums für externe Design-Dokumente genehmigt hat.

3. Mit der Genehmigung des Auftraggebers gemäß den vorherigen Absätzen gelten die externen Design-Dokumente als bestätigt.

In der Phase des externen Designs werden die Anforderungen festgelegt, die für die Durchführung der nachfolgenden Erstellung von internen Design-Dokumenten usw. erforderlich sind, aber wenn die Festlegung der Anforderungen unklar bleibt, können Probleme in der nachfolgenden Entwicklung auftreten. Dieser Artikel legt das Verfahren fest, nach dem der Benutzer die externen Design-Dokumente, die die Grundlage für die nachfolgende Entwicklungsarbeit bilden, prüft und durch die Genehmigung des Benutzers bestätigt.

Absatz 1 legt fest, dass der Benutzer die Übereinstimmung der externen Design-Dokumente mit dem in einem anderen Artikel festgelegten Anforderungsdokument und den Ergebnissen der Diskussionen in der externen Design-Review-Sitzung sowie das Fehlen von logischen Fehlern prüft. Es kann vorkommen, dass bei der Prüfung zur Genehmigung der externen Design-Dokumente eine Korrektur erforderlich ist, und der provisorische Absatz legt das Verfahren in diesem Fall fest.
Absatz 2 ist eine Bestimmung, die besagt, dass, selbst wenn die Unterzeichnung der Genehmigung nicht abgeschlossen ist, wenn der Benutzer innerhalb einer bestimmten Zeit keine Einwände erhebt, davon ausgegangen wird, dass der Benutzer die Genehmigung erteilt hat. Es besteht die Gefahr, dass Probleme auftreten, wenn die Genehmigung des Benutzers unklar bleibt und die interne Gestaltung fortgesetzt wird, und diese Klausel zielt darauf ab, solche Probleme zu verhindern.

Und Absatz 3 legt fest, dass die externen Design-Dokumente mit der Genehmigung des Benutzers als bestätigt gelten.

(Gewährleistungspflicht für Mängel)
Artikel ○ Wenn nach der Bestätigung im vorherigen Artikel festgestellt wird, dass die externen Design-Dokumente nicht mit dem Anforderungsdokument und den im Artikel ○ festgelegten Entscheidungen der externen Design-Review-Sitzung übereinstimmen oder logische Fehler enthalten (im Folgenden in diesem Artikel “Mängel” genannt), kann der Auftraggeber vom Auftragnehmer die Behebung dieser Mängel verlangen, und der Auftragnehmer behebt diese Mängel. Der Auftragnehmer ist jedoch nur dann zur Behebung dieser Mängel verpflichtet, wenn der Auftraggeber innerhalb von ○ Monaten nach der Bestätigung im vorherigen Artikel eine Anforderung stellt.

2. Ungeachtet des vorherigen Absatzes ist der Auftragnehmer nicht verpflichtet, die im vorherigen Absatz genannte Mängelbehebungspflicht zu erfüllen, wenn der Mangel geringfügig ist und die Behebung der externen Design-Dokumente übermäßige Kosten verursachen würde.

3. Die Bestimmungen des Absatzes 1 gelten nicht, wenn der Mangel durch vom Auftraggeber bereitgestellte Unterlagen oder Anweisungen des Auftraggebers verursacht wurde. Dies gilt jedoch nicht, wenn der Auftragnehmer wusste, dass diese Unterlagen oder Anweisungen unangemessen waren und dies nicht mitgeteilt hat.

Dieser Artikel legt die Gewährleistungspflicht für Mängel in Bezug auf die externen Design-Dokumente fest. Die Gewährleistungsfrist für Mängel wird unter Berücksichtigung der Größe des Informationssystems, der Vergütung usw. in einer angemessenen Frist festgelegt, die durch Verhandlungen zwischen den Parteien festgelegt wird.

Absatz 1 definiert die Nichtübereinstimmung der externen Design-Dokumente mit dem Anforderungsdokument und den Entscheidungen der externen Design-Review-Sitzung sowie logische Fehler in den externen Design-Dokumenten als Mängel.

Absatz 2 schützt den Anbieter, indem er, ähnlich wie in Artikel 634 Absatz 1 des Bürgerlichen Gesetzbuchs, festlegt, dass der Anbieter nicht verpflichtet ist, die im vorherigen Absatz festgelegte Mängelbehebungspflicht zu erfüllen, wenn der Mangel geringfügig ist und die Behebung der externen Design-Dokumente übermäßige Kosten verursachen würde.

Absatz 3 ist eine Bestimmung, die ähnlich wie Artikel 636 des Bürgerlichen Gesetzbuchs festlegt, dass, wenn der Mangel durch Anweisungen oder Unterlagen des Auftraggebers verursacht wurde, der Anbieter von der Gewährleistungspflicht befreit ist, es sei denn, der Anbieter wusste, dass diese Unterlagen oder Anweisungen unangemessen waren und dies nicht mitgeteilt hat.

Bitte beachten Sie, dass die Gewährleistungspflicht für Mängel eine optionale Bestimmung ist und dass, wenn eine solche Bestimmung nicht vorhanden ist, die Angelegenheit gemäß den allgemeinen Grundsätzen des Bürgerlichen Gesetzbuchs behandelt wird. Die Gewährleistungspflicht für Mängel ist stark von den Änderungen des Bürgerlichen Gesetzbuchs betroffen, die im April 2020 in Kraft treten, und nach Inkrafttreten der Änderungen des Bürgerlichen Gesetzbuchs wird sich die Behandlung in diesem Bereich ändern. Weitere Details finden Sie im folgenden Artikel.

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

Softwareentwicklung

(Durchführung der Softwareentwicklung)
Artikel X: Der Auftragnehmer führt nach Abschluss des Einzelvertrags gemäß Artikel 25 die Softwareentwicklung als Teil dieser Aufgabe durch, basierend auf den Systemspezifikationen, die durch die vorherigen Abschnitte festgelegt wurden, von der internen Planung bis zum Systemtest.

2. Bei der Durchführung der Softwareentwicklung kann der Auftragnehmer vom Auftraggeber die notwendige Zusammenarbeit verlangen, und der Auftraggeber wird rechtzeitig auf diese Anforderung reagieren, wenn er vom Auftragnehmer um Zusammenarbeit gebeten wird.

In den folgenden Abschnitten werden die Klauseln für den Fall definiert, dass ein Anbieter die Softwareentwicklung als Auftragnehmer durchführt. In der Phase der internen Systemplanung sind normalerweise die zu entwickelnden Ziele und Spezifikationen in den vorherigen Arbeitsphasen definiert, daher wird im Modellvertrag des Ministeriums für Wirtschaft, Handel und Industrie (METI) festgelegt, dass dies als Auftragsarbeit durchgeführt wird.

(Abschluss eines Einzelvertrags für die Softwareentwicklung)
Artikel X: Der Auftraggeber und der Auftragnehmer bestimmen nach Absprache die Handelsbedingungen gemäß Artikel X, Absatz X für die betreffende Softwareentwicklung und schließen einen Einzelvertrag für die Softwareentwicklung ab.

Der Umfang der Softwareentwicklung usw. wird gemäß den zuvor festgelegten Handelsbedingungen in einem Einzelvertrag festgelegt.

(Lieferung der Liefergegenstände)
Artikel X: Der Auftragnehmer liefert dem Auftraggeber die in dem Einzelvertrag festgelegten Liefergegenstände zusammen mit dem Antrag auf Abnahme (auch Lieferdokument) bis zum im Einzelvertrag festgelegten Datum.
2. Wenn eine Lieferung erfolgt ist, führt der Auftraggeber eine Inspektion gemäß den Inspektionsspezifikationen des nächsten Artikels und den Bestimmungen von Artikel X (Abnahme der betreffenden Software) durch.
3. Bei der Lieferung der Liefergegenstände kann der Auftragnehmer vom Auftraggeber die notwendige Zusammenarbeit verlangen, und der Auftraggeber wird schnell auf diese Anforderung reagieren, wenn er vom Auftragnehmer um Zusammenarbeit gebeten wird.
4. Das Risiko des Verlusts oder der Beschädigung der Liefergegenstände liegt vor der Lieferung beim Auftragnehmer und nach der Lieferung beim Auftraggeber.

Da dieser Prozess als Auftragsarbeit durchgeführt wird, wird die fertige Software als Liefergegenstand zur Inspektion geliefert. Absatz 1 legt fest, dass die Liefergegenstände zusammen mit dem Antrag auf Abnahme (auch Lieferdokument) geliefert werden.

Absatz 2 legt die Durchführung der Inspektion durch den Benutzer fest.
Absatz 3 legt die Pflicht zur Zusammenarbeit des Benutzers fest, da es Fälle geben kann, in denen die Zusammenarbeit des Benutzers bei der Lieferung an den im Einzelvertrag festgelegten Lieferort erforderlich ist (z.B. wenn die Lieferung in das Büro des Benutzers eingeliefert wird, wenn die Lieferung in einem betriebsbereiten Zustand in der tatsächlichen Betriebsumgebung des Benutzers erfolgt usw.).
Absatz 4 ist eine Klausel über das Risiko des Verlusts oder der Beschädigung der Liefergegenstände und teilt den Zeitpunkt des Risikotransfers durch den Übergang der physischen Kontrolle.

(Abnahme der betreffenden Software)
Artikel X: Für die betreffende Software unter den Liefergegenständen führt der Auftraggeber innerhalb des im Einzelvertrag festgelegten Zeitraums (im Folgenden “Inspektionszeitraum” genannt) eine Inspektion gemäß den Inspektionsspezifikationen des vorherigen Artikels durch und überprüft, ob die Systemspezifikationen und die betreffende Software übereinstimmen.

2. Wenn die betreffende Software den Inspektionen des vorherigen Absatzes entspricht, unterzeichnet und stempelt der Auftraggeber das Inspektionszertifikat und übergibt es dem Auftragnehmer. Darüber hinaus, wenn die betreffende Software die Inspektion des vorherigen Absatzes nicht besteht, übergibt der Auftraggeber dem Auftragnehmer schnell ein Dokument, das die spezifischen Gründe für das Nichtbestehen klar darlegt, und fordert eine Korrektur oder Ergänzung an. Wenn die Gründe für das Nichtbestehen anerkannt werden, korrigiert der Auftragnehmer die betreffende Software kostenlos innerhalb der vereinbarten Frist und liefert sie dem Auftraggeber, und der Auftraggeber führt die Inspektion gemäß dem vorherigen Absatz erneut in dem erforderlichen Umfang durch.

3. Auch wenn kein Inspektionszertifikat ausgestellt wird, wird die betreffende Software als bestanden betrachtet, wenn der Auftraggeber innerhalb des Inspektionszeitraums keinen Einwand mit spezifischen Gründen schriftlich erhebt.

4. Mit der Inspektion gemäß diesem Artikel wird die Abnahme der betreffenden Software abgeschlossen.

Da dieser Prozess als Auftragsarbeit durchgeführt wird, legt dieser Artikel das Verfahren für die Abnahme der gelieferten Software fest.

Absatz 1 legt fest, dass der Auftraggeber die betreffende Software innerhalb des Inspektionszeitraums gemäß den Inspektionsspezifikationen inspiziert und überprüft, ob die Systemspezifikationen und die betreffende Software übereinstimmen.
Absatz 2 verpflichtet den Anbieter, die betreffende Software zu korrigieren und die korrigierte Version dem Benutzer zu liefern, wenn festgestellt wird, dass die betreffende Software nicht den Systemspezifikationen entspricht.
Absatz 3 dient dazu, zu verhindern, dass die Abnahme aufgrund der Umstände des Benutzers verzögert wird, indem eine Klausel für die angenommene Abnahme eingeführt wird.
Absatz 4 stellt klar, dass die Abnahme der betreffenden Software mit der Inspektion abgeschlossen ist.

(Gewährleistungspflicht für Mängel)
Artikel X: Nach Abschluss der Inspektion gemäß dem vorherigen Artikel, wenn eine Nichtübereinstimmung mit den Systemspezifikationen (einschließlich Bugs, im Folgenden in diesem Artikel als “Mängel” bezeichnet) in den Liefergegenständen entdeckt wird, kann der Auftraggeber vom Auftragnehmer die Korrektur dieser Mängel verlangen, und der Auftragnehmer wird diese Mängel korrigieren. Allerdings ist der Auftragnehmer nur dann zur Korrektur verpflichtet, wenn der Auftraggeber innerhalb von X Monaten nach Abschluss der Abnahme gemäß dem vorherigen Artikel eine Anforderung stellt.
2. Ungeachtet des vorherigen Absatzes, wenn der Mangel geringfügig ist und die Korrektur der Liefergegenstände übermäßige Kosten verursacht, ist der Auftragnehmer nicht verpflichtet, die im vorherigen Absatz festgelegte Korrekturpflicht zu erfüllen.
3. Die Bestimmungen des Absatzes 1 gelten nicht, wenn der Mangel aufgrund von vom Auftraggeber bereitgestellten Materialien oder Anweisungen des Auftraggebers entstanden ist. Dies gilt jedoch nicht, wenn der Auftragnehmer wusste, dass diese Materialien oder Anweisungen unangemessen waren und dies nicht mitgeteilt hat.

Da dieser Prozess als Auftragsarbeit durchgeführt wird, legt dieser Artikel die Gewährleistungspflicht für Mängel in den Liefergegenständen fest. Es ist schwierig, in der Praxis zu entscheiden, ob es sich um eine Nichterfüllung der Verpflichtungen handelt (die Arbeit ist nicht abgeschlossen) oder um eine Gewährleistungspflicht für Mängel nach der Erfüllung (die Arbeit ist abgeschlossen). Es gibt ein Urteil des Bezirksgerichts Tokio vom 22. April 2002 (Heisei 14), das besagt, dass bei der Systementwicklung entschieden werden sollte, ob das System als abgeschlossen betrachtet werden kann oder nicht, basierend darauf, ob die Arbeit bis zum letzten geplanten Prozess im ursprünglichen Vertrag abgeschlossen ist. Wenn nach der Lieferung und Abnahme der Software ein Mangel entdeckt wird, wird in der Regel die Gewährleistungspflicht für Mängel angewendet.

Absatz 1 definiert “Nichtübereinstimmung mit den Systemspezifikationen” als Mangel in der Softwareentwicklung. Für Mängel wie Funktionsmängel, die in der Phase der externen Planung auftreten, wird die Verantwortung durch Bestimmungen wie die Gewährleistungspflicht für Mängel in der Phase der externen Planung festgelegt, nicht durch diesen Artikel. Die Gewährleistungsfrist sollte unter Berücksichtigung der Größe des Informationssystems, der Vergütung usw. auf einen angemessenen Zeitraum festgelegt werden, der durch Absprache zwischen den Parteien festgelegt wird.

Absatz 2 enthält eine Bestimmung, die der Ausnahmebestimmung des Artikels 634 Absatz 1 des Bürgerlichen Gesetzbuchs entspricht, für den Fall, dass der Mangel geringfügig ist und die Korrektur der Liefergegenstände übermäßige Kosten verursacht.

Absatz 3 enthält eine Bestimmung, die der Ausnahmebestimmung des Artikels 636 des Bürgerlichen Gesetzbuchs entspricht, dass der Anbieter keine Gewährleistungspflicht hat, wenn der Mangel auf Anweisungen oder Materialien des Benutzers zurückzuführen ist, es sei denn, der Anbieter wusste, dass diese Materialien oder Anweisungen unangemessen waren und hat dies nicht mitgeteilt.

Unter welchen Umständen ein Mangel anerkannt wird und was die spezifischen Verantwortlichkeiten im Falle einer Anerkennung sind, wird im folgenden Artikel ausführlich erläutert.

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

Unterstützung bei der Vorbereitung und Umstellung von Software

In der Phase der Systemannahme und -einführung ist es üblich, dass der Benutzer die Hauptrolle übernimmt. Daher legt das japanische Ministerium für Wirtschaft, Handel und Industrie (METI) in seinem Modellvertrag fest, dass der Benutzer die Hauptrolle spielt und der Anbieter ihn in Form einer quasi-Bevollmächtigung unterstützt.

Bestimmung der Art des Vertrags

Um die Art des Vertrags zu bestimmen, betrachten wir den gesamten Vertrag und prüfen, ob sein Zweck darin besteht, ein “fertiges Produkt zu liefern”, oder ob es dem Anbieter darum geht, “vernünftig zu arbeiten”. Ein grober Anhaltspunkt ist, ob der Inhalt des zu erfüllenden Ziels in gewissem Maße konkret festgelegt wurde und ob das Projekt in diese Richtung voranschreitet. Welche spezifischen Aspekte wir betrachten, erklären wir ausführlich im folgenden Artikel.