システム開発の契約とは？契約形態・契約書の注意点を解説【2024年最新版】

• システム開発の委託先と、どう契約を締結すればいいのか？
• トラブルを招かないシステム開発契約を結ぶには？

そんな悩みを抱えている企業担当者の方なら、以下のようなことが知りたいはずです。

・システム開発の契約形態にはどんなものがある？
・開発するシステムに応じて契約形態を使い分けるべき？
・システム開発契約書でチェックしておくべきポイントは？

成果物に形のないシステム開発だからこそ、適切な契約を締結したいもの。
そこで本記事では、システム開発で一般的な契約形態とその特徴、ケースごとの使い分けを解説！トラブルを招かないために知っておきたいシステム開発契約書のチェックポイントを紹介します。

※システム開発の依頼先を探している方はシステム幹事にご相談ください。予算や目的から最適な開発会社を選定させていただきます。相談料などは一切かかりません。

【無料】自社におすすめのシステム開発会社を紹介してもらう

システム開発に役立つ記事もご覧ください システム開発とは？工程・流れをプロが解説！発注者が知っておくべきポイント

システム開発の契約・契約書とは？

システム開発の契約とは、発注者と開発会社が結ぶもので、依頼した内容（機能、金額、納期など）に違反しないようにするため、または責任の所在を明らかにするために交わすものです。互いの認識に齟齬があった場合、契約書をもとにすり合わせを行います。契約・契約書には法的効力・拘束力が発生するため、契約書の遵守がマストになります。

契約を結ぶタイミング

システム開発の契約は見積もりを取り、金額や内容に納得したあと正式に発注する際に開発会社と締結します。契約書は開発会社が用意し、確認して修正も必要があれば直してもらいます。

契約が締結すれば、スケジュールや機能、費用などを細かく決めていく「要件定義」に入ります。

システム開発の要件定義とは？進め方や事例をわかりやすく解説（サンプル付）【2024年最新版】 | システム幹事 システム開発における要件定義では何を決めるのか、誰が担当するかなどを徹底解説。要件定義が重要な理由や要件定義で使われるツールなどを紹介します。

システム開発の契約で起こり得るトラブル

「あまり中身もチェックせず、開発会社に提示された契約書にサインしている」
システム開発に慣れていない一般的な企業の方ならやってしまいがちです。しかし、注文書・注文請書のやり取りで成立する物販と異なり、システム開発にはドキュメント類を除いた成果物に形がありません。開発途中の変更・修正も頻繁に発生します。

こうした特性を持つシステム開発プロジェクトでは、契約書に不備がないか？自社に不利な条項はないか？内容をキチンと理解したうえで契約を取り交わさなければ、思わぬトラブルに発展してしまうことがあります。

「納期」「質」「責任の所在」「費用」のリスクが

リーガルテックサービス企業、GVA TECH株式会社が2018年11月に調査した「システム開発契約トラブル実態」によると、ベンチャー・中小企業担当者の実に約4割が、システム開発に関する契約トラブルを経験しています。複数回以上のトラブルを経験した方も3割以上、なかには10回以上と答えた方もいたようです。

画像出典：中小・ベンチャー企業の契約トラブル実態調査

トラブルでもっとも多かったのは、28.5%を占めた「納期遅れ」、次いで26.9%の「成果物の質」、16.9%の「責任の所在」と続き、それに起因すると思われる「金額」トラブルも、15.8%と高い水準になっています。調査報告では、こうしたトラブルを招いた原因を「契約書の内容を充分確認していなかった」からだと結論付けています。

画像出典：中小・ベンチャー企業の契約トラブル実態調査

担当者の3人に1人は契約内容を理解していない

画像出典：中小・ベンチャー企業の契約トラブル実態調査

上の円グラフは「契約先との契約内容についてすべてを理解していましたか」という質問に対し、34.5%もの担当者が理解していなかった、と答えた状況が明らかになったからです。

一方、契約内容を「すべて理解」していた方はわずか27.5%。7割以上もの方が契約内容を「完全に」理解していない状況で、トラブルを経験した方が4割というのは、システム開発の特性を考えれば逆にラッキーだったといえるのかもしれません。

