システム開発の契約書で見るべき条項 — 発注側が確認すべき7点

システム開発の契約書は分量が多く、どこを見るべきか分かりにくいものです。
トラブルになりやすい7点に絞って整理します。

※ 一般的な考え方の整理であり、法的助言ではありません。
重要な契約は弁護士にご確認ください。

1. 請負か、準委任か

最も基本的で、最も重要な違いです。

仕様が固まっていない開発を請負契約にすると、
「完成」の定義で必ず揉めます。逆に、仕様が明確なのに準委任だと、
発注側は完成の保証を得られません。

実務では、要件定義は準委任、実装は請負と分けることもあります。

2. 検収の基準と期間

× 「甲が満足する品質に達した時点で検収とする」
○ 「別紙の検収項目をすべて満たした時点で検収とする」

主観的な基準は、双方にとって危険です。
何をもって完成とするかを、着手前に文書化します。

検収期間も確認します。「納品後14日以内に検査」といった期限があり、
期限内に何も言わないと自動的に検収完了となる条項が一般的です。

3. 著作権の帰属

A. 開発会社に帰属し、発注者に利用を許諾する
B. 検収・支払い完了時に発注者へ移転する

B でないと、他社への引き継ぎや自由な改変ができない場合があります。
一方、開発会社が汎用的に使う部品まで全部移転するのは現実的でないため、
「汎用部品を除く」という書き方になることが多いです。

確認すべきは「将来、別の会社に改修を頼めるか」という一点です。

4. 契約不適合責任（旧・瑕疵担保）

納品後に不具合が見つかったときの扱いです。

• 期間（納品後○ヶ月）
• 対象（仕様との不一致か、動作しないことか）
• 対応（無償修正か、代金減額か）

期間が「1ヶ月」と短い場合、運用開始が遅れると期限切れになります。
運用開始日を起点にできないか相談する余地があります。

5. 仕様変更の扱い

開発中の仕様変更は必ず発生します。
発生することを前提に、手続きを決めておきます。

・変更依頼は書面（メール可）で行う
・追加費用と期間への影響を提示し、双方の合意後に着手する

これが無いと、「言った・言わない」になります。

6. 再委託

・再委託の可否
・可の場合、事前の承諾が必要か
・再委託先の行為について、受託者が責任を負うか

誰が実際に作業するかは、品質と機密の両面で重要です。

7. 損害賠償の上限

「本契約に基づき受領した委託料の総額を上限とする」

上限が設定されているのが一般的です。
発注側としては、システム停止による営業損失が補償されないことを
理解しておく必要があります。

だからこそ、契約書で守るよりそもそも止まらない構成にすることが重要になります。

その他、確認しておくと安心な点

• 納品物の範囲（ソースコード、設計書、環境構築手順が含まれるか）
• 秘密保持の期間（契約終了後も継続するか）
• 中途解約（どちらからでも可能か、費用はどうなるか）

まとめ

着手前に確認すれば数分で済むことが、
後になると解決に数ヶ月かかることがあります。