アホヲタ元法学部生の日常

アニメを見て法律を思い、法律を見てアニメを思う法アニクラスタ、ronnorのブログ。頻繁にツイッター(@ahowota)に出没しております。メールはronnor1あっとgmail.comへ。BLJにて「企業法務系ブロガー」として書評連載中。 #新人法務パーソンへ #オタク流勉強法 #明認方法 「アホヲタ元法学部生の日常」(ブログ)、「これからの契約の話をしよう」(同人誌)、『アニメキャラが行列を作る法律相談所』(総合科学出版)等。

判例に学ぶ、納期遅延と瑕疵担保責任についての注意事項〜エンジニアへの法的知識の伝え方

瑕疵担保責任と債務不履行責任

瑕疵担保責任と債務不履行責任

本エントリは、あくまでもエンジニアの皆様にシステム開発訴訟に関する正確な知識を分かり易く知って欲しいという一心で作成したものであります。「特定のセミナー」とは「一切」関係ございませんのでご了承下さい。


1.法律とITの架橋
 法律家とエンジニアの間には深い溝ないしは高い壁がある。その理由の1つには、エンジニアがまじめに法律を学ぼうとしても、自分の問題意識に対応した、分かり易くかつ正確な説明が提供されることが少ないからという点があるだろう*1。非法務系の方相手に講演(と言う程のたいそうなものではないが)をすることも多く、一応国家資格*2であるプロジェクトマネージャ試験(情報処理技術者試験)に合格し、過去に
非法務系の聴衆に対する研修はどうすればいいのか〜『Web業界受注契約の教科書』の例を通じて - アニメキャラが行列を作る法律相談所withアホヲタ元法学部生の日常
のような記事を書いている立場から、今回は、納期遅延と瑕疵担保責任について裁判例*3から簡単に説明をしたいと考える。


 以下では、東京地方裁判所平成25年11月12日判決(以下、「平成25年判決」という。)と、東京地方裁判所平成9年2月8日判決(以下、「平成9年判決」)について説明する。


2.事案の概要
(1)平成25年判決

 平成25年判決の事案は、システムの受託開発等を目的とするレッドフォックス株式会社(原告)が、Jリーグ向け電子チケットサービス用のシステムを提供していたウェルネット株式会社(被告)から次世代電子チケットプラットフォームと称するシステムを受注し開発したとして、残代金の支払いを求めた事案である*4
 事案を単純化すれば、納期遅延があった事案で、原告が被告に対してシステム開発にかかる残代金の支払いを求め、被告が、納期遅延と瑕疵によって損害を被ったとして、その分を差し引く(相殺)と支払うべき報酬はないと反論したものである。裁判所は、525万円の請求額のうち、約321万円については被告が支払うべきであるが、約204万円については相殺を認めて支払いは不要とした。要するに、納期遅延及びシステムの問題があったとして、被告に対し、報酬のうち一部を差し引いて払うように命じたのだ。


 概ねの時系列表はこうなる。

平成21年9月17日 原告・被告間でソフトウェア開発基本契約締結
同月28日 要件確認・機能詳細化に関する個別契約締結
同年11月13日 基本設計・詳細設計に関する個別契約締結
同年12月25日 詳細設計・プログラム作成・テストに関する個別契約(本契約)締結
平成22年6月30日 納期として予定されていた5月31日まで納入できないので、納期を9月30日に伸ばす覚書(本件覚書)締結
同年11月30日 成果物の納入
同年12月14日 この日までの間に被告は検査を行い、不具合等を指摘
平成23年1月27日 原告が修補後の成果物を再納入
同年末 原告が被告に対し残代金を求めて提訴
平成24年8月10日 第一回弁論準備手続
平成25年11月12日 判決


 提訴から一審判決まで約2年間という期間は長いように見えるが、複雑で長期化しがちなシステム開発訴訟では十分にあり得る範囲であろう。当事者、代理人弁護士、そして裁判官*5も、通常のシステム開発訴訟並に苦労したものと思われる。


(2)平成9年判決*6
 もう1つの事案は、システム開発訴訟について、弁護士の間でも裁判官の間でもまだ知見が蓄積されていなかった平成4年に提訴された事件である。提訴から、一審判決まで足掛け5年の超長期訴訟になった。相互に訴訟を起こしていたり、間に商社がからんでいるのでわかりにくいが、要するに、貨物自動車運送業を行うユーザー(ダイセーロジスティクス株式会社)が、商社を通じてベンダー(エヌエスアンドアイ・システムサービス株式会社)に運送システム関連ソフト、給与計算ソフト、財務会計ソフトの各ソフトウエアの開発を委託した事案である。納品されたシステムに不具合があったとして、ユーザーはベンダー(正確に言うと商社)に損害賠償を求め、ベンダーはユーザーに対して仕様変更分等の未払い代金の支払いを求め、それぞれ提訴した。裁判所は、バグが一部存在するが、これは瑕疵に該当するものではないとして、ベンダーを勝たせた。


 概ねの時系列表はこうなる。

