ＵＳＬＦでは、ＩＴ企業の法律相談を行っています。

理系出身で、かつ企業の技術畑で勤務した経験を持つ弁護士や大企業での知財部経験を有する弁護士が事件に応じて対応致します。

システム・ソフトウエア企業については，代金回収や瑕疵担保責任に関する紛争など多く経験しており，弊所の業務は知財にとどまりません

１．まずはしっかりとヒアリングさせていただきます。

法律相談では、まず始めにご相談内容について丁寧にお話を伺わせていただきます。
詳しい事情をお伺いしながら、お客様の状況やご要望に合った提案させていただきます。

初回のご相談は原則として無料です。
ただし、そのご相談だけで一定の解決が図れてしまったなど、ご相談の目的を達成してしまった場合は1時間あたり2万円程度のご相談料をいただいております。

２． 今後の方向性を明確に致します。

御社にとって最善の方法をご提案させていただきます。
当事務所が問題解決に貢献できる場合は、明確なサポート内容と費用を明示して、ご提案させていただきます。
費用は、タイムチャージ（時間・人あたりのチャージ）もしくはお見積もりベース（着手・報酬金）のいずれかの方式でご提案することがあります。

契約解除に相当する瑕疵

バックナンバー

～　名古屋地裁平成16年1月28日判決（判例タイムズ1194号198頁）　～
「契約が成立したというためには」では，契約が成立しないまま開発作業に着手することの危険性を指摘しました。
ここでは，上記リンク先で紹介した裁判例をもう少し詳しく紹介します。

事案の概要

地方自治体Ｘは，ベンダＹに対し，財務会計システム等の導入を委託し，Ｙはパッケージソフトを利用しながら，住民記録システムや，人事・給与システムなどを順次導入していきました。 しかし，税務システムの導入にあたり，パッケージソフトのカスタマイズ項目が決まらず，予定していた稼動開始時期を大幅に遅れる見込みになり，結局Ｘは断念してしまいました。 そこで，Ｘは，Ｙに対し，税務システムを含めたシステム全体の基本契約が締結されていたことを前提に，この基本契約の履行不能を理由に2億円以上の損害賠償を求めました。 （Ｙからの反訴もありますが，ここでは割愛します。）

争点

本件には，多数の争点が存在しますが，ここでは，Ｘのいう「基本契約」が成立したか，という争点に絞ってみていきます。

判決の要旨

裁判所は，請負契約成立の一般論として， 

業務用コンピューターソフトの作成やカスタマイズを目的とする請負契約は，業者とユーザー間の仕様確認等を経て，業者から仕様書及び見積書が提示され，これをユーザーが承認して発注することにより相互の債権債務の内容が確定したところで成立するにいたるのが通常であると考えられる。

としました。続いて，本件では，

•Ｘより，「総合行政情報システム導入に関する提案書の提出について」という，いわゆるRFPが出された
•Ｙより，それに応える形で「御提案書」が提出された
•Ｘより，Ｙの提案を採用する旨の通知が送付された

という事情を認めたものの， 

（Ｙの提案書は）ＹにおいてＸの業務内容等を十分に検討した上で作成されたものとは認められない上，その内容は必ずしも具体的でなく，Ｘらの要望に即した形でＹおよびその提供するシステム等の概要及び長所を紹介したものとの域を出ない

と判断しました。
Ｙから送られた採用通知の意味づけとしても， 

今後本件総合システムの導入を委託する業者として交渉していく相手方をＹに決定したことを意味するにとどまる

としました。結局，基本契約の成立については， 

以上によると，本件においては，ＸとＹとの間で，個別のシステム又はプログラム等につき，仕様確認等の交渉を経て，カスタマイズの有無，カスタマイズの範囲及び費用等につき合意がされた時点で，契約が成立することが予定されていた

として，認めませんでした。

コメント 

Ｘは，ベンダからの提案書および，それに対する採用通知という書面の存在をもって契約の成立を立証しようとしましたが，認められませんでした。
本件では，契約が成立しなかったことによって，ユーザ側に不利な判断が下されたわけですが，逆に，プロジェクトが途中で頓挫したときに，それまでの費用をベンダが請求したい，というケースでは，ベンダに不利に作用することもありえます。
したがって，契約が成立しないままプロジェクトを進めることは，過去の裁判例からみても，ベンダ・ユーザ双方にとって大きなリスクとなるといえるでしょう。

