IT・システム判例メモ

弁護士 伊藤雅浩が,システム開発,ソフトウェア,ネットなどのIT紛争に関する裁判例を紹介します。

システムの完成,瑕疵担保責任,追加報酬の請求等が争われた事例 東京地判平22.1.22(平18ワ6445等)

大学のシステムの開発における元請けと,下請けとの間での報酬請求に関する紛争

事案の概要

学校法人A大学の事務システム(「本件システム」)の開発を請け負ったベンダYと,その下請けベンダXとの間の紛争。


システムは完成し,本番稼動したが,以下のようなトラブル(「本件トラブル」)が発生したとされている。

(ア)履修登録システムのトラブル
(イ)証明書類の発行不能
(ウ)入力データの消滅
(エ)学生個人情報の漏えい
(オ)成績通知書の誤発行
(カ)本番用データベースの消去


契約が締結されていた期間は,平成17年3月末日までであったが,その後もXは,同年9月まで本件システムに関連する作業を実施した。


A大学とYとの間では,本件トラブルに関連して,Yの損害賠償債務の総額が約25億円であるが,そのうち,YがA大学に瑕疵その他の問題に関する損害賠償債務について約6億7000万円支払うという旨の覚書が結ばれた。


Xは,Yに対し,報酬残額として約1.5億円と,契約金額のほかに実施した作業分の報酬として約5億円の合計約6.5億円を請求したのに対し(本訴),Yは,Xに対し,Xの開発したシステムには瑕疵があったことなどを理由に,約23億円の損害賠償を請求した。

ここで取り上げる争点

  • 本件トラブル発生の原因及び責任の帰属
  • Xが平成17年4月以降に実施した作業の内容及び報酬
  • Yに生じた損害

裁判所の判断

★争点1(トラブル発生原因等)について。


トラブル発生原因と責任を判断するにあたり,X,Yそれぞれがどのような債務を負っていたかを丁寧に認定した(XY間の契約は請負契約だと認定されている。)。


そして,Xの瑕疵又は債務不履行責任の有無について,次のように説示している。

請負人が仕事を完成させたか否かについては,仕事が当初の請負契約で予定していた最後の工程まで終えているか否かを基準として判断すべきである。

これは,本判決に限らず,システム開発契約におけるいくつかの判例で同様の基準が用いられており,実務的に定着した基準だといえる*1


この場合,どの工程が「最後の工程」といえるかが争いになることも多いが,本判決では,

Xの債務内容である仕事は,本件プロジェクトにおけるシステム開発に係る作業であり,同作業は(1)フィットギャップ分析段階,(2)詳細設計段階,(3)プログラム開発段階を経て,平成16年4月1日から新システムによる本番稼働を行うことを目的とするものであるから,その工程は新システムのプログラムを開発し,本番稼働を開始するまでの作業が最終の工程であり,本番稼働後の作業は本番稼働前の仕事の成果物の不備を補修する別個の債務の履行であるものと認められる。そして,前提事実によれば,A大において同年4月からXが作成した新システムにより本番稼働を開始していることが認められるから,Xは新システムのプログラムについて,甲1契約に基づく仕事を完成させたものといえる。

として,要するに本番稼動させている以上,「仕事の完成」は認めている。続いて,完成を前提とする「瑕疵担保責任」の判断に当たって,「瑕疵」の意義について,

情報処理システムの開発に当たっては,作成したプログラムに不具合が生じることは不可避であり,プログラムに関する不具合は,本番稼働前後の検収等の過程における補修が当然に予定されているものというべきである。このような情報処理システム開発の特殊性に照らすと,システム開発の途中で発生したシステムの不具合は直ちにシステムの瑕疵には当たるものではなく,システムの納品がされ本番稼働した後においても,注文者から不具合が発生したとの指摘を受けた後,請負人が遅滞なく補修を終えるか又は注文者と協議した上で相当な代替措置を講じたと認められるときは,システムの瑕疵には当たらないものと解する

この部分も,他の裁判例でもよくみられる論理である。つまり,法律上は,「バグ=瑕疵」とはとらえておらず,「不具合」のうち,「遅滞なく補修できない」and「相当な代替措置を講じない」ものが「瑕疵」にあたるとしている。


そういった観点からは,冒頭で述べた(ア)から(カ)の不具合のうち,(ア)(イ)(エ)については,「瑕疵」とはいえない一方で,(ウ)(オ)(カ)については,「瑕疵」(債務不履行)にあたるとした。


