システム・アプリ開発において、適切な契約書を作成することは、発注者・受託者の双方にとって重要です。IT業界では、仕様変更、納期遅延、費用の増加といったトラブルが頻繁に発生します。これらのリスクを軽減し、スムーズな取引を実現するためには、契約内容を事前に明確にしておくことが不可欠です。
本記事では、システム開発・アプリ開発の契約書作成におけるポイントと、ひな形(テンプレート)を利用する際の注意点を解説します。適切な契約書を作成し、トラブルを防ぎましょう。
なお、アロー行政書士事務所では、システム開発契約書やアプリ開発契約書、業務委託契約書の作成・サポートを行っています。
私自身もWeb制作やサービス開発に携わった経験があり、発注者・受託者双方の視点を踏まえた契約書作成が可能です。契約書作成に関するお悩みがあれば、お気軽にご相談ください。
システム・アプリ開発契約の法的性質
システム開発やアプリ開発の契約は、大きく分けて「請負契約」と「準委任契約」の2種類の契約形態に分類されます。契約の種類によって、業務の範囲や責任の所在が大きく異なるため、適切な契約を締結することが重要です。基本的なことを理解しておく必要があります。
請負契約とは?
請負契約とは、発注者が成果物の完成を目的として契約を締結し、受託者が完成した成果物を納品することで報酬を受け取る契約形態です(民法632条)。
システム開発やアプリ開発においては、以下のような場合に請負契約が適用されることがあります。
- 業務システム(経理システム等)の完成系がイメージできるシステムの開発
- 特定の機能を持つソフトウェアの納品
- ウォーターフォール型開発の場合に請負契約をすることがある
請負契約の特徴
- 成果物の完成が前提(仕様通りの納品が求められる)
- 契約不適合責任(旧・瑕疵担保責任)が発生する
- 途中解約ができない(発注者側からの一方的な解除が困難)
トラブル例
- 「完成後の不具合対応はどこまで?」
→ 契約書で「契約不適合責任」の範囲を明確に定める必要がある。 - 「追加要件が発生したが、契約上の対応が不明確」
→ 仕様変更に関する条項をしっかり盛り込むべき。
準委任契約とは?
準委任契約とは、特定の業務を遂行することを目的とした契約形態です(民法656条)。成果物の完成を約束するものではなく、「一定の業務を遂行すること自体」が目的となります。
システム開発では、以下のような場合に準委任契約が適用されます。
- 要件定義、設計フェーズのみを委託
- システムの保守・運用業務
- アジャイル開発で、継続的な開発業務(完成系がイメージしにくいシステム開発※AI開発等)
準委任契約の特徴
- 業務遂行が目的(成果物の完成は保証されない)
- 契約不適合責任(旧・瑕疵担保責任)は基本的に発生しない
- 途中解約が可能(発注者側から解約しやすい)
トラブル例
- 「思ったような成果物ができなかった…」
→ 準委任契約では成果物の完成義務がないため、発注者は期待した結果が得られないリスクがある。
→ 要件定義や成果物の目安を事前に明確にしておく必要がある。 - 「業務範囲があいまいで追加作業が発生」
→ 業務範囲や工数を契約書に明確に記載することが必須。
請負契約と準委任契約の使い分けや組み合わせ
案件によって、請負契約と準委任契約を適切に使い分けることが重要です。
契約形態 | 適したケース | 注意点 |
---|---|---|
請負契約 | 成果物(システム、アプリ)の完成が目的 | 追加要件が発生した場合の取り決めを明確に |
準委任契約 | 継続的な業務(設計、運用・保守、アジャイル開発) | 成果物の完成を保証できないため、業務範囲を明確に |
なお、一口にシステム開発における契約といっても、その内容やフェーズごとで部分的に異なってくる場合もあります。
準委任契約と請負契約の組み合わせ
システム開発では、準委任契約と請負契約を組み合わせるケースも多いです。
例:システム開発の流れ
- 要件定義・設計フェーズ(準委任契約)
- 実装・開発フェーズ(請負契約)
- 運用・保守フェーズ(準委任契約)
このように、開発プロジェクトのフェーズごとに最適な契約形態を選ぶことで、リスクを抑えながら開発を進めることができます。
以下、契約におけるそれぞれの簡易的なまとめです。
- ウォーターフォール型(請負契約に適している)
- メリット:開発工程が明確で管理しやすい
- デメリット:途中で仕様変更が発生すると追加費用が発生しやすい
- 契約の特徴:要件定義の明確化が重要、仕様変更条項を慎重に設計
- アジャイル型(準委任契約に適している)
- メリット:柔軟な開発が可能
- デメリット:納期や最終的な成果物が不確定になりやすい
- 契約の特徴:作業時間やマイルストーンの管理が重要、スコープの変更を明記
システム開発・アプリ開発業務委託契約書の作成と注意点
システム・アプリ開発の契約書を作成する際には、発注者・受託者双方が明確な合意のもとで契約を締結することが重要です。特にIT業界では、仕様変更や納期遅延、追加費用の発生などのトラブルが多いため、契約書に盛り込むべきポイントをしっかり押さえておきましょう。
仕様と業務範囲の明確化
契約書で最も重要なのは、「何をどこまで作るのか」を明確にすることです。
- 仕様書や要件定義書を契約書の添付資料として記載
- 業務範囲(どこまでが発注者の責任で、どこからが受託者の責任なのか)を明確化
- 成果物の範囲、対応ブラウザ・OS、納品形式を具体的に記載
NG例
「〇〇システムの開発を依頼する」→ どの機能が含まれるのか不明確
OK例
「〇〇システムの開発において、以下の機能を含める」
- ユーザー認証機能(メール認証、パスワードリセット)
- 商品管理機能(追加、編集、削除)
- API連携(外部決済サービスとの連携)
このように詳細な業務範囲を明示することで、後のトラブルを防ぐことができます。
仕様変更の対応
システム・アプリ開発では、開発途中で仕様変更が発生することが少なくありません。
そのため、仕様変更が発生した場合のルールを契約書に記載しておく必要があるかもしれません。
- 仕様変更の範囲を明確にする(軽微な変更と大幅な変更の区別)
- 仕様変更時の追加費用・スケジュール変更のルールを設定
- アジャイル開発の場合は「段階的な仕様確定」のルールを設ける
アジャイル開発とウォーターフォール開発の違い
- ウォーターフォール開発(従来型)
→ 仕様を最初に確定し、その通りに開発する(仕様変更のリスクが高い) - アジャイル開発(反復型)
→ 開発を進めながら仕様を調整し、段階的にシステムを完成させる(柔軟な対応が可能)
特にアジャイル開発では、準委任契約が適していることが多いため、契約形態も考慮する必要があります。
契約不適合責任
契約書には、納品後に発生する問題への対応を明確に記載する必要があります。
- 契約不適合(瑕疵)があった場合の対応期間を決める
- どの範囲まで無償対応し、どこから有償対応になるのかを明示する
- テスト・検収のルールを明確にする(検収期間を過ぎたら完了とみなす など)
- 契約不適合責任は主に請負契約に適用されるものであり、準委任契約では適用が難しい(準委任契約においても、業務遂行義務の違反(例:エンジニアの稼働不足や作業内容の著しい品質低下)があれば、別途責任追及が可能な場合がある)
契約不適合責任とは?
発注者が受け取った成果物が、契約内容に適合していない場合、受託者は修正・補償の義務を負います。
通常、開発前に要件定義書・仕様書が作成されますが、システム開発における契約不適合は仕様との不一致等にあたります。なので、事前に仕様を定めておくことが重要です。
報酬の支払いタイミングと検収
IT業界では、納品後に報酬が支払われないトラブルが発生することもあります。
そのため、支払いのタイミングや条件を契約書に明記しておくことが重要です。
- 一括払い or 分割払い(着手金・中間金・納品後)
- 検収完了後に支払うのか、納品後〇日以内に支払うのかを明確化
- 支払い遅延時のペナルティ(遅延損害金など)を設定
また、案件の規模が大きい場合は、着手金・中間金を設定することで受託者のリスクを低減できます。
知的財産権・著作権の取り扱い
システム・アプリ開発では、納品後の著作権の取り扱いを明確にしておく必要があります。
- 発注者に著作権を譲渡するのか、それとも使用許諾(ライセンス)を与えるのか
- ソースコードや開発ツールの権利関係を整理
- 第三者の知的財産権を侵害しないことを保証する条項を記載
著作権の注意点
- フリーランスや受託企業が開発したシステムの著作権は、原則として開発者に帰属
- 発注者が著作権を取得したい場合は、契約書で「著作権の譲渡」を明記する必要がある
- オープンソースソフトウェア(OSS)を使用する場合のライセンス条件を確認する
「発注者が成果物のすべての権利を取得する」といった記載をするとソースコードの権利範囲が不明確で、後のトラブルにつながるおそれがあります。
「発注者は本契約に基づき納品された成果物の著作権を取得する。ただし、受託者が保有する既存の開発資産およびオープンソースソフトウェアについてはこの限りではない。」等となります。
秘密保持(NDA)
開発に関わる情報が外部に漏れないよう、秘密保持契約(NDA)を締結することが重要です。
- 契約期間中だけでなく、契約終了後も秘密保持義務を継続する条項を入れる
- 開発中のデータ、ソースコード、顧客情報の取り扱いルールを明確にする
- 違反した場合の損害賠償請求の可能性を明記するとともに、違約金の設定も検討する
再委託の取り扱い
IT業界では、一部の開発業務を外部のフリーランスや別の企業に「再委託」するケースがよくあります。しかし、発注者が意図しない再委託が行われると、品質や納期に影響を及ぼす可能性がある他、ノウハウの流出や秘密事項の流出につながります。深刻なトラブルの多くが再委託によるものである場合が多いため、契約書でルールを定めておく必要があります。
- 再委託の可否を契約書で明記する(原則禁止 or 事前許可制)
- 再委託する場合の責任の所在を明確にする(受託者が全責任を負う)
- 再委託先の守秘義務(NDA)を確保する
- 再委託を行う場合、発注者の事前承諾が必要であることを契約書に明記する
「受託者は、発注者の事前の書面による承諾なしに、本契約の業務の全部または一部を第三者に再委託してはならない。
また、受託者は、承諾を得た場合においても、再委託先の行為について全責任を負うものとする。などといった内容です。
再委託に関するルールを明確にすることで、品質管理や情報漏えいのリスクを抑えることができます。
その他の条項(損害賠償等)
損害賠償となるケースが一程度あるため、上限を設けるなど、損害賠償の範囲を明確に定めることで、過度な責任を負うリスクを軽減できます。
ここでは一般論での記載となりましたが、内容をまとめると以下のようになります。
- 仕様と業務範囲を明確にし、契約書に詳細を記載する
- 仕様変更が発生した場合のルールを決めておく
- 契約不適合責任(瑕疵対応)の範囲を明確にする
- 報酬の支払い条件を明記し、支払い遅延を防ぐ
- 著作権や知的財産権の取り扱いを契約で定める
- 秘密保持契約(NDA)を締結し、情報漏えいを防ぐ
- 検収のルールを明確にし、検収完了後の修正範囲を制限する
- 再委託の可否を定め、品質・情報漏えいリスクを管理する
- 損害賠償の範囲を明記し、過度な責任を回避する
- 免責事項を設定し、不可抗力の影響を制限する
ソフトウェア開発委託モデル契約書(ひな形の有効活用)
システム・アプリ開発の契約書を作成する際、ひな形(テンプレート)を利用することで基本的な契約条項を押さえることができます。
特に、IPA(独立行政法人 情報処理推進機構)や業界団体が公表している「ソフトウェア開発委託モデル契約書」は、実務で広く参考にされており、有効活用が可能です。
IPA(独立行政法人 情報処理推進機構)が公表している「ソフトウェア開発委託モデル契約書」は、システム開発・ソフトウェア開発の業務委託における契約内容を整理したひな形です。
IPAのソフトウェア開発委託契約モデルの特徴
- システム開発における 請負契約・準委任契約 それぞれのリスクを考慮した設計
- 発注者・受託者間で発生しやすい 仕様変更・著作権・納品基準の問題 に対応
- 開発プロジェクトのトラブルを防ぐための 標準的な条項を盛り込んだ契約モデル
- 経済産業省が公表している「情報システム・モデル取引・契約書」とは異なるが、実務上参考にされることが多い
このモデル契約書を活用することで、一定の法的リスクをカバーしつつ、業界標準に沿った契約を締結することが可能です。
「IPAのソフトウェア開発委託契約モデル」:IPA公式サイト
ひな形を使いつつ、専門家に相談する重要性
ひな形は便利ですが、契約の細かい調整には法的知識が必要です。
IPAのモデル契約書を参考にしながらも、以下のポイントを押さえてカスタマイズしましょう。
- 契約形式(請負・準委任)の選択を適切に行う
- 著作権・知的財産権の帰属を明確にする
- 検収・納品のルールを明確にする
- 契約解除・損害賠償の範囲を適切に設定する
アロー行政書士事務所にご相談ください
システム開発の契約は、案件ごとに適切なカスタマイズが必要です。
アロー行政書士事務所では、業務委託契約書の作成・リーガルチェックを行っています。
「ひな形を使いたいが、どのように修正すればよいかわからない」
「取引に合った契約書を作成したい」
こうしたお悩みがありましたら、お気軽にご相談ください。
システム開発系の契約書作成は若干料金が高くなる傾向にありますが、比較的リーズナブルな価格帯でサポートしておりますので、ご検討いただければと思います。
契約書作成代行サービスの詳細は専門ページよりご覧いただけます。