- 更新日 2023.12.21
- カテゴリー 業務システム
システム開発訴訟の事例と原因発注側ができる対策方法は?【2024年最新版】
「システム開発を依頼したいけれど、満足できるシステムができるか不安」と悩みを抱えている方は多いです。想定外の不具合が起きやすいシステム開発では、訴訟問題にまで発展してしまうケースもあります。裁判にならないために発注側が気をつけることはあるのでしょうか。
- システム開発の訴訟事例は?
- 訴訟問題に発展しないためにできることは?
- 訴訟トラブルに発展しそうなときはどうすればいい?
今回はシステム開発訴訟の事例と原因について紹介します。開発トラブルを巡って裁判にならないように、発注側ができる対策方法を知っておきましょう。また、訴訟問題に発展しそうな場合の対処法についてもご紹介します。
※システム開発会社選びにお悩みの方はシステム幹事にご相談ください。専任のコンサルタントがあなたに最適な会社をご紹介します。相談料などは一切かかりませんので、お気軽にお問い合わせください。
システム開発における訴訟事例
システム開発トラブルから訴訟に発展しやすい3つのパターンを、実際の訴訟事例からご紹介します。自社の開発に近い場合は特に注意してください。
発注会社が開発に協力せずトラブルになった事例
原告 |
株式会社トクヤマ(発注会社)/総合化学工業メーカー |
---|---|
被告 |
TIS株式会社(開発会社)/システムインテグレーター |
請求内容 |
【本訴】損害賠償請求(約18億円)または原状回復請求(約18億円) 【反訴】委託料支払請求(約2億円)または 相当報酬額支払請求(約2億円) |
判決 |
被告は原告に対し約5億円の支払い、原告は被告に対し約2億円の支払い |
発注会社は開発会社にERP(会計や人事など経営関連情報を一元管理するシステム)システムを中心とする新基幹システムの構築を依頼。しかしシステム導入直前に、発注側の現場部門が新システム導入に強く反発。現場が開発協力を拒否したために、仕様変更へと方針転換することになります。
結果、多数の仕様変更により遅延が起こり、プロジェクトは中断となります。
発注会社は仕様の不適合、プログラム品質の問題、請負契約が成立していることなどを理由に、開発会社に約18億円の支払いを求める訴訟を起こしました。
2016年4月東京地方裁判所は「双方に責任はあるが、発注側内部のユーザーが現場改革の反発を抑えられなかったことが要因である」として発注側の責任を重くみる判決。
原告が訴えた18億円は払われず、請求する賠償額の3割相当に当たる約5億円の支払い、そして発注会社は開発会社に対し約2億円の支払いを命じました。
納期の遅れと追加請求が問題となった事例
原告 |
大手旅行代理店(発注会社) |
---|---|
被告 |
システム開発会社(開発会社) |
請求内容 |
【本訴】既払代金返還請求および損害賠償請求(約11億6千万円) 【反訴】作業委託料金の未収分などを請求(約7億6千万円) |
判決 |
原告被告ともに請求放棄、裁判費用は各自負担で和解が成立 |
発注会社は基幹業務で使用する宿泊予約等ができるHR(human resource:人的資源)システムの再構築を開発会社へ依頼。
しかしスケジュー ルが大幅に遅延。プロジェクト体制や開発側の人員体制を見直したものの、当初の見積額を大きく超えてしまいます。さらに1年以上の稼働時期の延伸を開発側が申し出たため、発注会社は作業中止を求め契約を解除しました。その後プロジェクト失敗の責任や開発費用支払いを巡り交渉を続けましたが解決せず、訴訟となりました。
裁判では遅延の原因がどちら側にあるかが争われましたが、3年余りの裁判の結果、原告被告ともに請求放棄。裁判費用はそれぞれが負担することで和解が成立しました。
システムの完成と、不具合による契約解除を争う事例
原告 |
システム開発会社(開発会社) |
---|---|
被告 |
石材の加工・販売会社(発注会社) |
請求内容 |
【本訴】請負代金請求(約1億1千万円) 【反訴】損害賠償請求(約1億3千万円) |
判決 |
原告の請求棄却、 被告の請求一部認容 (前払い金約1千万円の返還および損害賠償金約500万円の支払い) |
発注側は開発会社に販売管理システムの開発を一括請負しました。納品されたシステムを発注側が稼働させたところ、処理速度が遅く不具合も発生。開発会社は不具合と認めずに補修も行わなかったため、発注側が支払いを拒否。
システムの完成・納品後に支払いがないとして開発会社が発注会社を訴えました。発注会社は反訴して、システムの不具合を原因とした請負契約の解除と前払い金の返還、損害賠償の支払いを求めました。
2002年4月東京地方裁判所により、システムは完成している、しかし不具合発生後に補修されておらず、重大な不具合であるため契約解除の原因になるとの判決。
開発会社の請求棄却、発注会社の請求を一部認容して、前払い金約1千万円の返還および損害賠償金約500万円の支払いを命じました。
開発トラブルで訴訟に発展する理由
システム開発の訴訟の例を3つ紹介しましたが、開発トラブルによる訴訟に発展する理由は主に3つです。ビジネスパートナーである受発注者が、なぜ争うことになるのかご説明します。
発注側と受注側の認識のずれ
「システム開発のことはよくわらかないから開発会社にお任せしよう」と考える方もいるでしょう。しかしシステム開発における認識のずれは、訴訟問題にまで発展することもあります。受発注間の認識のずれによるトラブルについて、具体的にご説明します。
契約成立・不成立の認識のずれ
受発注間で契約の成立・不成立の認識にずれが生じ、トラブルになるケースです。実際、正式な契約書を交わす前に、契約成立前に開発会社が作業を始めてしまい、トラブルになるケースは非常に多いです。
開発費用の支払いを巡って争いになり、契約成立を主張する開発側と、まだ交渉段階であると主張する発注側でトラブルになります。正式に契約書が交わされなければ契約成立と認められないケースが多いです。
しかし覚書(当事者間同士の合意を書面にしたもの)が締結されており、契約成立が認められたケースもあります。また開発会社の会議やセレモニーに発注側が参加して契約成立と解釈され、開発がスタートしてトラブルになったケースもあります。
システム像の認識のずれ
開発の目的となるシステム像の認識にずれが生じ、発注側が希望するシステムが完成しなかったためにトラブルになるケースです。せっかくシステムが完成しても、発注側にとって使い物になるシステムでなければ意味がありません。
システム像がずれているため、後から機能追加や目先の課題修正をしても、根本的な問題解決には至らない場合があります。結果、追加のコストばかり膨らんでしまい、全体的に見たときに希望するシステムが完成しない状態に陥ります。
システム像の認識のずれは、受発注間のコミュニケーション不足により生じます。具体的には発注者が欲しいシステム像を受注側にきちんと伝えていない場合や、受注側が要望をしっかりヒアリングできていない場合などです。また要件定義があいまいで、優先させたい機能や必要な機能などの認識を共有できていない場合もあります。
関連記事:システム開発の要件定義とは?受託開発における重要性や進め方を解説!
契約書にトラブル時の責任の記載がない
システム開発費は「単価×工数」で計算され、開発工程で直しが必要になった分だけ、追加の費用と工数が必要です。修正や追加が入るほど納期が遅れ、コストも膨れ上がります。受注側の人手不足、工数や費用の見積もりの甘さ、発注側が要望を出し続けるなど、さまざまな理由によりプロジェクトの遅延が発生します。
しかしそもそもシステム開発では想定外のトラブルが起きやすく、修正はつきものです。あらじめトラブルが起きたときを想定して、対応方法や責任の所在を契約書にきちんと記載しておくことが重要です。
契約書にトラブル時の対応が明記されていないと、納期の遅れや追加請求の責任をどちら側が取るのかがあいまいです。トラブルの対応方法や、修正・追加作業に伴う報酬の支払いをどちら側が負担するかで争いになり、訴訟問題に発展する恐れがあります。
システムの品質が悪く修正もされない
「完成したシステムが使い物にならない」「品質が悪い」と判断されて、プロジェクトの中止から訴訟問題に発展するケースです。システムの品質とは開発側の視点だけではなく、ユーザーが使用したときの利便性も含まれます。品質が悪いと評価されるのは、以下のような症状がある場合です。
- 欲しい機能が備わっていない
- 故障が多い、復旧に時間がかかる
- 操作性が悪い
- バグが多い
- 処理速度が遅い
- 機能追加に時間がかかる
ただし上記の不具合があっても、すぐに不具合を修正できればトラブルになる可能性は少ないです。システムの品質が悪く、以下のような場合は訴訟に発展する恐れが高まります。求めるシステムが完成しなかった発注側と、開発コストを支払って欲しい開発側で争いになるでしょう。
- 開発側が不具合と認めず修正をしない
- 修正に時間がかかりすぎる、または修正できなかった
システム開発の失敗については下記の記事も参考にしてください。
関連記事:システム開発の失敗例・原因・防止策まで解説失敗時の対処法も
訴訟に発展しないために発注側ができる対策方法
前章で紹介した原因を踏まえて、システム開発訴訟に発展しないために発注側ができる対策を紹介します。希望するシステムを完成させるためにも、開発会社任せにしないようにしましょう。
作りたいシステムを明確にする
どのようなシステムを作りたいのか、発注者が求めるシステム像を明確にしておくことは非常に重要です。すべての要求を満たせない場合もあるので、優先順位も決めておきましょう。優先したい機能から開発してもらうことで、大幅な修正を防止できます。
もちろん発注側内で意見を統一させておくことも大切です。実際にシステムを扱うユーザーである、現場の意見もヒアリングして取り入れましょう。いざ新システムを導入する段階で、現場からの反発が起きると、受発注間だけではなく社内のトラブルにも発展する恐れがあります。
ISO※ではソフトウェアの品質モデルとして、以下の3つの特性を定めています。以下のポイントからどのようなシステムを作りたいのか、開発の目的や優先順位を考えてみましょう。
※ISO/International Organization for Standardization:国際標準化機構。国際的な取引において、共通の基準となる規格を制定する非政府機関。
機能性 |
要求された機能が備わっている |
---|---|
信頼性 |
システムが故障しにくい、故障しても回復しやすい |
使用性 |
ユーザーが使いやすい、分かりやすい |
コミュニケーションを密に取る
備えたい機能や優先順位が明確に定まったら、作りたいシステム像を開発側にくわしく伝えましょう。受発注者間で認識を統一させて、開発を進めることが大切です。
見積もりや契約時はもちろんのこと、プロジェクト中も綿密にコミュニケーションを取りましょう。「よくわからかないから」と開発会社任せにすると、認識のずれに気づきにくく、大幅な修正が必要になる可能性があります。不明な点がある場合はその都度担当者に確認し、発注側も開発の流れや開発方法を把握しておきましょう。
あいまいな契約をしない
口約束は後からトラブルを招く原因になります。訴訟問題に発展しないために曖昧な契約は避けましょう。きちんとした見積書・契約書を作成してもらい、しっかり確認することが大切です。
見積書は費用の妥当性や内訳を細かくチェックします。
特に修正に必要な料金が含まれているか、納期にゆとりがあるかを確認しましょう。途中で機能を追加したり修正が入ったりするほど、工数がかかりコストが跳ね上がるからです。
契約書の内容もくわしく記載されていることが重要です。
契約の目的・内容・期限、所有権、委託する場合はその費用、トラブル発生時の責任やコスト、相談体制、報酬の支払い時期など、細かく確認しましょう。
契約書の見方についてのくわしい解説は以下の記事をご覧ください。
関連記事:システム開発の契約とは?契約形態・契約書の注意点を解説
業者選定を慎重に行う
開発会社選びは非常に重要です。希望するシステムを開発できる、信頼できる業者を選びましょう。会社選びの失敗はコストと時間の損失につながります。
以下のポイントを参考に業者選定を行いましょう。
- 経験・実績が豊富か
- 専門性があるか、得意分野は何か
- 見積もりが妥当か
- 運用・保守も可能か
- 担当者の対応が迅速・ていねいか
- 質問に答えられるか
システム開発会社によって得意・不得意な分野は分かれます。料金を公開している会社は少なく、どの会社に問い合わせればいいのかお困りの方も多いでしょう。
システム開発会社選びにお悩みの方はシステム幹事にご相談ください。専任のアドバイザーが最適な会社をご紹介します。相談料などは一切かかりませんので、お気軽にお問い合わせください。
また、システム開発でトラブルを防ぐために、他にも発注者が注意すべきポイントがあります。
詳しくは以下の記事をご覧ください。
関連記事:システム開発の注意点を流れに沿って解説!
訴訟に発展しそうな場合の対処法
上記の「発注側ができる対策方法」に気をつけていても、訴訟問題に発展してしまうことはあります。訴えるだけではなく逆に訴えられてしまうケースもあり、損害賠償額も少なくありません。
受発注間でのトラブルはできるだけ避けたいものです。またトラブルが起きた場合も、早い段階で対処して受発注間のもつれが小さいうちに和解できるよう努めましょう。
つづいて訴訟に発展しそうなそうな場合の対処法についてご説明します。
契約書の再確認
まずはどのような契約を交わしたのか、契約書を必ず再確認しましょう。特に以下のポイントをチェックします。
- 仕様変更が起きたときの対応方法や費用負担
- トラブル発生時の対応方法
- 損害賠償金額の制限(賠償を受けられるケース)や範囲(上限金額)
- 成果物の所有権や知的財産権、または使用の許諾
また、システム開発には「請負契約」と「準委任契約」があります。
- 請負契約:完成物を納品すると報酬が支払われる契約。開発工程は受注側に一任する。
- 準委任契約:仕事・業務をした量に対して報酬が支払われる契約。
請負契約の場合、受注側には「契約不適合責任」があり、成果物の品質が契約内容に適していない場合は責任を負わなければなりません。完成したシステムからバグが発生して補修や措置が取られないケースなどです。
発注者は納品後に不具合を発見してから1年以内に受注者へ通知すると、無償の修理や減額、契約解除などを求めることができます。
契約の種類は下記の記事に詳しく書いてあるので参考にしてください。
関連記事:システム開発の契約とは?契約形態・契約書の注意点を解説
開発会社と交渉する
受発注間でトラブルが起きたからといっても、必ず訴訟になるわけではありません。
受発注間で交渉の場を設けましょう。話し合いをすることで、受注側と発注側が互いに納得できる妥協点をすり合わせていきます。交渉で解決できれば、裁判よりも手間や費用を抑えられ、短期間で解決できる可能性が高いです。なにより受発注間の関係にしこりを残さずに済みます。
交渉ではトラブルとなった原因や状況を明確にして、どちらに責任があるのかを特定します。今まで交わした書類や連絡内容から情報を集めて、整理しておきましょう。
交渉で解決できるかどうかは交渉力だけではなく、お互いの交渉へ臨む姿勢が非常に大切です。自分の利益だけを考えず、円満に解決できるように落ち着いて冷静に話し合いましょう。
弁護士やADRに相談する
弁護士に相談する
システム開発の契約書は複雑でわかりにくいものです。トラブルに発展しそうな場合は、できるだけ早く弁護士に相談しましょう。対応が早ければ早いほど、受発注間の関係がもつれる前に有効な対処を取れる可能性が高まります。
しかし弁護士の多くは、IT分野にくわしくないのが実情です。弁護士がトラブル内容を十分に理解できないまま、交渉が進んでしまうケースもあります。システム開発トラブルを扱った実績のある弁護士に依頼しましょう。
弁護士に相談する場合は、初回で1時間5,000~10,000円の相談料金が相場です。依頼する場合は着手金や成功報酬などの弁護士費用が必要です。
ADRを活用する
ソフトウェア専門の知識を有する「ソフトウェア紛争解決センター(SOFTIC)」のADR(裁判外紛争解決機関)を活用する方法もあります。ADRは自分も相手側も話し合いに応じる場合のみ利用できる機関。IT関連の企業間トラブルを裁判せずに、当事者同士で話し合いすることで解決します。
ソフトウェア紛争解決センターのADRでは、弁護士・弁理士・ソフトウェア技術開発者などがそろっており、以下の4つの解決方法を選択できます。
- 仲裁:裁判所に代わり仲裁人が解決・判断する方法。裁判の確定判決と同じ効果がある
- 中立評価:中立評価人が判断・解決案を提示する方法
- 単独判定:単独判定人が専門性に基づき判定を行う方法
- 和解あっせん:あっせん人が解決案の提示などにより和解を支援する方法
ADRでは仲裁人やあっせん人を選ぶことができ、裁判よりも短期間で費用を抑えて解決できる可能性があります。手続きの公開・非公開を選択できるので、非公開にすれば紛争中であることを周りに知られず、プライバシーを守ることも可能です。
【まとめ】システム開発で訴訟問題に発展しないためにも信頼できる開発会社と契約を
システム開発は想定外の不具合が生じやすく、システム品質や納期・追加請求をめぐって訴訟問題に発展するケースもあります。トラブルを防ぐためにも開発会社任せにするのではなく、発注側もできる対策方法があります。今回紹介した「訴訟に発展しないための対策方法」を参考に、契約時は慎重に、契約後も受発注間でコミュニケーションを密に取りましょう。
さらにシステム開発会社の選定も非常に重要です。会社選びの失敗はコストと時間の損失に繋がります。開発会社によって得意分野があり、信頼できる業者を探すのにお困りの方も多いでしょう。
システム開発会社選びにお悩みの方はシステム幹事にご相談ください。専任のコンサルタントがあなたに最適な会社をご紹介します。
コンサルタントのご紹介
岩田
専任のコンサルタントが、
お客様の予算と目的を丁寧にヒアリング。
最適な会社をピックアップ・ご紹介させていただきます!
初心者の方でも安心してご相談いただけます。
相談料などは一切かかりませんので、お気軽にお問い合わせください。
Q. システム開発の訴訟事例には何がある?
システム開発の訴訟事例として「発注会社が開発に協力せずトラブルになった」「納期の遅れと追加請求が問題になった」等が挙げられます。そのほか豊富な事例と参考になるポイントは記事内で紹介していますので、ぜひご覧ください。
Q. システム開発で訴訟に発展しないための対策方法は?
システム開発で訴訟に発展しないための対策方法として「作りたいシステムを明確にする」「コミュニケーションを密に取る」等が挙げられます。詳しくは記事をご覧ください。
この記事を書いた人
川口リカ
専門分野: Webライティング
30代で教育業界(専門は数学・情報)からWebライターへ転職。得意の説明能力を活かした、読みやすく分かりやすい文章が強みです。好奇心旺盛な性格で情報収集好き。趣味はランニングと釣りです。