昭和63年12月 ソフトウェア開発委託
平成2年2月 テスト稼働開始*7
その後 仕様変更・機能追加等を行い、それぞれ納品がなされる
平成4年3月13日 ベンダーがユーザーにプログラムの再設計・再製作を申し入れる
同年6月23日 ユーザーがベンダーに対し解除通知
同年8月20日 ユーザーがベンダー(正確には商社)を提訴
平成5年 ベンダーがユーザーを提訴
平成6年7月〜8月 検証実験を実施し、実験記録として、三者共通の書面にまとめる
平成7年6月〜7月 検証実験の結果明らかになった問題点について原因解明作業を実施
平成9年2月18日 判決


 本判決では、検証実験及び原因解明作業により「コンピュータープログラムについて専門の知識を有しない裁判官であっても判断が可能な程度にまで争点の整理がなされ、後は健全な常識に基づく判断を残すのみとなり、審理の見通しが明瞭に立つこととなった」とされており、この作業が賞賛されている。その背景には、鑑定人*8を選任する手続で両当事者が対立したことがあると説明されている。
 システムの現況と不具合事象の原因の究明は当時だけではなく現在も行われる。但し、両当事者が長期に渡って訴訟外で共同作業を進めるというよりも、例えば、「説明会方式」といって各当事者がシステムをラウンドテーブル法廷や調停室に持ち込んで実演をする期日を設けるとか、一方当事者の作成した不具合事象原因究明報告書のようなものを提出する等、より簡易な方法を採用することが多いと思われる*9


3.納期遅延
 平成25年判決で大きな問題となったのは納期遅延である。確定的期日を納期として合意していた場合、その日までにベンダーが納入できなければ、原則として債務不履行履行遅滞)の責任を負う
 但し、システム開発では純粋にベンダー側だけの原因で納期遅延になる場合だけではなく、ユーザー側の責任で納期遅延になることも少なくない。例えば「予定日までに仕様が固まらない」「仕様変更が入る」等々である。
 ベンダー仮に納期遅延を起こしたとしても、その原因がユーザー側にあり、ベンダーの責任ではないことをベンダー側が立証できれば、ベンダーは債務不履行による損害賠償等の責任を免れることができる*10


(1)覚書の「罠」
 平成25年判決でも、原告は仕様確定の遅延や度重なる仕様変更、設計変更、契約外の要求等があったと主張し、履行遅延は被告の責任で発生したと主張した。但し、上記の時系列表にあるとおり、平成22年6月30日に納期を延長する覚書が締結されていた。裁判所は、この覚書の趣旨を、それまでに被告側の仕様確定の遅延や度重なる仕様変更、設計変更の要請があったことから、両当事者は当初の期日までに納入が難しいことを認識し、そのような仕様変更等を前提として納品可能な日時を改めて合意したものと理解した*11。その結果、覚書締結以前に発生した仕様変更等があっても、原告が覚書で合意された納期(9月30日)の納入ができないことを正当化しないと判断されたのである。


 実際のプロジェクトでは、「納期」は「お客様」の都合で一方的に指定されることが多く、もしかすると、平成25年判決の原告は、覚書について「取りあえず伸ばすことに合意してもらったが、『お客様』側の都合で相当の遅延が生じており、実際に9月30日までに完成させるのは難しいだろう。そうはいっても、遅延は『お客様』の都合によるものだから、よもや債務不履行責任を問われることはないだろう。」といった認識でいたのかもしれない。


 平成25年判決の実務的意義は「裁判所にはそのような甘い考えは通じない」ということであり、遅延が生じた後、納期を伸ばす合意をする場合には、ベンダーとしては、「既に生じた遅延の原因(仕様変更等)に鑑みて、この日までなら確実に納入できる」という日を合意しなければ、ある意味予想外の債務不履行責任を負わせられるのであって、注意が必要である。