システム開発契約は業務委託契約？ システム開発の契約書タイトルには「業務委託契約」がよく使われますが、業務委託契約という名称は民法に存在しません。業務委託契約とは「請負契約」「委任契約」「準委任契約」の総称。このうち委任契約は、契約代理などの法律行為に関する契約であるため、システム開発を含めた一般的な業務委託は請負契約、もしくは準委任契約だということになります。

【無料】システム開発の契約について相談する

システム開発契約の種類・形態

システム開発では、プロジェクトの完了・成果物の納品までに多数の作業工程が必要。それぞれの工程は作業の方法・特性が異なり、開発モデル（手法）によっても工程は変化します。そのため、近年では請負契約、準委任契約をシステム開発の特性に応じて使い分けるケースが増えています。

以下からは、その前提となる「請負契約」「準委任契約」の特徴、それぞれの契約形態に向いているシステム開発手法を簡単に紹介していきます。

請負契約

請負契約とは、仕事の完了に対して報酬が発生する契約形態のこと。
ここでいう仕事とは「成果物」を指しますが、受託側が成果物を納品しても「仕事が完了」したと認められるのは発注側の検収が済んでから。それまでは、原則として報酬の請求は行いません。

システム開発プロジェクトの場合であれば、プログラム本体が成果物となることが一般的。成果物として各種設計書、システム構成図、テスト結果報告書、ユーザーマニュアルなどのドキュメントを指定する場合は、双方の合意のもとで契約書内に明記する必要があります。

契約不適合責任に注意

請負契約の場合、受託側は仕事の完了だけではなく「品質の満足」義務も果たす必要があります。これを「瑕疵担保（かしたんぽ）責任」といい、成果物の品質が契約内容を満たさない場合、発注側は受託側にシステムの改修・修正、損害賠償、契約解除などを請求できます。

ただし瑕疵担保責任が、2020年4月の民法改正で「契約不適合責任」に置き換えられたことは知っておくべきポイント。品質の満足に対する義務という点ではどちらも同じですが、瑕疵担保の請求権が「成果物の納品から1年以内」であるのに対し、契約不適合の請求権は「契約不適合を知ったときから1年以内」に変更されました。

致命的なバグを発見したときには瑕疵担保の期間が過ぎていた、といったことがなくなるため、発注側にとっては安心できる民法改正だといえるでしょう。

請負契約と相性がいいのはウォーターフォール型

仕事の完成・成果物の納品などの特性があることから、請負契約と相性がいいのは「ウォーターフォール型システム開発」だといえます。

ウォーターフォール型とは、「企画」「要件定義」「基本・詳細設計」「開発」「テスト」など、水が上流から下流に流れるように各工程を経て「納品」「運用保守」にいたるシステム開発モデルのこと。企画の時点から「仕事の完成」を前提としている点でも、請負契約と馴染みやすい特徴があります。

ウォーターフォール型の詳しい解説は下記の記事をご覧ください。

関連記事：ウォーターフォール型システム開発とは？開発工程・メリット・アジャイル型との違いを解説！

準委任契約

準委任契約とは、仕事・業務の遂行に対して報酬が発生する契約形態のこと。仕事の完成・成果物の納品ではなく、時間・日数などの単価を基準に、業務を遂行した量（時間）に対して報酬が支払われます。

たとえば、客先常駐でシステム開発プロジェクトに参画するエンジニアなどは、準委任契約で働くケースがほとんど。仕事の完了や、請負契約の契約不適合責任に相当する品質の満足に対する責任もありません。ただし、準委任契約も2020年4月の民法改正で、これまでとは異なる契約形態が追加されています。

履行型と成果型

民法改正による最大の変更は、これまでの「履行型（業務遂行に対する報酬）」に加えて、準委任契約にも「成果型（仕事の完了に対する報酬）」の規定が設けられたこと。

