システム開発契約書で失敗しないための8つのポイント｜仕様変更・検収・著作権を行政書士が解説

「システム開発を依頼したいけれど、どんな契約書を作ればいいのかわからない」

「開発会社から契約書を提示されたけれど、この内容で問題ないのだろうか？」

「システム開発を受託する際、追加作業や納期遅延のリスクに備えておきたい」

このようなお悩みはありませんか？

システム開発では、開発費用や納期だけでなく、仕様変更、検収、著作権、契約不適合への対応など、契約書で決めておくべき事項が数多くあります。

特に注意したいのは、発注者と開発会社の間で、完成するシステムや業務範囲について認識の違いが生じやすいことです。

例えば、発注者は「当然、この機能も含まれている」と考えていても、開発会社は「その機能は追加開発の対象」と認識している場合があります。

こうした認識の違いは、追加費用の請求、納期の遅延、検収をめぐる対立などにつながりかねません。

そこで今回は、契約書作成に強い行政書士が、システム開発契約書で確認しておきたい8つのポイントを実務的な視点から解説します。

---

1．開発するシステムの仕様・業務範囲を明確にする

システム開発契約書で最初に確認したいのが、開発するシステムの仕様と業務範囲です。

例えば、次のような事項を明確にしておく必要があります。

開発するシステムの目的と機能

対応する端末や動作環境

外部システムとの連携範囲

画面設計やデザインの範囲

データ移行の有無

テストや導入支援の内容

マニュアル作成の有無

納品する成果物の内容

これらが曖昧なまま開発を開始すると、発注者が想定していた機能と、実際に開発されたシステムが異なることがあります。

一方、開発会社にとっても、業務範囲が不明確な契約は危険です。

当初予定していなかった作業について、追加費用を請求できるかどうかが問題になるためです。

実務上のポイント

すべての仕様を契約書本文に記載する必要はありません。

詳細な仕様については、仕様書や要件定義書などの別紙・電磁的記録に定め、それらを契約内容に組み込む方法が考えられます。

その際は、仕様書の確定方法、変更手続、契約書本文との優先関係も明確にしておくことが重要です。

また、契約締結時点で仕様が確定していない場合は、要件定義などの工程を区分し、後続工程の契約条件をどのように決定するかを整理しておきましょう。

---

2．開発費用と追加費用の発生条件を定める

システム開発では、開発途中で追加費用が発生することがあります。

例えば、次のようなケースです。

新しい機能を追加する場合

当初の仕様を変更する場合

外部サービスとの連携が必要になった場合

発注者の要望によって画面や処理内容を変更する場合

当初想定していなかった作業が必要になった場合

このような場合に問題となるのが、どこまでが当初の開発費用に含まれ、どこからが追加費用の対象となるのかという点です。

発注者としては、事前の承諾なく開発費用が増加する事態を避けたいところです。

一方、開発会社としては、追加作業を無償で求められることを防ぐ必要があります。

そのため、契約書では次の事項を定めておくことが考えられます。

開発費用の総額と内訳

着手金・中間金・残代金の支払時期

追加費用が発生する条件

追加費用の見積方法

追加作業に着手するための承認手続

支払遅延が生じた場合の取扱い

実務上のポイント

追加費用については、原則として発注者の事前承諾を必要とする仕組みが有効です。

また、承諾の方法をメールなどの電磁的記録も含めて定めておくと、実際の業務運用に合わせやすくなります。

---

3．納期・開発スケジュールを明確にする

システム開発では、納期をめぐるトラブルも少なくありません。

例えば、開発会社が予定どおり作業を進めていても、発注者から必要な資料や確認結果が提供されず、開発が遅れる場合があります。

また、仕様変更によって作業量が増え、当初の納期を維持できなくなることもあります。

そのため、単に「○月○日までに納品する」と定めるだけでは不十分な場合があります。

契約書では、次のような事項を整理しておくことが重要です。

開発開始日と納期

工程ごとのスケジュール

発注者が協力すべき事項

進捗報告の方法

遅延が発生した場合の通知義務

納期変更の手続

遅延が生じた場合の責任分担

特に重要なのが、発注者の協力が得られなかった場合や、仕様変更が発生した場合の納期の取扱いです。

開発会社に責任のない事情によって遅延した場合まで、すべて開発会社が責任を負う内容になっていないか確認する必要があります。

一方、発注者としては、開発会社の事情による遅延について、報告や対応を求められる仕組みを設けておきたいところです。

---

4．仕様変更の手続と費用負担を定める

システム開発では、契約締結後に仕様が変更されることも珍しくありません。

実際に開発を進める中で、新しい機能が必要になったり、当初予定していた機能が不要になったりすることがあります。

しかし、仕様変更のルールがないと、次のような問題が発生します。

「発注者は軽微な変更だと思っていたが、開発会社は大幅な追加作業だと考えていた」

