システムのソフトウェア開発やアプリ開発で紛争になる法律的問題点をIT弁護士が解説

システム開発・アプリ開発は紛争の宝庫

我々、グローウィル国際法律事務所は、IT企業専門の法律事務所ですが、相談として多いのが、システム開発・アプリ開発の紛争です。1年間の相談件数は、毎年100件を超えていて、毎年増えている印象です。

今回は、システム開発・アプリ開発紛争についての法律的な問題点及びその解決策を解説していきます。

システム開発・アプリ開発におけるトラブルの原因は様々ですが、共通しているのは、ベンダ側とユーザ側のコミュニケーションミスです。

ベンダ側とユーザ側では、システム制作・アプリ制作についての知識に差があります。そのため「ベンダ側とすれば、こう思っていた」「ユーザ側とすれば、こう思っていた」ということにズレがあり、最終的に紛争に発展していくのです。

RFP（提案書）に法律的な拘束力はある？

システム開発・アプリ開発では、RFP（Request for Proposal)をユーザ側が提示することがあります。

REPとは「このようなシステムを提案してくれませんか」とユーザが、ベンダに依頼するための文書です。

ここで問題となるのは、REPの内容は、法的拘束力があるのかという点。具体的には、REPの仕様、機能、構成、画面、開発手法が実際のものと異なるという場合に、ベンダ側に修正などを求められるのか、又はベンダーに責任を追求できるのか、といった点が問題になります。

REPがシステム開発契約書と一体となっているのか

これまでの判例の流れからすると、REP単独では、法的効力を認めることは難しいです。

これは、システム開発では、REPは最初の段階で示されるもので、そこから交渉が始まり、契約に至るので、REPの段階では、両者の合意が取れていないのが、その理由です。

しかし、東京地裁平成１６年３月１０日判決では、以下のことからREPの法的効力を認めました。

ベンダー企業は、本件電算システム開発契約の締結に当たり、ユーザ企業と契約書を取り交わしている上、契約締結に先立ち、本件電算システム提案書を提出し、その内容に基づくシステム開発を提案し、これを了承したユーザ企業と本件電算システム開発契約を締結したものであるから、本件電算システム提案書は、契約書と一体を成すものと認められる。

この判決では、ベンダ側としては、システム開発契約書とシステム提案書に記載されたシステム構築すべき義務を負っていることになります。

一方で、REPの内容が具体的でないなどの理由で、法的拘束力を否定している裁判例も、多数あります。

RFPの位置づけを明確にする必要がある

ここまでみてきたことからもわかるように、RPFの扱いや位置づけを明確にすることは重要といえます。

では、どのようにRPFの扱いや位置づけたらいいのでしょうか。

ユーザとしてのRPFの位置付け

ユーザとしては、REPの内容について、法的拘束力を持たせたいと思うでしょう。そこで、REPは、システム開発契約書と一体となっていると、評価されることが必要です。

例えば、REPを契約書の別紙として添付するなど、契約書の一体性をはっきりさせることが必要になります。

また、REPの内容が抽象的だと法的拘束力が認められない可能性が高くなります。そこでREPの内容も、できるかぎり具体的にする必要があります。

ベンダーとしてのRPFの位置付け

ベンダー側としては、提案書が法的拘束力を持つかのような誤解を避けたいと思うかもしれません。それで例えば、開発委託契約において、念を入れて、契約締結以前のドキュメントには法的拘束力がない旨の条項を記載するといった方法が考えられます。

ソフトウェア開発、アプリ開発においての「完成」とは

ソフトウェア開発、アプリ開発について、ベンダ側は、納品物を開発して完成させることが必要です。

ですが、ユーザ側に納品したはいいものの、ユーザが完成品であると認めないケースもあります。ユーザ側も「約束したものが出来てない!不具合が多数ある!」と主張したい場合もあるでしょう。