さらに,本件トラブルのほか,「多数の学生等が同時に使用することが想定されたシステムにおいて排他制御機能がないこと」と「数万人規模に利用されるシステムとなっていなかったこと」も「瑕疵」にあたるとした。


★争点2(平成17年4月以降の報酬について)


この争点は,Xが,明確な合意があった期間を経過した後の作業に対する報酬を求めたものである。Yは,瑕疵の修補を行っていただけであるから,報酬請求権は発生しないと主張していたが,

平成17年4月以降に原告が行っていた作業は,少なくともその一部が甲3契約において原告が担保責任に基づき行う作業であったことがうかがわれるが,その全てが被告主張の無償を前提とした委託に基づく作業であったと認めるべき証拠はない


として,「相当額の報酬を請求できる」とした。問題は,書面での合意がない中で,「相当額」の認定である。ここは非常にざっくりとしていて,平成17年1月から3月までの3ヶ月間の準委任契約に基づく報酬が6000万円であったから,4月から9月までの6ヶ月間の報酬は1億2000万円だとした。


★争点3(Yに生じた損害)

Yは反訴として,ユーザであるA大との関係で生じた損害賠償金などを,本件トラブルによって生じた損害であるとして,Xに請求した。


結果として,Yの損害として認められたのは,現に損害賠償金として支払った約6億2000万円である。その他の請求のうち,Yの社内の作業費用については,

瑕疵又はXの債務不履行により,Yにおいて新システムの不具合に対応する作業,A大からの要求事項に無償で対応する作業が生じているものといえる。しかし,Yが行った作業には,上記瑕疵及び債務不履行により生じた作業に加えて,Xの請負の対象に含まれていなかった運用管理に属するものや瑕疵とまではいえないトラブルに対応するものが含まれており,いずれの作業が上記瑕疵及び債務不履行によるものであるか明らかでない。
したがって,かかるY主張の作業が,上記瑕疵及び債務不履行によって生じた損害と認めるべき証拠はない。

として否定している。


結果的に,XからYに対する本訴請求は,追加の半年分1億2000万円について認め,YからXに対する反訴請求は,6億強の損害額を認めた上で,未払いの報酬残額(本訴請求とは別)を控除した約4億6000万円について認めた。

若干のコメント

この事例では,システム開発紛争でしばしば争点となる問題が多く含まれていました。


1点目の「システムの完成」。これが争われる事例は少なくないです。裁判実務的な話になりますが,請負契約における「仕事の完成」は規範的要件であり,その評価根拠事実として「最後の工程が終えていること」さらには「ユーザがシステムを使っていること(本番稼動したこと)」という事実の主張がなされるのが一般的です。ユーザが別のベンダに依頼してシステムの作り直しを進めているという事実は評価障害事実といえるかもしれません。また,単に「バグがある」というのは,評価障害事実にはならないと考えておいた方がよいでしょう。


2点目に,「瑕疵」とは何かという論点。裁判実務では,軽微なバグは法的評価における「瑕疵」とは認めないことはほぼ定着しています。なお,仕様書との不一致に限らず,本件のように排他制御ができていないなど,システムの目的に照らして基本的な機能について実現されていない場合には,瑕疵と認められることは十分あり得ます。


3点目の,追加報酬請求。もともとの合意に含まれた作業以外の範囲の作業を行った場合,どのような根拠に基づいて報酬を請求するのかというのは非常に難しい問題です。一つには,「黙示の合意」による契約成立を主張する方法がありますが,大型の取引の場合,書面によらない合意の立証は難しいというべきでしょう。その場合,商法512条の

商人がその営業の範囲内において他人のために行為をしたときは,相当な報酬を請求することができる。

という規定に基づいて「相当な報酬」を請求することになりますが,これもまた何が「相当か」というのが難しいです。本件では比較的シンプルに作業期間に基づいて算定していますが,その他に,ステップ数(東京地判14.8.29),プログラム本数(東京地判平17.4.22)などで判断したケースがあります。


4点目の損害の範囲。しばしばこうしたトラブルにおいては,ユーザ側が「バグ対応のために従業員が○日稼働した。その費用を賠償請求したい。」と主張することがあります。しかし,本件でも,認められなかったように,具体的な損失と,ベンダ側の過失との因果関係の立証が難しく,簡単には認められないことにも留意する必要があります。

*1:古くは建築請負工事についてこの基準が用いられている。