「要件定義どおりに作ったはずなのに、ユーザーからは『動かない』と支払いを拒まれている」──システム開発をめぐって、こうした紛争のご相談は後を絶ちません。私自身、元IT企業経営者として多数の開発プロジェクトを動かしてきた経験から断言しますが、システム開発の紛争は契約書の書き方と「プロジェクト進行中の記録の残し方」で結果が大きく変わります。

この記事では、近年の裁判例を踏まえつつ、ユーザー・ベンダのどちらの立場からも押さえておきたい実務のポイントを、IT法務を専門とする弁護士の視点でわかりやすく解説します。

結論：システム開発紛争の勝敗を分ける3つの論点

まず結論から申し上げます。システム開発をめぐる紛争では、主に次の3つの論点で勝敗が決まります。

• ベンダの「プロジェクトマネジメント義務」（PM義務）を尽くしたか
• ユーザーの「協力義務」を尽くしたか
• 納入後の不具合が契約不適合（旧：瑕疵）にあたる重大なものか

いずれの論点も、抽象的な主張だけでは裁判所を動かせません。議事録・メール・進捗管理表などの「記録」が勝敗を左右します。元IT経営者の立場からも、プロジェクト中のドキュメントを軽視して後悔する事案を数多く見てきました。

紛争の3大パターン

システム開発取引で裁判沙汰になる原因は、大きく次の3パターンに整理できます。

• 開発範囲・仕様について、ユーザーとベンダの認識が食い違うケース
• プロジェクトが途中で頓挫し、既払金の返還や追加報酬の支払をめぐって争うケース
• システム納入後に不具合が発覚し、契約不適合責任が問題となるケース

いずれも突き詰めれば「お金をめぐる争い」ですが、ポイントは、裁判所が何を根拠にどちらの主張を採用するかを理解しておくことです。

なぜシステム開発は紛争になりやすいのか

建物の建築と違って、システムは無形のものを作る契約です。完成イメージが当事者間でズレやすく、途中での仕様変更も頻発します。加えて、要件定義フェーズは準委任契約、開発フェーズは請負契約という二段構えの契約形態が一般的であり、どちらの契約フェーズで問題が生じたかによって責任の所在も変わります。

こうした構造的な難しさがあるため、契約書の整備と進行中の記録管理を怠ると、紛争時に一気に不利な立場に追い込まれます。

ここからは、実務への影響が大きい近年の裁判例を取り上げ、それぞれのポイントを解説します。

【裁判例1】処理速度の遅さは「契約不適合」にあたるか（東京高判令和6年1月31日）

事案の概要

ユーザーが、納入されたシステムについて「タイムアウトが頻発する」「通知メールが届かない」といった不具合が契約不適合（重大な瑕疵）にあたるとして、ベンダに損害賠償等を請求した事案です。

裁判所の判断

一審ではユーザーの主張が多く認められましたが、控訴審ではいずれも否定されました。特に注目すべきは、処理速度について「非機能要件として仕様書に明記されていなかった以上、時間を要することだけをもって契約不適合にあたるとは言えない」という判断がなされた点です。

実務のポイント

ユーザー側の教訓：「当然これくらいの速度で動くだろう」という期待は、契約書・要件定義書に書かれていなければ守られません。レスポンスタイム、同時接続数、ピーク時の処理件数など、非機能要件こそ数値で具体的に合意しておく必要があります。

ベンダ側の教訓：非機能要件は仕様書に明確に書かれていないと、後から「これはできていない」と言われがちです。提案段階で処理速度・性能基準を数値で合意しておくこと、書面化しておくことが身を守ることにつながります。

【裁判例2】ユーザーの協力義務違反で14億円超の支払命令（札幌高判平成29年8月31日）

事案の概要

