契約・取引の「一単位」と解除等の取扱い

IT法務

 「開発の中間成果と報酬支払」で言及した「システム開発の中間成果に独立した完成物としての価値があるか」ということをより一般化すると、契約ないし取引の単位の問題となります。つまり、契約の成立や履行、解除などは、まとまりのある「一単位」毎に考えるべきということです。

判例に見る「一単位」

 このような「一単位」は、通常は契約の単位に一致しますが、複数の契約で「一単位」とされる場合があります。例えば、最判平成8年11月12日は、「同一当事者間の債権債務関係がその形式は甲契約及び乙契約といった二個以上の契約から成る場合であっても、それらの目的とするところが相互に密接に関連付けられていて、社会通念上、甲契約又は乙契約のいずれかが履行されるだけでは契約を締結した目的が全体としては達成されないと認められる場合には、甲契約上の債務の不履行を理由に、その債権者が法定解除権の行使として甲契約と併せて乙契約をも解除することができる。」としています。
 また、1個の契約の部分が「一単位」とされる場合もあります。例えば、最判昭和56年2月17日は、「建物その他土地の工作物の工事請負契約につき、工事全体が未完成の間に注文者が請負人の債務不履行を理由に右契約を解除する場合において、工事内容が可分であり、しかも当事者が既施工部分の給付に関し利益を有するときは、特段の事情のない限り、既施工部分については契約を解除することができず、ただ未施工部分について契約の一部解除をすることができるにすぎない。」としています。
 いずれにおいても、契約の切分けにとらわれない「実質」的な単位が問われています。他方で、契約書等の「形式」も、当事者意思を通して契約の「実質」を推認する有力な材料となりますから、契約の際に十分な注意が必要なことは言うまでもありません。

「一単位」の判断要素

 このような「一単位」を判断する要素として重要なのは、契約上の給付の内容です。システム開発の例で、このような「一単位」となり得るものを、小さいものから順に挙げると、①あるシステムの工程(例えば、「販売管理基幹システム」の設計工程や製造工程のそれぞれ)、②あるシステムの各フェーズ(例えば、「販売管理システム」の「第1フェーズ=基幹系」と「第2フェーズ=情報系」のそれぞれ、③あるシステム(例えば、「販売管理システム」の全体)、④別個のシステム(例えば、A社の「販売管理システム」と「会計システム」を併せたもの)、システム開発と運用・保守、あるいはシステム開発とハードウェア、となるでしょう。このうち、②や③は実際の「一単位」となり易く、①は「一単位」の一部分とされ易く、④は複数の「一単位」を含んだものとされ易いと言えます。
 もっとも、判断は具体的な状況にもよります。①の類型でも、一括請負の場合に開発が途中頓挫しながら、引継利用が可能な要件定義の成果物に対する報酬が認められる場合は考えられなくはありません。逆に、④の類型でも、システム開発委託契約が解除されて対象となるシステムが消滅すれば、当該システムを対象とする保守・運用契約もまとめて解除(あるいは「原始的不能」でしょうか)が認められると思われます。
 他方、契約書等での扱いについて、前と同様に列挙すれば、a.単純な成果の単位(例えば、契約書上で作業や納品物として別記されているだけ)、b.支払の単位(検収を伴わない支払)、c.検収の単位(検収を伴う支払)、d.契約書の単位、e.複数の契約書を束ねた単位、となるでしょう。概ね、c.やd.の大きさが「一単位」とされ易いでしょうが、そのような単位を構成する給付内容の組合せや、そのような単位となった意図・経緯が問われます。

システム開発における事例

 システム開発の事例では、開発請負契約とこれに付随したサーバの売買契約(上記④の類型)を一体のものと見て、開発請負契約の解除事由が当然に売買契約の解除事由になるとしたものがあります(東京地判平成18年6月30日)。
 しかし、その理由は「本件契約は……、ウインドウズサーバーによるデータベースの開発を前提にしており、そのことからこれまでの使用していたマッキントッシュサーバーからウインドウズサーバーに変更することを前提として、原告はウインドウズ用のサーバーを購入したのであって、本件データベースの開発がなければ本件サーバーを購入していない関係にあるといえる。」というものに過ぎません。対応するOSの変更があるとは言え、ウィンドウズサーバも流用可能な汎用サーバで、実際にも流用していたというのですから、あっさりと認め過ぎです。また、判旨のように条件関係を理由にするのであれば、仮に開発請負契約と売買契約の相手方が異なっていても解除が認められる理屈となり、この点でも疑問が残ります。