システム会社から「契約書はこちらの雛形でお願いします」と渡され、内容を細かく確認せずに判子を押してしまった——そんな後悔の声を、ぷらすわんの相談現場で何度も聞いてきました。契約書はリリース後にトラブルが起きてから読み返すものではなく、判子を押す前に「揉めそうな10論点」を潰しておくものです。本記事では中小企業の経営者が発注前に確認すべき10項目を、領域別に整理します。
この記事の結論（3行）
- システム契約で揉める論点は概ね10項目、検収・知財・瑕疵・解約・保守の5領域に集中する
- 雛形をそのまま受け入れず、自社にとって不利な条項を1つでも修正交渉する姿勢が大事
- 発注金額の0.5〜1%程度を顧問弁護士・行政書士のレビュー費用に充てると、損失回避効果が10倍に跳ね返る
なぜシステム契約は中小企業にとって不利になりやすいか
中小企業がシステム会社と契約するとき、契約書はほぼ確実にベンダー側が準備した雛形が出てきます。これはベンダーの怠慢ではなく、システム業界の慣習です。ところがこの雛形は、ベンダーが自社のリスクを最小化するために整えたもので、発注側のリスクは十分にカバーされていないことが多くなっています。
- ベンダー側雛形は、ベンダーが過去のトラブル経験を反映している
- 発注側は契約経験が少ないため、抜け漏れに気づきにくい
- 契約交渉せずに判子を押すと、トラブル時に発注側が泣くケースが多い
実際にぷらすわんに相談に来られた経営者の中には、「契約書を読み返したら、追加要望は全て別途見積もりと書かれていた」「リリース後3か月の瑕疵対応は本来当たり前なのに、明文化されておらず有償対応になった」という事例があります。判子を押す前に確認すれば防げた損失です。
ベンダー雛形は「ベンダー目線」
ベンダーが用意する契約書雛形は、過去のトラブル経験を踏まえてベンダー自身を守る構成になっています。これは商売の常識として理解できますが、発注側はそれを前提に「自社を守る条項を追加する」交渉が必要です。
発注経験の少なさが弱みになる
中小企業がシステム発注をするのは数年に1度です。一方でベンダーは年間数十件の契約を結んでいます。経験量の差がそのまま交渉力の差になり、雛形をそのまま受け入れる流れになりがちです。
判子を押した後では遅い
契約締結後にトラブルが発生してから条項を読み返しても、契約の枠内でしか解決できません。判子を押す前の10〜30分の確認が、後の数百万円規模の損失を防ぎます。
必ず確認すべき10項目を5領域で整理
システム契約で揉めやすい論点は、5領域10項目に集約できます。発注前のチェックリストとして使ってください。
| 領域 | 確認項目 | 揉めるポイント | |---|---|---| | 検収 | 検収基準・検収期間 | 何をもって検収完了か曖昧だと泥沼化 | | 検収 | 追加要望の取扱い | 「言った言わない」で別途見積もりになる | | 知財 | 著作権・成果物の帰属 | ベンダー帰属だと自社で改修できない | | 知財 | 第三者ライセンスの扱い | OSS違反で訴訟リスクが残る | | 瑕疵 | 瑕疵担保期間 | 3か月か1年かで対応コストが10倍違う | | 瑕疵 | 瑕疵対応の費用負担 | 「当方判断」と書かれると有償化されやすい | | 解約 | 中途解約の条件 | 違約金が発注額の50%になるケース | | 解約 | データ持ち出しの権利 | 解約時にデータを返してもらえない事故 | | 保守 | 保守費用と内容 | 何が保守の範囲か曖昧で月額が膨らむ | | 保守 | 保守契約の縛り | 3年縛り・自動更新で抜けられない |
10項目のうち、自社にとって不利な条項を1つでも修正交渉する姿勢が大事です。雛形をそのまま受け入れる姿勢では、ベンダー側のリスクが減るだけで、発注側のリスクは残ったままです。契約前に確認すべき論点を整理したい場合は、業務改善・システム見積もりAI適正診断で発注前のチェックリストを洗い出せます。
領域別の確認ポイント
10項目を5領域に分けて、確認すべきポイントを掘り下げます。
検収領域：基準と期間と追加要望
検収は、トラブルが最も多発する論点です。「動くこと」だけが基準だと、想定した業務フローで使えなくても検収完了になってしまいます。発注前に「業務要件一覧」を作り、それを満たすことが検収条件と契約書に書き込んでください。検収期間は2週間が一般的ですが、複雑な業務システムなら1か月を要求するのが現実的です。
検収基準には「合格基準」と「不合格時の対応」をセットで明文化してください。合格基準だけ書かれていて、不合格時にどう対応するかが書かれていない契約書は、トラブル時にベンダー側の善意頼みになります。「不合格項目があった場合、ベンダーは7日以内に修正版を再提出する」のような具体的な手順まで盛り込むのが安全です。
追加要望の取扱いは、特に揉めます。雛形では「契約範囲外は別途見積もり」と書かれていることが多く、ちょっとした調整も有償化される可能性があります。発注前に「軽微な調整（30分以内の修正）は契約範囲内」のような線引きを書き込むだけで、リリース直前の摩擦が大きく減ります。さらに「軽微・中規模・大規模」の3段階で対応方針を分け、中規模までは月次定例の中で対応、大規模のみ別途見積もり、という運用ルールを契約に紐付けると、追加発生時の合意形成がスムーズになります。
知財領域：著作権と第三者ライセンス
成果物の著作権がベンダー帰属になっていると、後に別ベンダーへ乗り換えるときに改修できません。著作権は発注側帰属にするのが基本で、ベンダー側が雛形作成の特殊技術を再利用したい場合は、再利用権を別途認める形で交渉してください。
ソースコードの納品形態も明記が必要です。「コンパイル済みバイナリのみ納品」だと、別ベンダーが改修するときに事実上ベンダーロックインが発生します。「ソースコード一式・ビルド手順書・環境構築手順書」をセットで納品物に含めるよう、契約に書き込んでください。GitHub等のリポジトリで管理する場合は、発注側のオーナー権限で運用し、ベンダーは協業者として招待する構造が安全です。
第三者ライセンス（OSSや有償ライブラリ）の扱いも明記が必要です。GPL系のライセンスを含む構成だと、自社の本業コードまで公開義務が発生するリスクがあります。発注前にベンダーへ「使用するOSSライセンス一覧」を出してもらい、契約書に添付することをお勧めします。有償ライブラリのライセンス料を誰が払うか（初期費用に含むか、運用費に乗せるか）も明文化しておくと、ランニングコストの予測精度が上がります。
瑕疵領域：期間と費用負担
瑕疵担保期間は、3か月と1年で対応コストが10倍違ってきます。雛形では3か月とされていることが多いですが、業務システムなら6か月〜1年を交渉する余地があります。瑕疵対応の費用負担を「当方判断」と書かれていると、ベンダー側に有償化される余地が広く残るため、「明らかな不具合は無償対応」と明文化してください。
瑕疵の定義そのものを契約書に書き込むことも有効です。「契約書に明記された業務要件を満たさない動作」を瑕疵と定義し、要件外の機能改善要望は瑕疵に含めないと両者で握っておけば、対応範囲をめぐる紛争が減ります。リリース直後の1か月間に集中して見つかる初期不良については、専用の窓口と対応SLAを別途設定する運用が現実的です。
解約領域：中途解約とデータ返還
中途解約の違約金が発注額の50%という条項は珍しくありません。トラブルでベンダーを変えたい場合に、違約金が発注額の半分になると経営判断が縛られます。違約金は「未着手分の20〜30%」程度に交渉するのが現実的です。
加えて、中途解約に至る原因がベンダー側の債務不履行（納期大幅遅延、品質不足など）にある場合は違約金が発生しない、という条項を入れるよう交渉してください。ベンダー側の責任に起因する解約まで違約金を取られる構造は、発注側にとって極めて不利な条件になります。
データ持ち出しの権利も大事です。解約時にベンダーがデータを返さない事故は実際に発生しています。「契約終了時はベンダーが14日以内にデータを発注側へ返還し、その後はベンダー側で速やかに消去する」と明記してください。返還形式（CSV・SQL dump・JSON等）まで指定すると、別ベンダーへの移行作業がスムーズになります。
保守領域：費用内容と縛り
保守契約の内容が曖昧だと、毎月の保守費用に「何が含まれるのか」が見えません。月額10万円の保守が、実は月1時間しか作業を含まないというケースもあります。発注前に「保守の範囲・対応時間・対応窓口・SLA」を契約書に書き込んでください。
具体的には「障害対応はベンダー責任で無償・機能追加は時間単価で別途・運用問合せは月8時間まで無償」のように、項目別に費用負担の枠組みを定義します。SLAも「平日9-18時の問合せには2営業日以内に1次回答」のような数値レベルまで落とし込まないと、運用フェーズで「すぐ返事が来ない」摩擦が発生します。
保守契約の3年縛りや自動更新も注意点です。リリース後にベンダーへの不満が出ても、縛りで解約できない構造になります。1年契約・1か月前通知での解約可能の条件を交渉してください。自動更新条項がある場合、更新前60日以内に再交渉できる窓を設ける文言を加えると、料金見直しの機会を確保できます。
経営者目線で考える「契約レビュー費用の投資対効果」
ここからは経営の話です。中小企業がシステム発注するとき、契約書を自社だけで読み込むのは現実的ではありません。法律の専門知識が必要な箇所が複数あり、見落としが致命傷になります。一方で、契約レビューを顧問弁護士や行政書士に依頼すると5〜20万円の費用がかかり、二の足を踏む経営者の方が多いのも事実です。
ぷらすわんの考え方は、発注金額の0.5〜1%を契約レビュー費用に充てることをお勧めしています。1,000万円の発注なら5〜10万円、3,000万円なら15〜30万円。これは契約レビューで発見できる損失リスクの規模を考えれば、十分にペイする投資です。
実際に、契約レビューで「瑕疵期間を3か月から1年に変更」「中途解約違約金を50%から20%に変更」「データ返還期間を14日に明文化」の3点だけ修正できれば、それだけで数百万円の損失回避効果が見込めます。レビュー費用の10倍以上のリターンが期待できる投資です。
経営者がやるべきは、契約レビューを「贅沢な追加コスト」ではなく「リスク管理の必要経費」と位置付け直すことです。社内に法務担当がいない中小企業ほど、外部の専門家を活用する判断が効きます。発注前に契約レビューの観点を項目別に整理することから始めるのが現実的です。
ぷらすわんの実例：契約論点の事前整理が交渉力を上げた事例
ぷらすわんの相談現場でよく見られるのが、「契約書のどこを直してほしいかが言えないので、雛形をそのまま受け入れた」というパターンです。ある建設業A社の場合、3,000万円規模のシステム発注で雛形を受け入れた結果、リリース後の追加要望が全て別途見積もりになり、最終的に4,200万円まで膨らんだ事例がありました。
リカバリーで相談に来られたとき、論点を5領域10項目で整理し直すと、本来は事前に交渉できた箇所が複数見えてきました。次回の発注では同じ枠組みで契約交渉を進めた結果、追加コスト発生時の負担割合が「ベンダー50：発注側50」に改善され、トラブル時の損失リスクが半分になりました。
中小企業の経営者にとって、契約交渉は「ベンダーと戦う場」ではなく、「お互いの認識を揃える場」です。5領域10項目を事前に整理して臨めば、ベンダー側も「この発注側は契約をきちんと見る会社だ」と認識し、雛形をそのまま渡すような扱いをしなくなります。手元の契約書について、確認すべき項目を診断する流れで進めるのが現実的です。
まとめ
システム契約で揉める論点は、検収・知財・瑕疵・解約・保守の5領域10項目に集約できます。ベンダー側が用意する雛形をそのまま受け入れるのではなく、自社にとって不利な条項を1つでも修正交渉する姿勢が、発注後のトラブルを防ぎます。
経営者がやるべきは、契約レビュー費用を「リスク管理の必要経費」と位置付け直すことです。発注金額の0.5〜1%を契約レビューに充てるだけで、損失回避効果は10倍以上に跳ね返ります。手元の契約書をどう確認すれば良いか整理したい経営者の方は、現状のチェック項目を比較を依頼する流れで進めるのが現実的です。