では、納入された成果物にバグなどの不具合があった場合、これが未完成とされてしまうのでしょうか。システムの完成と未完成をどのように判断するのか、みていきましょう。

完成未完成の判断基準

システム、ソフトウェア開発、アプリ開発について、何をもって「完成」といえるのでしょうか。

この点、裁判例では、以下のように判示しています。

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

これは「最終工程基準」と呼ばれ、裁判例では、この基準でシステムが完成しているかしていないかを判断しています。最後の工程まで終えているか否かは、以下の観点から判断することになります。

• 当初の仕様書の記載や議事録、メールのやり取りなどから、どういうシステムの内容の合意があったのか？
• ベンダが作成したものは、上記を満たしているのか？

また、上記裁判例では「注文者（ユーザ側）は、請負人（ベンダ側）が仕事の最後の工程まで終え目的物を引き渡したときには、単に、仕事の目的物に瑕疵があるというだけの理由で請負代金の支払を拒むことはできない。」と述べています。

つまり、ユーザ側としては、ベンダ側が当初の仕様の通りに開発していれば、その後バグがあったとしても、請負代金は支払う必要があるのです。

バグなどの不具合については、ユーザ側は別途、瑕疵担保責任を追及することになります。

完成判断の要素

「最終工程基準」に沿って、システム、ソフトウェア開発、アプリ開発が完成されているかは、当初の仕様書の記載や議事録、メールのやり取りなど様々な証拠から判断する必要があります。

その中で、有力な証拠なるのが、検収の終了です。

システム、ソフトウェア開発、アプリ開発の標準的な工程では、検収の終了により運用に移行するため、検収の終了があった場合には、仕事の完成とみられる有力な事情になります。

検収の終了に際しては、納品書、検収書、テスト仕様書等をユーザ側から出してもらうようにしましょう。

ユーザ側が検収書への署名・押印を拒否する場合

システムの完成の有無が問題となり紛争となるケースでは、ユーザ側が検収書への押印を拒否する場合が少なくありません。

このような場合には、以下のような点を「最終工程基準」の判断要素として考えます。

• 納品済のシステム、アプリをユーザ側が使用している（サービスをリリースしている）
• 保守契約締結の有無
• 納品からどれだけ期間が経過しているか
• マニュアルの制作とユーザによる受領の有無
• 納品からの期間の経過

ソフトウェア開発、アプリ開発で完成後にバグがあった場合

上記のように、ユーザ側としては、ベンダ側が、最後の工程まで終えているのであれば、バグがあったとしても、請負代金は支払う必要があります。

では、ユーザ側として、バグなどの不具合があった場合には、どのような対応ができるのでしょうか。

この場合、当該バグ等の不具合が、法律上の「瑕疵」に該当する場合には、ユーザは、ベンダに「瑕疵担保責任」を追及できます。

ユーザ側としては、以下のような請求をすることができます。

瑕疵修補請求

瑕疵修補請求は、バグなどを修理するように請求する権利です。

損害賠償請求

損害賠償請求は、バグがあることによって、ユーザが被った損害を請求できます。

損害賠償の金額としては、ベンダ側の技術力不足などによりバグが修正できなかった場合に、ユーザが別のベンダに修正を依頼したという場合には、その費用を、ベンダに請求できるということになります。

ここで、注意しなればならないのは、バグがあれば、直ちに損害賠償ができるわけではないということです。特に、システム、ソフトウェア開発、アプリ開発については、バグがあることは不可避です。それは、裁判所なども理解しています。

よって、損害賠償ができる場合というのは、以下のような事情が必要になるのです。

• ベンダ側が瑕疵に速やかに対応しなかった
• 瑕疵が補修不能であった

契約解除

契約解除も、バグがあるからといって、直ちに、ユーザ側が解除できるわけではありません。

法律上は「請負の目的物に瑕疵があり、これによって契約の目的が達成できないときに限り解除」つまり「バグなどの不具合＋契約の目的を達成できない」という事情が必要なのです。