では、成果型準委任契約は請負契約と同じなのか？と感じるかもしれませんが、そうではありません。成果型準委任契約には「成果物に対する契約不適合責任＝品質の満足がない」、「仕事の完了または成果物の納品と同時に報酬を請求できる」特徴が。この点において請負契約とは大きく異なります。

善管注意義務と債務不履行責任

ただし、準委任契約だからといって、責任の所在が請負契約よりも軽いというわけではありません。準委任契約では、履行型・成果型どちらにも「善管注意義務」があり、成果型に関しては「債務不履行責任」もあります。

具体的には、プロフェッショナルSE・プログラマーとして期待されるレベルの注意義務（善管注意義務）を果たさなければなりません。成果型なら、契約で約束した成果物を納品できない場合、損害賠償、契約解除などの債務不履行責任を負わなければなりません。

準委任契約と相性がいいのはアジャイル型

善管注意義務・債務不履行責任という特性を持つことから、準委任契約と相性がいいのは「アジャイル型システム開発」だといえます。

アジャイル型とは、要件定義でおおまかな方向性を決め、機能ごとに「設計」「開発」「テスト」「リリース」を繰り返していくシステム開発モデルのこと。修正・変更を前提とし、小さな機能を追加していくことで完成を目指す点でも準委任契約と馴染みやすく、成果物の納品が必要な「成果型」と特に相性がいいといえるでしょう。

【無料】自社におすすめのシステム開発会社を紹介してもらう

システム開発契約書の注意点・チェックポイント

システム開発契約の種類、契約形態ごとの特性を把握できたところで、契約書の内容を理解するために知っておきたい注意点・チェックポイントを解説していきます。

システム開発会社から提示される契約書は、記載される項目・条項などがある程度決まっているケースがほとんど。これは、IPA（情報処理推進機構）が公表する「情報システム・モデル取引・契約書」を、プロジェクトの実態に沿ってアレンジ・活用する開発会社が多いからです。

IPA：「情報システム・モデル取引・契約書」

ここで注意しておきたいのは、契約書の内容が「プロジェクトの実態に沿ってアレンジ」されること。請負契約・準委任契約には、民法で定められた「任意規定」がありますが、それよりも「契約当事者の意思表示」が優先されます。

つまり、アレンジして契約書を作成するシステム開発会社は、自社に不利になる条項を変更している可能性が。発注側として不利益を被らないためにも、契約形態ごとに異なる任意規定を理解したうえで、契約書の内容をチェックしていくことが重要です。

多段階契約か？一括契約か？

近年では、ウォーターフォール型であっても、作業工程の特性に応じて契約形態を使い分ける傾向が強まっています。これは、IPAのモデル契約書で、以下のような多段階契約（工程ごとに個別契約を締結する方式）が推奨されているためです。

各工程の特性を考慮した多段階契約は、システム開発の質を高めてトラブルを避けるために有効な手法であるのは事実。ただし、品質の満足に責任を負わない準委任契約は、質の向上を目的とした作業に追加費用が発生する場合も。

当初の見積もり金額をオーバーしたくない発注側にとっては、多段階契約の採用は難しい決断になり得ます。

システム開発契約という特殊性に関して、社内の合意を得ておく（見積もり金額をオーバーする可能性がある）、あるいは、予算内で収まるような一括契約を模索するなどの対応が必要です。

各工程がどんな作業をするかは下記の記事を参考ください。

関連記事：システム開発の基本設計とは？その位置付け・重要性・発注者としての関わり方
関連記事：システム開発の詳細設計とは？プロジェクトの位置付け・役割をわかりやすく解説！
関連記事：システム開発のテスト工程を徹底解説！システムテストと受け入れテストの違い
関連記事：システム運用とは？開発との関係・保守との違い・重要性・作業内容を解説！

責任の所在は明確か？

契約形態の次に確認しておくべきは、契約書内に記載される各条項。まず挙げられるチェックポイントは、システム開発対象の特定・明確化によって成果物を明らかにし、責任の所在を明確に定義できているか？です。

これは「納期」「質」「費用」という、システム開発のトラブルを避けるためにも重要なポイント。なぜなら、開発対象が特定されていなければ、成果物が完成したのかがわからず、変更・修正が契約の範囲内なのか？追加作業なのか？がわからないからです。

