システム開発契約書で必須の5つの重要ポイント

システム開発は「目に見えないもの」をゼロから作り上げる性質上、「想定していた機能と違う」「仕様変更で追加費用を請求された」「バグ対応で赤字になる」といった炎上トラブルが極めて起こりやすい分野です。
私自身、ソフトウェア開発会社での20年近い業務経験を通して、システム開発のトラブルの怖さ、お客様との認識齟齬のリスクについては身に染みて感じてきました。
インターネット上の無料ひな形をそのまま使うと、実際の開発プロセスや、お客様と開発会社の役割分担や認識が合致せず、自社が一方的に不利な責任を負う危険性があります。将来の重大な紛争を防ぐため、契約締結前に必ず確認しておくべき5つのポイントを解説します。

1. 開発手法に合わせた「請負」と「準委任」の使い分け

システム開発の契約形態には大きく分けて請負と準委任の2種類あります。この理解は契約書を作成する上での大前提になります。工程（要件定義、設計、プログラミング、テスト、運用）ごとに、これらを分割して使い分ける「多段階契約」が現在の標準的なリスク管理です。

契約形態	目的	適したフェーズ	受託者の主な責任
請負契約	成果物の「完成」	詳細設計、プログラミング	契約不適合責任（バグ等の無償修正義務）
準委任契約	業務の「遂行」	要件定義、運用保守、アジャイル	善管注意義務（専門家として適切に行う義務）

例えば、全工程を一括で「請負契約」にしてしまうと、要件が未確定のまま完成責任を負うことになり、取り返しのつかないトラブルの元になることもあります。

2. 仕様変更ルール（チェンジコントロール）の厳格化

開発途中の仕様変更や機能追加は、納期遅延やコスト増大の最大の原因です。「言った・言わない」を防ぐため、以下のルールを契約書に組み込みます。

• 変更の要望は必ず「書面（メールやチャットツールを含む）」で行うこと
• 追加費用と納期の変更について調査・協議し、「合意書」を交わしてから初めて変更作業に着手すること

3. 知的財産権（著作権）の帰属と整理

開発されたシステム（ソースコードなど）の著作権は、原則として作成した受託者（ベンダー）に帰属します。納品後、権利関係で揉めないための整理が不可欠です。状況に応じて以下の点を意識する必要があります。

• 発注者側： システムを自社で自由に改修・他社展開したい場合は、「代金の完済をもって著作権（著作権法第27条・28条の権利含む）を移転する」と明記します。
• 受託者側： 開発以前から保有していた汎用モジュールやライブラリの権利は移転させず、受託者に留保する条項を入れます。
• あわせて、受託者は「著作者人格権を行使しない」旨を規定し、発注者が円滑にシステムを改修できるようにします。

4. 契約不適合責任の期間と損害賠償の上限設定

納品・検収後に不具合（バグ）が発覚した場合のルールです。システムに不具合はつきものであるため、無制限に責任を負う契約は非常に危険です。

• 期間の限定： 「検収完了後〇ヶ月以内」と、無償で修正対応を行う期間を限定します。
• 損害賠償の上限： 万が一のシステム障害で重大な損害が発生した場合に備え、「損害賠償額は受領済みの委託料総額を上限とする」など現実的な限度額を設け、ベンダーの倒産リスクを回避します。

5. 再委託（下請け）のルールと秘密保持義務（NDA）

IT業界では多重下請けが一般的ですが、無断の再委託は品質の低下や情報漏洩のリスクを高めます。

• 再委託を行う場合は、「事前に発注者の書面による承諾を得る」ルールとします。
• 顧客データや事業アイデアを守るため、再委託先（フリーランス等を含む）に対しても、元請けと同等の「秘密保持義務」を負わせることを義務付けます。

まとめ

システム開発契約書は、一般的なビジネス契約とは異なり、IT業界特有の開発現場のリアルなリスク（非機能要件の解釈ズレや、テスト基準の曖昧さなど）を考慮して作成しなければなりません。「ひな形を流用して後から高額な賠償請求を受けた」という事態を防ぐため、契約の締結・押印前には、必ず技術と法務の両面からの精査が必要です。

自社に最適な契約書の作成や、相手方から提示された契約書の内容に不安がある場合は、ITの現場を知る専門家への事前チェックをご検討ください。