(2)プロジェクトマネジメント義務
 なお、一点誤解がないように本判決の内容について説明しておくと、本判決は、受託者(ベンダー)である原告が仕様を確定しないといけないとは言っていない。(注文者の求める仕様通りのシステムを構築するのが「受託者」なのだから、当たり前である。)むしろ、仕様確定は注文者(ユーザー)の義務であり、本判決は、「被告は、システムの設計・開発業務の注文者として、本件システムの仕様を最終的に決定する義務を負っていた」と明確に判示している。


 このように言うと、仕様をいつ確定するかは全部被告側の責任で、原告はただ待っているだけいいのかというと、そうではない。受託者である原告はプロジェクトマネジメント義務を負うのである*12。その中身として、様々なものが挙げられるが*13その重要なものとして進捗管理義務がある。スケジュールの遅れを防ぐため、注文者側(ユーザー)の作業であっても、受託者(ベンダー)がきちんとスケジュールに間に合うよう話し合い、助言をしなければならない*14


 本件では9月30日という納期に間に合わないことが見込まれるのに、「納期の見直しを要望し、あるいは各仕様の項目にこれ以上の変更追加がないかを積極的に確認していた事実などは認められない」とされており、プロジェクトマネジメント義務が履行されていないことから、この点においても、納期遅延は原告(受託者)の責任であるとされた。


(3)口頭のやり取りは証拠化が鍵
 ここで、11月4日に原告・被告の代表者間の協議が行われ、原告(受託者)は、被告(注文者)の代表者のその場での発言を根拠に、納期を遅らせる旨の合意があったと主張した。しかし裁判所はそのような合意を認めなかった。
 そもそも、口頭のやり取りの場合、

・そもそもその発言がされたのか
・それがどのような文脈の下でされたのか
・それがどのような意味を持つものとしてされたのか

等が後で問題となることが多い。議事録を取って相手に確認をしてもらう*15等の証拠化が重要だろう


なお、既に和解済みの事案であるが、訴訟になってからユーザーから「(ベンダーの)発言は全部(秘密裏に)録音していた」と主張された事案に接した事がある。


4.不具合
(1)「瑕疵」とは何か
 およそバグがないシステムは存在しない。ここで、バグ等による不具合が発生した場合、ユーザーはこれを問題視することが多く、場合によってはベンダーに損害賠償を請求することもある。
 しかし、システムに瑕疵があってはじめてベンダーは責任を負うのである。瑕疵とは、システムが約束した仕様・性能に仕上がっていないことをいうが、簡単に直せる程度のバグが混入していても、それが軽微なものであれば、ベンダーに修補させればいいのであり、これを瑕疵としてベンダーの法的責任を追及すべきではない。平成5年判決はこのように判示する。

プログラム納入者が不具合発生の指摘を受けた後、遅滞なく補修を終え、又はユーザーと協議の上相当と認める代替措置を講じたときは、右バグの存在をもってプログラムの欠陥(瑕疵)と評価することはできないものというべきである。これに対して、バグといえども、システムの機能に軽微とはいえない支障を生じさせる上、遅滞なく補修することができないものであり、又はその数が著しく多く、しかも順次発現してシステムの稼働に支障が生じるような場合には、プログラムに欠陥(瑕疵)があるものといわなければならない。

要するに、

「軽微なバグについて指摘を受けてからすぐに対応した場合」には瑕疵にはならない
「重大な不具合(バグ)」又は「なすべき対応をしない場合」には瑕疵になり得る

 という整理をしたのである。平成5年判決の事案では、バグが見つかったが、全て軽微なもので、検証実験後の原因解明作業の中で、半日ないし一日程度の作業により補修を終えた等として瑕疵はないとされた*16。これに対し、平成25年判決では「ログインできないなど、本件システムを稼働する上で障害となる不具合が少なからず存在した」とされており、不具合は重大だと認定されている*17


 ここで留意すべきは、対応義務があるのは「バグ」等の問題がある場合に限られるということである。例えば「仕様通り」の場合については、そもそもユーザーから指摘があっても対応義務はない*18ことである。平成5年判決でも一部の機能(データ削除に関するもの等)は、仕様通りであり、瑕疵ではないとされてる。


 
(2)検収と瑕疵
 では、検収」と「瑕疵」はどのような関係にあるのだろうか。検収は仕事の完成を確認するプロセスを言う。
 請負契約といわれる仕事(プログラム等)の完成を目的とする契約においては、仕事が完成してはじめてベンダーはユーザーに対して報酬等を請求できることになる。不具合があっても、それは瑕疵担保責任の問題であり、もはやユーザーはシステムが「できていない」とは言えなくなる*19。逆にいうと、通常は検収後も瑕疵があれば、ベンダーはそれを修補しなければならない。そこで、平成25年判決は検収期間満了前に指摘がなかった瑕疵についても、ベンダーは修補義務を負うとした。(なお、検収による瑕疵の遮断効を認めると読めるものとして東京地判平成15年5月8日参照。)


 (1)で述べた、バグと瑕疵の話と、(2)で述べる「検収」の話を一緒にまとめると、検収後については、

