
「ITシステム開発トラブル」契約書の不備で、どうする?納期遅延・使えない成果物
2025年7月10日
業務効率化やDXの推進に伴い、外部にシステム開発を委託する企業が急増しています。一方で、「納期に間に合わない」「完成したはずのシステムが使い物にならない」といった深刻なトラブルも後を絶ちません。
こうした事態の多くは、契約書や仕様書の不備、あるいは双方の認識のズレに起因します。本記事では、実際のトラブル事例やその背景、弁護士がどのように対応するかについて解説します。
よくある相談事例
【ケース1】納期に3か月以上遅れ、プロジェクトが頓挫寸前に

相談に来られたのは、ある中小企業の社長。業務効率化の一環として、受発注を自動化する社内システムの開発を、外部のIT会社に委託していました。
契約では「6か月で納品」と明記されていたものの、5か月目の時点でまだ詳細な設計すら上がってこない。状況を聞いても「順調です」と言われるばかり。納期が迫り焦るなか、社長はようやく開発責任者と面談。しかしその場で、「実は担当エンジニアが辞めた」「人手が足りない」と告げられました。
結果として、予定より3か月以上の遅れが発生。新システムを中心に予定していた販促企画もキャンセルしなければならず、会社には大きな損失が…。
「今さらキャンセルできるのか?遅延による損害賠償は請求できるのか?トラブルになっても、こちらの言い分が通るのか不安です…」
このような相談に対しては、まず契約書を確認し、納期の扱いや損害賠償条項の有無をチェックします。
また、打合せ記録やメールのやりとりを整理し、「開発の遅れ」が客観的に証明できるかを検討。証拠がそろえば、債務不履行として契約解除や損害賠償請求も現実的になります。
【ケース2】納品されたシステムが現場で全く使えず…

こちらは、ある卸売業の業務管理部門からの相談です。
導入コストを抑えようと、比較的安価で請け負ってくれる中堅開発会社に在庫管理システムを委託。要件定義は初期のヒアリング数回とメールのやり取りで済ませ、契約書も「開発一式」のような簡易な内容にとどまっていました。
いざ納品されたシステムは、インターフェースが複雑で現場スタッフからは不満の声が続出。肝心のリアルタイム在庫更新機能も動作が不安定で、「これでは現場で使えない」との声が上がりました。
それでも開発会社側は、「依頼通りの仕様で開発した」「これは完成している」と主張。修正を依頼すると、「追加費用が必要」との請求まで届く始末でした。
「これは明らかに“未完成”ではないのか?契約書には何も書いていないけれど、こちらが泣き寝入りするしかないのか…」
このようなケースでは、成果物に「瑕疵(かし=欠陥)」があるかどうかが争点になります。契約書に受け入れ条件の記載がない場合でも、実務上の要件定義や使用目的に照らして“不完全”と評価できることもあるのです。
弁護士としては、要件定義書やメールの記録、社内での利用状況などを集めて、まず「完成とは認められない」という根拠を整理。そのうえで、追加請求の支払停止、必要であれば契約解除や損害賠償請求の準備を進めていきます。
どちらの事例も、経営判断を誤ったわけではありません。ただ、契約段階で見落とされがちな小さな穴が、後に大きな損失やストレスとなって経営を圧迫することはよくあります。
弁護士が実際にどう関われるのか?

「こんな契約、ちゃんと見ておけばよかった」――そう感じて相談に来られる方は少なくありません。
私たち弁護士が最も多く関わるのは、「契約はしてしまったけれど、想定外のトラブルが起きた」という段階です。
たとえば、納期が大幅に遅れたケースでは、まず契約書を精査し、「納品期限」「遅延時の対応」「損害賠償の可否」がどう定められているかを確認します。そのうえで、相手方への通知文書を作成し、契約解除や損害賠償を含めた交渉に入ります。
一方で、裁判になる前に「一度、弁護士が入ったほうが話がスムーズに進む」ことも多々あります。
相手方が不誠実な対応をしているとき、弁護士の名前が入った文書が届くだけで態度が一変することも珍しくありません。
もちろん、理想はトラブルが起きる前に関わること。たとえば、「契約書にこれではリスクが大きいですよ」といった事前のレビューだけでも、損害の回避につながることが多いのです。
トラブルを未然に防ぐにはどうすればいいか?

実務上、システム開発トラブルの多くは、契約段階での“あいまいさ”が原因です。
「そこまで書かなくても大丈夫だと思った」「先方を信用していた」という声もよく聞きますが、あとから見返したときに“言った・言わない”の争いになりやすいのです。
たとえば、成果物が納品された際、「完成」とみなす基準(=受け入れ条件)が契約書に明記されていないと、後で「これで完成のはずだ」「いや未完成だ」といった泥沼の論争になります。
また、見落とされがちなのが「修正対応」の範囲です。
一部の開発業者は、仕様にわずかでも書かれていなかった点については「追加費用になります」と主張してくることがあります。こうしたリスクは、ほんの数行の条項で防げることもあるのです。
契約書の確認は、“念のため”ではなく、“経営を守るための投資”と考えていただければと思います。
実際に、わずかなチェックで防げたはずの損害が、後になって何十万、何百万円という形で跳ね返ってくることもあります。