システム開発の遅延に伴う責任はどのように決まるのか？IT業界に精通した弁護士が解説

【ご相談内容】

当社は取引先よりシステム開発を受託し、制作を進めています。ただ、取引先の要望が大きく変化し、これに応じた作業工程の見直しが発生したことから、当初想定していた稼働目標日までに完成させることができないという事態に陥りました。

これに対し、取引先が当社に対して、「履行遅滞による責任を取れ！」と言ってきているのですが、当社は責任を負うことになるのでしょうか。

 

 

【回答】

取引経過の詳細について確認する必要がありますが、取引先の要望内容の変更が想定外であった場合、ベンダは履行遅滞責任を負わない可能性が高いと考えられます。

ただ、なぜ責任を負わないのか法的な理論構成を行うとなると、思った以上に難しい問題があります。

以下では、納期（履行期）遅延の意義に触れた上で、システム開発取引等でよく見かける納期（履行期）遅延紛争を2例取り上げ、どういった視点で検討すればよいのかにつき解説を行います。

 

【解説】

 

1.納期（履行期）遅延とは何か

(1)納期（履行期）遅延により生ずる効果

システム開発契約書等では、制作や開発に基づく成果物の完成又は引渡し時期のことを「納期」と呼ぶことが多いと思われますが、法律上は「履行期」という言い方になります。

さて、民法では、納期（履行期）に遅れた場合の処理につき、次のように規定しています。

 

【民法第412条】

1.　債務の履行について確定期限があるときは、債務者は、その期限の到来した時から遅滞の責任を負う。 2.　債務の履行について不確定期限があるときは、債務者は、その期限の到来した後に履行の請求を受けた時又はその期限の到来したことを知った時のいずれか早い時から遅滞の責任を負う。 3.　債務の履行について期限を定めなかったときは、債務者は、履行の請求を受けた時から遅滞の責任を負う。

 

要は、納期（履行期）に遅延したことは契約違反である以上、債務不履行責任を負うということが民法第412条では定められています。なお、システム開発契約の場合、一般的には何らかの確定期限を設定しますので、不確定期限（第2項）や期限の定めなし（第3項）を適用することは少ないと思われます。

 

では、債務不履行責任の具体的な内容は何かとなるのですが、主なものは、①契約の解除が可能となること、②損害賠償請求が可能となることです。

もっとも、契約を解除する場合は、民法第541条と民法第542条に定める法定解除事由に該当するかが問われます（システム開発契約書等で別途解除事由を定めているのであれば、その契約書等に定められている解除事由に該当するかも検討することになります）。

 

【民法第541条及び民法第542条】

第541条（催告による解除） 当事者の一方がその債務を履行しない場合において、相手方が相当の期間を定めてその履行の催告をし、その期間内に履行がないときは、相手方は、契約の解除をすることができる。ただし、その期間を経過した時における債務の不履行がその契約及び取引上の社会通念に照らして軽微であるときは、この限りでない。   第542条（催告によらない解除） 1.　次に掲げる場合には、債権者は、前条の催告をすることなく、直ちに契約の解除をすることができる。 ①債務の全部の履行が不能であるとき。 ②債務者がその債務の全部の履行を拒絶する意思を明確に表示したとき。 ③債務の一部の履行が不能である場合又は債務者がその債務の一部の履行を拒絶する意思を明確に表示した場合において、残存する部分のみでは契約をした目的を達することができないとき。 ④契約の性質又は当事者の意思表示により、特定の日時又は一定の期間内に履行をしなければ契約をした目的を達することができない場合において、債務者が履行をしないでその時期を経過したとき。 ⑤前各号に掲げる場合のほか、債務者がその債務の履行をせず、債権者が前条の催告をしても契約をした目的を達するのに足りる履行がされる見込みがないことが明らかであるとき。 2.　次に掲げる場合には、債権者は、前条の催告をすることなく、直ちに契約の一部の解除をすることができる。 ①債務の一部の履行が不能であるとき。 ②債務者がその債務の一部の履行を拒絶する意思を明確に表示したとき。

 

また、損害賠償請求を行う場合は、相手方の帰責性が問われることになります（ちなみに、契約解除の場合は相手方の帰責性は不要です）。

 

【民法第415条第1項】

