記事

2023年07月13日

「システム開発について善管注意義務が問題とされる場合」

■1.はじめに

 システム開発はプログラミングにより作成したソフトウエアをインストールする作業が主な目的とされることから請負契約として締結されることが多いでしょうが、仕様が定まっていないような場合や段階的に個別契約を締結する場合等では準委任契約とすることもあります。

 当事者が請負契約のつもりであっても裁判所が実際の契約の形式や内容から準委任契約であると認定することもあります。

 準委任契約を前提とすると、システム開発業者は、仕事の完成義務がなく、善管注意義務を負うことになります。

 ではどのような場合に準委任契約と認定され、その善管注意義務の内容はどのような内容なのでしょうか。いくつかの裁判例から検討します。

 

■2.システム開発につき仕事の完成義務を負わない準委任契約であるとした一方で善管注意義務違反があるとされた事例(東京地裁令和2年9月24日判決ウエストロー2020WLJPCA09248012)

 (2-1)事案の概要

 原告は被告に対し、システム開発業務の報酬等の支払いを求めたのに対し、被告は仕事を完成させていないと反論した(本訴)。

 一方被告は原告に対し、システム開発業務について善管注意義務違反により損害賠償請求を主張したのに対し原告は被告が仕様を確定させなかったことに原因があると反論した(反訴)。

 (2-2)裁判所の判断

 原告の報酬等請求について、本件のシステム開発契約の法的性格が請負か準委任化が問題となりましたが裁判所は、「本件契約書1条には,本件契約が民法上の準委任契約として締結されるものであり,原告は,原則として成果物の完成についての義務を負うものではない旨の定めがあり,本件契約書2条には,システムの構築及びプログラム業務並びにこれに付随する業務を原告に委託するとの定めがある」こと、「原告が開発に着手した時点で本件システムの仕様が明確でなかったことから,原告は,被告に対し,請負契約ではなく準委任契約の形式で契約を締結することを再三要求し,その結果,契約書に準委任契約とする旨が明記され,これに当事者双方が署名押印するに至っている」ことから、準委任契約で合意があったものと認定しました。

 そのため、「原告が本件システムの完成義務を負わず,準委任契約としての性質を有するもの」とされ、仕事を完成させていないとする被告の反論を認めませんでした。

 そして原告が、「発注金額及び開発人員が明らかにされた被告の発注に従い,3月7日から5月31日までの間,本件システムの開発に従事する人員を確保し,本件システムの開発業務を実施した」として原告の報酬等請求を認めました(本訴)。

 一方被告が原告の善管注意義務違反による損害賠償請求を求めたことについて、裁判所は、「本件契約が準委任契約としての性質を有することから,原告は,本件システムの開発業務を行うに当たり,善管注意義務を負う。」としました。

 原告が本件システム開発で果たすべき役割について、裁判所は、「本件システムの開発においては,①システム企画,②要件定義,③概要設計(基本設計,ユーザーインターフェイス設計),④詳細設計,⑤プログラム設計,⑥プログラミング及び⑦各種テストの各工程を経る必要があるところ,少なくとも,本件契約上,①システム企画,②要件定義及び③概要設計については被告及びゆるりとが担う一方で,⑤プログラム設計及び⑥プログラミングについては原告が担当し,⑦各種テストについては原告及びゆるりとが行うものとされていました。

  そして,原告は,コンピューターシステムのプログラミング等を事業とする株式会社であり,開発業務を担当することが可能な企業として本件システムの開発に参画している」とし、具体的にも、「開発の着手から間もない時期に開発に必要となる作業項目及び作業期間を示したスケジュール表を作成し,その中で内部設計に分類される「データベース設計」等の3項目を自ら担当することを明らかにしている」ことや「原告は,その後も,本件システムの開発に必要となる作業項目や作業期間を明らかにしたタスク一覧やスケジュール表といった文書を作成し,これを被告に示している」ことから、「原告は,本件契約上,本件システムの開発に向けて必要となる作業項目及び作業期間を明らかにした工程表を策定すべき立場にあり,また,④詳細設計においても,相当程度関与することが予定されていた」としました。

 これらの原告の立場や役割から善管注意義務の内容として、「原告は,被告又はゆるりとから指示を受けた業務を実施する義務にとどまらず,本件契約上の善管注意義務として,本件システムの開発において必要となる作業の内容並びにその作業に必要となる期間及び人員を把握し,適切な工程を示す義務を負っており,相手方から示された仕様の内容が十分でなく,適切な工程を示すことが困難である場合には,仕様を確定する期限を定めるなどの具体的方策を講ずる義務を負っていた」としました。

 本件にて原告は何度かスケジュールを示したものの完成に必要な工程が示されていない等実現可能性が乏しいか疑義が残るものであったとしました。

 そして「原告が,本件システムの開発において必要となる作業の内容並びにその作業に必要となる期間及び人員を把握し,適切な工程を示したとは認められないから,本件契約における善管注意義務に違反したというべきである。」と判断しました。

 また原告は被告が仕様変更や追加の要求を繰り返したことが原因で原告の責任ではないと主張しましたが、裁判所は、「原告が,3月に策定した工程表が実現可能性に乏しく,4月に策定した工程表も実現可能性に疑義が残るものであること」、「原告は,被告に対し,5月13日にリリースする部分の詳細な仕様について連休前に確定することを求めており,同月7日には,同月27日にリリースする部分について被告から求められた仕様の追加が困難である旨を伝えるなどして対応しているが,結局,期限である同月13日までに本件システムは稼働可能な状況に至っていない」ことから、「被告による仕様の追加に関する要求がなかったとしても,原告が策定した工程表のとおりに本件システムのリリースが可能であったとは認め難い。」としました。

 そのため結論として、「被告が5月以降も仕様の変更の要求を続け,仕様の確定作業が遅れていたという事情をもってしても,原告の善管注意義務違反を否定することは困難である。」としました。

 また原告は被告の承諾なく本件を再委託したことについても債務不履行があると判断されました。

 被告の損害額をどのように算定するかが問題になりますが裁判所は、「被告は,遅くとも平成28年5月25日までに本件システムを稼働させ,株式会社マルケトが同年7月に開催するイベントに利用することを予定していたこと,本件システムの開発は遅延し,同年5月31日に原告による開発業務が中止されたこと,被告は,上記イベントに本件システムの一部を用いるため,ゆるりとに対し,本件システムのベース部分の追加の開発費として324万円を,上記イベントに向けたカスタマイズのための開発費として68万5800円を,それぞれ支払った」として「被告が追加の開発費として支払った392万5800円は,原告の債務不履行がなければ支払う必要がなかった」とした上、「もっとも,上述した経緯によれば,被告及びゆるりとが,原告から本件システムの詳細な仕様を確定させる必要がある旨を繰り返し伝えられたにもかかわらず,これを早期に確定させなかったことが,本件システムの開発が遅延した原因の一つであることは否定し得ないから,被告が追加の開発費として支払った392万5800円の6割に相当する235万5480円を原告の債務不履行と相当因果関係のある損害と認めるのが相当」として6割に減額しました。

 (2-3)コメント

 本件ではシステム開発業者である原告が被告から本件業務を受注する段階ですでに被告が仕様を明らかにしていないという問題があったため仕事の完成義務を負わない準委任契約を締結したものと考えられます。

 もっとも原告はシステム開発業者として仕事の完成に向け実現可能な工程を示してシステムの稼働に向けた義務を負っていることには変わりがなく、これを怠れば善管注意義務違反となるのは当然といえるでしょう。

 本件では被告が仕様を変更したり追加したりする等問題があったようですが、コンピュータのプログラミングを行う業者としては使用確定の期限を定める等システムの完成に向けた現実的な手段をとる必要はあったという判断でした。発注者が仕様を確定しない場合に開発業者がどのような措置を取るべきかについて示唆を与えてくれるものでしょう。

 