開発対象となるシステム名だけではなく、機能要件を明らかにした仕様書も契約書内に盛り込むことがベスト。RFP（提案依頼書）をもとにした開発会社との合意内容を別紙でまとめ、契約書に添付するなどがおすすめです。

関連記事：RFPとは？システム開発の質を高める提案依頼書の作り方を解説！【サンプルあり】

なにをもって成果物が納品とするか？

3つめのチェックポイントは、なにをもって成果物が納品されたとするのか、検収されたとするのか、明確に定義されているか？上述した「システム開発対象の特定・明確化」の対となる重要な条項だといえるでしょう。成果物の納品でチェックするべきは以下の3点。

・納入期限の明示
・納入物（成果物）の明示
・成果物納品方法の明示

納入物に抜け・モレがないか？指定サーバへのアップロード、ダウンロードなど、納品方法が具体的に記載されているか？などがチェックポイント。また、成果物の検収でチェックするべきは以下の3点。

・検査期間の明示
・検査基準の明示
・検査期間満了時の取扱

検収は発注側の責任であるため、本来は検査基準も発注者が策定すべきですが、検査仕様書の作成・テスト方法の策定を開発会社が支援する場合が一般的。この点に関しても契約書内の記載をチェックしておく必要があります。

委託費用や支払い方法は明確か？

4つめのチェックポイントは、システム開発の委託費用がいくらなのか、支払い方法をどうするのか、明確に定義されているか？です。

支払い方法は、一括払いと段階的支払いの2つのパターンがあります。請負契約の場合は、成果物の納品・検収後に委託費用を支払う形（一括払い）が基本であり、発注側にとってもメリットが大きい方法です。一方、規模の大きなプロジェクトやアジャイル型の場合、開発会社の負担を軽減するため、委託費用を設計完了時、開発完了時、検収後などに分けて支払う（段階的支払）ケースも少なくありません。

加えて、修正・変更が頻繁に発生するシステム開発プロジェクトでは、委託費用の変更も契約書に明記しておくべき重要な条項です。もし開発費の変更について契約書に記載がないと、後から機能を増やしたい、あるいは減らしたい場合に費用の交渉に応じてもらえない危険性があるからです。チェックするべきは以下の2点。

・委託費用の支払期間
・委託費用の変更

契約書に「甲と乙が委託料の変更について協議するものとする」など、費用の変更について記載があるかを確認しましょう。

所有権・知的財産権は書かれているか？

5つめのチェックポイントは、成果物であるシステムの所有権・知的財産権の取り扱いが明確に定義されているか？　委託費用を支払ったにもかかわらず、修正・改変を含めたシステムの利用に制限が生じる状況は、発注側にとって好ましくありません。契約書内に、以下のような文言を追加できるよう、協議することがおすすめです。

・成果物の所有権は、甲が乙に委託料を全額支払った時点で乙から甲に移転する（所有権の移転）
・成果物の著作権は、甲が乙に委託料を全額支払った時点で乙から甲に移転する（著作権の移転）
・乙は、甲および甲が指定した者に対して、当該著作物の使用を許諾する（著作権移転が困難な場合）

再委託の可否は書かれているか？

6つめのチェックポイントは、受託側開発会社の再委託・下請に関連する条項が明確に定義されているか？です。システム開発では、開発工程（プログラミング）を別会社に再委託することは珍しくありません。

しかし、多重下請構造になってしまえば、成果物の品質が担保できない可能性も。再委託条項を明確にすることで、成果物のクオリティをコントロールしやすくなります。ポイントとなるのは以下の3点。

・再委託の可否
・再委託先の管理責任
・再委託に関する発注者の権利

そもそも再委託を認めるのか？認めないのか？を規定したうえで、認める場合の条件を明確化することがポイント。再委託を事前承認制にする、再委託先の義務と責任を受託開発会社が負う、クライアントとして再委託の撤回・取消のできる権利を設ける、などが考えられます。

