---
title: "システム開発トラブルはなぜ起きるのか。原因と対処の方法を解説"
date: 2026-10-02
author: 野俣智裕
slug: system-development-trouble-causes
permalink: https://ip.darwin.law/ip-column/system-development-trouble-causes/
---

「システム開発では、どのようなことがトラブルにつながるのだろうか」  

「そもそも、システム開発でトラブルになっている事例は、どれくらいあるのだろうか」  

と気になりませんか。  

システム開発は、業務効率化や売上向上に直結する重要な投資です。  

一方で、内容が専門的になりやすく、「よく分からないまま進めてしまった結果、大きなトラブルに発展した」ということもあります。  

実際、システム開発に関する紛争は裁判にまで発展するケースもあります。  

本記事では、システム開発トラブルが起きる背景と具体例を整理し、経営者が事前に押さえるべき対処法を分かりやすく解説します。

## システム開発トラブルが起きやすくなる原因

![](/wp/wp-content/themes/ip/images/staff/fukidashi-nomata.png)  

弁護士  

野俣 智裕
ここでは、システム開発においてトラブルが起きやすくなる典型的な原因について解説します。

### 契約成立前に作業が始まってしまう

*発注を急ぐあまり、正式な契約書を取り交わす前に作業が始まってしまうケースがあります。*  

この段階では、業務内容や報酬、責任範囲が明確になっておらず、後から「そこまで頼んでいない」「追加費用とは聞いていない」といった認識のズレが生じやすくなります。  

**契約が成立していない状態で作業が進むと、トラブル発生時に費用負担や支払義務を巡って争いになりやすく、裁判に発展するリスクも高まります。**

### 契約書を「形式的なもの」と考え、中身を詰めずに進めてしまう

契約書を単なる形式的な書類と考え、細かい内容を確認せずに締結してしまうことも、トラブルの原因になります。  

契約書は、万が一の際に双方の認識を確認するための重要な資料です。  

業務範囲や役割分担が曖昧な契約書では、問題が起きた際に「どこまでが契約に含まれていたのか」を巡って争いになりやすくなります。

### 「何を作るか」が最後まで決まりきらないまま進めてしまう

システム開発では、要件が固まらないまま開発が進んでしまうことがあります。  

「細かい部分は作りながら決めればいい」と考えがちですが、この進め方は後々の認識ズレを生みやすくなります。  

完成イメージが共有されていない状態では、完成後に「思っていたものと違う」といった不満が生じやすくなります。

### 途中で話が変わったときのルールを決めていない

開発途中で仕様変更が発生することがあります。  

問題となるのは、仕様変更があった場合の費用や納期、手続について事前にルールを決めていない点です。  

その場の口約束で進めてしまうと、後から追加費用を巡って揉める原因になります。

### どこまでできたら「完成」なのかを決めていない

完成基準を明確に定めていないと、「完成した」「まだ完成していない」という認識のズレが生じます。  

特に業務システムでは、「実務で使えるかどうか」が重要であり、単にプログラムが動くかどうかだけでは判断できません。

### 発注側と受注側の役割・責任を曖昧にしたまま任せてしまう

データ提供やテスト、運用準備など、どちらが担うのかを明確にしないまま進めると、責任の所在が不明確になります。  

結果として、トラブルが起きた際に互いに責任を押し付け合う状況になりやすくなります。

## 企業で起こり得るシステム開発トラブル

![](/wp/wp-content/themes/ip/images/staff/fukidashi-nomata.png)  

弁護士  

野俣 智裕
ここでは、実際に企業で多く見られるシステム開発トラブルの具体例を紹介します。

### 要件を説明したつもりだったが、想定と違うシステムが完成した

発注側は十分に説明したつもりでも、受注側には別の理解をされていたというケースです。  

言葉だけの説明では、業務の細かなニュアンスまで正確に伝わらないことがあります。

### 途中の仕様変更で追加費用を請求され、揉め始めた

仕様変更のたびに追加費用が発生すること自体は不自然ではありません。  

しかし、事前にルールが決まっていないと、「そんな話は聞いていない」とトラブルになりやすくなります。

### 完成したと言われたが、業務では使えず支払を拒否した

形式的には完成していても、実務で使えない場合、発注側が支払を拒否するケースがあります。  

完成基準が曖昧なまま進めた結果、紛争に発展してしまうのです。

### ベンダーを変更したくてもソースコードを引き継げなかった

開発を依頼していたベンダーとの関係が悪化し、別の会社に引き継ごうとした際に、ソースコードがベンダーから提供されないケースです。  

契約内容によっては、自由に利用できない場合があります。

### 契約内容を十分に確認せず進め、著作権の帰属が曖昧になった

*システムの著作権が誰に帰属するのかを決めていないと、完成後の利用や改修に制限が生じることがあります。*  

*契約締結後に著作権や利用範囲を修正しようとすると、再交渉や追加契約が必要となる可能性があるため、実務上は容易ではありません。*

## 経済産業省のトラブル事例から見るシステム開発トラブルの現実

