この記事でわかること
- システム開発の契約形態（請負・準委任・SES）の違い
- 契約書に盛り込むべき必須条項
- トラブルを防ぐための契約のポイント
- 多段階契約（工程別契約）の進め方
- 契約書の雛形と修正チェックリスト
システム開発の3つの契約形態
| 比較項目 | 請負契約 | 準委任契約 | SES契約 |
|---|---|---|---|
| 成果物の義務 | あり（完成責任） | なし（善管注意義務） | なし |
| 報酬の対象 | 成果物の納品 | 作業時間・工数 | エンジニアの稼働時間 |
| 瑕疵担保 | あり（契約不適合責任） | なし | なし |
| リスク | 開発会社が負う | 発注者が負う | 発注者が負う |
| 向いている工程 | 要件が明確な開発 | 要件定義・設計・保守 | 人手不足の補充 |
| 費用の予測 | しやすい（固定価格） | しにくい（時間精算） | しにくい |
工程別の推奨契約形態
| 工程 | 推奨契約 | 理由 |
|---|---|---|
| 要件定義 | 準委任 | 成果物が不明確、試行錯誤が必要 |
| 基本設計 | 準委任 or 請負 | 設計書を成果物とする場合は請負 |
| 詳細設計・開発 | 請負 | 仕様が確定しているため完成責任を求められる |
| テスト | 請負 | テスト結果報告書が成果物 |
| 保守運用 | 準委任 | 継続的な作業、成果物の定義が困難 |
システム開発でよくあるトラブルは「全工程を一括請負で契約する」パターンです。要件が固まっていない段階で請負契約にすると、後から仕様変更が発生した際に「契約範囲外」と言われ、追加費用が発生します。要件定義は準委任、開発は請負の「多段階契約」が最も安全です。
契約書の必須条項
①業務範囲（スコープ）
- 開発する機能の一覧（機能一覧表を別紙で添付）
- 対象外の範囲を明記（「本契約に含まれない事項」）
- 仕様変更時の手続き（変更管理プロセス）
②納期・マイルストーン
- 各工程の開始日・終了日
- マイルストーン（中間成果物の提出日）
- 遅延時のペナルティ or 対応方法
③報酬・支払条件
| 支払パターン | 内容 | リスク |
|---|---|---|
| 一括払い | 納品後に全額支払い | 開発会社のキャッシュフローリスク |
| マイルストーン払い | 工程完了ごとに分割 | 最もバランスが良い（推奨） |
| 月額精算 | 毎月稼働時間で精算 | 総額が予測しにくい |
④知的財産権
- 著作権: 開発成果物の著作権が発注者に帰属するか（必須確認）
- ソースコード: 納品物にソースコードが含まれるか
- 既存ライブラリ: 開発会社の既存資産の利用条件
⑤契約不適合責任（旧：瑕疵担保）
- 契約不適合（バグ・仕様との不一致）の修補義務
- 通知期間：納品後1年以内（民法改正後のデフォルト）
- 修補の範囲：無料対応の範囲と有料対応の範囲
⑥秘密保持
- 秘密情報の定義と管理義務
- 別途NDAを締結する場合はその旨を記載
⑦損害賠償
- 賠償額の上限（一般的に契約金額を上限とする）
- 間接損害・逸失利益の扱い
⑧解約条件
- 中途解約の条件と違約金
- 解約時の成果物の取扱い（途中までの成果物の帰属）
多段階契約の進め方
Phase 1: 基本契約の締結
- 取引の基本ルール（秘密保持、知的財産、損害賠償等）を規定
- 個別の開発案件は「個別契約」で対応
Phase 2: 工程ごとの個別契約
- 要件定義契約（準委任）: 2〜4週間、100〜300万円
- 設計・開発契約（請負）: 2〜6ヶ月、要件定義の結果に基づき見積もり
- テスト契約（請負）: 2〜4週間
- 保守運用契約（準委任）: 月額制、年単位
各工程で「ゲートレビュー」を実施
工程の切り替え時に成果物をレビューし、次の工程に進むか判断。問題があれば次の工程に進まない（=次の個別契約を締結しない）選択ができます。
契約書でよく見落とされるのが「仕様変更の手続き」です。開発中に仕様変更が1件も発生しないプロジェクトはありません。「仕様変更は書面で依頼→影響分析（費用・期間）→双方合意→実行」のフローを契約書に明記してください。口頭での仕様変更依頼は、後から「言った・言わない」のトラブルの原因になります。
契約トラブル予防の5つの鉄則
鉄則①: 要件定義書を契約書の別紙にする
口頭の合意は証拠になりません。機能一覧表・画面遷移図・非機能要件を契約書の別紙として添付し、双方が署名してください。
鉄則②: 仕様変更の手続きを明文化
「仕様変更は書面で依頼→影響分析→費用・期間の合意→実行」のフローを契約書に明記。口頭での変更依頼は「言った・言わない」のトラブルの原因。
鉄則③: 中間成果物のレビューポイントを設定
要件定義完了時、基本設計完了時、開発50%時点など、中間レビューのタイミングを契約に含め、問題の早期発見・是正を可能にしてください。
鉄則④: 著作権の帰属を明記
デフォルトでは著作権は開発会社に帰属します。「本契約に基づく成果物の著作権は、発注者に帰属する」と明記してください。
鉄則⑤: 契約書のリーガルチェック
3〜10万円で弁護士にチェックを依頼できます。数百万円のプロジェクトで3万円のリーガルチェックを省くのはリスクに見合いません。
まとめ
- 要件定義は準委任、開発は請負の「多段階契約」が最も安全
- 契約書に業務範囲・仕様変更手続き・知的財産権・契約不適合責任を必ず含める
- 支払いはマイルストーン払いが最もリスクバランスが良い
- 著作権の帰属は必ず「発注者」と明記（デフォルトでは開発会社に帰属）
- 契約書は弁護士のリーガルチェックを推奨（費用3〜10万円）
システム開発の契約相談は、お問い合わせからお気軽にどうぞ。
<script type="application/ld+json">{"@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [{"@type": "Question", "name": "各工程で「ゲートレビュー」を実施", "acceptedAnswer": {"@type": "Answer", "text": "工程の切り替え時に成果物をレビューし、次の工程に進むか判断。問題があれば次の工程に進まない（=次の個別契約を締結しない）選択ができます。"}}, {"@type": "Question", "name": "鉄則①: 要件定義書を契約書の別紙にする", "acceptedAnswer": {"@type": "Answer", "text": "口頭の合意は証拠になりません。機能一覧表・画面遷移図・非機能要件を契約書の別紙として添付し、双方が署名してください。"}}, {"@type": "Question", "name": "鉄則②: 仕様変更の手続きを明文化", "acceptedAnswer": {"@type": "Answer", "text": "「仕様変更は書面で依頼→影響分析→費用・期間の合意→実行」のフローを契約書に明記。口頭での変更依頼は「言った・言わない」のトラブルの原因。"}}, {"@type": "Question", "name": "鉄則③: 中間成果物のレビューポイントを設定", "acceptedAnswer": {"@type": "Answer", "text": "要件定義完了時、基本設計完了時、開発50%時点など、中間レビューのタイミングを契約に含め、問題の早期発見・是正を可能にしてください。"}}, {"@type": "Question", "name": "鉄則④: 著作権の帰属を明記", "acceptedAnswer": {"@type": "Answer", "text": "デフォルトでは著作権は開発会社に帰属します。「本契約に基づく成果物の著作権は、発注者に帰属する」と明記してください。"}}]}</script>よくある質問
システム開発の契約で注意すべきポイントは？
成果物の定義、検収条件、瑕疵担保（契約不適合責任）の範囲と期間、知的財産権の帰属を明確にすることが重要です。口頭の合意ではなく、必ず書面で取り決めましょう。
請負契約と準委任契約、どちらを選ぶべき？
完成物が明確に定義できる場合は請負契約、要件が流動的な場合やアジャイル開発には準委任契約が適しています。工程ごとに契約形態を変える「多段階契約」も有効な選択肢です。
開発途中でトラブルが起きた場合の対処法は？
まずは契約書の紛争解決条項を確認しましょう。多くの場合、協議→調停→裁判の流れです。トラブルを防ぐためには、定期的な進捗報告と議事録の作成を契約時に取り決めておくことが重要です。
この記事をシェア