債務者がその債務の本旨に従った履行をしないとき又は債務の履行が不能であるときは、債権者は、これによって生じた損害の賠償を請求することができる。ただし、その債務の不履行が契約その他の債務の発生原因及び取引上の社会通念に照らして債務者の責めに帰することができない事由によるものであるときは、この限りでない。

 

つまり、納期（履行期）に遅延した場合、契約違反（債務不履行）とはなりますが、これに起因して何らかの権利主張（解除、損害賠償など）を行う場合、権利主張を行うための要件を充足するのか別途検討する必要があるということがポイントとなります。

そして、この要件の補充や明確化を図るために、システム開発契約書等が締結されることになります。

 

 

(2)納期（履行期）の決め方

上記(1)で「一般的には何らかの確定期限を設定」すると記載しましたが、例えば大型のプロジェクトとなると、実際に作業を進めてみないと納期（履行期）を決めることが困難といったことが起こり得ます。また、何らかの理由でシステム開発契約書等に納期（履行期）を明記せず、口約束程度に稼働予定時期を確認するといったこともあったりします。

この場合、法的な意味での納期（履行期）はいつと認定すればよいのか、実は難しい問題があります。

例えば、次の裁判例では、ベンダが提出した開発スケジュールの記載内容をもって納期（履行期）と認定することはできないとしています（原告がベンダ、被告がユーザの事例）。

 

【東京地方裁判所平成25年12月19日判決】

原告が同年４月１０日に提出した開発スケジュールには、論理設計の完了日が同月３０日、物理設計の完了日が同年５月３０日と記載されていたことが認められる。 しかし、開発スケジュールは、原告が契約内容を達成するための工程を記載したものにすぎず、その記載内容が直ちに法的な債務となるものではない。したがって、上記各日が履行期限であるとはいえないから、原告に履行遅滞があったとは認められない。

 

ベンダが提出した提案書や工程表だけでは、納期（履行期）を定めたと認定される保証はないことを押さえておく必要があります。また、ユーザが稼働希望日を提示しているだけでは、やはり納期（履行期）を定めたとは言い難いと考えられます。さらに実際の現場実務では、システム開発契約書等に納期（履行期）が明示されていたとしても、ユーザの追加要望への対応等により納期（履行期）を変更合意したとされることが多いことにも注意を要します。

 

以上の通り、納期（履行期）遅延と一方的に指摘することは可能であっても、そもそも納期（履行期）に関する合意があったと言えるのか、合意があったとして個別具体的な権利主張ができるのかは、突き詰めて考える必要があるということになります。

具体例として、次の2.と3.において、システム開発でよく発生する納期（履行期）遅延に関する紛争パターンと対処法ににつき解説します。

 

 

2.システム不稼働と遅延

タイトルに関する紛争ですが、例えば…

【ユーザの主張】納品されたシステムが満足のいくパフォーマンスを発揮していない（＝稼働していない）以上、未完成であり納期（履行期）遅延が生じている

【ベンダの主張】仕様通りに制作・開発を行い納品した以上、少なくとも納期（履行期）遅延ではない

といったものが挙げられます。

上記のような例の場合、納期（履行期）遅延か否かを判断するために、「完成」したと言えるのかが重要となります。なぜなら、完成しているのであれば、納期（履行期）遅延に該当しようがないからです。

 

(1)そもそも完成とは何か？

広辞苑第6版では「完全に仕上げること」と記載されています。この記載からすると、ユーザの主張の通りであれば、まだ完成していないのではと思われるかもしれません。

しかし、システム開発のような請負契約では、法的な意味での「完成」とは、予定工程が終了した場合を意味し、仕上がりの程度を問わないと解釈されています。

例えば、次のような裁判例が存在します（引用中にある条文は2020年4月改正前民法の条文となります）。

 

【東京地方裁判所平成14年4月22日判決】

