Was sind die Kooperationspflichten der Nutzerseite als Auftraggeber der Systementwicklung?

Die Arbeit in der Systementwicklung erfordert, insbesondere bei groß angelegten Systemen, den Einsatz einer Vielzahl von Arbeitskräften und Arbeitsstunden. Daher besteht nicht nur auf Seiten des Anbieters, der die Entwicklung übernimmt, sondern auch auf Seiten des Nutzers, der die Systementwicklung in Auftrag gibt, eine gewisse Pflicht zur Zusammenarbeit.

Dies unterscheidet sich von der üblichen Auftragsbeziehung. Wenn Sie beispielsweise einen maßgeschneiderten Anzug von einem Schneider anfertigen lassen, anstatt ein IT-System zu verwenden, hat der Kunde (Nutzer), der den Auftrag erteilt, keine besonderen “Pflichten”. Die “Pflicht” liegt hauptsächlich beim Auftragnehmer, dem Schneider (Anbieter). Gerade weil ein IT-System viele Arbeitskräfte und Arbeitsstunden erfordert, müssen auch die Nutzer mit dem Anbieter “zusammenarbeiten”. Das ist die Struktur.

In diesem Artikel erklären wir, welche rechtlichen Pflichten für den Auftraggeber bei der Systementwicklung bestehen, die nicht allein dem Anbieter überlassen werden kann.

Es reicht nicht aus, alles “auszulagern”, wenn es um Ihr eigenes System geht

Auch bei einem einzigen Systementwicklungsprojekt sind oft viele Personen und Organisationen beteiligt. Nicht nur Ingenieure und Programmierer, die sich mit Codierungstechniken auskennen, sind wichtig, sondern auch die Rolle des Projektmanagers, der die Ergebnisse dieser Mitarbeiter zu einem einzigen Erfolg zusammenfasst, ist von großer Bedeutung.

Aber selbst wenn der Anbieter über hohe technische und organisatorische Fähigkeiten verfügt, kann die Systementwicklung nicht allein durch die Kraft des Anbieters erreicht werden. Zum Beispiel gibt es keine Möglichkeit, firmeninterne Begriffe, die nur innerhalb des Unternehmens verwendet werden, oder spezifisches Geschäftswissen des Unternehmens zu kennen, nur durch die einseitigen Bemühungen des Anbieters. Je größer die Entwicklung eines Systems ist, desto häufiger ist das Unternehmen, das das System nutzt, ein großes Unternehmen mit vielen Mitarbeitern und Aufgaben. Um ein Systementwicklungsprojekt zum Erfolg zu führen, ist es oft der Fall, dass die Organisation der Geschäftslogik vor der Computerarbeit einen großen Anteil einnimmt.

Daher sollten die Benutzer nicht passiv sein, weil sie “keine IT-Experten sind”, sondern sollten vielmehr aktiv Informationen bereitstellen, um den Projektfortschritt zu erleichtern. In diesem Sinne ist die Rolle, die die Benutzerseite in einem Systementwicklungsprojekt spielt, tatsächlich nicht klein.

Was sind die Pflichten zur Zusammenarbeit auf Seiten des Nutzers auf der Grundlage von Präzedenzfällen?

Was sind konkret die Pflichten zur Zusammenarbeit, die auf Seiten des Nutzers in einem Systementwicklungsprojekt bestehen? Zu diesem Punkt gibt es viele Hinweise in früheren Gerichtsentscheidungen.

In einem Gerichtsverfahren wurde über die Frage gestritten, ob es eine Pflicht zur Zusammenarbeit des Nutzers (Kläger) bei der Entwicklung gibt, da es Verzögerungen bei der Entscheidungsfindung des Nutzers gab, die zu einer Verzögerung der Lieferfrist auf Seiten des Anbieters (Beklagter) führte. In diesem Fall erkannte das Gericht einen Verstoß gegen die Pflicht zur Zusammenarbeit auf Seiten des Nutzers an und lehnte die Haftung des Anbieters für Nichterfüllung ab. (Obwohl die Auflösung des Vertrags anerkannt wurde, wurde auch eine Minderung der Schuld um 60% anerkannt.)

Der Vertrag über die Entwicklung dieses Computersystems ist ein sogenannter maßgeschneiderter Systementwicklungsvertrag. Bei einem solchen maßgeschneiderten Systementwicklungsvertrag kann der Auftragnehmer (Anbieter) das System nicht alleine fertigstellen. Der Auftraggeber (Nutzer) muss während des Entwicklungsprozesses interne Meinungsabstimmungen durchführen, seine Ansichten vereinheitlichen, klar kommunizieren, welche Funktionen er vom Auftragnehmer erwartet, zusammen mit dem Auftragnehmer die gewünschten Funktionen prüfen, schließlich die Funktionen festlegen, weiterhin die Bildschirme und Formulare festlegen und die Abnahme der Ergebnisse durchführen usw. Diese Rollen müssen aufgeteilt werden.