![](/wp/wp-content/themes/ip/images/staff/fukidashi-nomata.png)  

弁護士  

野俣 智裕
経済産業省のトラブル事例をもとに、システム開発トラブルがどのように争いに発展するのかを見ていきます。

### 契約成立前に作業を開始し、費用負担を巡って争いになったケース

この事例では、正式な契約が成立する前にシステム開発作業が始まっていたことがトラブルの発端になりました。  

ユーザが独立行政法人の公募事業への応募を検討し、ベンダーとシステム提案や開発について協議を進めていました。ベンダーは提案書作成や開発作業を行っていましたが、請負代金額などの条件が折り合わず、最終的に共同事業は解消されました。  

その後、ベンダーは開発作業などに要した費用の支払を求めましたが、ユーザは申請書作成の共同作業を依頼したにすぎず、システム開発については合意していないと主張しました。  

裁判所は、ユーザがベンダーによる開発作業への着手を認識していたことや、開発費用の清算について口頭合意があったことなどを踏まえ、ベンダーの請求の一部（約1365万円）を認めました。

出典：経済産業省「情報システム・ソフトウェア取引トラブル事例集」p14  

[https://www.meti.go.jp/policy/it_policy/softseibi/trouble%20cases.pdf](https://www.meti.go.jp/policy/it_policy/softseibi/trouble%20cases.pdf)

### 著作権の帰属を決めていなかったため、システムを自由に使えなくなった事例

この事例では、システム開発の成果物の著作権の帰属を契約で明確に定めていなかったことから紛争になりました。  

委託者は、珠算ソフトの開発をA社に委託しましたが、A社は開発作業を受託者に再委託しました。受託者はソフトの企画設計やプログラム作成を行い、A社を通じて委託者に納品されました。その後、委託者はソフトの販売を開始しましたが、委託者からA社に委託料が支払われていなかったことから、受託者は本件ソフトの著作権は自らにあるとして、複製や頒布の差止めを求めました。  

裁判所は、実際にソフトの企画設計や制作を行ったのは受託者であり、委託者は発注を行ったにすぎないことなどを踏まえ、本件ソフトの著作権は受託者に帰属すると判断しました。また、委託者とA社との契約では、委託料の完済後に成果物の権利が移転する旨の条項がありましたが、委託料が支払われていなかったため、権利は委託者に移転していないとされました。

出典：経済産業省「情報システム・ソフトウェア取引トラブル事例集」p54  

[https://www.meti.go.jp/policy/it_policy/softseibi/trouble%20cases.pdf](https://www.meti.go.jp/policy/it_policy/softseibi/trouble%20cases.pdf)

## システム開発トラブルを避けるために経営者が押さえるべきポイント

![](/wp/wp-content/themes/ip/images/staff/fukidashi-nomata.png)  

弁護士  

野俣 智裕
ここでは、システム開発を進めるうえで、経営者が最低限意識しておくべきポイントについて解説します。

### 「話したつもり」で済ませず、合意内容を言語化・記録する

システム開発では口頭のやり取りが増えがちですが、「言った」「聞いていない」は後から証拠になりません。  

打合せで決まった内容は、メールや議事録などの形で残し、双方の認識を揃えておくことが重要です。

### 契約書で「業務内容・範囲・完成基準」を明確にする

契約書は形式的な書類ではなく、「どこまでやれば契約が果たされたといえるのか」を定めるためのものです。  

特に重要なのは、業務内容の範囲と完成の基準です。  

「システムを作る」とだけ書かれている契約では、どの状態をもって完成とするのか判断できず、支払を巡って紛争になりやすくなります。  

経営者としては、専門的な表現でなくても構わないので、「何ができる状態になれば完成か」を契約書で確認する姿勢が必要です。

### 仕様変更は必ず書面で整理する

開発途中で仕様が変わること自体は、珍しいことではありません。  

問題になるのは、その変更が「追加業務なのか」「契約内の修正なのか」を曖昧にしたまま進めてしまう点です。  

仕様変更が発生した場合は、費用や納期への影響を含めて、必ず書面で整理する必要があります。  

これを怠ると、後から「それは契約外だ」「追加費用が必要だ」といった主張が対立し、深刻なトラブルに発展します。

### 成果物と著作権の帰属を事前に確認する

システムは「お金を払ったから自由に使える」と思われがちですが、著作権の扱いは別問題です。  

契約で定めがなければ、原則として実際に設計・制作を行った側に著作権が帰属します。  

その結果、ベンダー変更ができない、改修が自由にできないといった問題が生じることがあります。  

経営者としては、成果物をどの範囲で利用できるのか、ソースコードの扱いをどうするのかを、事前に確認しておくことが重要です。

## まとめ

システム開発トラブルは、技術ではなく契約や合意内容の整理不足が原因です。契約成立前の着手や、業務範囲・完成基準・著作権を曖昧にしたまま進めると、後から紛争に発展しやすくなります。不安がある場合は、当事務所までお気軽にご相談ください。