IPA「ソフトウェア開発データ白書」および経済産業省「情報システムの信頼性向上のための取引慣行・契約に関する研究会」の報告によると、システム開発のトラブルの約40%が「契約内容の不明確さ」に起因している。特に中小企業では、ベンダーが提示する契約書をそのまま締結してしまい、後からトラブルになるケースが後を絶たない。
2020年施行の改正民法により、従来の「瑕疵担保責任」が「契約不適合責任」に変更され、権利行使の期間や要件が変わった。この改正を反映した契約書になっているかの確認も重要だ。本記事では、システム開発の契約書で発注者が確認すべき20のチェックポイントを解説する。
目次
- システム開発契約の種類
- 契約書チェックリスト20項目
- 瑕疵担保責任（契約不適合責任）の確認ポイント
- 知的財産権の確認ポイント
- 支払い条件の確認ポイント
- よくあるトラブルと契約での予防策
- まとめ
- FAQ
1. システム開発契約の種類
契約形態の比較
| 契約形態 | 内容 | リスク負担 | 向いているフェーズ |
|---|---|---|---|
| 請負契約 | 成果物の完成を約束。完成しなければ報酬を支払わない | ベンダー側が高い | 設計・開発・テスト |
| 準委任契約 | 業務の遂行を約束。成果物の完成義務なし | 発注者側が高い | 要件定義・コンサルティング・運用 |
| 派遣契約 | 指揮命令権が発注者にある | 発注者側が高い | エンジニアの一時的な補充 |
多段階契約の推奨
IPA「情報システム・モデル取引・契約書」では、開発工程ごとに契約を分けることを推奨している。
| 工程 | 推奨契約形態 | 理由 |
|---|---|---|
| 要件定義 | 準委任契約 | 成果物が確定しにくい |
| 基本設計 | 準委任契約 or 請負契約 | 設計書の完成で判断する場合は請負 |
| 詳細設計・開発 | 請負契約 | 成果物（プログラム）が明確 |
| テスト | 請負契約 | テスト完了基準が明確 |
| 運用・保守 | 準委任契約 | 継続的な業務遂行 |
2. 契約書チェックリスト20項目
全20項目の一覧
| # | カテゴリ | チェック項目 | 重要度 |
|---|---|---|---|
| 1 | 基本事項 | 契約形態（請負/準委任/混合）が明記されているか | ★★★ |
| 2 | 基本事項 | 契約の対象範囲（スコープ）が具体的に定義されているか | ★★★ |
| 3 | 基本事項 | 成果物の一覧と各成果物の検収基準が明記されているか | ★★★ |
| 4 | 支払い | 支払い条件（金額、タイミング、分割方法）が明確か | ★★★ |
| 5 | 支払い | 追加費用が発生する条件と上限が定義されているか | ★★★ |
| 6 | 支払い | 検収後の支払い期限が明記されているか | ★★☆ |
| 7 | 品質保証 | 契約不適合責任（旧・瑕疵担保責任）の期間が定義されているか | ★★★ |
| 8 | 品質保証 | 契約不適合の場合の対応（修補、代金減額、損害賠償）が明記されているか | ★★★ |
| 9 | 品質保証 | テスト（単体、結合、総合、受入）の実施責任が明確か | ★★☆ |
| 10 | 知的財産 | 成果物の著作権の帰属先が明記されているか | ★★★ |
| 11 | 知的財産 | ベンダーが保有する既存部品（ライブラリ等）の扱いが定義されているか | ★★★ |
| 12 | 知的財産 | ソースコードの引き渡しが契約に含まれているか | ★★★ |
| 13 | 秘密保持 | 秘密情報の定義と保持期間が明記されているか | ★★☆ |
| 14 | 秘密保持 | 再委託先への秘密保持義務の適用が明記されているか | ★★☆ |
| 15 | 変更管理 | 要件変更の手続き（変更管理プロセス）が定義されているか | ★★★ |
| 16 | スケジュール | 納期と各マイルストーンの期日が明記されているか | ★★☆ |
| 17 | スケジュール | 遅延時のペナルティまたは対応が定義されているか | ★★☆ |
| 18 | 解約 | 中途解約の条件と手続きが明記されているか | ★★☆ |
| 19 | 責任制限 | 損害賠償の上限額が定義されているか | ★★★ |
| 20 | 紛争解決 | 紛争時の管轄裁判所または仲裁機関が指定されているか | ★☆☆ |
3. 瑕疵担保責任（契約不適合責任）の確認ポイント
改正民法のポイント
| 項目 | 旧民法（2020年3月以前） | 改正民法（2020年4月以降） |
|---|---|---|
| 名称 | 瑕疵担保責任 | 契約不適合責任 |
| 対象 | 隠れた瑕疵 | 契約内容に適合しない場合 |
| 発注者の権利 | 修補請求、損害賠償、解除 | 修補請求、代金減額、損害賠償、解除 |
| 権利行使の期限 | 瑕疵を知ってから1年以内に「権利行使」 | 不適合を知ってから1年以内に「通知」 |
| 任意規定 | 契約で変更可能 | 契約で変更可能 |
契約書で確認すべきポイント
| チェック項目 | 推奨内容 |
|---|---|
| 責任期間 | 検収後12ヶ月以上（ベンダーは3〜6ヶ月を主張することが多い） |
| 対象範囲 | 「仕様書に記載された要件に適合しない場合」と明記 |
| 対応方法 | 修補→代金減額→損害賠償の順で段階的に定義 |
| 修補の期限 | 通知後30日以内の修補完了を目安 |
4. 知的財産権の確認ポイント
著作権の帰属パターン
| パターン | 内容 | メリット | デメリット |
|---|---|---|---|
| 発注者帰属 | 成果物の著作権をすべて発注者に譲渡 | 自由に改変・二次利用できる | 費用が高くなる傾向 |
| ベンダー帰属 | 著作権はベンダーが保有、発注者に利用権を許諾 | 費用が抑えられる | ベンダー変更時に制約 |
| 共同帰属 | 発注者とベンダーで共有 | 双方が利用可能 | 運用が複雑になる |
確認すべき具体的なポイント
| チェック項目 | 推奨内容 |
|---|---|
| カスタム開発部分の著作権 | 発注者に帰属（または独占的利用権） |
| ベンダーの既存ライブラリ | ベンダー保有のまま、利用許諾を受ける |
| OSSの利用 | 利用しているOSSのライセンス一覧の提出を求める |
| ソースコードの引き渡し | 必ず契約に含める。納品物リストに明記 |
5. 支払い条件の確認ポイント
支払い方式の比較
| 方式 | 内容 | 発注者のリスク | 推奨ケース |
|---|---|---|---|
| 一括払い | 検収後に全額支払い | 低 | 小規模プロジェクト |
| マイルストーン払い | 工程完了ごとに分割支払い | 中 | 中〜大規模プロジェクト |
| 前払い＋残金 | 着手金（20〜30%）＋検収後残金 | 中 | 一般的な中規模プロジェクト |
| 月額払い | 毎月固定額を支払い | 高 | 準委任契約（要件定義・運用） |
追加費用のトラブル防止
| チェック項目 | 推奨内容 |
|---|---|
| 追加費用の発生条件 | 「発注者の要件変更による場合のみ」と限定 |
| 見積もりの根拠 | 人月単価×工数の内訳を求める |
| 変更管理プロセス | 書面による合意なしに追加費用を請求しない旨を明記 |
| 上限額 | 追加費用の合計上限を設定（例：当初契約金額の20%以内） |
6. よくあるトラブルと契約での予防策
| トラブル事例 | 根本原因 | 契約での予防策 |
|---|---|---|
| 納品物にバグが多い | 検収基準が曖昧 | 検収基準（テストケース合格率等）を契約に明記 |
| ベンダーロックイン | ソースコード未引渡し、著作権がベンダー | ソースコード引渡し・著作権譲渡を契約に含める |
| 追加費用が膨らむ | 変更管理プロセスの欠如 | 変更管理手順と追加費用の上限を契約に定義 |
| ベンダーが途中で撤退 | 解約条件の不備 | 中途解約時の成果物引渡し・精算条件を明記 |
| 情報漏えい | 再委託先の管理不足 | 再委託の事前承認制と秘密保持義務の適用を明記 |
| 納期遅延 | 遅延ペナルティの未設定 | 遅延1日あたり契約金額の0.1%等のペナルティを設定 |
7. まとめ
システム開発契約書の確認で最も重要なポイントは以下の3つだ。
- 契約不適合責任の期間と内容：検収後12ヶ月以上を確保し、修補・代金減額の条件を明記する
- 知的財産権の帰属：カスタム開発部分の著作権とソースコードの引渡しを確保する
- 変更管理と追加費用の上限：書面合意なしの費用追加を防ぐ条項を入れる
システム開発のご相談・契約に関するお問い合わせはお問い合わせフォームよりお気軽にどうぞ。
8. FAQ
Q1. 契約書のレビューを弁護士に依頼する費用はいくらですか？
契約書のリーガルチェックは5〜20万円が相場だ。IT業界に精通した弁護士に依頼することを推奨する。契約金額が1,000万円以上のプロジェクトでは、弁護士費用は十分に投資に見合う。
Q2. ベンダーが提示する契約書をそのまま締結してもよいですか？
推奨しない。ベンダーが提示する契約書はベンダーに有利な条項（瑕疵担保期間の短縮、著作権のベンダー帰属、損害賠償の上限設定等）が含まれていることが多い。本記事のチェックリストを使って確認し、必要な修正を求めるべきだ。
Q3. 請負契約と準委任契約のどちらが有利ですか？
一概にはいえないが、成果物が明確なフェーズ（開発・テスト）は請負契約、成果物が不確定なフェーズ（要件定義・コンサルティング）は準委任契約が適切だ。請負契約は成果物の完成義務があるため発注者にとって有利だが、ベンダー側のリスクが高くなるため見積もりが高くなる傾向がある。
Q4. 契約不適合責任の期間は何ヶ月が妥当ですか？
発注者としては12ヶ月以上を確保したい。ベンダーは3〜6ヶ月を主張するケースが多いが、システムの不具合は運用開始後6ヶ月以上経ってから発覚するケースもある。交渉のポイントは「重大な不適合」と「軽微な不適合」で期間を分けることだ。
Q5. ソースコードの引渡しを拒否された場合はどうすればよいですか？
著作権をベンダーに残す場合でも、ソースコードの引渡し自体は契約に含めるべきだ。引渡しを拒否する場合は、エスクロー（第三者預託）の仕組みを検討する。ベンダーが倒産した場合にソースコードを受け取れるようにする保険的な措置だ。
GXO実務追記: システム開発・DX投資で発注前に確認すべきこと
この記事のテーマは、単なるトレンド紹介ではなく、要件定義、費用、開発体制、ベンダー選定、保守運用を決めるための検討材料です。検索で情報収集している段階でも、発注前に次の観点を整理しておくと、見積もりのブレ、手戻り、ベンダー依存を減らせます。
まず決めるべき3つの論点
| 論点 | 確認する内容 | 未整理のまま進めた場合のリスク |
|---|---|---|
| 目的 | 売上拡大、工数削減、リスク低減、顧客体験改善のどれを優先するか | 成果指標が曖昧になり、PoCや開発が終わっても投資判断できない |
| 範囲 | 対象部署、対象業務、対象データ、対象システムをどこまで含めるか | 見積もりが膨らむ、または重要な連携が後から漏れる |
| 体制 | 自社責任者、現場担当、ベンダー、保守運用者をどう置くか | 要件確認が遅れ、納期遅延や品質低下につながる |
費用・期間・体制の目安
| フェーズ | 期間目安 | 主な成果物 | GXOが見るポイント |
|---|---|---|---|
| 事前診断 | 1〜2週間 | 課題整理、現行確認、投資判断メモ | 目的と範囲が商談前に整理されているか |
| 要件定義 / 設計 | 3〜6週間 | 要件一覧、RFP、概算見積、ロードマップ | 見積比較できる粒度になっているか |
| PoC / MVP | 1〜3ヶ月 | 検証環境、効果測定、リスク評価 | 本番化判断に必要な数値が取れるか |
| 本番導入 | 3〜6ヶ月 | 本番環境、運用設計、教育、改善計画 | 導入後の運用責任と改善サイクルがあるか |
発注前チェックリスト
- [ ] 発注前に目的、対象業務、利用者、現行課題を1枚に整理したか
- [ ] 必須要件、将来要件、今回はやらない要件を分けたか
- [ ] 見積比較で、開発費だけでなく保守費、運用費、追加改修費を見たか
- [ ] ベンダー選定で、体制、実績、品質管理、セキュリティ、引継ぎ条件を確認したか
- [ ] 検収条件を機能、性能、セキュリティ、ドキュメントで定義したか
- [ ] リリース後3ヶ月の改善運用と責任分界を決めたか
参考にすべき一次情報・公的情報
上記の一次情報は、社内稟議やベンダー比較の根拠として使えます。一方で、公開情報だけでは自社の現行システム、業務フロー、データ状態、予算制約までは判断できません。記事で一般論を把握した後は、自社条件に落とした診断が必要です。
GXOに相談するタイミング
次のいずれかに当てはまる場合は、記事を読み進めるだけでなく、早めに相談した方が安全です。
- 見積もり依頼前に、要件やRFPの粒度を整えたい
- 既存ベンダーの提案が妥当か第三者視点で確認したい
- 補助金、AI、セキュリティ、レガシー刷新が絡み、判断軸が複雑になっている
- 社内稟議で費用対効果、リスク、ロードマップを説明する必要がある
- PoCや診断で終わらせず、本番導入と運用改善まで進めたい
システム開発の契約書チェックリスト｜瑕疵担保・知的財産・支払い条件の確認ポイント20項目を自社条件で診断したい方へ
GXOが、現状整理、RFP/要件定義、費用対効果、ベンダー比較、導入ロードマップまで実務目線で確認します。記事の一般論を、自社の投資判断に使える形へ落とし込みます。
※ 初回相談では営業資料の説明よりも、現状・課題・判断材料の整理を優先します。