所定の納期に遅延したことについて変更合意があったか否か、現行踏襲が実現されていないことが不完全履行にあたるか等が問題となった事例。
事案の概要
Ｘ（ベンダ）とＹ（ユーザ）はＹの取引先であるＺとの連携を含めたシステム（本件システム）の開発を目的として、要件定義書作成支援業務委託契約を締結し、履行後に代金が支払われた。その後、ＸＹは、平成29年6月26日にソフトウェア開発業務委託契約（本件開発契約）を締結したが（契約上の納期は、平成29年10月31日）、Ｙは納期までに完成しないとして平成30年3月13日に解除通知を行った（本件解除）。
Ｘは、正当な理由なき開発中止の通告によって、Ｘの開発債務が履行不能になったとして、民法536条2項に基づいて請負代金等として、合計約3000万円の支払いを求めたのに対し（本訴）、Ｙは、契約解除による支払済代金相当額の返還等を求めた（反訴）。
ここで取り上げる争点
（１）履行期の変更の合意の有無（履行遅滞解除の可否）
Ｘは、もともと本件開発契約上の納入期限は、平成29年10月31日とされていたが、締結後にＹがＸに対し、各種の変更要望を提案したことから、追加契約の必要が生じ、平成30年2月末日へと変更するという合意が成立したから、履行遅滞の状態とはなっていないと主張していた。
（２）商品マスタの作成責任はユーザにあるか
Ｘは、商品マスタの準備は、Ｙの責任において行うべきであるところ、これを怠ったことが遅延の原因であって、仮にＸに履行遅滞があるとしても、Ｘに帰責事由はないとしていた。
（３）本件システムは本件開発契約の目的に適合するか（不完全履行を理由とする解除の可否）
Ｙは、本件システムには多数の問題点ないし欠陥があり、完成の見込みがないものであるから不完全履行を理由に解除ができると主張していた。
裁判所の判断
争点（１）履行期の変更の合意の有無（履行遅滞解除の可否）について
裁判所は次のように述べて、本件解除の時点（平成30年3月13日）では、履行遅滞にはなっていなかったとした。
本件開発契約の契約書（甲１）には納期が平成２９年１０月３１日と記載されているものの、同日が経過した後もＸ及びＹは、本件システムの開発作業を継続していること、前記１認定のとおり、Ｙが同年１２月２０日付け及び平成３０年１月２６日付けで本件各契約に係る契約書を作成しているところ、本件システムの開発に係る本件追加契約②及び本件追加契約③の契約書に記載された納入期限は同年３月３１日であること（甲５から８まで）、同年２月６日に開催されたＸ、Ｙ及びＺの協議のメモには、諸々の準備の進行状況から本件システムへの切替えを同年４月１日とすることを検討する旨記載されていること（甲４６の２）、このような納期の遅れについて、Ｙ代表者がＣ取締役その他の担当者を叱責したり、本件開発契約の解除を指示したりしたことはうかがわれず、かえって、Ｙ代理人がＸ代理人に対し平成３０年６月２９日付けで送付した通知書と題する書面には、本件システムの不具合についての記載はある一方、納期の遅れに関する記載は存在しないこと（乙１）が認められる。
そうすると、上記の議事録記載のとおり、ＸとＹ（Ｃ取締役）との間で、平成２９年８月１日に本件開発契約の納期を平成３０年２月末日に変更する旨の合意をし、さらに、その後もＸとＹが黙示のうちに上記の納期を変更する旨合意していたものと認められ、Ｙが本件解除をしたと主張する同年３月１３日の時点では、まだ本件開発契約は履行遅滞にはなっていなかったと認めるのが相当である。
争点（２）商品マスタの作成責任はユーザにあるかについて
裁判所は、①見積書の記載、②Ｘ担当者による説明、③Ｘ担当者による依頼メールなどから、Ｙがやるべき作業であると認定した。
このように、本件開発契約の見積りの段階において、商品マスタをＹにおいて作成することを前提に見積額が算出されている上、本件開発契約の締結後の打合せにおいて、Ｘ側からＹ担当者に対し、商品マスタの作成方法等を説明の上、提出期限を定めてその作成を依頼したものの、平成３０年２月上旬頃まで、Ｙにおいてその作成ができなかったことに照らすと、商品マスタの提出遅延に伴う本件システムの開発の遅延につき、Ｘの責めに帰すべき事由はなかったと認めるのが相当である
争点（３）本件システムは本件開発契約の目的に適合するか（不完全履行を理由とする解除の可否）
裁判所は、Ｙが挙げる13カ所の項目について、目的適合性を欠くことにはならないとした。特に、Ｙは、現行システムが有する機能を有しないことを目的適合性を欠くと述べているが、その点について、裁判所は次のように述べた。
現行のシステムと本件システムとの間に機能や使用方法について相違があるとしても、現行のシステムの機能や使用方法が本件開発契約上の仕様になっているとは限らず、要件定義書の作成、本件開発契約の締結に続く設計の段階で、Ｙから要望し、それが仕様に落とし込まれない限り、本件開発契約の内容・目的になっていると認めることは困難である。
この点につき、Ｙは、現行のシステムを所与の前提として、本件システムを開発すべきである旨主張するが、Ｘは、現行のシステムの機能を知り得る立場にはない以上、Ｙにおいて、求める機能を説明し発注しなければ、本件開発契約において要求される機能となり得ないことは明らかであって、Ｙの上記主張は採用の余地はない。
総論として以上のように述べた上で、13カ所の項目について、いずれも要件定義から仕様確定の事実関係等から目的適合性を否定した。
以上を踏まえ、裁判所は、Ｙの責に帰すべき事由によって、Ｘによる開発は履行不能になったとし、Ｙは、民法536条2項に基づいて、反対給付の履行義務があるとした（一部を除き、請求の全額について認容した）。
若干のコメント
本件は「契約上の納期を変更する合意はあったか」「遅延の責任の所在はユーザ／ベンダのどちらにあるか」「不具合は不完全履行か／仕様か」といったシステム開発紛争によくある争点がたくさん含まれている事案です。
最初の、納期変更の合意の有無については、明確な合意はなかったものの、追加契約の納期が変更されていたことや、当初は履行遅滞を追及していなかったこと等により、納期は変更されていたと認定しました。同種のケースでは、東京地判令3.3.17（変更合意あり）、東京地判平29.1.20（変更合意あり）、東京地判平22.5.21（変更合意なし）、東京地判平26.4.7（変更合意なし）などがあり、ケースバイケースと言わざるを得ません。
また、ユーザは多数の不具合を指摘していましたが、裁判所はこれを不完全履行だとは認めませんでした。本文中では、指摘された具体的な不具合の内容は割愛しましたが、多くは「現行システムにある機能がない」というもので、裁判所はこれに対し「Ｘは、現行のシステムの機能を知り得る立場にはない以上、Ｙにおいて、求める機能を説明し発注しなければ、本件開発契約において要求される機能となり得ない」と退けています。「現行踏襲」という希望が挙げられることは多く、ベンダはこれを警戒していますが、ユーザもそれを具体的に示さない限り、仕様に含まれないことは留意すべきです。