民法632条及び633条は、請負人の注文者に対する報酬の支払時期について、請負人が仕事を完成させ、仕事の目的物を注文者に対して引き渡したときであると規定し、他方、同法634条は、仕事の目的物に瑕疵があるときは請負人は注文者に対し担保責任を負い（１項）、請負人が仕事の目的物の瑕疵についてその担保責任を果たすまでは注文者は報酬の支払につき同時履行の抗弁権を有すると規定している（2項）。これら民法の規定によれば、法は、仕事の結果が不完全な場合のうち仕事の目的物に瑕疵がある場合と仕事が完成していない場合とを区別し、仕事の目的物に瑕疵が存在しても、それが隠れたものであると顕れたものであるとを問わず、そのために仕事が完成していないものとはしない趣旨であると解される。 よって、請負人が仕事を完成させたか否かについては、仕事が当初の請負契約で予定していた最後の工程まで終えているか否かを基準として判断すべきであり、注文者は、請負人が仕事の最後の工程まで終え目的物を引き渡したときには、単に、仕事の目的物に瑕疵があるというだけの理由で請負代金の支払を拒むことはできないものと解するのが相当である。

 

つまり、法的な意味での「完成」とは、不具合やバグが存在しても、最終工程まで終了しているのであれば完成として取扱うということになります（不具合やバグへの対応は契約不適合責任で処理する）。

現場実務では、この点を勘違いする方が非常に多いので、特に注意して欲しい事項となります。

 

(2)どうやって完成したことを証明するのか？

上記(1)で解説した通り、最終工程が終了した場合は完成として扱われるのですが、何をもって最終工程というのかが次に問題となります。

この点、検収（ユーザによる受入検査のこと）が完了しているのであれば、最終工程が終了したと取り扱ってもほぼ問題ないと考えられます。なぜなら、検収工程は、ベンダが前工程を経て制作・開発した成果物をユーザに引渡し、ユーザの責務で行うべきものであって、ベンダが関与する工程ではないといえるからです。なお、このように考えた場合、いわゆるみなし検収規定（一定期間内にユーザが異議を申し出なかった場合は検収合格したものとみなすという趣旨の条項のこと）は、ベンダにとっては是非とも明記しておきたい条項となります。一方、ユーザにおいては、システム開発契約書にみなし検収規定が定められていないか注意を払うと共に、みなし検収規定がある場合、期限徒過しないよう管理を徹底することが重要となります。

ところで、ベンダから懇願され、ユーザとしては不本意ながらも検収書を提出したという事例が散見されます。この場合、ユーザとしては条件付きで検収したことを明示した上で、証拠として残さないことには、後で完成してないと主張することは難しいと認識しておくべきです。

 

次に、ユーザが成果物を実践利用していた場合も、最終工程が終了したと評価することが可能と考えられます。なぜなら、実践利用の段階にまで至っているのであれば、ベンダが対処するべき工程が存在しないからです（もちろん契約不適合責任が追及されている場合は、補修工程が発生しますが、本来の制作・開発工程とは外れるものとなります）。

ところで、システム開発契約書等で、ユーザが実践利用を開始した場合は検収に合格したものとみなすといった規定が定められていることがあります。ただ、検収のために成果物を利用しているのか、実践目的で成果物を利用しているのか判別がつかないことがあります。この点で解釈の相違を生じてトラブルになることがありますので、ベンダ・ユーザを問わず、みなし検収に該当する事由の明確化を意識したいところです。

 

さらに、多段階契約の場合が当てはまるのですが、各段階において個別契約が締結され、ユーザが次の段階への移行を承認した場合、少なくとも前段階にかかる工程は全て終了したと考えることが可能です。もっとも、段階を移行させたにもかかわらず、前段階の業務に戻って対応しているといった五月雨式の業務遂行となっている場合、果たして前段階の工程が終了したと言えるのか疑義が生じることになります。

 

ちなみに、契約書で完成（最終工程）の定義を明記し、一義的に完成の有無を判断できるようにするという方法も考えられるところです。

ただ、例えば、完成の時期（最終工程）を検収合格後と定めたところ、ユーザが検収に協力しない（ベンダとしてはやるべきことは尽くしたので如何ともしがたい）場合、果たして契約書に従って未完成扱い（最終工程を終了していない）としてよいのかについては議論の余地があります。この問題への対応につき、「最終工程が終了していなくても仕事の完成を認めるべき特段の事情あり」として解決を図る裁判例が存在します。また、解釈論としては、受領遅滞やユーザの協力義務違反として処理することも考えられます。

 

 

3.制作途中での打切りと遅延

このタイトルに関する紛争ですが、例えば…

【ユーザの主張】納期（履行期）を猶予してきたが、成果物が完成する見込みが立たない以上、納期（履行期）の遅延として取り扱うほかない