■3. ベンダーに帰責される履行不能があるとのユーザーの主張を一部認めた第一審の判断を取り消すとともに、第一審で否定されたベンダーの報酬請求を一部認容した事例(東京高裁令和3年4月21日判決ウエストロー2021WLJPCA04216002、判例タイムズ 1491号20頁   、東京地裁平成31年3月20日判決ウエストロー2019WLJPCA03206001)

 (3-1)事案の概要

ユーザー(発注者)がベンダー(開発業者)に証券に関するシステムの開発を業務委託まししたがベンダーの責任により個別契約の途中で頓挫したとしてベンダーに損害賠償を請求したところ(本訴)、ベンダーがユーザーに対し帰責事由がある等と主張して報酬支払を求めました(反訴)。

(3-2)第一審裁判所の判断

  ア 第一審裁判所では、まず個別契約13~14がベンダー(被告)の責任により履行不能に陥ったと認定しました。

 例えば個別契約14については次のように説明しています。

 「本件個別契約5~17は,いずれもリテールITプロジェクトにおいて更新されるSTARの開発と併せて,そのサブシステムの一つとして本件システムを開発し」、「平成25年1月4日にSTARと連携して同時に稼働を開始させる目的で締結されてきた」とされたものの、これらの契約によって進められた本件開発業務は,「要件定義に関する作業が遅延して完了しないまま平成23年9月に設計・開発フェーズが開始され」「スケジュールの調整が行われたが」「度重なる出荷遅延が発生」「品質向上のためにSTARとの同時稼働開始を断念して本件開発業務を一時中止することが検討されるような状況も経て」、「平成24年8月に設計・開発フェーズと並行してテストフェーズが開始されたが」、「同フェーズにおいて前工程までのテストが十分でなかったと分析される障害が多発し,同年8月24日の本件リスク報告では,ベンダである被告自身が,STARとの同時稼働開始にスケジュール及び品質のリスクがある旨を申し出る状況に陥ったものである」とされました。

 そして「被告が報告した上記スケジュール及び品質のリスクとは,要するに,本件システムが平成25年1月4日のSTARの稼働開始までには完成せず,仮に完成させても稼働開始後に不具合を生じるというリスクにほかならず,このようなリスクが現実化したときには,原告野村證券の顧客に対する本件各サービスに係る業務に支障が生じることは避けられないと考えられる。そして,顧客に対し,日々円滑に本件各サービスに係る業務を提供すべき立場にある原告野村證券にとって,社内のコンピュータ・システムの更新に伴い,顧客との関係で上記のような業務支障を生じさせるリスクは,到底,許容し得るものとは思われない。しかも,本件リスク報告は,STARの稼働開始まで4か月強しか残されていない時期に,遅延し障害が多発していた当時の本件開発業務の状況を踏まえ,ベンダである被告自身が行ったものであるから,そのリスクは,客観的にみて,現実的で差し迫ったものであったというべきである。」としました。

 そのため、「原告野村證券は,平成24年8月24日の本件リスク報告を受け,総合テストを中止してコンティンジェンシープランを発動することとし,同月27日には本件発動通知をし,STARの稼働開始に向けて現行システムとの接続が開発されるに至ったが」「ここで発動されたコンティンジェンシープランとは,不測の事態が発生したときに被害や損失を最小限にとどめる目的であらかじめ定められたものであり」「以上のような許容し得ない現実的で差し迫った業務支障リスクに直面した当時の状況の下で,ユーザである原告野村證券が,リスクマネジメント策としてコンティンジェンシープランを発動するということは,社会通念に照らして客観的にみて,ごく通常の,あるいは当然の因果の流れであったと認められる。むしろ,当時の状況の下で,本件開発業務がそのまま継続されるということは,通常考え難いほどに不自然・不合理なことというべきである。」としました。

 そして、「以上の事情の下では,本件発動通知の後に,現行システムでなく,本件システムがリテールITプロジェクトの総合テストに再び参加することは,社会通念上,客観的にみてあり得ない。

  そうすると,本件個別契約14における被告の債務は,本件発動通知がされた平成24年8月27日の時点において,履行不能を来したものと認められる。」としました。

 すなわち裁判所は、ベンダーがスケジュールと品質について予定日までに間に合わないというリスク報告を出したのに対し、ユーザーがプロジェクトの中止を指示したのはやむを得ないことであるとしています。

 この履行不能がベンダー(被告)の責任により生じたものであることの理由として裁判所は、「被告は,それ以前に,A11やA12を本件開発業務から離脱させ,カスタマイズ量の著しい増大の中で,パッケージ・ソフトウェア導入の経験に長けたA17を本件開発業務に従事させ続けていたわけであり」ベンダーに責任がないとはいえないとし、また「被告やテメノス社の頻繁な人員の変更は,原告野村證券側から批判を受けることが多く」、「原告野村證券との約束に反した本件開発業務からの離脱を止められず,被告が管理の甘さを謝罪した例もあった」として人員や管理に問題があったことを指摘しました。

 さらに「被告がいかにマネジメント策を講じたとしても,履行補助者であるテメノス社に要件及びカスタマイズ量の把握不足があり,これを原因としてプログラムの出荷が遅延した可能性が極めて高い」ことからベンダーに責任があると判断しました。

  イ 次にユーザー(原告)の損害としては、いわゆる責任制限条項をどこまで厳格に適用するかが問題になりましたが、裁判所は、「本件各責任制限条項は,経済産業省が提唱するモデル契約においても類似の規定が設けられているものであり」「その趣旨は,コンピュータ・システム開発に関連して生じる損害額が多額に上るおそれがあることに鑑み,段階的に締結された契約のいずれかが原因となってユーザに損害が生じた場合,ベンダが賠償すべき損害を当該損害発生の直接の原因となった個別契約の対価を基準として合意により限定し,損害賠償という観点からも契約の個別化を図るものと解される。また,その性質は,賠償上限額についての損害賠償の予定と解される。」として、損害額を代金相当額に限定しました。

 その他原告らは被告に重過失があるとの主張、不法行為が成立するとの主張もしましたが裁判所はいずれもみとめませんでした。

  ウ ベンダー(被告)の報酬請求(反訴)について裁判所は、個別契約13及び15は履行が完了しておらず、個別契約14「による総合テストは,ウォーターフォール型開発プロセスにおける通常のテストとは異なり,原告野村證券への納品前の被告の受入れテストであるサブシステム内連結テストが終了したプログラムから,順次並行して行われたものであり」「債務の本旨に従ったものとはいえないから,報酬請求権は発生しない」とした上で、被告の帰責により履行不能となった旨を示しました。

 またベンダーの追加作業分についても合意がないとして認めませんでした。

 結論としてベンダー(被告)の反訴についてはいずれも認めら認めませんでした。

  (3-3)控訴審裁判所の判断

  ア まず個別契約について履行不能となるか否かについて裁判所は、ビジネス上の目標について「ビジネス上の目標が重要であるからといって,ビジネス上の目標がそのまま契約上の債務として合意されるとは限らない。ビジネス上の目標をそのまま契約上の債務とすることに合意した後に,目標の実現が予定日より遅れたり,目標の実現が不可能になったりした場合には,履行遅滞や履行不能による損害賠償の問題が生じてしまう。そこで,目標の実現可能性やその確実さの度合い,逆に予定日に遅れるリスクや実現不能となるリスクの度合いに応じて,様々な対応をとることになる。ビジネス上の最終目標の実現に無視できないリスクがある場合には,ビジネス上の最終目標の実現を契約上の債務としないことも,リスク回避の一つの方法である。ビジネス上の最終目標の実現を契約上の債務とする場合においても,債務不履行のペナルティを合理的な内容のものに制限(縮減)することも,リスク低減の一つの方法である。ビジネス上の最終目標が実現できなかった場合のリスク分担に関する定めについて協議がされた結果,合意に至らなかった場合には,契約の締結に至らず,他の契約相手を探すか,ビジネス上の目標の実現を断念することになる。」として必ずしも契約上の合意となるわけではないことを確認しました。

  そして本件個別契約では、IBM所定の契約書を使用してフェーズごとに契約を締結し,契約書には「当該フェーズの作業内容の実施の支援」をIBMに準委任することまたはプログラム(サブシステム間連結テスト及びSTARとの総合テストに入る前の段階,すなわちサブシステム内連結テスト終了の段階のプログラムで,営業稼働に耐える完成度は求められていない。)を製作して納入することなどをIBMの債務の内容と記載した。」として契約の文言上システムの完成が含まれていないことを確認しました。

 そして「本件各個別契約の契約書には,本件システムを完成して稼働させることや,その履行期限を平成25年1月4日とすることは,IBMの債務の内容としては記載されたことはない。」としました。

 さらに裁判所は各個別契約でベンダー(IBM)の債務の内容を確認した上で、「以上によれば,本件システムを最終的に完成させることや,本件システムを平成25年1月4日にSTARのサブシステムの一つとしてSTARと同時に稼働開始させることが,契約当事者双方のビジネス上の目標であったという事実は認定できるものの,これらが契約上のIBMの債務として合意されたという事実を認定するには,無理がある。ましてや,本件各個別契約の締結に先立ち,IBMがWMを利用した本件システムの導入を提案して採用されたことをもって,IBMと野村HDの間に本件システムを完成させる合意がされたという事実を認定するには,無理がある」としてベンダーにシステム完成義務を負わせることはできないと判断しました。

 そして各個別契約についてはすべて履行が完了していると認定しました。

 第一審で問題とされた個別契約13及び15についいても、「本件個別契約13及び15は,本件システムを構築して,基本設計書,テスト計画書及び結果報告書並びにプログラムの仕掛品(ソースコード,実行モジュール)を製作納品し,サブシステム内連結テストを終了する段階(STARなど他のシステムとの総合テスト等に入ることができる段階)にまで進めることをIBMの債務の内容とする請負兼準委任契約であるということができる。成果物最終納入予定日は,契約締結当初は本件個別契約13が平成24年3月31日,本件個別契約15が平成24年6月30日とされていた。これらの予定日は,履行期限(遅れると債務不履行責任を負うもの)ではなかったと認定するのが相当であるが,仮に履行期限であったとしても,双方の合意により履行が猶予され,納入予定日が延期されたものと推認される(報酬支払計画における最終支払日が平成24年9月30日迄延期されたことから,納入予定日も合意により同年8月末日頃まで延期されたものと推認される。)。そして,本件個別契約13及び15所定のプログラムの仕掛品(ソースコード,実行モジュール)の全部(Drop2の顧客Web部分も含む。)が遅くとも平成24年7月27日までに製作納品され,平成24年8月9日の第9回ステコミにおいてプログラムの全部が納品基準を満たして納品されたことが確認され,かつ,本件システムの総合テストへの参加が承認された」ことから「本件個別契約13及び15に基づきIBMが負う債務は,その履行を終えたという事実を推認することができる。」としました。

 その後に発生した問題については、「総合テスト参加中止の判断があった後の平成24年9月及び10月の時期にIBMがサブシステム内連結テストを行っていたこと」は裁判所の認定に影響を与えるものではないとし、その理由として「この時期のIBMは,平成24年8月までのテストの実施により発生したTPRの修正作業を行っていたが,修正作業が成功したかどうかの検証作業としては,単体テスト及びサブシステム内連結テスト(IBMが単独で行うことができるもの)までしか行うことができず,サブシステム間連結テストを実行することは野村證券による総合テスト参加中止決定が原因で不可能であったものとみられる。プログラムの仕掛品の全部は,納品基準を満たすと双方に判断された上で平成24年7月27日までに納品されたのであるから,その後のテスト等において問題が発見されたことに伴う修正作業の中でサブシステム内連結テストを行ったからといって,納品基準を満たすと双方に判断された上で平成24年7月27日までに納品されたという履行完了の事実が覆されるものではない。」としました。

 さらに個別契約14については、「本件個別契約14は,STARとの総合テスト及びデータ移行等の準備及び実施の支援を行う準委任契約(仕事の完成を目的とした請負契約ではない)であり,「240.6人月」の提供終了又はサービス期間の終了(平成25年1月4日)のいずれか早い日にサービスの提供を終了するものとされている。そうすると,IBMは,総合テストを経て本件システムをバグのない状態に仕上げ,データ移行を終えるなどして平成25年1月4日に本件システムをSTARと同時に稼働開始する債務を本件個別契約14に基づいて負うものではない。IBMは,受任者として,本件システムの平成25年1月4日稼働開始を目標として誠実にサービスを提供すべき善管注意義務を負うにとどまる。」としました。

 そのため第一審判決の内容であった「IBMが本件システムを完成させる義務を負うことを前提とする本件個別契約14の履行不能の主張は,理由がない。」として第一審判決を覆しました。

 また第一審裁判所が認めたユーザー側の主張であるベンダーの帰責事由による履行不能については、履行不能となった証拠はない上、むしろ改善が可能であったとする意見書があるとしました。

 そして帰責事由については、「本件システムが前記の時点において改善を要する点を多数抱えていたことは前記認定のとおりであるが,双方にその原因があり,特に下流工程の基本設計フェーズに入った後も,さらには当初はテスト期間と想定されていた平成24年に入ってからもCR(変更要求)を繰り返して,工数の著しい増大とテメノス社の作業の手戻りと遅れを繰り返し誘発し,テメノス社からプログラム製作作業の十分な時間的余裕を奪った野村證券側に,より大きな原因がある」とし、「仮に百歩譲って前記の時点で履行不能であると評価することが可能であるとしても,その帰責事由の多くは野村HDらの側に多々あるのであって,IBMの帰責事由と評価することは困難である」としてユーザー側に責任があるとしました。

 さらに「STAR及び本件システム以外のSTARのサブシステムがビジネス上の目標を達成して予定通り平成25年1月に稼働開始したことからすれば,ビジネス上の目標不達成となった唯一のシステムである本件システム(SMAFW)の担当者らが,野村グループの中で非難の目にさらされていたことは容易に推認することができ,社内説明用のスケープゴートとして,IBMを必要以上に悪者扱いして,ビジネスパートナーとして信頼するに値しないと社内説明していた可能性は,高いものとみられる。いずれにせよ,信頼関係の点は,野村HDらが主張する履行不能を根拠付けるものとはいえない。」と踏み込んだ説明をしています。

 また「本件開発業務の節目において,IBMの担当者から,その時々の問題点の発生原因がIBM側にあるかの発言や文書記載がされることがある」点については、「IBMは報酬を受領する側,野村HDは報酬を支払う側であるから,IBMがプロジェクトの続行を希望して,低姿勢な態度に終始して,自己の問題点は指摘するが,野村HD側に問題があってもこれをあまり指摘しない言動に出るのは,自然なことである。このようなIBMの言動を,それのみで直ちにIBMの帰責事由の根拠と評価することは,不適当である。」として顧客であるユーザーに対するベンダー立場を考慮しました。

 またユーザー側の履行遅滞や不法行為の主張についても同様の理由から認めませんでした。

  イ ベンダーの報酬請求については、例えば個別契約13について裁判所は「IBMは,平成24年7月27日までに納品基準を満たして成果物を納品するなど本件個別契約13に基づく債務を全部履行し,債務不履行(履行遅滞・不完全履行)もなかったものというべきである。そうすると,IBMは,野村HDに対して,報酬の全額を請求することができるから,平成24年9月30日を支払期限とする未払報酬1564万5000円(14,900,000×1.05)及びこれに対する約定期限の翌日(平成24年10月1日)以降の商事法定利率による遅延損害金の支払を求めるIBMの請求は,全部理由がある。よって,これを全部棄却した原判決を取り消して,認容すべきである。」として第一審裁判所の判断を覆しました。

 同様に、個別契約15についても全額について報酬請求を認めました。

 一方個別契約14については、「本件個別契約14は,野村證券が平成24年8月27日に本件システムのSTARとの総合テストを中止して,平成25年1月稼働開始を断念したことにより,IBMの債務のうち,総合テストの実施支援などについては履行することができなくなったものである。他方,データ移行準備支援など,履行可能な部分も残っていた。その意味で,本件個別契約14は,平成24年8月27日にIBMの債務の一部が履行不能となったものである。また,野村證券が同年11月2日に本件開発業務中止をIBMに通告したことにより,本件個別契約14に基づくIBMの債務は全部履行不能となったものである。そして,IBMとしては,本件開発業務が遅延していたことから,予定より遅れて本件システムを稼働開始するつもりではあったものの,STARとの総合テストをとりあえず中止すること及び平成25年1月の稼働開始を断念すること自体は,やむを得ないものとして容認していたものと評価すべきである。」としました。

 そして報酬については、「本件個別契約14の報酬体系(総額を確定料金6億9500万円(消費税別)とし,240.6人月の提供終了又は平成25年1月4日のいずれか早い日にサービスの提供を終了する)は,平成25年1月稼働開始を前提とするものである。そうすると,本件個別契約14自体は,平成25年1月稼働開始を前提とする支援作業を行う契約であることになる。そして,IBMがSTARとの総合テスト中止及び平成25年1月稼働開始断念自体を容認したことにより,平成25年1月4日までに行うことのできる作業の総量も客観的に減少したことから,本件個別契約14の報酬体系については,IBMが履行した分だけを支払う出来高払い制に変更する旨の黙示の合意があったものと推認するのが相当である。そうすると,IBMの請求のうち民法536条2項を根拠にする部分は全部理由がなく,それ以外の部分は認定された出来高に相当する部分を認容すべきである。」として出来高分のみを認めました。

 その他ベンダーは追加作業等について報酬請求をしましたが、いずれも当事者間で合意がなく契約書にも根拠がないとして認められませんでした。

 (3-4)コメント

 本件は第一審と控訴審で裁判所の判断が大きく分かれました。第一審では当事者の信頼関係という人的要素を重視しユーザーの主張を一部認容(ベンダーの請求を棄却)しましたが、控訴審では契約書の記載という形式面を重視してベンダーの主張を一部認容(ユーザーの請求を棄却)しました。

 控訴審裁判所の判断は双方とも大手企業ということで契約の形式面に従った判断を下したものといえます。システム開発ではベンダー側のひな形を利用することも多く、本件でもベンダー側が契約書を準備したものであることから、仕事の完成義務を負わない準委任となっていたり、請負でも成果物を検査報告書等としてシステムの完成が債務の目的となっていませんでした。システム開発業務を準委任とするとプログラムの完成が契約の目的とはならずシステム開発業者は善管注意義務を負うのみということになり注意義務を果たしていれば契約違反はないということになります。

 またビジネスの目標として例えば平成25年1月4日にシステムを稼働開始としたいのであれば契約書にその旨を明記してそれが達成できなかった場合にベンダーが履行遅滞になる等記載しておく必要があったということになります。

 控訴審裁判所が一般企業に出したメッセージはある意味で極めて明確であるといえ、今後はシステム開発を葉中するユーザー側に慎重な態度がもとめられているといえそうです。

 