軽微なバグについては、それが瑕疵にならないようにするためすぐに対応しなければならない
重大な不具合については、瑕疵担保責任の履行(瑕疵修補義務の履行)として対応しなければならない


 ということになる。もちろん、永久に対応が必要なのではなく、例えば半年等*20の瑕疵担保期間に合意しておけば、それ以降については不具合が指摘されてもベンダーは瑕疵の責任を負わないことになる。


まとめ
 エンジニアが忙しい中、わずかな休暇時間を削って、しかも身銭まで切ってセミナーに参加した結果、もしも仮に誤った説明しか受けられないとすれば、それは大変不幸なことである。
 もし、私が「三題噺」として「エンジニア向け」「平成25年判決」「平成9年判決」というお題が与えられたセミナーの講師になったら何を話すかということで簡単なレジュメを作ってみた。エンジニアの方には法律に関する「正確」な知識を習得して、実務に生かしてもらいたいものである。


参考:
スルガ銀行対IBM事件控訴審判決(東京高判平成25年9月26日) - アニメキャラが行列を作る法律相談所withアホヲタ元法学部生の日常
IBM対スルガ銀行事件判決評釈(東京地判平成24年3月29日第一法規判例体系) - アニメキャラが行列を作る法律相談所withアホヲタ元法学部生の日常

*1:この点について、システムに関しては「99%の弁護士は素人」と説明されることがあるが、そもそもほとんどの弁護士はそもそもシステム開発訴訟に関与しないのであり、少なくともベンダー側の代理人として出てこられる先生方は知識と経験がある方が多い。もちろん、ユーザー側の代理人として「素人」と評さざるを得ない先生が出て来る可能性があるが、ユーザー側でも専門の弁護士を選ぶことが増えてきているし、また、ユーザーの顧問弁護士なのによくシステム開発について勉強していらっしゃる先生もいらっしゃるので、少なくとも「システム開発訴訟の代理人」の中で素人が占める割合が99%なんかになることはおよそあり得ないだろう。なお、従来裁判官の方はシステム開発について知識がない方も多かったが、最近では裁判所内で勉強会を開催する等して知識を貯えつつある。

*2:経済産業大臣にご認定頂いております。

*3:なお、これはこの分野の法律を少し勉強した者にとって「常識」であるが、最高裁判所の先例拘束性のある判断という意味での「判例」はシステム開発に関しては存在しない。

*4:なお、当事者名については、別に私が特別な調査をしたのではなく、当事者名は「隠され」ていないので、判例データベース上で簡単に確認できた。

*5:「検察」は含まれない

*6:通常は判決日なので平成9年と略すべきであろう。なお、本判決もいうように、メインは平成4年に提訴された方なのであって、少なくともこれを「平成5年判決」と表現すべきではない。

*7:システムは(ユーザーの意図通りではない部分があるにしても)動いている

*8:「司法委員」ではない

*9:その理由の1つとしては、専門委員、専門家調停委員等の形で専門家の力を借りることが容易になり、これらの実演や報告書を読むことで瑕疵の有無に関する判断をしやすくなったという点があげられるだろう。

*10:なお、ベンダーの帰責性が否定された事案には、東京地判平成15年6月30日や東京地判平成21年3月25日等がある。

*11:「これらの要望を前提に本件覚書を締結し、平成22年9月30日という納期が設定された」とある。

*12:東京地方裁判所平成16年3月10日判決判例タイムズ1211号129頁等参照

*13:合意した開発手順、工程に従って開発作業を進める義務やユーザーによって開発作業を阻害する行為がされることのないよう働きかける義務等も挙げられる事が多い

*14:本判決が「被告から仕様の変更追加の申出があった際に、それによってスケジュールに遅延をもたらす場合にはその旨説明するなどして被告と協議し、その都度納期を見直すなどした上で、最終的に決められた納期に間に合うように仕様を確定させていく義務が原告にあった」というのは、このプロジェクトマネジメント義務の履行のことを言っていると理解される。

*15:少なくともメールで送付する

*16:システムのテスト稼働の約5年後にバグの原因が解明され対応されているので、「すぐに(遅滞なく)」といえるかは問題となり得るが、「本件システムが原告の業務の用に供されていないものであることを合わせ考えると、(エヌエスアンドアイ・システムサービス株式会社)による右補修作業に不相応な遅滞があったものということはできない」とされた。

*17:なお、ログインができない不具合にも、その理由によっては軽微なものもあるとは思われるが、この辺りは判決文だけからはなんとも言いようがない。

*18:「仕様通り」と回答すればよい

*19:なお、「納品から●日以内に異議がなければ検収とみなす」といういわゆる「みなし検収」について、そのような「検収」としての効果以上の効果が期待できるはずがない。

*20:平成25年判決の事案では12ヶ月