【ベンダの主張】当初の納期（履行期）より遅れているのは事実だが、遅延した原因はユーザにある以上、履行遅滞の責任は負わない

といったものが挙げられます。

上記のような例の場合、納期（履行期）遅延か否かを判断するために、「遅延原因」、すなわちシステム開発が頓挫したことにつきユーザとベンダのどちらに帰責性があるのかが重要となります。なぜなら、民法第543条では「債務の不履行が債権者の責めに帰すべき事由によるものであるときは、債権者は…契約の解除をすることができない。」として解除権行使が不可と定め、民法第415条第1項では「その債務の不履行が契約その他の債務の発生原因及び取引上の社会通念に照らして債務者の責めに帰することができない事由によるものであるときは」損害賠償請求ができないと定めているからです。

 

(1)システム開発頓挫の原因

遅延した責任はユーザとベンダのどちらにあるのかを検討する上で、避けて通れないのがユーザの協力義務とベンダのプロジェクトマネジメント義務です。

この義務について、例えば次のような裁判例があります（なお、原告はユーザ、被告はベンダです）。

 

【東京地方裁判所平成16年3月10日判決】

＜協力義務＞ 本件電算システム開発契約は、いわゆるオーダーメイドのシステム開発契約であるところ、このようなオーダーメイドのシステム開発契約では、受託者（ベンダ）のみではシステムを完成させることはできないのであって、委託者（ユーザ）が開発過程において、内部の意見調整を的確に行って見解を統一した上、どのような機能を要望するのかを明確に受託者に伝え、受託者とともに、要望する機能について検討して、最終的に機能を決定し、さらに、画面や帳票を決定し、成果物の検収をするなどの役割を分担することが必要である。このような役割を委託者である原告が分担していたことにかんがみれば、本件電算システムの開発は、原告と受託者である被告の共同作業というべき側面を有する。 （省略） したがって、原告は、本件電算システムの開発過程において、資料等の提供その他本件電算システム開発のために必要な協力を被告から求められた場合、これに応じて必要な協力を行うべき契約上の義務（以下「協力義務」という。）を負っていたというべきである。   ＜プロジェクトマネジメント義務＞ 被告は、納入期限までに本件電算システムを完成させるように、本件電算システム開発契約の契約書及び本件電算システム提案書において提示した開発手順や開発手法、作業工程等に従って開発作業を進めるとともに、常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切に対処すべき義務を負うものと解すべきである。 そして、システム開発は注文者と打合せを重ねて、その意向を踏まえながら行うものであるから、被告は、注文者である原告…のシステム開発へのかかわりについても、適切に管理し、システム開発について専門的知識を有しない原告によって開発作業を阻害する行為がされることのないよう原告に働きかける義務（以下、これらの義務を「プロジェクトマネジメント義務」という。）を負っていたというべきである。

 

なお、両義務はシステム開発契約という性質から当然に導かれる義務であり、システム開発契約書等に記載されていないから発生しないというものではありません。

ただ、抽象的に義務違反を指摘したところでは紛争解決とはなりません。どのような事実があったから義務違反と言えるのか個別事情に応じて検討することが重要です。

 

(2)納期変更の合意

制作途中での打切りに関する紛争では、上記(1)で解説した通り、誰のせいで遅延が発生したのかその帰責性が問われることが多いのですが、紛争になる前は両当事者とも、多少は時間がかかってもシステムを完成させるという共通目的に向かって行動していることが通常です。

このため、そもそも納期日変更の合意がある以上、納期（履行期）遅延は発生していなという形でも争いが生じることがあります。

この点、ケースバイケースであるとはいえ、明示的な納期（履行期）変更の合意がないとしても、黙示的には認められるとする裁判例が散見されます。例えば次のようなものです（原告はベンダ、被告はユーザの事例です）。

 

【東京地方裁判所平成29年5月15日判決】

上記の経緯からすれば、原告と被告との間では、本件変換器契約締結当時、本件変換器の納期は平成25年9月24日と定められていたものの、その後、本件基本契約書7条2項に基づき、本件変換器の製造状況に応じて、原告が納期の延期を申し入れ、被告がそれに応じ、希望する納期を伝えていたものといえる。 また、被告は、平成26年3月21日、原告に対し、本件変換器を納品できない状態での調整に移行すると表明してはいるものの、その後も、原告と被告の認識をまとめた表について、原告側の確認、承認をした旨記載されたものの提出を求め、本件打合せに応じていることからすれば、仮に同月28日に本件変換器の仕様を満たした物が納入されれば、受領するつもりはあったといえる。そのため、原被告間において、黙示的に、同日を納期とする合意があったものと認められる。

 