では、どういう場合に、「契約の目的を達成できない」といえるのでしょうか。裁判例では、以下の場合に、解除が認められています。

東京高裁平成26年1月15日判決

• 現行ホストコンピュータの保守期限が９月３０日に満了するはずだった
• 新システムについては再納入後の検収期間終了時である６月１６日時点で補修未了の不具合・障害が３１件
• 補修工数は93.4人日を要する規模
• 新システムの本番稼働までにさらに少なくとも5カ月の導入支援期間が必要
• さらにその先に現行ホストコンピュータとの並行稼働が必要

⇒現行ホストコンピュータの保守期間が、満了後もなお長期間を要する状態になっていたものと認められることから、新システムの瑕疵のために、ソフトウェア開発個別契約をした目的を達することができないと判断されました。

東京地裁平成16年12月22日判決

• 当該システムと同程度のシステムにおける一括在庫引当処理に要する時間がせいぜい数分程度の仕様
• 実際は、当該システムにおいてはテストデータ300件ですら処理時間に44分も要するもの
• 数時間を要する一括在庫引当処理中、他の商品マスタを利用する処理が一切できない
• １人でも商品マスタのメンテナンスを行っていればその間は全く一括在庫引当処理ができない

⇒当該システムが実際の業務において使用に耐えないことが明白であって、およそ契約の内容に適合しないといわざるを得ず、契約の目的を達することができない重大な暇疵に該当することが明らかである、判断しました。

以上のように、バグが当初の仕様とかけ離れているような場合には、「契約の目的を達成できない」とされ、契約解除が認められる可能性があります。

ソフトウェア開発、アプリ開発が途中で終了した場合

ソフトウェア開発、アプリ開発を締結したものの、完成を待たずに、途中で契約がとん挫するケースが多々あります。

途中でとん挫した場合に以下のような主張する場合があります。これらは法律的にはどうなるのでしょうか？

• ユーザ側が、ベンダ側に対し、納期遅延があったので、ユーザー側が契約の解除を通知し、それまでに支払った着手金などの返還を求める
• ベンダ側も納期遅延をしたのは、ユーザー側がたび重なる仕様変更が原因であるとして、報酬残額を支払ってほしい

ベンダ側の義務

ソフトウェア開発、アプリ開発において、ベンダ側は，成果物を完成させる義務を負います。

それにプラスして、システム開発の専門家として、開発で起こる問題点を処理し、適宜ユーザの意見を調整し、開発作業を進行させるという「プロジェクト・マネジメント義務」があるとされているのです。（東京地裁平成16年3月10日判決，東京地裁平成24年3月29日判決）。

よって、ベンダ側としては、ユーザーの意見も聞きつつ、それに振り回されることなく、プロジェクトを推進させる必要があります。

ユーザ側の義務

これに対して、ユーザ側も、ベンダ側に任せっぱなしでいいかというと、そんなことはありません。

先ほどの平成１６年の判決では、システム開発は、ベンダとユーザとの共同作業であるという側面があるためユーザ側にも、システムの開発に向けて，ベンダの作業に協力する義務（協力義務）があるとされています。

ソフトウェア開発、アプリ開発の義務を履行しているか

ソフトウェア開発、アプリ開発が途中でとん挫した場合に、システムが完成しなかったのは，どちらの責任かということが争われることになります。

そうなると、ベンダ側、ユーザー側とも、それぞれの義務を果たしていたのかがポイントになるわけです。このような中、有力な証拠になるのが「議事録」や「やり取りのメール」などです。

特に議事録は、実際の裁判でも、議事録に基づいて当時のプロジェクトの進捗，課題状況，役割分担の実施状況などの事実認定されています。

つまり紛争になる前から、双方の義務履行状況がわかるように議事録をつけておくことが重要になります。

また、取った議事録は、相手方に送付し、間違いがないか確認してもらうとよいでしょう。相手方も、その議事録が間違いないと言った、異議を述べなかったという事情があれば、その議事録の信ぴょう性が増します。