「口頭で仕様変更を依頼したが、変更内容について認識が一致していなかった」

「仕様変更によって納期が延びたが、責任の所在が不明確になった」

こうしたトラブルを防ぐためには、仕様変更の手続を契約書で定めておくことが重要です。

具体的には、次のような事項が考えられます。

仕様変更を申し出る方法

変更内容の確認方法

追加費用の見積り

納期への影響の確認

変更内容の承認方法

変更が合意に至らなかった場合の取扱い

実務上のポイント

仕様変更については、変更内容・追加費用・納期への影響を確認したうえで、当事者双方が合意する仕組みを設けることが望ましいでしょう。

特に、口頭での依頼だけで仕様変更が確定する運用は、後から証拠が残りにくいため注意が必要です。

---

5．検収の方法と合格基準を定める

システム開発契約書で特に重要なのが、検収に関する条項です。

検収とは、納品されたシステムが契約で定めた仕様や基準に適合しているかを確認する手続です。

例えば、次のようなトラブルが考えられます。

「システムを納品したのに、発注者がいつまでも検収を完了してくれない」

「発注者は不具合があると主張しているが、開発会社は仕様どおりに完成していると考えている」

「検収完了後に不具合が見つかり、無償修正の範囲で争いになった」

こうした問題を防ぐため、契約書では次の事項を定めておくことが重要です。

検収期間

検収の方法

合格基準

不合格の場合の通知方法

修正・再検収の手続

検収期間内に通知がない場合の取扱い

検収完了の時期

特に、検収期間内に発注者から合否の通知がなかった場合の取扱いは重要です。

一定の条件の下で検収に合格したものとみなす規定を設けることも考えられます。

ただし、発注者にとって過度に短い検収期間や、確認が困難な場合まで無条件に合格とみなす規定は、慎重に検討する必要があります。

また、検収完了と残代金の支払時期を連動させる場合は、その関係も明確にしておきましょう。

なお、検収が完了したことと、その後に発見された契約不適合について責任を負うかどうかは、区別して整理する必要があります。

---

6．著作権・知的財産権の帰属を明確にする

システム開発では、完成したシステムの著作権が誰に帰属するのかも重要な問題です。

発注者の中には、「開発費用を支払ったのだから、システムの著作権も当然に自社のものになる」と考えている方もいるかもしれません。

しかし、開発費用を支払っただけで、著作権が当然に発注者へ移転するわけではありません。

著作権の帰属は、著作物性や権利発生の事情、契約内容などによって判断されます。

そのため、契約書で権利の取扱いを明確にしておく必要があります。

例えば、次のような事項です。

開発されたプログラムの著作権の帰属

著作権を移転する場合の移転時期

著作権法第27条・第28条の権利の取扱い

著作者人格権の不行使

開発会社が従前から保有するプログラム等の取扱い

第三者のソフトウェアやオープンソースソフトウェアの利用条件

発注者による改変・複製・再利用の範囲

例えば、発注者が将来、別の開発会社にシステムの改修を依頼する予定であれば、必要な権利や利用許諾を確保しておくことが重要です。

一方、開発会社としては、以前から保有している汎用プログラムや開発ノウハウまで、無条件に発注者へ移転する内容になっていないか注意が必要です。

実務上のポイント

著作権を移転する場合は、著作権法第27条・第28条の権利を含めるかを明確にすることが重要です。

また、著作者人格権は譲渡できないため、必要に応じて不行使に関する規定を設けます。

ただし、開発会社が実際に権利を保有しているか、従業員や再委託先から必要な権利を確保できているかについても確認が必要です。

---

7．契約不適合への対応と損害賠償の範囲を定める

システム開発では、検収完了後に不具合が発見されることがあります。

例えば、次のようなケースです。

特定の条件下でシステムが正常に動作しない

契約で定めた機能が実装されていない

処理結果が仕様と異なる

他のシステムとの連携に問題がある

このような場合に備えて、契約不適合への対応を定めておくことが重要です。

具体的には、次のような事項が考えられます。

契約不適合の判断基準

不適合を通知する期間

修補・代替対応などの方法

修補に要する費用負担

修補が困難な場合の対応

損害賠償責任の範囲

損害賠償額の上限

特に、開発会社にとって重要なのが、損害賠償責任の範囲です。

例えば、システムの不具合によって発注者の業務が停止した場合、開発費用を超える損害が主張される可能性もあります。

そのため、契約内容や取引規模に応じて、損害賠償額の上限を開発委託料相当額とするなどの責任制限を検討することがあります。

ただし、損害賠償の上限を設ければ、あらゆる場合に必ずその上限が適用されるとは限りません。

故意・重過失の場合の取扱い、適用される法令、契約条項の有効性などを踏まえた検討が必要です。

