コンピューターソフトウェア開発における主なリスク、司法裁判およびコンプライアンスに関する提言

華誠律師事務所  呉月琴  何鑫

このほど、最高人民法院知的財産権法廷が『最高人民法院知的財産権法廷による年次報告書（2019）』を発表し、それによれば、コンピューターソフトウェアに関する契約紛争事件が増加しており、争点は開発成果が引き渡されているか否か、引渡内容が約定に合致するか否か、履行中の変更について合意がなされているか否か、履行遅滞をどのように認定すべきか、などの問題に集中している。本稿は上記の紛争における争点をまとめた上で、裁判所の審判実務における関連争議の認定基準を踏まえ、企業に向けてコンピューターソフトウェア開発契約における主なリスクの整理、更にそれに応じたコンプライアンスに関する提言を狙いとする。

一、開発成果が引き渡されているか否か

開発成果が引き渡されているか否かは、この種の事件によくある争点であるとともに、引渡内容が契約の約定に合致するか否か、および当事者に違約行為があるか否かの事実認定においても、先に解決すべき争点である。この争点は、主に立証責任の配分に関わる。引渡行為は積極的事実であるため、既に開発成果を引き渡したと主張する側が立証責任を担うべきである。訴訟において、既に開発成果を引き渡したと主張する側は一般的にはソフトウェア開発側であり、その場合は、開発側がソフトウェアの引渡に関する証拠を提供すべきである。一般的には、開発側が委託開発ソフトウェアを引き渡した後、委託側は必ず引渡確認書を発行しなければならないため、開発側が訴訟において契約で約定した形式に合致する引渡確認書を提出した場合、相応の立証責任を尽くしたと認定してよい。その場合、委託側がソフトウェアが引き渡されていないと立証しなければならない。たとえば、上海匡丞企業管理諮詢有限公司が高騰斯佳を訴えたコンピューターソフトウェア開発契約紛争控訴事件において[1] 、裁判所は次のように考えた。開発側である高騰斯佳氏が録音および検収合格証明を提供し、匡丞社が係争製品ついて確認を行っていることを証明した状態で、委託側である匡丞社はその引渡確認が開発側に誘導されたことである、または係争製品が実際に引き渡されていないと証明する証拠を提供できていないため、この場合、係争製品は既に引き渡されたと認定すべきである。

ソフトウェアの開発過程においては、開発側がクラウド・サーバーにソフトウェアを配置する形で委託側にソフトウェアを引き渡すこともあり、この状況で争議が起こった場合、裁判所はクラウド・サーバーにソフトウェアが実際に配置されているか否かを検証するだけで、ソフトウェアが引き渡されたか否かを確認できる。しかし、実務においては、クラウド・サーバーのレンタルに費用を払う必要があるため、争議が起こった際にクラウド・サーバーのレンタル側（通常は委託側）がレンタル料の支払いを停止していると、裁判所はクラウド・サーバーにログインしソフトウェアが実際に引き渡されているか否かを確認することができない。この場合、開発側が既にソフトウェアを引き渡したことを証明するために初歩的な証拠を提供していても、ソフトウェアが実際に引き渡されたことをクラウド・サーバーにて検証することはできないが、相反する証拠がない状況で、裁判所はソフトウェアが既に引き渡されたと直接認定することができる。ただし、もし開発側がソフトウェアを既に引き渡したことを証明する証拠を提供できないのと同時に、委託側がレンタル料の支払いを停止したためクラウド・サーバーにログインできず、ソフトウェアが実際に引き渡されたか否かを確認できない状況で、裁判所は「証明は主張する者にあり」という原則を踏まえ開発側に立証不能の責任を負わせるか、クラウド・サーバーにログインできないという事情をもたらした委託側に立証不能の責任を負わせる[2]ところに問題がある。これは、開発側と委託側の両方の権利行使に大きな不確実性をもたらす。

二、引渡内容が約定に合致するか否かの認定