ソフトウェア開発、アプリ開発において、追加費用を請求できるか？

ソフトウェア開発、アプリ開発について、よく問題になるのが「追加費用」に関する問題です。

ベンダ側が、ユーザー側から当初の仕様とは異なる機能の開発依頼があり、これに応じて開発し、追加の費用を請求すると、ユーザー側から断られた。

これに対して、ベンダ側は、「当初の仕様にはないから、追加費用だ」と主張し、ユーザ側は、「当初の仕様の範囲内だ」と主張して、トラブルになるのが一般的です。

このような「追加費用」をめぐる争いについては、法律上、どうなるのでしょうか。

追加費用の請求が認められない場合

例えば、ベンダ側の見積りの誤りがあり、想定以上に工数がかかってしまったというような場合には、追加請求できる余地はありません。

また、ベンダ側から、「当初の報酬の範囲内で、この機能を追加して」と言われ、ユーザ側も「いいですよ」と応じている場合には、追加費用をするのは、難しいでしょう。

追加費用の請求が認められる場合

裁判例で実際にあった事例として、機能数などに基づいて報酬額が算定されていて、その根拠となる機能数に変動が生じ、そのことをユーザも認識していた場合には、追加請求が認められた事例があります（東京地裁平成17年4月22日判決）。

また、もともとの開発範囲が明確になっていて、その範囲を超えた作業であることが明らかである場合にも認められる可能性が高いといえます。

追加機能について明確な約束がなくても報酬請求できるのか

通常は「この仕様を、この金額で完成させます」という合意（契約）がないと、ベンダ企業は、ユーザ企業に請求できません。

しかし、このような明確な合意がない場合もあります。このような場合でも、請求できる法律があります。それが、商法512条です。商法512条は、以下のとおり規定しています。

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

ここで問題になるのは「相当な報酬」とは、どの程度の請求ができるかということです。過去の裁判例では、以下のような算出がされています。

• 「１人日当たりの作業可能ステップ数」から、追加開発部分が何人日の作業であるのかを算出（平成１１年大阪地裁判決）
• システムのプログラム１本当たりの単価に追加開発したプログラム数を乗じて算出（平成１４年東京地裁判決）
• ３か月間における作業の対価を基準として、追加開発に要した期間から算出（平成１８年東京地裁判決）

以上のように、裁判所としては、システム開発の報酬の大部分が、エンジニアの人件費であり、その人件費は、開発するシステムの分量によって増加するという考え方を取っています。

つまり、ベンダ企業の作業量に応じた報酬を認めています。

ソフトウェア開発やアプリ開発の損害賠償は、どの範囲で認められるの？

例えば、ベンダ側に契約違反をした場合には、ユーザ側としては、どのような損害賠償を提起できるのでしょうか。もちろん、個別の判断にはなるのですが、可能性があるのは、以下の通りです。

1. システム開発契約に基づいて、ベンダに支払った開発費用
2. システム開発契約のために、支払った人件費
3. システム開発のために外注した場合には、その外注費
4. システム開発のための回線費用
5. システム開発のために発生した出張旅費
6. システム導入に当たって実施した社員研修費用

この中で、裁判上争いになるのが「２ システム開発契約のために、支払った人件費」です。

ユーザ側の人件費も、損害賠償の対象になるの？

ユーザ側の人件費ですが、典型的には、対応した従業員の給料などです。しかし、これをベンダ側に請求するには、以下のような問題点があります。

1. ユーザ側の担当者は、当該システム開発の業務だけを行っているわけではない。他の業務も行っているのであり、どの程度の時間を、当該システム開発の業務に費やしていたのか立証が難しい
2. 人件費は、雇用契約や委託契約によって、最初から支払うことが予定されており、ベンダの責任によって発生したものではない

このように、ユーザ側から人件費を損害賠償として請求する場合には、当該システム開発のために、人件費が余計にかかったということを立証できないといけないのです。