大学病院（ユーザー）と大手通信事業者（ベンダ）の間で、基幹システム開発をめぐって争われた事案です。ユーザー側は、仕様凍結合意をした後も、画面・帳票・操作性などに関する大量の追加要望を出し続け、プロジェクトは大幅に遅延。最終的にユーザー側が契約を打ち切り、支払を拒否しました。

裁判所の判断

札幌高裁は、ベンダがプロジェクトマネジメント義務として「仕様凍結合意」を取り付け、追加要望を拒否する姿勢を示していたと評価。遅延の原因は、凍結合意後も要望を出し続けたユーザーの協力義務違反にあるとして、ユーザーに14億9744万円余りの支払を命じました。

実務のポイント

ユーザー側の教訓：「お金を払う側だから自由に要望できる」という発想は危険です。仕様凍結後の追加要望は、協力義務違反として逆に損害賠償責任を負うリスクがあります。社内の意見を集約してから要望を出す体制を整えることが不可欠です。

ベンダ側の教訓：ユーザーから過度な追加要望が出された場合、「対応が難しい」「納期に間に合わない」ことを書面で説明し、仕様凍結合意を取り付ける行動が身を守ります。記録を残して議論をリードする姿勢こそが、後の裁判での最大の武器になります。

【裁判例3】データ提供を怠ったユーザーに責任はあるか（東京地判令和4年9月15日）

事案の概要

ベンダが、システム開発の完成ができなかった原因は「ユーザーが必要なデータを提供しなかったから」として、ユーザーの協力義務違反を主張した事案です。

裁判所の判断

裁判所は、ベンダの主張を退けました。ポイントは、ベンダが「どのデータをいつまでに提供してほしいか」を具体的に期限を切って要請した証拠が乏しかったことにあります。

実務のポイント

ベンダ側の教訓：「ユーザーが協力してくれなかった」と後から主張しても、具体的な要請記録がなければ裁判所は認めてくれません。必要な資料・データは、内容・期限・提出形式をメールや議事録で明確に要請し、その記録を残すことが重要です。

ユーザー側の教訓：逆に、ベンダから具体的な要請が来た場合は、放置は禁物です。対応できない事情があれば、その旨と代替案を速やかに返信し、記録に残す姿勢が、後の紛争時の備えになります。

【裁判例4】プロジェクトマネジメント義務の原点（東京地判平成16年3月10日）

事案の概要

少し古い裁判例ですが、ベンダの「プロジェクトマネジメント義務」という概念を最初に明示した、いわばリーディングケースです。

裁判所の判断

裁判所は、ベンダはシステム開発の専門家として、次のような義務を負うと判示しました。

• 情報を集約・分析して、専門的知見を用いて開発を進める義務
• ユーザーに必要な説明を行い、了解を得ながら進める義務
• 懸案事項について複数の選択肢と利害得失を示し、ユーザーの適切な判断を促す義務
• 開発計画の変更・中止が必要な局面では、そのことを進言する義務

実務のポイント

PM義務は、契約書に書かれているかどうかに関わらず、システム開発契約の性質上当然に認められると考えられています。ベンダは「ユーザーに言われたとおりに作りました」では責任を免れられない、という点を理解しておく必要があります。

ユーザー企業が気をつけるべきポイント

1. 要件・仕様はできる限り書面に落とし込む

「当然このくらいの機能はあるだろう」「これくらいの速度で動くはず」という期待は、契約書・要件定義書に書かれていなければ原則として法的に保護されません。特に処理速度・応答性能・同時接続数などの非機能要件は、数値で具体的に合意することが重要です。

2. 仕様凍結後の追加要望は慎重に

仕様凍結合意をした後に大量の追加要望を出すと、協力義務違反として巨額の賠償責任を負うリスクがあります。社内で意見を集約し、本当に必要な要望だけを整理してから出す体制が不可欠です。

3. 「ベンダ任せ」は通用しない

ユーザーは、ベンダから質問や判断を求められたら、適時に対応する義務があります。意思決定者を明確にし、必要な工数を割り当てることがプロジェクト成功の前提条件です。「お金を払っているのだから」という発想では、裁判で負けます。