■4. 独自販売サイト等の新たな機能を付加作成する業務委託につき請負・労働者派遣ではなく準委任であるとして善管注意義務を否定した事例(東京地裁令和元年9月27日判決ウエストロー2019WLJPCA09278009)

 (4-1)事案の概要

 原告は、稼働していたシステムに独自販売サイト等の新たな機能を付加作成するために被告と契約を結んだが被告がこれを完成させなかったとして請負に基づく債務不履行責任、準委任契約に基づく善管注意義務違反を主張したのに対し(本訴)、被告は労働者派遣契約に基づき報酬支払を求めた(反訴)。

 (4-2)裁判所の判断

 まず本件契約の内容及び性質について、「請負は「当事者の一方がある仕事を完成させることを約し,相手方がその仕事の結果に対して報酬を支払うことを約することによって,その効力を生ずる」(民法632条)ものである。しかるに,以下の事情を総合すれば,本件契約において,完成させるべき仕事の内容が特定されていたとは認めるに足りない(本件業務の内容が,請負契約において完成させるべき仕事に当たるほど特定されていたとは認めるに足りない)から,本件契約が請負契約であるとは認められない。」としました。

 この点原告は、「本件契約が,プロジェクト名「BSPver.7」(インターネットショッピングサイト出店に関するシステムであり,商品の出庫,サイト内の在庫管理,ユーザーの閲覧画面,注文操作等を内容とするもの)に関するシステムの開発及び設計を目的とし,原告の商品管理システム等に新しい機能等の上記9項目を追加するものであることを,本件個別契約の前に合意していた旨主張する(前記第2,3(1)ア,イ)。しかしながら,その9項目について原告が主張する内容を見ても,例えば,「パッケージソフトEC-CUBEをカスタマイズして,自社の独自通販サイトを構築すること」といった抽象的な内容にとどまるのであって,これでは,請負契約の対象である仕事が完成したか否かを具体的に判断することはできないから,完成させるべき仕事の内容が特定されていたとはいえない。」としました。

 また「本件契約に係る代金支払等について見ても,本件個別契約書によれば,毎月80万円(消費税込み)を検収完了後に月末締め翌月10日払いをすることとされており,本件個別契約書の記載振りをみても,特定の完成成果物に対して代金ないしは報酬が支払われることが前提とされているとは直ちに解しがたい(なお,本件基本契約書においては,個別業務の成果物について検査合格後にその委託料を月末締め翌月払いすることとされているが,この定めは,下記の実際の代金支払の態様と反しており,本件契約の実際の内容と齟齬する)として仕事の完成に対する対価とするものではないとして請負契約ではないとしました。

 次に準委任又は労働者派遣かについては、「原告において稼働していた本件システムに独自販売サイト等の新たな機能を付加作成するためのものであるところ,原告は,それまで断続的に原告からシステム開発を依頼され,本件システムについて事前知識のある被告との間で本件契約を締結したのであるから,本件契約はその相手方が本件システムに事前知識のある被告であることが重要な動機となっている」として人的要素を指摘し、「実際の作業の過程を見ても」一義的に制作作業の内容が確定するともいえず,Bには一定の裁量が残されていた」としました。

 また本件で「実際にBが原告の指揮命令権の下で労働者として働いていたことを認めるに足りる証拠もない」とした上で、「被告(B)の作業には,本件システムの事前知識やBの専門性を前提とする一定の裁量が認められていたものであるから,本件契約は,作業者(派遣労働者)の個性や裁量が重視されない労働者派遣ではなく,むしろ,準委任の性質を持つものと認められる。すなわち,本件契約は,原告において稼働していた本件システムに独自販売サイト等の新たな機能を付加作成するための制作作業を行うことを内容とする準委任である」と認定しました。

 原告は準委任を前提とする善管注意義務違反として「被告が納品した本件納品物には多数の不具合があり,繰り返し修正を求めたがこれらの不具合が解消されることはなかったなど」と主張しましたが、裁判所は「いずれも成果物の結果についての指摘であって,準委任契約たる本件契約に基づく被告の事務処理にどのような問題があったのかを具体的に指摘するものではない。そして,本件契約に基づく被告の事務処理に善管注意義務違反(債務不履行)があったと認めるに足りる証拠はない。」として原告の主張を認めませんでした。

 さらに「本件システムは本件契約以前にも各種機能の付加変更をその都度重ねて行ってきていたものであるところ,本件業務はそのような本件システムにさらに機能を付加作成するものである。一般に,システム設計上,既存のシステムに各種機能の付加変更を繰り返してきた場合には,システムのデータベースの構造やデータの処理過程が複雑化し,さらなる機能の付加変更によって既存部分にも付加変更部分にも論理的誤りが生じやすくなるものであるところ,本件システムも同様であったと推認することができる。

  このことに加えて,上記認定のとおり,原告(A)は被告(B)に対し,都度,具体的な指摘により付加変更内容を伝え,被告(B)はこれに対応するコーディング作業等を行っていたことも踏まえれば,仮に被告の事務処理の結果,本件システムに何らかの不具合が出たとしても,そのことから直ちに被告による事務処理が善管注意義務違反に当たると推認することはできない」として既存のシステムに付加・変更する作業の困難さから一定の不具合が生じても善管注意義務違反とはならないことを確認しました。

 また被告の反訴について裁判所は「①のメンテナンス委託契約の主張については,被告の主張に係る合意の成立やメンテナンスの実施を認めるに足りる証拠はない。また,上記②の労働者派遣契約の主張についても,被告の主張に係る合意の成立を認めるに足りる証拠はない。なお,上記説示のとおり,本件契約は労働者派遣契約ではなく準委任契約であると認められるところ,準委任契約に基づく報酬請求に当たっては,委任事務が履行されたことを主張立証する必要がある。」としていずれも認めませんでした。

 (4-3)コメント

 本件は既存のシステムに販売サイトといった機能を追加する業務が問題となりましたが目的とする仕様が特定されていないことに加え被告との従前の取引を重視して依頼されていることから仕事の完成を目的とする請負ではなく準委任契約であると認定されました。

 また本件のように追加・修正する作業では既存のシステムとの齟齬が発生しやすいことに留意すべきであることから不具合が発生したとしても直ちに善管注意義務違反となるとはいえないとしてシステム開発業者側を保護する構成をとりました。特に追加・修正する業務を行う際には参考になるものと思います。

 

■5.まとめ

 これらの裁判例から、請負契約とするのであれば、仕様を特定して仕事の完成を目的とすること、納期、題記など基本的な要素を契約書に明記しておく必要があるでしょう。注文者側はシステムに関する知識が十分でなく仕様を特定することに困難な面がありますが、これを確定しないまま進めると、仕様の追加・変更が増えたりするだけでなく、そもそも仕事の完成を目的にしていないとして準委任契約であると認定される可能性もあります。

 一方順位に契約であるとしても専門技術を有するシステム開発業者は当然ながらシステムの完成に向けて仕様を確定させるよう協力しなければならず注文者のニーズを的確にシステムに反省させるよう最善を尽くす必要があるでしょう。

 開発業者、注文者のどちらの立場にあったとしても現在の裁判所の実務で契約書の果たす役割は極めて大きいものと考えられます。

 

水野健司特許法律事務所

弁護士 水野健司

電話 052-218-6790

電子メール info@patent-law.jp

 

 

閉じる