引き渡す成果物の内容が契約上の合意を満たしているか否かの認定は、一方では技術レベルの判断に関わり、他方では契約内容の理解に関わる。一部の委託側がコンピューターの専門技術および用語の一定程度の理解に欠けていたり、双方が成果物の具備すべき機能について枠組み的な説明しか約定していなかったり、または双方が契約条項を詳しく審査できなかったりしたことにより、契約の締結において、引き渡す成果物への要求についての約定が不明瞭になったり、または成果物の要求につき双方の理解がずれるといった状況が起こる。そのため、司法実務においては、係争ソフトウェアの技術鑑定を通じて事実を明らかにするほか、契約条項の理解も裁判所が裁量するための重要な根拠であり、これは契約の解釈の問題に関わる。

『契約法』第125条第1項では、当事者は契約条項の理解につき争議がある場合、契約で使用する語句、契約の関連条項、契約の目的、取引慣行および信義誠実の原則に従い、当該条項の真意を確定しなければならない、と規定している。すなわち、文理解釈、体系的解釈、目的論的解釈を通じて、業界の取引慣行に配慮して契約条項を解釈することができる。王彬が上海涵予信息科技有限公司を訴えたコンピューターソフトウェア開発契約紛争事件において、双方は契約において、引き渡されるソフトウェアにはチャットとショッピングの部分を含むと約定しており、契約の1.3条では更に、チャット部分には私の友達、友達検索（条件で探す、友達申請、申請のメッセージ）、オンラインチャット（チャットのリスト、チャットのインターフェース）を含むと約定している。しかし、涵予社が引き渡したソフトウェアにはチャットとショッピングのインターフェースしかなく、契約で約定したチャットとショッピングの部分がチャットとショッピングの機能を含むか否かにつき、一審裁判所は次のように指摘した。「上記の『条件で探す、友達申請、申請のメッセージ』などの約定からすると、チャットの部分はチャットのインターフェースだけでなく、実際のチャット機能も具備すべきである。」ここで、裁判所は文理解釈という方法で契約条項を解釈した。

この他、契約の解釈は厳格に順序に従い、文理解釈が最優先させるべき解釈法であり、その後は体系的解釈であり、最後は契約の目的、取引慣行および信義誠実の原則に基づく解釈である。[3]

三、履行中の変更について合意がなされているか否かの認定

コンピューターソフトウェアの開発過程においては、委託側のニーズが変化することもあり、このとき、委託側は開発側に対し、ソフトウェアに機能モジュールの追加などの調整を行うよう求めることがある。このとき争議が起こった場合、委託側は開発側が委託側による変更の要求を満たさなかったため違約を構成すると主張することがある。済南艾雅信息系統有限公司が済南鳳凰新鋭科技有限公司を訴えたコンピューターソフトウェア開発契約紛争事件において[4]、委託側の艾雅社は、開発側の鳳凰新鋭社の引き渡したソフトウェアは契約履行中に提示された新しい開発要求および機能を満たさなかったため違約を構成する、と主張した。同時に、開発側も、委託側がソフトウェアの開発過程において新たに追加された機能やプロジェクトの金額を支払わなかったため、違約を構成すると主張することがある。上海凱岸信息科技有限公司が上海麦易信息軟件有限公司を訴えたコンピューターソフトウェア開発契約および売買契約紛争事件において、開発側の麦易社は反訴を提起し、後から追加された「自動車ローン」プロジェクトの開発費用の支払を委託側の凱岸社に求めた。[5]この時、裁判所は審理において、当事者が契約の変更につき合意に達したか否かの確認に焦点を当てる。