しかし，本件のようなパッケージソフトのカスタマイズを伴うケースで，カスタマイズの範囲を決めるまで契約の範囲が決まらない，ということになってしまうと，カスタマイズ範囲を決める作業（いわゆるFit & Gap分析）は，ベンダがすべて無償で行わなければならないのか，ということになってしまって不合理です。
そこで，パッケージ選定フェーズ，Fit & Gap分析フェーズ，カスタマイズフェーズ，というように，段階的に契約を区切っていくということが必要になります。前二者のフェーズについては，事の性質上，準委任契約，後者については請負契約とするのが一般的でしょう。

このように，プロジェクトの性質に応じて，契約の切り方，締結タイミング，内容は異なるといえます。
契約書のレビューの部分のみを弁護士に委託するだけでは不十分であり，プロジェクトの性質に応じた契約全体のスキームを弁護士に相談することも重要でしょう。

課題

ケース

損害賠償額の事前の定めは許されない

退職後も義務が存続するようにする

労働組合との協議・通知を怠らない

派遣社員からの誓約書提出にも注意が必要

ケース［一部修正］

ポイント　特許権の侵害や，著作物性が認められにくい場合でも，不正競争防止法による保護を受けられる可能性はある

営業秘密とは

ポイント 　流出しては困る情報は，適切な管理体制を構築し，適切に運用しなければならない

課題

ケース 

ポイント　ライセンサが破産すると権利関係が不安定になる。できるだけ早めに行動する

ケース［再掲］ ‐ 一部修正

このケースのような場合にＡ社には，どのような損害が発生するのでしょうか。

損害と一口にいっても，さまざまなものがあります。ここでは，以下の２つについて考えてみることにします。

１．漏えい事故の被害者となった個人からの慰謝料請求
２．被害者となった個人への金券等の交付

１．漏えい事故の被害者となった個人からの慰謝料請求

慰謝料の額はどのように決定されるのでしょうか。
個人情報保護法施行前の事例ですが，エステ会社TBCの顧客情報が漏えいした事件（注１）では，一人あたり3万円，ネット接続事業会社のYahooBBの事件（注２）では，一人あたり5千円という判断が出ています。

これらの事例は，どちらも個人情報が漏えいしたという点で共通しますが，(1)漏えいした情報の性質，(2)二次被害の有無といった点が慰謝料額の違いに反映されたと考えられます。
すなわち，(1)について，TBC事件では，エステティックサロンの会員であるという情報ですから，一般的にみて「他人に知られたくない」情報だといえるのに対し，YahooBB事件では，氏名等の識別情報にすぎないため，比較的秘匿する必要性は低くなると考えられます。
また，(2)について，TBC事件では，実際に迷惑メールやいたずら電話などの二次被害に遭った方がいたのに対し，(2)では具体的にそのような事実は見当たらなかったようです。これらの要素が裁判所による慰謝料算定に影響しそうです。
特に，(1)については，健康に関する情報，宗教・思想に関する情報，クレジットカード等の財産に関する情報が漏えいした場合には，慰謝料が高くなるものと思われます。

また，上記の２つの事例では，(3)情報流出原因や経緯，(4)事故後の対応についても検討されていました。
(3)については，管理体制の問題が大きい場合や，(4)について，事故後に十分な対策を立てていない場合などには，慰謝料が増す可能性があります。

２．被害者となった個人への金券等の交付

裁判によって慰謝料が認められるとしても，事業者は訴えた人（原告）に対してのみ，支払義務を負い，その他の被害者に対する支払義務は生じません。ただし，企業の社会的責任の一つとして，被害者に対して公平な対応を取ることが求められるといえるでしょう。

ただし，上記の裁判例のような額と同額を支払わなければならないか，というと難しい問題です。
具体的な基準はありませんが，YahooBB事件では，会員一人あたり500円を支払ったといわれています。会員が600万人いたようなので，総額30億円程度の損害が発生したものと思われます。
 

（注１）	東京地裁平成１９年２月８日判決
（注２）	大阪地裁平成１８年５月１９日判決