Urteil des Bezirksgerichts Tokio vom 10. März 2004 (Heisei 16)

Dieses Urteil ist nicht nur eine Aussage darüber, dass die Systementwicklung selbst eine gemeinsame Arbeit mit dem Nutzer ist, sondern es gibt auch sehr anregende Hinweise darauf, “in welchen Punkten konkret zusammengearbeitet werden sollte”.

Lassen Sie uns versuchen, den Wortlaut des oben genannten Urteils in IT-Begriffe der Systementwicklung zu übersetzen.

Diese Punkte können auf diese Weise organisiert werden. All diese Punkte können, unabhängig davon, wie hoch die Fachkompetenz für IT-Systeme ist, nicht alleine ohne die Zusammenarbeit des Nutzers erreicht werden. Die gewünschten Funktionen und das Layout des Bildschirms sind grundsätzlich vom Nutzer zu klären, und ob das gewünschte Produkt realisiert wurde oder nicht, kann auch nur vom Nutzer überprüft werden.

Es ist zu beachten, dass, genau wie dem Anbieter eine Projektmanagementpflicht auferlegt wird, auch dem Nutzer eine Pflicht zur Zusammenarbeit auferlegt wird. Wenn der Nutzer in den oben genannten Prozessen gegen seine Pflicht zur Zusammenarbeit verstößt, besteht die Möglichkeit, dass er im Gegenzug vom Anbieter auf Schadensersatz wegen Nichterfüllung oder unerlaubter Handlung in Anspruch genommen wird.

Wie werden Anfragen zur Änderung der Spezifikationen nachträglich interpretiert?

Wenn man davon ausgeht, dass ein Systementwicklungsprojekt eine gemeinsame Arbeit von Benutzer und Anbieter ist, führt dies zu einer weiteren fortgeschrittenen Diskussion. Es geht um das Problem, wer verantwortlich ist, wenn der Benutzer nachträglich zusätzliche Funktionen oder Korrekturen anfordert und dadurch die Einhaltung des Liefertermins schwierig wird.

Systementwicklung zielt im Allgemeinen darauf ab, in einer Reihenfolge, die mit der Anforderungsdefinition beginnt und dann durch grundlegende Design, detailliertes Design, Herstellung (Programmimplementierung) und Tests fortgesetzt wird, so weit wie möglich zu vermeiden, dass Arbeit zurückgegeben wird (allgemein als Wasserfallmodell bezeichnet). In der Realität kommt es jedoch oft vor, dass Arbeit zurückgegeben wird, wenn sich herausstellt, dass es Mängel in den vorherigen Prozessen gibt.

Wie sollte man in solchen Fällen denken, wenn man den Liefertermin nicht einhalten kann? Bei der Interpretation früherer Urteile scheint es Unterschiede in den Schlussfolgerungen zu geben, je nachdem, wann zusätzliche Arbeiten aufgetreten sind.

Wenn zusätzliche Arbeiten vor der Klärung der Spezifikationen wie dem externen Design aufgetreten sind

Das oben genannte Urteil zeigt gleichzeitig, dass es nicht unbedingt einen Verstoß gegen die Pflicht zur Zusammenarbeit darstellt, wenn der Benutzer während des grundlegenden Designprozesses (vor der Programmimplementierungsphase) eine Anfrage zur zusätzlichen Entwicklung stellt.

Es ist selbstverständlich, dass der Benutzer während der grundlegenden Designarbeit verschiedene Anforderungen an das zu erstellende System stellt. Darüber hinaus ist es für den Benutzer, der keine Fachkenntnisse hat, schwierig zu beurteilen, ob diese Anforderungen zusätzliche Gebühren oder eine Verlängerung der Lieferfrist erfordern, oder ob sie den Arbeitsprozess beeinträchtigen. Daher kann man nicht sagen, dass der Benutzer sich selbst zurückhalten sollte, Anforderungen zu stellen, die zusätzliche Gebühren oder eine Verlängerung der Lieferfrist erfordern. Vielmehr, wenn der Benutzer solche Anforderungen stellt, sollte der Beklagte, der die Projektmanagementpflicht hat, den Benutzer darüber informieren und um Diskussionen über den Rückzug der Anforderungen oder die Verlängerung der Lieferfrist bitten, um sicherzustellen, dass die Entwicklungsarbeit nicht beeinträchtigt wird.

Urteil des Bezirksgerichts Tokio vom 10. März 2004 (Heisei 16)