契約不適合責任の範囲・期間は明確か？

7つめのチェックポイントは、契約不適合責任の範囲・期間が明確に定義されているか？です。契約不適合責任とは、完成したシステムが契約内容と違う場合、開発会社が責任を負うことを指します。この条項をチェックするには、契約不適合（契約書通りの品質を満たしていない）基準が明確であることが大前提。システム開発対象の特定・明確化でも触れたように、詳細な仕様書が必要でしょう。そのほかでポイントとなるのは以下の2点。

・契約不適合責任の開始と保証期間
・契約不適合責任が生じた場合の対応

契約不適合責任の範囲・期間を明記しておかないと、納品物に不備があった場合に、十分に修正対応してもらえない可能性があります。

また、受託側の開発会社では、できる限り契約不適合の範囲・期間を小さくしたいと考えています。そのため、契約書内に「契約不適合期間は納品から6か月」などと記載されている場合も。本来の任意規定は「契約不適合を知ってから1年間」ですが、法律だからと無理強いするのも考えものです。協議を重ねて妥協点を見つけることがおすすめです。

損害賠償の制限・範囲は明確か？

8つめのチェックポイントは、損害賠償の制限・範囲が明確に定義されているか？です。具体的には、どのような場合に損害賠償できるのか？損害賠償の上限金額はいくらなのか？を明確にするということです。損害賠償の範囲・期限が明確でないと、契約内容と違うことが後から分かったが損害賠償に応じてもらえないなどのトラブルが起きる危険性があります。

ただし、通常損害、逸失損害、特別損害など、一般の方にはわかりにくい用語が多用されるのもこの条項の特徴。損害賠償の上限は「開発委託費用と同等」にするケースが一般的ですが、金額の妥当性も含め、弁護士などの専門家にチェックしてもらうことがおすすめです。

【無料】システム開発の契約について相談する

システム開発における契約まとめ

システム開発契約書のチェックポイント

• 多段階契約か？一括契約か？
• 責任の所在は明確か？
• なにをもって成果物が納品とするか？
• 委託費用や支払い方法は明確か？
• 所有権・知的財産権は書かれているか？
• 再委託の可否は書かれているか？
• 契約不適合責任の範囲・期間は明確か？
• 損害賠償の制限・範囲は明確か？

本記事では、システム開発で一般的な契約形態とその特徴、ケースごとの使い分け、トラブルを招かないために知っておきたい契約書のチェックポイントを解説してきました。

本来、契約は口約束でも成立するものではありますが、立場も役割も異なる多数のスタッフが携わるシステム開発では、契約書で責任の所在、ルールを明確にしておくことが肝心。その前提となるのは、お互いにとってベストな合意内容を協議できる、優良なシステム開発会社の存在です。

システム開発プロジェクトをスムーズに進行させるためにも、委託先の選定が非常に重要なポイントとなります。

システム開発会社を探している方へ

システム開発は会社によって得意・不得意が分かれることが多く、少ない情報から見極めるのは大変です。依頼をしようにも料金が書かれていないことが多く、どこの会社に問い合わせればいいのか迷っている方も多いでしょう。

システム開発には少なくない時間と予算がかかるので、会社選びの失敗は絶対に避けたいところ。

そのような場合は、システム幹事にご相談ください。専門のコンサルタントがあなたの要望を丁寧にヒアリングし、予算にあった最適な開発会社を選びます。

コンサルタントのご紹介 岩田 専任のコンサルタントが、
お客様の予算と目的を丁寧にヒアリング。
最適な会社をピックアップ・ご紹介させていただきます！
初心者の方でも安心してご相談いただけます。

業界の相場や開発会社の選び方などWebサイトには載っていない情報をご提供します。

相談料、会社紹介料は完全無料。必ず開発会社に発注する必要はありません。システム開発の相場の情報から最適な会社選びまで無料でサポートします。お気軽にご相談ください。

【無料】自社におすすめのシステム開発会社を紹介してもらう

システム開発に役立つ記事もご覧ください システム開発とは？工程・流れをプロが解説！発注者が知っておくべきポイント