4. 議事録・メールを必ず残す

言った・言わないの水掛け論になるのがシステム開発紛争の常です。打ち合わせの議事録、メール、進捗管理表などの記録は、全て保存しておくことをお勧めします。

ベンダ企業が気をつけるべきポイント

1. 契約書で開発範囲を明確に

どのような機能を実装するのか（逆に実装しないのか）、開発対象を契約書および付随書類に具体的に明記しておくことが、紛争予防の基本です。口頭での合意や曖昧な表現は、紛争時にベンダ側に不利に働く傾向があります。

2. PM義務の履行を記録化する

ベンダは、単に言われたとおりに作るだけではPM義務を果たしたとは評価されません。開発進行上のリスク、仕様変更の影響、納期への影響を、その都度ユーザーに書面で説明し、判断を促したことを示す記録を残す必要があります。

3. 追加要望への対応は「拒否も義務」

ユーザーから無理な追加要望が出された場合、それが納期・品質に悪影響を及ぼすのであれば、「対応が難しい」と説明し、場合によっては拒否する義務があります。黙って引き受けた結果、納期遅延や品質不良が生じれば、ベンダの責任とされるリスクが高まります。

4. 協力を求めるときは「具体的」に

ユーザーに資料提供や判断を求める際は、「何を・いつまでに・どの形式で」を具体的に指定してください。抽象的な協力要請だけでは、後から協力義務違反を主張しても認められないのが裁判所の傾向です。

5. 責任限定条項を入れる

契約書には、損害賠償の上限（通常は契約金額相当額）を定める責任限定条項を入れることが一般的です。この条項の有無で、万が一の際のダメージは大きく変わります。

【実務チェックリスト】紛争予防の10のポイント

No.	チェック項目	対象
1	開発対象機能が契約書・要件定義書に具体的に明記されているか	両者
2	非機能要件（処理速度・性能等）が数値で合意されているか	両者
3	契約形態（請負／準委任）がフェーズごとに明確か	両者
4	議事録・進捗管理表が継続的に作成・共有されているか	両者
5	仕様変更のルール（追加費用・納期変更）が定められているか	両者
6	検収基準が契約書に明記されているか	両者
7	責任限定条項（損害賠償上限）が設けられているか	ベンダ側
8	リスク・懸案事項が書面で都度報告されているか	ベンダ側
9	社内の意思決定者・対応体制が明確か	ユーザー側
10	仕様凍結後の追加要望ルールが決まっているか	両者

それでも紛争が発生してしまったら

どれだけ気をつけていても、紛争が起きるときは起きます。紛争の兆候が出たら、次の手順で対応することをお勧めします。

• まずは関連する書類・メール・議事録をすべて時系列で整理する
• 争点を整理し、事実関係と法的主張を切り分ける
• 交渉による解決の余地を探る（裁判よりコスト・期間・関係性の面で有利）
• 交渉が難航する場合は、早い段階でIT法務に強い弁護士に相談する

特に重要なのは、早期に専門家に相談することです。紛争が深刻化してからでは取れる選択肢が限られ、不利な形で決着せざるを得ない場面も多く見てきました。

まとめ

システム開発紛争は、契約書・議事録・メールという「地味な記録」が勝敗を決めます。裁判所は、抽象的な「信頼関係」ではなく、具体的な記録に基づいて判断するからです。

私自身、IT企業を経営していた時代に、顧問弁護士の重要性を身をもって痛感しました。プロジェクトが走り出してから弁護士に相談するのと、契約段階から並走してもらうのでは、リスクの抑え込み方がまったく違います。特にシステム開発は、一度紛争化すると数千万円～数十億円規模の争いに発展することも珍しくありません。

中小企業やスタートアップだからこそ、予防法務の投資対効果は大きいと考えています。