In diesem Urteil wurde festgestellt, dass der Benutzer eine gewisse Pflicht zur Zusammenarbeit hat, aber es wurde auch darauf hingewiesen, dass der Benutzer nicht unbedingt ein Experte für Systementwicklung ist. Mit anderen Worten, da der Benutzer, der die Bestellung aufgibt, kein Experte für Systementwicklung ist, ist es nicht ungewöhnlich, dass er während der Zeit, bis der Inhalt des zu entwickelnden Systems klar wird, nach und nach verschiedene Anforderungen stellt (in einigen Fällen ist er nicht einmal an das Aufgeben von Bestellungen gewöhnt), und es ist zu hart zu sagen, dass er “sich selbst bemerken sollte”, wenn der Inhalt seiner Bestellung eine Überprüfung der Lieferfrist usw. erfordert.

Die Pflicht, die dem Anbieter hier auferlegt wird, bezieht sich jedoch im Wesentlichen auf die Bemühungen um Kommunikation, wie das Anfordern einer Verlängerung der Lieferfrist oder (wenn die Lieferfrist nicht verschoben werden kann) das Vorschlagen, dass die zusätzliche Anforderung zurückgezogen wird. Daher sollte man beachten, dass dies nicht bedeutet, dass es die Pflicht einschließt, alle Anforderungen des Benutzers zu akzeptieren und das Produkt bis zum ursprünglichen Termin zu liefern.

Wenn zusätzliche Arbeiten nach der Festlegung der Spezifikationen in der Herstellungs- oder Testphase aufgetreten sind

Wenn man den Inhalt des oben genannten Urteils umkehrt, kann man bis zu einem gewissen Grad vorhersagen, welche Schlussfolgerung gezogen worden wäre, wenn es sich um eine zusätzliche Entwicklung handelt, nachdem die Spezifikationen bereits festgelegt worden waren. In diesem Fall wäre es schwieriger, solche Anforderungen zu erfüllen. Es ist wahr, dass es keinen Unterschied macht, ob die Spezifikationen vor oder nach der Festlegung festgelegt wurden, wenn es um das Verständnis der Entwicklungsarbeit zwischen dem Benutzer und dem Anbieter geht.

Aber wenn man den Inhalt der Bestellung ändert oder hinzufügt, nachdem die Spezifikationen festgelegt wurden, besteht eine hohe Wahrscheinlichkeit, dass die Arbeit neu gemacht werden muss. In solchen Fällen ist es oft schwierig, die Verzögerung der Lieferung, die sogar in solchen Fällen aufgetreten ist, zu verteidigen, indem man sagt, “Es ist natürlich, dass der Kunde verschiedene Anforderungen stellt”. Darüber hinaus wirft die Tatsache, dass viele Spezifikationsänderungen und Funktionserweiterungen nachträglich auftreten, die Frage auf, ob es nicht bereits einen Verstoß gegen die Pflicht zur Zusammenarbeit auf Seiten des Benutzers in den vorherigen Prozessen wie dem grundlegenden Design gab, das bereits abgeschlossen sein sollte.

Aus diesen Gründen ist es unwahrscheinlich, dass die Verzögerung der Lieferung, die durch eine Spezifikationsänderung verursacht wurde, die nach der endgültigen Festlegung der Spezifikationen durchgeführt wurde, als Verantwortung des Anbieters angesehen wird. Es ist angemessen, aus dem oben genannten Urteil zu lesen, dass es auch in dieser Hinsicht eine Bedeutung hat.

Darüber hinaus neigt diese Beurteilung dazu, nicht nur auf der Grundlage des Vertrags, sondern auch auf der Grundlage von Protokollen, die dem Fortschritt der Systementwicklung entsprechen, als Beweis durchgeführt zu werden. Details zu Protokollen werden im folgenden Artikel erklärt.

Verwandter Artikel: Wie man Protokolle in der Systementwicklung aus rechtlicher Sicht führt[ja]

Zusammenfassung: Es ist wichtig, nicht zu vergessen, dass die Anforderungsdefinition ein Prozess auf der Benutzerseite ist

Obwohl die Anforderungsdefinition eine Gelegenheit für den Anbieter ist, seine Fähigkeiten zu demonstrieren, sollte man sich bewusst sein, dass es ursprünglich eine Aufgabe auf der Benutzerseite ist. Da es sich um ein System handelt, das in Ihrem eigenen Unternehmen verwendet wird, sollte es auch dann, wenn es mit Hilfe externer Experten erstellt wird, als ein Bereich angesehen werden, der unter der eigenen Unternehmensführung steht und rechtlich gesehen sollte.

Wenn die Benutzerseite nicht kooperativ im Entwicklungsprozess ist, besteht eine große Möglichkeit, dass das Gericht auch eine strenge Meinung gegenüber der Benutzerseite äußert, selbst wenn das Projekt scheitert. Dies sollte zunächst anerkannt werden.