『契約法』第77条第1項によれば、当事者が合意した場合、契約を変更することができる。したがって、委託側と開発側が契約変更について合意に達したか否かの判断は、双方において契約変更の有効な申込と承諾があったか否かの判断である。実務においてよくある争議は、一方の当事者が契約変更の通知（例えばソフトウェア機能の調整の要求や開発費用の変更など）を出したが、他方の当事者が明示的に同意または拒否をしなかった場合である。この場合、双方による合意の状態を如何に判断するかが裁判所の審査の焦点になる。「契約法」第22条の規定によれば、承諾は通知の方式によりなさなければならないが、取引慣行に基づく場合または申込において行為による承諾が可能であると明示している場合を除く。すなわち、当事者間で約定している場合と取引習慣に従っている場合以外、承諾は明示の方式で行わなければならない。この理解をふまえると、開発側が委託側による変更の要求に対し沈黙している場合、双方が契約変更について合意したと見なすべきではない。凱岸社が麦易社を訴えた前述の事件では、裁判所は次のように指摘した。「本件において、凱岸社または麦易社が書面をもって、自動車ローンが係争中のソフトウェア開発における『新たに追加されたプロジェクト』であると明確に述べたことを示す証拠はない。……自動車ローンプロジェクトが凱岸社の新たに追加したニーズであるなら……双方の当事者が書面による協議を経て確認しなければならない。したがって、双方の当事者が書面をもって自動車ローンプロジェクトが係争中のソフトウェア開発における『新たに追加されたプロジェクト』であることを確認していない状況で、麦易社による『来週の作業計画（2015/8 / 3-7）』における自動車ローンプロジェクト中の「インクリメンタル」という言葉のみでは、自動車ローンプロジェクトが係争中のソフトウェア開発における『新たに追加されたプロジェクト』であると結論付けることはできない。」もちろん、開発側がクライアントの契約変更の要求に明示的に同意していなくても、関連するソフトウェア開発の要求を実際に履行している場合は、開発側が暗黙の承諾をしており、双方は契約の変更について合意をなしたと見なすべきである。

四、履行遅滞の認定

コンピューターソフトウェア開発契約において、双方は通常、ソフトウェアの引渡日を確定し、かつ開発側の引渡が遅滞した場合に違約を構成すると約定する。そのため、開発側によるソフトウェアの引渡という契約義務の履行遅滞が、開発側が違約を構成するという委託側の主張の主な理由となる。しかし、開発側がソフトウェアを期日までに引き渡さなかったことは、開発側が違約を構成する十分条件ではない。一部の事件において、開発側はいずれも自身の履行遅滞が委託側の落ち度によるものであることを抗弁理由とした。裁判所は開発側の履行遅滞において委託側の落ち度があると認定した場合、開発側の違約責任を軽減し、さらに開発側が違約を構成しないと認定することさえある。したがって、委託側の責任をどのように認定するかが、裁判所がこの種の事件を審理する際の難点となる。

北京中易遊網絡科技有限公司が北京盛世星輝網絡科技有限公司を訴えたコンピューターソフトウェア開発契約紛争事件[6]において、委託側である中易遊社は盛世星輝社が期日までにソフトウェアを引き渡せなかったため履行遅滞を構成すると主張した。盛世星輝社は、ソフトウェアを期日までに引き渡せなかったのは中易遊社が何度もポートの修正と追加を要求したからであるため、自社は履行遅滞を構成しない、と抗弁した。裁判所は審理の結果、次のように考えた。双方は契約を履行する初めの段階で『プロジェクト説明書』とソフトウェア開発計画を制定しなかったため、双方ともに落ち度がある。中易遊社は委託側として、盛世星輝社にソフトウェア開発計画の制定について速やかに協議を行うように積極的に求め、開発計画に沿って段階ごとに盛世星輝社の開発した段階的な製品のテスト・検収を行う義務を負っている。『プロジェクト説明書』とソフトウェア開発計画が制定できていなかったことにより、開発側が期日通りにソフトウェアを引き渡せないリスクおよび難度が高まった。この外に、既存の証拠では中易遊社が何度も盛世星輝社にソフトウェアの修正を求めた原因は盛世星輝社の作業が要求に合致していなかったためであることを証明できない。以上の理由をふまえ、開発の進捗が遅れた原因の責任を単に盛世星輝社に帰属させるべきではない。この事件が我々に与えた示唆として、委託側はコンピューターソフトウェア開発契約を締結する早い段階で、機能に対する自身のニーズを明確にし、開発側とともにソフトウェアの開発基準を明確にし、自身の原因によるプロジェクト進捗の遅れを避けるべきである。

五、企業へのコンプライアンスに関する提言

契約の締結段階において、企業は契約締結段階において少なくとも三つの「明確化」を徹底することを提言する。すなわち開発ニーズの明確化、引渡方式の明確化、および検収基準の明確化である。

