「システム会社に騙された」とまで言える深刻な事例は決して多くありませんが、契約書の細部を詰めずに発注した結果、稼働後に追加請求や保守縛りで身動きが取れなくなる中小企業は珍しくありません。本記事では、実際に経営者から聞いた典型的な失敗事例3つと、契約書に潜む4つの罠を整理し、契約前に確認すべきポイントを経営者目線で解説します。
この記事の結論（3行）
- 「騙された」事例の大半は、契約書の検収条件・知財・保守・損害賠償の4つの罠に起因する
- ベンダー側のひな型をそのまま受け入れず、第三者レビューを入れることで防げる
- 契約書修正に「面倒だ」と応じない会社は、稼働後のトラブル対応も期待できない
システム会社に騙されたと感じる典型シーン3つ
経営者が「騙された」と感じるのは、稼働後に予想外の追加請求が発生したり、保守を切り替えようとして高額な手数料を請求されたりするタイミングです。代表的な3つのシーンを整理します。
- 検収が曖昧なまま「完了」とされ、不具合修正が有償に
- システムの権利がベンダーにあり、他社に保守を移せない
- 解約時にデータ移行費を高額請求される
3つとも契約書の条項を詰めていれば防げる類の問題です。
シーン1: 検収が曖昧なまま「完了」とされた
リリース直後にバグや仕様の食い違いが見つかったが、ベンダーから「検収完了済み」と返されて、修正が全て有償対応になった——というケースです。検収基準が「全機能の動作確認」のような抽象的な表現で書かれていると、検収後の不具合修正は瑕疵担保期間を超えた段階で有償扱いになります。検収基準は「具体的な機能ごとの動作確認シナリオ」で書かれているかを契約前に確認してください。検収シナリオが30〜50項目あり、それぞれに合否の判定基準が明記されていれば、検収後の食い違いは大きく減ります。シナリオ作成自体は発注側の責任ですが、雛形をベンダーに提示してもらい、自社業務に合わせて埋めていく形が現実的です。
シーン2: システムの権利がベンダーに残り、他社に移せない
「保守費用が高くて他社に切り替えたいが、ソースコードの著作権がベンダー側にあり、他社で保守できないと言われた」というケースです。中小企業のシステム開発では、知的財産権の帰属が契約書に明記されていないことが多く、デフォルトではベンダー側に帰属します。他社への保守切り替えやシステム移行が事実上できなくなる構造です。
シーン3: 解約時にデータ移行費を高額請求された
保守契約を解約してシステムを移行しようとしたら、「データ移行費として500万円」「ソースコード提供費として200万円」と請求されたというケースです。契約書に「解約時のデータ提供条件」が記載されていないと、ベンダー側の言い値で請求される構造になります。解約時の費用上限を契約書に明記しておくことで防げます。具体的には「CSVまたはSQLダンプ形式でのデータ提供は無償」「APIアクセスは契約終了後30日間無償継続」「ソースコード提供は税抜◯万円を上限」のような形で、項目ごとに金額または条件を明示してください。
契約書に潜む4つの罠
「騙された」と感じるトラブルの大半は、契約書の以下4つの条項に起因します。順番に整理します。
| 罠 | 起きる問題 | 契約前に確認する条項 | |---|---|---| | 検収条件の曖昧化 | 検収後の不具合修正が有償に | 検収基準・瑕疵担保期間 | | 知財帰属の不明確 | 他社移行できない | 知的財産権の帰属 | | 保守縛り | 解約時に追加費用 | 解約条件・データ移行費 | | 損害賠償の上限制限 | 重大障害でも補償が薄い | 損害賠償の上限金額 |
これら4つの罠を1つずつ詰めていきましょう。
罠1: 検収条件の曖昧化
検収条件が「全機能の動作確認」「業務に支障がないことを確認」のような抽象的な表現で書かれていると、ベンダー側の判断で検収完了とされる余地が生まれます。検収後の不具合は瑕疵担保期間（通常3〜6か月）を過ぎれば有償対応です。契約前に「検収シナリオ書」を文書化し、シナリオごとの合格基準を明記してください。シナリオ数は機能数の2〜3倍が目安です。
罠2: 知財帰属の不明確
知的財産権が契約書に明記されていない場合、デフォルトではベンダー側に帰属します。ソースコードの提供を受けられず、他社への保守切り替えやシステム移行ができなくなります。中小企業の場合、ソースコードの所有権までは譲渡されなくても「永続的・無償の利用権」を契約書に明記してもらえば、他社移行が可能になります。
罠3: 保守縛り
保守契約の解約条件が曖昧だと、解約時にデータ移行費・ソースコード提供費・移行協力費などの名目で高額請求される場合があります。契約前に「解約時のデータ提供は無償」「ソースコードは契約期間中いつでも提供」「移行協力は◯時間まで無償」のような条件を明記してください。これらを書面化することで、保守縛りを防げます。
罠4: 損害賠償の上限制限
ベンダー側のひな型では、損害賠償の上限が「契約金額の50%」「年間保守費の3か月分」のように低く設定されていることが多いです。システム障害でデータ喪失や業務停止が発生した場合、実害が上限を大幅に超えても補償されません。重要な業務システムでは、損害賠償の上限を「契約金額の100%」「年間保守費の12か月分」程度まで引き上げる交渉を行うことをお勧めします。逸失利益や間接損害が対象に含まれているかも確認すべき論点です。多くのひな型では「直接損害のみ」と限定されていて、業務停止による売上機会損失は補償されない構造になっています。発注前にこれら4つの罠を業務改善・システム見積もりAI適正診断で点検しておくと、契約交渉の精度が高まります。
騙されないための契約前チェックリスト
具体的に、契約前にチェックすべき項目をリスト化します。各項目について、ベンダー側に文書での回答を求めてください。
チェック1: 検収シナリオ書の作成
検収基準を「シナリオ書」で詳細化し、シナリオごとの合格基準を明記してください。例えば「受注入力シナリオ：在庫数の自動引き当てが行われ、納期回答画面に表示されること」のように、機能と挙動を具体的に書きます。シナリオ書を契約書の付属書として添付すれば、検収判断の曖昧さを排除できます。
チェック2: 知財帰属と利用権の明記
知的財産権の帰属と、ユーザー企業側の利用権を契約書に明記してください。ソースコードの所有権が完全譲渡されなくても、「永続的・無償・改変可能・第三者への保守委託可能」な利用権が認められていれば、実質的にシステムの所有権を保持できます。
チェック3: 解約時の費用上限
解約時に発生する費用の上限を契約書に明記してください。「データ提供は無償」「ソースコード提供は◯万円以内」「移行協力は1か月◯時間まで無償、超過分は時間単価◯円」のように、項目別の上限を設定すれば、解約時の予算上の不確実性を排除できます。
チェック4: 損害賠償上限の引き上げ交渉
ベンダー側のひな型の損害賠償上限を、自社の業務リスクに見合った金額まで引き上げてください。基幹システムであれば「契約金額の100%」、業務停止のリスクが高ければ「年間保守費の12か月分」が目安です。交渉に応じないベンダーは、稼働後のトラブル対応にも消極的になる傾向があります。
チェック5: 第三者レビューを入れる
契約書のレビューに、顧問弁護士やシステム開発に詳しい第三者を入れてください。レビュー費用は5〜20万円程度ですが、契約後のトラブルを未然に防ぐ投資としては安いものです。発注前に項目別に整理してから動き出すことで、レビュー時間も短縮できます。レビューでは「自社にとって不利な条項」だけでなく「明記されていない論点」も洗い出します。書かれていないことが後で問題になる、というのが契約書トラブルの特徴です。
チェック6: 段階リリースと検収分割
大規模なシステム開発では、検収を1回ではなく段階に分けてください。フェーズ1で受発注、フェーズ2で在庫、フェーズ3で帳票のように分割し、各フェーズで検収を完了させていく方式です。一括検収だとフェーズ1の不具合がフェーズ3まで持ち越され、最終検収で全機能の修正が必要になります。段階リリースで検収を分けると、不具合の発見と修正が早くなり、瑕疵担保期間の管理も柔軟になります。
経営者目線で考える「契約書交渉の判断軸」
ここからは経営の話です。契約書の交渉は「面倒な手続き」ではなく「数年先のリスクを今潰す経営判断」です。契約書修正に応じる柔軟性は、稼働後のトラブル対応の姿勢に直結します。条文の修正要請に「ひな型ですから変えられません」と硬直的に対応する会社は、稼働後の追加要望にも同じ姿勢で臨むため、長期の付き合いには向きません。
経営者が踏み込むべき判断は3つです。第一に、契約書のレビューに第三者を必ず入れる体制を作ること。社内法務がなければ顧問弁護士、それも難しければシステム開発に詳しい外部アドバイザーで構いません。第二に、契約書修正の交渉を「ベンダー選定の最終判定」として使うこと。修正要請に柔軟に応じるか、即答で断るかで、稼働後の対応姿勢が見えます。第三に、契約金額の3〜5%をレビュー予算として最初から確保すること。1,000万円のシステムなら30〜50万円のレビュー費用を予算化してください。
「契約書はベンダー任せ」「印鑑だけ押す」発想を変えるだけで、稼働後の追加請求リスクは大幅に減ります。中小企業の経営者にとって契約交渉は不慣れな領域ですが、システム開発は数年単位の付き合いになるため、最初の契約書で詰めるべき項目は10〜15項目程度に収まります。チェックリスト化しておけば、何度でも繰り返し使える経営資産になります。
ぷらすわんの実例：ある卸売業D社の場合
ぷらすわんが診断で関わった、ある卸売業D社（従業員30名）の例をお伝えします。D社は受発注管理システムを1,500万円で発注しましたが、稼働2年後に保守費の値上げ通知を受け、他社への切り替えを検討したところ「ソースコード提供費400万円、データ移行費300万円、合計700万円」を請求されました。
D社の契約書を確認すると、知的財産権の帰属について明記がなく、解約時の費用上限も書かれていませんでした。当初の発注時にベンダー側のひな型をそのまま受けており、稼働後に身動きが取れない構造になっていました。結果として、D社は値上げを受け入れて保守継続を選ぶしかなく、3年間で合計1,200万円の追加保守費を支払うことになりました。
ぷらすわんがD社に提案したのは、次回のシステム入れ替え時には「契約前の第三者レビュー」「知的財産権の利用権明記」「解約時の費用上限設定」を必ず実施することでした。契約書の罠は事前に潰せる類のリスクです。さらに、保守契約の値上げ条件についても「年率◯%まで」「3か月前事前通知必須」のような上限を契約書に明記しておけば、稼働後の保守費高騰を未然に防げます。発注前にこれらを診断することで、稼働後の身動きの自由度を保てます。
まとめ
システム会社に騙されたと感じる事例の大半は、契約書の検収条件・知財・保守・損害賠償の4つの罠に起因します。ベンダー側のひな型をそのまま受け入れず、検収シナリオ書の作成、知財帰属の明記、解約時の費用上限設定、損害賠償上限の引き上げ、第三者レビューの導入を組み合わせれば、後悔の8割は防げます。
契約書のレビューは「面倒な手続き」ではなく「数年先のリスクを今潰す経営判断」です。契約金額の3〜5%をレビュー予算として確保し、修正要請への対応姿勢でベンダーの本性を見極めてください。発注前に契約条項を項目別に整理してから動き出す流れが、騙されないための最短ルートです。