課題

システム開発の途中でユーザから契約が解除されるとどうなるのか？

ケース

システム開発業務委託契約が解除されると，報酬の一部が内金として支払われていた場合には，ベンダは利息付で返還しなければなりません。その場合，ユーザの下にあるドキュメントやプログラムの一部を返還するよう求めることができますが，当然，報酬を請求することはできません。

さらには，契約解除によってユーザに生じた損害を賠償しなければならない場合もあります。
ベンダにしてみれば，それまで投下したエンジニアの費用や，外部に委託した費用を回収できないばかりか，損害賠償まで請求されては，まさに踏んだり蹴ったりの可能性があるわけです。

しかし，契約はユーザから一方的に解除できるわけではありません。
ユーザからシステム開発業務委託契約を解除できるのは，以下の４つのケースが考えられます。

１．契約書に記載された解除事由に該当する場合
２．ベンダに債務不履行（納期遅延や完成不能）がある場合
３．ユーザが損害を賠償して解除する場合
４．完成したシステムに重大な不具合がある場合

ここでは，契約書には書かれていないケースとして，２（ベンダの債務不履行）を取り上げます。

２のケースの典型例は，ベンダが期限までに成果物を納入しない場合（履行遅滞といいます。）や，何らかの理由でシステムを完成させることができなくなった場合が挙げられます。いずれの場合も，ベンダ側にその原因（帰責事由といいます。）がある場合でなければなりません。

システム開発業務委託契約におけるベンダの義務は，システムを完成させることにありますが，それが達成できなかった原因を探ると，プロジェクトマネジメントが不十分であった，というところにたどり着くことが多いようです。
プロジェクトマネジメント義務を果たす責任は，ベンダ，ユーザのどちらにあるのかが問題になりますが，過去の裁判例では，契約書に特別の定めがなくとも，第一義的にはベンダがプロジェクトマネジメント義務を負うと判断しています（下記参照）。

「（ベンダは）常に進捗を管理し，開発作業を阻害する要因の発見に務め，これに適切に対処すべき義務を負う。」                                                                          　　　　　  （東京地裁平成16年3月10日判決）

このような判断の根底にあるのは，ベンダとユーザとでは，システム開発に対する専門的知識，経験に大きな差があるから，専門家であるベンダが適切にリードしなければならない，という考え方でしょう。

ポイント１ 　ベンダは，プロジェクトマネジメント義務を果たさないと，契約が解除されたり，損害賠償責任を負ったりする可能性がある

しかし，現実のプロジェクトでは，プロジェクト遅延の責任が常にベンダにあるともいえません。システム開発においては，ベンダとユーザが互いに協力し合わないと，前に進まないのは明らかです。
そこで，上記の裁判例では，ユーザについても，

「システム開発のために必要な協力をベンダから求められた場合，これに応じて必要な協力を行うべき契約上の義務を負っていた。」

と判断しています。ですから，ユーザ側にも責任があると判断されれば，解除が無効とされ，逆にユーザが損害賠償責任を負う場合も考えられます。そこまでいかなくとも，「過失相殺」という規定により，損害賠償額が減額されることは十分あり得ます。

ただし，紛争に発展した段階で「プロジェクトマネジメント義務」を果たしていたことを証明するのは容易ではありません。そこで，普段から議事録，課題管理の記録を残すことが求められます。言うまでもなく，これらの記録を残すことは，紛争回避という後ろ向きの理由に限られず，プロジェクトの円滑な推進にも貢献するのではないでしょうか。

ポイント２ 　紛争回避，解決の観点からも，ベンダとユーザ間のやり取りを記録に残すことが望まれる

しかし，現実にプロジェクトマネジメント義務を怠ったかどうか，プロジェクト遅延の責任はベンダにあるか，などは容易に判断できません。
ユーザが契約を解除したい場面においては，これらの判断を誤ると，解除の意思表示は無効とされ，逆にベンダから損害賠償を請求されることもあり得ます。
また，解除を通知された場合も，解除の有効性いかんによってその後の対応が変わります。
したがって，紛争を回避するためにも，プロジェクトの大幅な遅延などが生じた場合には，今後の対応について弁護士に相談すべきでしょう。