また、発注者にとっても、責任制限の内容が過度に広く、重大な不具合が生じた場合に十分な対応を受けられない契約になっていないか確認することが重要です。

なお、システム開発契約が請負契約に該当するか、準委任契約に該当するかによっても、法的な義務や責任の考え方は異なります。

契約書の名称だけではなく、実際の業務内容や契約上の義務を踏まえて整理する必要があります。

---

8．開発中止・中途解約の条件を定める

システム開発では、契約締結後に開発が中止されることもあります。

例えば、次のような場合です。

発注者の事業方針が変更された

開発予算が確保できなくなった

必要なシステムの仕様が大幅に変わった

開発会社の業務遂行に問題が生じた

当事者間の協議がまとまらなくなった

このような場合に問題となるのが、契約を途中で終了できるか、終了時にどのような費用を精算するかという点です。

発注者としては、事業上の必要性がなくなった場合に契約を終了できる仕組みを設けたいところです。

一方、開発会社としては、すでに実施した作業や確保した人員に関する費用を回収できないリスクがあります。

そのため、契約書では次の事項を整理しておくことが重要です。

中途解約を認める条件

解約の通知方法と予告期間

解除事由と是正期間

開発済み部分の費用精算

着手金や前払金の取扱い

開発途中の成果物の引渡し

ソースコードや関連資料の取扱い

契約終了後の秘密保持義務

実務上のポイント

中途解約時の費用精算については、単に「支払済みの費用は返金しない」と定めるだけでなく、作業の進捗状況や既に発生した費用などを踏まえて設計することが重要です。

また、請負契約や準委任契約には、それぞれ民法上の解除・解約に関する規定があります。

例えば、請負契約では、仕事の完成前に注文者が損害を賠償して契約を解除できる旨が民法第641条に定められています。

契約類型や適用法令を踏まえたうえで、中途解約条項を検討する必要があります。

システム開発契約書は「請負」と「準委任」の違いにも注意

ここまで8つのポイントを解説しましたが、システム開発契約書では、契約類型の整理も重要です。

システム開発に関する契約は、大きく分けると「請負契約」と「準委任契約」が問題になります。

請負契約

仕事の完成を約束し、その結果に対して報酬を支払う契約です。

完成したシステムを納品することが中心となる開発業務などで採用されることがあります。

準委任契約

一定の業務を遂行することを目的とする契約です。

要件定義、調査、技術支援など、業務の遂行そのものに重点を置く場合に採用されることがあります。

ただし、契約書のタイトルに「業務委託契約書」と書かれているだけで、請負か準委任かが決まるわけではありません。

また、準委任契約であっても、報酬の定め方などによって取扱いが異なる場合があります。

重要なのは、契約書の名称ではなく、当事者がどのような義務を負う契約なのかという点です。

システム開発の工程ごとに契約類型を分けることも考えられます。

システム開発契約書で確認したい8つのポイント【まとめ】

システム開発契約書では、次の8つのポイントを確認しておきましょう。

仕様・業務範囲：何をどこまで開発するのか

開発費用：追加費用はどのような場合に発生するのか

納期：遅延が発生した場合にどう対応するのか

仕様変更：誰が、どのような手続で変更を決定するのか

検収：何を基準に合否を判断するのか

著作権：開発したシステムの権利は誰に帰属するのか

契約不適合・損害賠償：不具合が発生した場合に誰がどこまで責任を負うのか

中途解約：開発を途中で終了する場合にどう精算するのか

システム開発では、契約締結時にすべての問題を予測することは困難です。

だからこそ、想定外の事態が生じた場合に、どのような手続で協議し、費用や責任を分担するのかを契約書で定めておくことが重要です。

システム開発契約書は、単にシステムを発注・受注するための書類ではなく、開発プロジェクトを円滑に進めるための重要なルールです。

システム開発契約書の作成は、契約書作成に強い行政書士へ

「システム開発を発注するので、自社に合った契約書を作成したい」

「開発会社として、追加費用や損害賠償のリスクに備えたい」

「ネットのひな形では、自社の開発内容に対応できるか不安」

このようなお悩みはありませんか？

システム開発契約書は、開発内容、契約金額、開発体制、成果物の利用方法などによって、必要な条項や適切な条件が異なります。

当事務所では、契約書作成に強い行政書士が、取引内容やご希望を丁寧にヒアリングし、実際の開発プロジェクトに合わせたシステム開発契約書を作成いたします。

発注者側・開発会社側のいずれからのご依頼にも対応しています。

「どのような契約書を作ればよいかわからない」という段階でも構いません。

システム開発契約書の作成をご検討の方は、お気軽にご相談ください。

※本記事は、システム開発契約に関する一般的な法的事項を解説するものです。具体的な契約条件や法的な取扱いは、契約内容・取引形態・適用法令等によって異なります。