よって、当該システム開発によって、従業員が余計な作業をしないといけなかった場合でも、その人件費全額を損害賠償請求することは、難しいといえます。

裁判例でも、ユーザ側が主張する人件費全額については、認められないことが多いのが実情です。

システム開発トラブルによる損害といえるかがポイント

以上のように、ユーザとしては人件費を請求するためには、「当該システム開発トラブルによって、発生した」と主張立証できるかにかかってきます。

反対に、ベンダ側としては、ユーザ側の人件費は「当該システム開発によって発生したものではない」ということを主張していくことになるのです。

ソフトウェア開発、アプリ開発訴訟の現状

様々なシステム開発やソフトウェア開発、アプリ開発上のトラブル事例を見てきましたが、お互いの話し合いでまとまらなければ、最終的には訴訟という形になります。

訴訟になった場合、システム開発の紛争は、どのように進んでいくのかを最後に紹介します。

システム開発訴訟は、膨大な証拠が提出される

システム開発のトラブルは、その多くが契約当初、お互いにどういう合意があったのかがポイントになることが多いです。

そうすると、提案書や契約書などのほか、仕様書、議事録、メールなどの大量の証拠が提出されることになります。そして、このときに証拠として何を提出するかによって、勝敗が決することも、多いのです。

ここは、債権回収や一般の民事事件とは違って、専門的な知見が必要になります。

システム開発訴訟は長期化傾向

このように、大量の証拠が提出されることが多いので、その分、審理が長期化する可能性があります。

例えば、スルガ銀行とIBMのシステム開発訴訟では、訴訟の提起から４年たって一審判決が出ました。

この事件は、争いになっている金額が数百万円規模の事案なので、かなり長期化していますが、通常のシステム開発訴訟でも、１～２年程度の期間が必要になることが多いのです。

ITについては素人の裁判官に理解してもらうことが最優先

システム開発訴訟で難しいのは、システムの内容を裁判官にわかってもらうこと。裁判官は法律の専門家ですが、ITについては全くの素人です。

しかし、判決をするのは、裁判官なので、ITやシステムについて、裁判官にも分かるように説明しないといけません。

一番困るのは、システム開発どころか、インターネットを使ったことがないのではないかと思われる年配の裁判官に当たったとき。裁判官から「サーバーって、なんですか？」と聞かれたときは、冷や汗が出たことを覚えています。

しかし「裁判官がＩＴが分からない」と文句を言っても、始まりません。そんな裁判官を説得するのも、弁護士の役割です。システムについて理解し、それを素人である裁判官にも理解してもらい、適切な証拠を出すということが求められているのです。

また、裁判官の手に負えない事件は「専門委員」という人に加わってもらうことがあります。

これは、システム開発訴訟であれば、ベンダ出身者などの専門知識がある人が、裁判所から任命されて、裁判官をフォローする役目を担います。

専門委員の方は、専門化だけあって、ITやシステム開発の知識があります。

それゆえ、弁護士としても、当然、ITやシステム開発に関する知識がないと専門委員の方が求められているものを提示できないことになります。そうなってしまうと、勝てる裁判も勝てないという最悪の事態になるのです。

以上のようにシステム開発訴訟は、通常の訴訟とは違った側面があります。法律の知識とＩＴの知識を駆使した総合格闘技なのです！

システム開発やソフトウェア開発、アプリ開発の法律に強い法律事務所　グローウィル国際法律事務所

システム開発のご相談　年間１００件以上の実績

グローウィル国際法律事務所では、システム開発の法律相談を多数受けており、その数は、年間１００件以上になります。

システム開発の訴訟も、２００件以上を受任しております。

グローウィル国際法律事務所の代表弁護士である中野は、元々ＩＴ企業を経営しており、エンジニアの経験もあるので、ＩＴ×法律のことは熟知しておりますので、安心してご相談ください。

お問い合わせ