このような黙示的な合意が認められる背景として、システム開発の場合、契約締結後に要件が膨れ上がる等の理由で、しばしば納期（履行期）変更が行われているといった実情を考慮しているからと考えられます。

とはいえ、できる限り明示的な納期（履行期）変更の合意を証する書類等を入手しておいた方が良いことは言うまでもありません。

 

4.弁護士に依頼するメリット

システム開発が遅延したことによる紛争において、弁護士に依頼するメリットは以下の5つです。

①法的専門知識の活用

システム開発における契約や法的義務は複雑です。弁護士は契約書や関連法規を理解し、契約違反や過失がどこにあるかを正確に判断し、最適な解決策を提供します。

②紛争の戦略的解決

弁護士はクライアントの利益を最大限に守るため、交渉や調停、裁判を含む最適な紛争解決の方法を提案し、実行します。これにより、無駄なコストや時間をかけずに効率的な解決が期待できます。

③証拠収集と分析

契約書やメールのやり取り、進捗報告書などの証拠を整理し、システム開発の遅延がどの段階で、どのような理由で発生したかを明確にすることが重要です。弁護士はこれらの証拠を的確に分析し、法的な視点で主張を裏付ける資料を準備します。

④交渉力の強化

弁護士がいることで、相手方との交渉で優位に立つことができます。専門家のサポートを得ることで、相手方も真剣に対応する可能性が高まり、有利な条件での解決を目指せます。

⑤リスク管理と予防

弁護士は今後のシステム開発や契約において、同様の遅延や紛争を回避するためのリスク管理策をアドバイスします。再発防止策や契約内容の見直しなど、将来的なトラブルを防ぐ手段も提供します。

 

システム開発の遅延に伴う法的問題は複雑で、専門的な知識が必要です。弁護士のサポートを得ることで、紛争解決のスムーズな進行や、今後のリスク軽減が期待できます。

 

 

5.当事務所でサポートできること

当事務所の代表弁護士は情報処理技術者資格を保有すると共に、システム開発取引特有の慣行や実情に関する深い知識と経験を持っています。

そして、次のような強みとサポートを行っています。

 

①システム開発会社の顧問弁護士として多数の実績があること

当事務所の代表弁護士は、2001年の弁護士登録以来、複数のシステム開発会社の顧問弁護士として活動し、紛争予防から訴訟対応まで幅広く関与し、解決を図ってきました。

これらの現場で培われた知見とノウハウを活用しながら、ご相談者様への対応を心がけています。

 

②時々刻々変化する現場での対応を意識していること

弁護士に対する不満として、「言っていることは分かるが、現場でどのように実践すればよいのか分からない」というものがあります。

この不満に対する解消法は色々なものが考えられますが、当事務所では、例えば、法務担当者ではなく、現場の交渉担当者や開発担当者等との直接の質疑応答を可としています。

現場担当者との接触を密にすることで、実情に応じた対処法の提示を常に意識しています。

 

③原因分析と今後の防止策の提案を行っていること

弁護士が関与する前にトラブル対応を開始したところ、法的判断の誤りにより、ご相談者様が思い描いていたような結論を得られず、以後の対応に苦慮している場合があるかもしれません。

こういった場合に必要なのは、方針・対処法の軌道修正をすることはもちろんのこと、なぜ思い描いた結論に至らなかったのか原因検証し、今後同じ問題が発生しないよう対策を講じることです。

当事務所では、ご相談者様とのやり取りを通じて気が付いた問題点の抽出を行い、改善の必要性につきご提案を行っています。そして、ご相談者様よりご依頼があった場合、オプションサービスとして、社内研修やマニュアルの整備、契約書の常時チェックなども行っています。

事業の適正化とトラブル防止のための継続的なコンサルティングサービスもご対応可能です。

 

 

＜2024年10月執筆＞

※上記記載事項は弁護士湯原伸一の個人的見解をまとめたものです。今後の社会事情の変動や裁判所の判断などにより適宜見解を変更する場合がありますのでご注意下さい。