システム開発の契約書を初めて読むと、多くの経営者が「専門用語が多くて全部読み解けない」と感じるはずです。実は、中小企業の発注で本当に揉めるのは、表面の文言ではなく契約構造の中に埋め込まれた「3つの罠」です。本記事では、ぷらすわんが相談現場で繰り返し見てきた契約書の罠を3つに絞り、それぞれの正体と回避方法を経営者目線で解説します。
この記事の結論（3行）
- 罠は3つに集約される：準委任契約の責任所在・知財帰属の逆転条項・損害賠償の上限
- どれも契約書の文面では分かりにくく、トラブルが発生してから気づくケースが大半
- 発注前に3点だけチェックすれば、致命的なリスクの大半は事前に避けられる
契約書の文言が読みづらい本当の理由
中小企業の経営者が契約書を読むときに感じる「読みづらさ」は、語彙の問題だけではありません。契約書は「平時の合意事項」だけでなく「有事のリスク配分」を文書化したもので、後者が読み手にとって直感に反する書き方になっているからです。
- 平時はベンダーと発注側の合意で進むので、契約書を読まなくても問題が起きない
- 有事になって初めて、契約書のリスク配分が効いてくる
- リスク配分は「不利益をどちらが負うか」の話で、発注側が損する設計になっていることがある
契約書を「揉めた時の取り決め」と捉え直すと、見るべきポイントが明確になります。揉めるのは検収・知財・瑕疵・解約・損害賠償の5領域ですが、その中でも特に中小企業が見落としやすい「3つの罠」が存在します。
平時の文言は読みやすい
「乙は甲が指示する業務を、善良な管理者の注意義務をもって遂行する」のような平時の文言は、読んでも違和感がありません。問題は、平時の合意の下に有事のリスク配分が埋め込まれている構造です。
有事の文言は遠回しに書かれる
「乙は本件業務の遂行に関し、甲に対して結果について責任を負わないものとする」のような有事条項は、専門用語で遠回しに書かれているため、読み流してしまいがちです。実はこれが「成果が出なくても費用は払う」という重大な条項です。
リスク配分の見方を持つこと
契約書を読むときは、「トラブルが起きた時に誰が不利益を被るか」を1条ごとに考えてください。この視点を持つだけで、罠への感度が上がります。
罠1：準委任契約の責任所在
最も見落とされやすいのが、契約形態が「請負」ではなく「準委任」になっているケースです。
| 観点 | 請負契約 | 準委任契約 | |---|---|---| | 成果物の保証 | あり（仕様通り完成させる義務） | なし（業務遂行を約束するだけ） | | 検収 | 仕様充足が必要 | 業務遂行で完了 | | 報酬支払い | 完成後 | 業務遂行に応じて支払い | | 不具合対応 | ベンダー側に直す義務 | 別途追加費用 | | 中小企業向け | おすすめ | 上級者向け |
準委任契約は「業務遂行を約束する」契約形態で、成果物の完成保証がありません。アジャイル開発で広く使われており、それ自体は悪い契約形態ではありません。ただし発注経験の少ない中小企業が「請負だと思って準委任契約に判子を押す」と、システムが想定通りに動かなくても費用を払い続ける構造になります。
契約書の冒頭で「請負」「準委任」「業務委託」の文言を必ず確認してください。「業務委託」は包括用語で、内訳が請負か準委任か分からないため、本文を読み込む必要があります。準委任契約を結ぶ場合は、別途「成果報酬条項」「マイルストーン承認」を追加することで、業務遂行責任に成果連動性を持たせる工夫ができます。発注前に契約形態の判断軸を整理したい場合は、業務改善・システム見積もりAI適正診断で契約形態の選び方を洗い出せます。
請負契約の特徴
請負契約は、ベンダーが「仕様書通りに完成させる」義務を負います。完成しない場合は瑕疵担保責任が発生し、ベンダー側で修正する義務があります。中小企業の発注ではこちらが基本です。
準委任契約の特徴
準委任契約は、ベンダーが「善良な管理者の注意義務をもって業務を遂行する」だけで、成果物の完成義務はありません。仕様変更が頻繁に発生するアジャイル開発に向く反面、発注側にプロジェクト管理能力が求められます。
中小企業がやるべきこと
社内にPMOやプロジェクトマネジメント経験者がいない中小企業は、原則として請負契約を選ぶか、準委任の場合でも「成果報酬条項」を追加してください。マイルストーン承認を要求する条項を入れるだけでも、発注側のリスクが大きく減ります。
罠2：知財帰属の逆転条項
2つ目の罠は、知財帰属が「逆転」している条項です。
雛形では「成果物の著作権は乙（ベンダー）に帰属する」と書かれているケースが多くあります。これは一見ベンダー側に有利な条項に見えますが、実はそれを上回る逆転的な意味を持っています。著作権がベンダー側にあると、発注側は「自社のシステム」のはずなのに、改修・別ベンダーへの委託・社外公開ができなくなります。
例えば、3年後にベンダーAが廃業した場合、発注側はソースコードを別ベンダーBに渡して改修を依頼することができません。理由は、著作権がベンダーAにあり、別ベンダーが触れることが著作権侵害になるためです。これがリリース後数年経ってから発覚すると、システムを再構築するしか道がなくなります。
知財帰属の交渉は、必ず「発注側帰属」を基本にしてください。ベンダー側が「他社案件でも使う共通モジュールが含まれる」場合は、その部分のみ「ベンダーが再利用権を保持し、発注側に使用権を付与」という形で切り分けできます。全てを一括でベンダー帰属にする条項は、発注側に重大な制約をかけるため、修正交渉が必要です。
著作権はなぜ重要か
著作権は「複製・改変・公衆送信」の権利を独占的に保有する権利です。著作権を持たないと、ソースコードを別ベンダーに渡すことすらできません。
「使用権」だけでは不十分
ベンダー側から「著作権はベンダー保持だが、発注側に永久使用権を付与する」と提案されるケースがあります。これは使用権だけでは「改変」が含まれないため、結局別ベンダーで改修ができません。「改変・複製・別ベンダーへの委託権」を含む条項を要求してください。
共通モジュールの切り分け方
ベンダー側が「他社でも使う共通モジュールがある」と主張する場合は、その部分だけリスト化してもらい、別契約で扱う形が現実的です。本案件で個別に作る部分は発注側帰属、共通部分はベンダー帰属、と切り分けてください。
罠3：損害賠償の上限設定
3つ目の罠は、損害賠償の上限が極端に低く設定されている条項です。雛形では「乙の損害賠償の上限は、本件業務の対価相当額を限度とする」と書かれていることが多くあります。
この条項の意味は、ベンダーの過失で発注側に重大な損害が発生しても、賠償額は契約金額が上限になるということです。例えば1,000万円の発注で、ベンダーのバグにより顧客データが流出し1億円の損害が発生しても、ベンダーから受け取れる賠償は最大1,000万円までになります。残り9,000万円は発注側の負担です。
これは中小企業にとって深刻なリスクです。特に顧客の個人情報や決済情報を扱うシステムでは、データ流出時の損害が契約金額の10倍以上になることが珍しくありません。賠償上限を契約金額の3倍、もしくは「故意・重過失の場合は上限なし」とする条項を交渉してください。
上限が低い理由
ベンダー側は事業継続のために、賠償リスクを契約金額以下に抑えたい立場です。これ自体は理解できる主張ですが、発注側のリスクを丸ごと引き受ける条項は不公平です。
故意・重過失の例外
法律上は、故意や重過失による損害は賠償上限の例外とすることが認められています。「ただし故意または重過失による場合はこの限りでない」の文言を加えるだけで、ベンダー側の杜撰な対応に対する抑止力が働きます。
サイバー保険の活用
賠償上限を引き上げる交渉が難しい場合は、ベンダーにサイバー保険への加入を条件にする方法があります。ベンダーが保険を持っていれば、賠償上限を超える部分も保険でカバーできる可能性が出てきます。サイバー保険の保険証券のコピーを契約添付資料として取り寄せ、保証対象事故と保証上限額を契約期間中ずっと維持する義務をベンダーに課す形にすると、抜け道を防げます。
加えて、発注側もサイバー保険に加入しておくと二重の備えになります。中小企業向けのサイバー保険は年間保険料10〜30万円から加入でき、顧客データを扱うシステムを発注する経営者には現実的な選択肢です。ベンダー側と発注側の双方が保険でカバーする構造を作っておくと、事故発生時の経営判断に余裕が生まれます。
経営者目線で考える「3つの罠を避ける投資判断」
ここからは経営の話です。3つの罠を全て契約交渉で外そうとすると、ベンダー側との交渉時間と弁護士レビュー費用が発生します。経営者がやるべきは、「どこまで交渉するか」の優先順位を決めることです。
ぷらすわんがお勧めする優先順位は、第一に「契約形態（請負か準委任か）」、第二に「知財帰属」、第三に「損害賠償上限」の順です。理由は、契約形態は契約全体の骨組みを決める要素で、ここを間違えると他の条項を直しても効果が限定的だからです。知財帰属は3〜5年後にリスクが顕在化する性質で、損害賠償上限は事故発生時の致命傷になる性質です。
3つ全てを完璧に交渉する必要はありません。優先順位の高いものから1つずつ整えれば、発注リスクの大半は減らせます。発注金額が1,000万円を超える案件では、弁護士レビュー費用5〜10万円を投入する価値が十分にあります。レビューで罠を1つ外せれば、それだけで数百万円〜数千万円の損失回避効果が見込めます。
経営者が見落としやすいのは、「契約レビューは社内の法務担当でも十分」という思い込みです。社内の法務担当者がいても、システム契約に固有の論点（例えば準委任契約のリスク、OSSライセンスの扱い、データ返還の手順）は、IT特化の弁護士でなければ気づかない部分があります。手元の契約書について、確認すべき論点を項目別に整理することから始めるのが現実的です。
ぷらすわんの実例：3つの罠を回避した契約交渉
ぷらすわんの相談現場で、3つの罠を回避できた事例をお伝えします。あるサービス業A社の場合、初回発注時に「請負契約」と思っていた契約が実は「準委任契約」で、リリース後にバグが多発しても全て追加費用を請求された苦い経験がありました。
リカバリーで新たな発注を進める際、契約レビューを弁護士に依頼し、3点を交渉しました。第一に契約形態を請負に変更、第二に著作権を発注側帰属に変更、第三に損害賠償上限を契約金額の3倍に引き上げ。弁護士レビュー費用は8万円、契約交渉の追加期間は2週間でした。
結果として、リリース後に発生した想定外バグの修正は全てベンダー側の責任範囲で対応され、追加費用は発生しませんでした。8万円の投資で、当初想定していた追加費用200〜300万円を回避できた計算になります。3つの罠への対策は、コストではなく投資として考える視点が経営者には必要です。手元の契約書について、罠の有無を診断する流れで進めるのが現実的です。
まとめ
システム開発契約書には、準委任契約の責任所在・知財帰属の逆転条項・損害賠償の上限設定という3つの罠が潜んでいます。どれも契約書の表面では分かりにくく、トラブルが発生してから気づくケースが大半です。発注前に3点だけチェックすれば、致命的なリスクの大半は事前に避けられます。
経営者がやるべきは、3つの罠を「優先順位を付けて1つずつ交渉する」姿勢を持つことです。全てを完璧に交渉する必要はありません。発注金額1,000万円以上の案件では、弁護士レビュー費用5〜10万円を投入することで、損失回避効果が10倍以上に跳ね返ります。手元の契約書をどう見直せばよいか整理したい経営者の方は、現状のチェック軸を比較を依頼する流れで進めるのが現実的です。