システム開発の契約ガイド｜請負・準委任・SESの違いと注意点

システム開発の3つの契約形態

比較項目	請負契約	準委任契約	SES契約
成果物の義務	あり（完成責任）	なし（善管注意義務）	なし
報酬の対象	成果物の納品	作業時間・工数	エンジニアの稼働時間
瑕疵担保	あり（契約不適合責任）	なし	なし
リスク	開発会社が負う	発注者が負う	発注者が負う
向いている工程	要件が明確な開発	要件定義・設計・保守	人手不足の補充
費用の予測	しやすい（固定価格）	しにくい（時間精算）	しにくい

工程別の推奨契約形態

工程	推奨契約	理由
要件定義	準委任	成果物が不明確、試行錯誤が必要
基本設計	準委任 or 請負	設計書を成果物とする場合は請負
詳細設計・開発	請負	仕様が確定しているため完成責任を求められる
テスト	請負	テスト結果報告書が成果物
保守運用	準委任	継続的な作業、成果物の定義が困難

契約書の必須条項

①業務範囲（スコープ）

• 開発する機能の一覧（機能一覧表を別紙で添付）
• 対象外の範囲を明記（「本契約に含まれない事項」）
• 仕様変更時の手続き（変更管理プロセス）

②納期・マイルストーン

• 各工程の開始日・終了日
• マイルストーン（中間成果物の提出日）
• 遅延時のペナルティ or 対応方法

③報酬・支払条件

支払パターン	内容	リスク
一括払い	納品後に全額支払い	開発会社のキャッシュフローリスク
マイルストーン払い	工程完了ごとに分割	最もバランスが良い（推奨）
月額精算	毎月稼働時間で精算	総額が予測しにくい

④知的財産権

• 著作権: 開発成果物の著作権が発注者に帰属するか（必須確認）
• ソースコード: 納品物にソースコードが含まれるか
• 既存ライブラリ: 開発会社の既存資産の利用条件

⑤契約不適合責任（旧：瑕疵担保）

• 契約不適合（バグ・仕様との不一致）の修補義務
• 通知期間：納品後1年以内（民法改正後のデフォルト）
• 修補の範囲：無料対応の範囲と有料対応の範囲

⑥秘密保持

• 秘密情報の定義と管理義務
• 別途NDAを締結する場合はその旨を記載

⑦損害賠償

• 賠償額の上限（一般的に契約金額を上限とする）
• 間接損害・逸失利益の扱い

⑧解約条件

• 中途解約の条件と違約金
• 解約時の成果物の取扱い（途中までの成果物の帰属）

多段階契約の進め方

Phase 1: 基本契約の締結

• 取引の基本ルール（秘密保持、知的財産、損害賠償等）を規定
• 個別の開発案件は「個別契約」で対応

Phase 2: 工程ごとの個別契約

1. 要件定義契約（準委任）: 2〜4週間、100〜300万円
2. 設計・開発契約（請負）: 2〜6ヶ月、要件定義の結果に基づき見積もり
3. テスト契約（請負）: 2〜4週間
4. 保守運用契約（準委任）: 月額制、年単位

各工程で「ゲートレビュー」を実施

工程の切り替え時に成果物をレビューし、次の工程に進むか判断。問題があれば次の工程に進まない（=次の個別契約を締結しない）選択ができます。

契約トラブル予防の5つの鉄則

鉄則①: 要件定義書を契約書の別紙にする

口頭の合意は証拠になりません。機能一覧表・画面遷移図・非機能要件を契約書の別紙として添付し、双方が署名してください。

鉄則②: 仕様変更の手続きを明文化

「仕様変更は書面で依頼→影響分析→費用・期間の合意→実行」のフローを契約書に明記。口頭での変更依頼は「言った・言わない」のトラブルの原因。

鉄則③: 中間成果物のレビューポイントを設定

要件定義完了時、基本設計完了時、開発50%時点など、中間レビューのタイミングを契約に含め、問題の早期発見・是正を可能にしてください。

鉄則④: 著作権の帰属を明記

デフォルトでは著作権は開発会社に帰属します。「本契約に基づく成果物の著作権は、発注者に帰属する」と明記してください。

鉄則⑤: 契約書のリーガルチェック

3〜10万円で弁護士にチェックを依頼できます。数百万円のプロジェクトで3万円のリーガルチェックを省くのはリスクに見合いません。

あわせて読みたい

• システム開発のNDA（秘密保持契約）｜テンプレートと締結時の注意点
• システム開発トラブルの法的対応｜瑕疵担保・損害賠償・契約解除
• SES契約と派遣の違い｜偽装請負のリスクと適切な活用方法
• システム開発の検収・納品ガイド｜検収基準の決め方とトラブル防止策
• SLA（サービスレベル契約）の決め方｜システム運用保守で押さえるべき指標と条項
• システム開発の見積書の読み方｜費用の妥当性チェックと比較のポイント

このテーマの関連記事

「IT契約・法務」をさらに深掘りする記事をまとめました。

• システム開発のNDA（秘密保持契約）｜テンプレートと締結時の注意点
• システム開発トラブルの法的対応｜瑕疵担保・損害賠償・契約解除
• SES契約と派遣の違い｜偽装請負のリスクと適切な活用方法
• システム開発の検収・納品ガイド｜検収基準の決め方とトラブル防止策
• SLA（サービスレベル契約）の決め方｜システム運用保守で押さえるべき指標と条項
• システム開発の見積書の読み方｜費用の妥当性チェックと比較のポイント

まとめ

• 要件定義は準委任、開発は請負の「多段階契約」が最も安全
• 契約書に業務範囲・仕様変更手続き・知的財産権・契約不適合責任を必ず含める
• 支払いはマイルストーン払いが最もリスクバランスが良い
• 著作権の帰属は必ず「発注者」と明記（デフォルトでは開発会社に帰属）
• 契約書は弁護士のリーガルチェックを推奨（費用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>