1.開発ニーズの明確化によって、一方では開発側はさらに委託開発ソフトウェアの実際の機能に対する委託側のニーズをはっきりさせることができ、ソフトウェアの開発をより効率的に行うことができる。他方では、開発ニーズの明確化は、ソフトウェア開発の過程におけるソフトウェアの機能の調整に関する双方のコミュニケーションのための原則的なガイドラインとなる。開発ニーズの明確化は、開発側から委託側へのニーズ調査等の形で行うことができる。ニーズが確定した上で、双方はソフトウェア開発の『プロジェクト機能説明書』またはソフトウェア開発計画などの書面をもってニーズを確認すべきであり、機能モジュールの記述はできるだけ詳細に、具体的に、明白にすべきである。

2、引渡方式の明確化は、引渡日、引渡場所、引渡に必要な書類、引渡の流れなどの内容を含む。実際の必要に応じて、双方は引渡完了の指標とする事柄を約定することもできる。たとえば、委託側が引渡確認書を発行することや、ソフトウェアが開発側によってクラウド・サーバーに配置されたこと、または実際に実行されたことなどである。注意すべきなのは、実務において裁判所は通常、引渡確認書に基づきソフトウェアが引き渡されたか否かを確認し、委託側は消極的な事実を主張する主体として、反証を提供することは割と難しい。そのため、委託側は、引渡の流れにおける不備によって争議発生時に受動的な立場におかれないように、ソフトウェアが実際に引き渡されたことを確認した上で引渡確認書を発行すべきである。

3.検収基準の明確化。契約の締結段階において、双方はソフトウェアの検収基準を約定し、各技術指標の数量化を重点的に行うべきである。必要な場合は、ソフトウェアが開発基準に合致するか否かにつき、第三者に検証してもらうことも約定できる。

中易遊が盛世星輝を訴えた事件において、裁判所は契約履行段階における委託側の対応についてガイドラインを示した。すなわち、契約を締結する早い段階で確定したソフトウェア開発計画などの書類に基づき、約定したタイミングに沿って、段階ごとに開発側の開発作業につきテストと検収を行う。この外に、ソフトウェアの開発過程において、委託側のニーズがソフトウェアの各段階の完成状況や市場の変化等によって変わることは普通ではあるが、頻繁なニーズ変更は、開発側が期日通りにソフトウェアを引き渡しにくくなることにつながるため、ニーズの変更は合理的な範囲に収めるべきである。開発側にとって、委託側のニーズ変更などによって期日までにソフトウェアを引き渡すのが難しくなったことを予見できた場合、速やかに委託側とコミュニケーションを取り、引渡期限を延ばし、争議の発生を避けるべきである。

契約の履行において、双方はコミュニケーションを重視し、コミュニケーションの書面記録を保存すべきである。たとえば開発側が委託側にプロジェクトの進捗を知らせるメールのやりとりを保存し、委託側は開発側の進捗の段階的な検収結果報告書、開発過程におけるソフトウェアの問題などを保存する。契約内容の変更に係る場合、双方は書面を持って約定の変更を確認すべきである。特に委託側の開発ニーズの変更に係る場合には、開発側は委託側とともに正式に書面をもって確認すべきであり、争議が発生した際に引き渡したソフトウェア成果物が約定に合致することを証明しにくいという受動的な立場に置かれないようにする。

[1]上海知識産権法院（2016）滬民終389号民事判決書。

[2]委託側に立証不能の責任を負わせる根拠は主に『最高人民法院による民事訴訟証拠に関する若干の規定』第95条で確立した証明妨害制度である。しかし、駱永家教授の観点によれば、証明妨害制度は立証責任を負わない当事者が故意的にもしくは誤って立証責任を負う当事者人を立証不能の状態に陥れたことを前提としている。委託側がレンタル料の支払いを停止することにコストの増加を避けるという理由はあるが、主観的に故意や過失があるのか、または当該理由は正当なものであるか否かは、検討が必要である。

[3]たとえば北京市第二中級人民法院(2019)京02民終2834号民事判決書において、裁判所は、「契約の解釈は、まず語句の意味から着手し、語句の意味に曖昧さや別の理解がある場合のみ、契約の関連条項、契約の目的などに応じて解釈してもよい」と指摘している。

[4]山東省済南市中級人民法院(2018)魯01民初2334号民事判決書。

[5]上海知識産権法院（2016）滬73民初730号民事判決書。

[6] 最高人民法院 (2019)最高法知民終433号民事判決書。