システム開発の契約で注意すべきポイントは？

システム開発では、費用負担や責任を巡ったトラブルが起きることが少なくありません。このようなトラブルの原因は、この2つが大部分を占めます。

• 契約書の内容があいまいで、どちらが責任を負うのか明確になっていない
• 契約書の内容をよく理解していない

裏を返せば、契約書の内容を両者がよく理解したうえで契約することで、トラブルの原因を大きく減らすことができます。

そこでこの記事では、システム開発の契約をする際の注意点を解説します。記事の概要は以下の通りです。

この記事に書いてあること：システム開発の契約にあたっての基礎知識や注意点、参考にしたいひな形
この記事に書いていないこと：具体的な契約書の文言

契約前に押さえておきたい法律や契約形態など、特に発注者視点で知りたい情報にフォーカスを当てて紹介していきます。この記事がシステム開発契約の際に役立ちましたら幸いです。

システム開発の契約書には何が書いてある？

まず最初に、システムの契約書には何が書いてあるのかを簡単に紹介します。この表の項目は代表的なもので、他にもさまざまな細かい取り決めを行い契約を結びます。

契約の目的	契約の具体的な目的や内容
期限	結んだ契約の有効期限
定義	契約書に使われている言葉や用語などの定義
役割分担と責任者	発注者・受注者の役割分担とそれぞれの責任者を明確にする
仕様	システムの完成像はどのようなものか
実施場所	業務を行う場所はどこか
納期	いつまでに何を納品するか
報酬	具体的な報酬金額や支払い時期、支払い方法
保証期間、不具合対応	システムの保証期間や、納品物に不具合があった際の補償内容
情報の取り扱い	機密情報などの管理について
権利	納品された成果物（プログラム、資料など）の権利をどちらが所有するか

システム開発の成果物は、資料や設計書などといったドキュメント以外は形がないものです。開発中の仕様変更や修正もたびたび発生します。取り決めがあいまいなままシステム開発を進めてしまうと、正しい状態や完成図がわからないため、トラブルの原因になります。

細かく取り決めた契約書を交わすことで発注者と受注者の認識のずれをなくし、スムーズに開発を進めることができます。

円滑に開発を進めるためには、両者が契約内容を十分に理解していることも重要です。ここからは、契約書で特に理解しておきたいポイントを詳しく解説していきます。

実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>

システム開発の契約書作成前にチェックしておきたい情報

契約書を作成する前に、法律や契約形態について確認しておきましょう。

下請法

下請法は、大きな企業と小さな企業が取引する場合に適用されます。概要を表すと、親事業者（大きな企業）が有利な立場を濫用して、立場の弱い下請事業者（小さな企業）に不公正な取引を求めることを禁止した法律です。

親事業者が資本金1千万円以上であれば対象になり、資本金によって遵守する法律が異なります。少し複雑なので、下記表を参照ください。

親事業者にはいくつかの義務と禁止事項が定義されています。

親事業者の義務

1. 書類の交付義務
2. 支払期日を定める義務
3. 書類の作成・保存義務
4. 遅延利息支払い義務

口約束での言った・言わないのトラブルを防ぐため、下請事業者に発注を行う際は直ちに必須事項を記載した書面（3条書面）を発行しなくてはなりません。3条書面の必須事項は取引内容・取引金額・支払い期日などの12項目です。つまり、必ず発注書や契約書を交付しましょうということです。

支払い期日は親事業者が下請事業者の給付の内容について検査するかどうかを問わず，物品等を受領した日から起算して60日以内のできる限り短い期間内で、代金の支払期日を定める義務があります。

また、遅延利息支払い義務は、支払い期日を過ぎた日から実際に支払いをする日までの日数に応じた遅延利息を支払わなくてはなりません。つまり、「社内検査が完了していないからまだ代金が支払えない」と言われ報酬をもらえないなどのトラブルを防ぐことができます。

取引が完了したら、親事業者は取引記録を5条書類として作成し、2年間保存することが義務付けられています。5条書類の必須事項は取引内容・取引金額・受領日・支払い方法などの17項目です。

親事業者の禁止事項

1. 受領拒否
2. 下請代金の支払い遅延
3. 支払い代金の減額
4. 返品
5. 買いたたき
6. 購入・利用強制
7. 報復措置
8. 有償支給原材料等の対価の早期決済
9. 割引困難な手形の交付
10. 不当な経済上の利益の提供要請
11. 不当な給付内容の変更及び不当なやり直し

システム開発においてよくある問題をピックアップします。

例えば無償で追加機能の開発を求めるなど、契約内容にない内容を不当に要求することは「不当な経済上の利益の提供要請」に抵触します。また、システム納品後に仕様書と全く違う内容の変更を無償で要求することは、「不当な給付内容の変更及び不当なやり直し」に抵触します。無償で対応しないならば納品を拒否するという場合は、「受領拒否」に抵触します。

盲点としては、契約書で支払いサイトを「月末締め翌々月末払い」にしている場合は注意が必要です。もしも月初に納品された場合は、支払日が定められた期間である60日をオーバーしてしまい、「下請代金の支払い遅延」に抵触してしまう可能性があります。

知らず知らずのうちに下請法違反をしてしまわないように、下請法に該当する事業者は発注書・契約書に「下請法に準拠した項目」が網羅されているか確認することが大切です。

契約の方式（一括契約と多段階契約）

契約締結の方式は、一括契約と多段階契約に分かれます。

一括契約は、要件定義〜システムの完成まで全工程を一括で契約締結する方式です。1回で契約締結が済むこと、契約時に費用の総額が確定できることがメリットです。しかし、最初の見積もりが重くなりがちであったり、スケジュールや報酬の見直しをしにくいという面もあります。タイトな見積もりであった場合は、開発そのものが頓挫してしまう可能性もあります。

多段階契約は、工程ごとに契約を分けて締結していきます。工程ごとにかかる費用の見積もりを出せること、スケジュールや報酬の見直しがしやすいこと、再見積もりがしやすいことがメリットです。その反面、契約の個数が増えるため契約締結コストが一括契約よりも高くなります。

近年ではウォーターフォール型開発であっても、作業工程の特性に応じて契約形態を使い分ける多段階契約を採用する傾向が強まっています経済産業省によって作成されたモデル契約書（後述）では、多段階契約方式が採用されています。

工程	契約形態
要件定義 （システムの方向性を決めて計画〜要件定義）	準委任契約
基本設計 （システムの見た目の設計）	準委任契約 または 請負契約
詳細設計・開発 （システム内部の設計、プログラミング〜単体・結合テスト）	請負契約
システムテスト	準委任契約 または 請負契約
導入支援〜運用テスト （システムの完成まで）	準委任契約
運用	準委任契約 または 請負契約
保守	準委任契約 または 請負契約

契約形態（請負契約と準委任契約）

契約形態には請負契約と準委任契約があります。それぞれの特性を理解しましょう。

請負契約

請負契約は特定の仕事を受注側が仕事の完了を約束し、発注側が仕事の結果に対する報酬の支払いを約束する契約です。受注側は「仕事を完成させる義務」を負うことが特徴です。

システム開発の場合は完成したプログラム等の成果物を納品・発注側の検収を経て、仕事が完成したと認められます。プログラム本体の他の成果物として、設計書やテスト結果報告書、操作マニュアル等のドキュメント類が指定される場合もあります。もしドキュメントを指定する場合は、双方の合意のもとで契約書内に明記する必要があります。

また、請負契約では受注側は発注側に対して完成責任のほかに「契約不適合責任」を負います。契約不適合責任では、成果物の品質が契約内容を満たしていることを約束します。成果物の品質が契約内容を満たさない場合、発注側は受託側にシステムの改修・修正、損害賠償、契約解除などを請求できます。

契約不適合責任は、2020年4月に施行された民法改正によって瑕疵担保責任から改定された概念です。瑕疵担保の請求権が「成果物の納品から1年以内」であるのに対し、契約不適合の請求権は「契約不適合を知ったときから1年以内」に変更されました。
この民法改正によって「致命的なバグを発見したときには瑕疵担保の期間が過ぎていた」といったことがなくなり、より公正な契約ができるようになりました。

準委任契約

準委任契約とは、任務の遂行に対して報酬が発生する契約です。時間・日数などの単価を基準に、任務を遂行した量（時間）に対して報酬が支払われます。請負契約とは違い、完成責任や品質の満足を問う契約不適合責任はありません。

準委任契約も2020年4月の民法改正で、これまでとは異なる契約形態が追加されています。これまでの任務遂行に対する報酬を定める「履行割合型」に加えて、仕事の完了に対する報酬を定める「成果完成型」の規定が設けられました。

成果型準委任契約には「仕事の完了、または成果物の納品と同時に報酬を請求できる」「成果物に対する契約不適合責任がない」という特徴があります。
しかし、準委任契約だから請負契約よりも責任が軽いというわけではありません。準委任契約では、履行型・成果型どちらにも「善管注意義務」があります。

善管注意義務とは、具体的にはプロのITエンジニアとして期待されるレベルの注意義務を果たさなければなりません。善管注意義務に違反した際は、損害賠償、契約解除などの債務不履行責任を負うことになります。

	報酬の支払条件	完成責任	契約不適合責任	善管注意義務	債務不履行責任
請負契約	仕事の完成	○	○	×	仕事を完成できなかったとき
準委任契約（履行割合型）	任務の遂行 （事務の処理）	×	×	○	善管注意義務に違反したとき
準委任契約（成果完成型）	任務の遂行による成果の納品	× 成果物を納品する責任はあるが 完成させる責任はない	×	○	善管注意義務に違反したとき （成果が達成できなかったこと自体では債務不履行にはならない）

契約書の種類

システム開発の契約書には、「基本契約書」と「個別契約書」の2種類があります。

基本契約書は、作業範囲や責任分担、開発成果物の権利の帰属、検査方法など基本的な事項を記載する契約書です。

個別契約書は、開発案件ごとの取引条件を定めた契約書を指します。開発の進行にともない変動しやすい「納期」や「金額」は、基本契約書ではなく、個別契約書で取り決めるケースが一般的です。

今後も継続的に取引する際に共通する事項については初回のみ基本契約書で取り交わしをして、毎回異なる部分（金額や納期）のみを個別契約書で取り交わすというやり方はアクシアでも行っています。

しかし、契約書は必ずこの2種類を用意しなければいけないわけではありません。基本契約書を取り交わさずに、毎回全ての契約事項を盛り込んだ契約書を作成して取り交わすこともあります。

実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>

システム開発の契約書：作成する際の注意点

契約書を作成する際の注意点は、「成果物が明らかになっているか？」「責任の所在を明確に定義できているか？」の2点です。

成果物が明らかになっているか

まずはシステム開発対象の特定・明確化を行い、成果物を明らかにすることが重要です。開発対象が特定されていなければ、成果物が完成したかどうかがわかりません。完成しているかがわからないと、変更や修正がどこまでが契約の範囲内なのか、追加作業になるのかもあいまいになります。

開発対象となるシステム名だけではなく、機能要件を明らかにした仕様書についても契約書内に盛り込むことがベストです。

責任の所在を明確に定義できているか

責任の所在を明確に定義することも大切です。例えば納品されてからの保証期間はいつまでなのか、どのような場合を契約不適合と定めて受注者が責任を負うのか、再委託を行う場合についてなど、明確に決めておく必要があります。

該当のフェーズの契約形態が、請負契約なのか準委任契約なのかも確認しておきましょう。

実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>

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

契約の際に大切なことは、とにかく契約書をよく読むことです。発注者と受注者両方が契約書の内容を理解していることがとても重要です。

ここでは前項でまとめた法律や契約形態に加えて、契約書の中でも特にチェックしておきたいポイントを解説します。

契約内容が明確か

発注者と開発者、両者の認識ずれをなくすために開発・設計作業の対象となる範囲を明確に特定しましょう。

もしプロジェクトの途中で仕様変更が必要になった場合に、契約書に規定した範囲内か、範囲外かを明確にすることでトラブルを減らすことができます。

支払い時期と支払い方法

システム開発の報酬の支払い時期は「システム完成のタイミング」もしくは「労務完了後のタイミング」の2つに分かれます。

前者はシステムが完成して初めて報酬を支払うもので、後者はシステムが未完成でも労務提供が完了していれば報酬を支払うものです。

もしも支払い時期が不明確なままの場合、システムが完成していなくとも報酬を要求されるという不測の事態にもなりかねないため必ず確認しましょう。

また、支払い方法も分割支払いになるのか、一括支払いになるのか確認しておきましょう。

機密情報等の取り扱い

発注者と開発者で共有される情報の中には機密情報や個人情報も存在することから、資料等の管理方法も契約書上で規定しておく必要があります。

システム開発契約においては、契約に至る前段階でもお互いの機密情報を開示しあうため、その段階で秘密保持契約（NDA）を結ぶことも考える必要があります。

納品物の所有権、知的財産権の取り扱い

知的財産権は具体的には、特許権、著作権、ノウハウなどを指します。

両者の利害が対立することから、所有権と知的財産権についてはどちらに帰属するものなのか契約書上で明確にしておく必要があります。

また、システム開発では第三者のソフトウェアを利用するケースも多くあります。第三者のソフトウェアを利用する際はその取り扱いについても確認し、記載しておきましょう。

仕様変更が起きた時の取り扱い

仕様変更をめぐるトラブルは少なくありません。仕様変更に関する業務内容や報酬金額などが記載されているか、目を通しておきましょう。「修正依頼の際にはどう手続きするか」「費用負担はどうするか」というような仕様変更時の取り扱いを明記しておくことで、発注側と開発側両者でスムーズにやり取りが行えます。

トラブル発生時について

システム開発を進める中でトラブルが発生し予定通りに進行できない場合、両者が協力し合ってトラブルの解決を図る必要があります。

システム開発会社側には、原因追究・対処を実施するプロジェクトマネジメント義務があります。発注側には、トラブル解決に向けて協力する義務があります。いずれかが義務を果たさない場合は損害賠償責任を負うといった旨を、契約書に必ず記載しておきましょう。

損害賠償の制限・範囲は明確に定義することがポイントです。具体的には「どのような場合に損害賠償するのか」「損害賠償の上限金額はいくらなのか」を明確にして記載しましょう。

契約書の変更について

契約書の変更には発注側とシステム開発会社側双方の合意が求められます。そして、変更には会社の代表者といった権限のある者同士の合意が必要とされています。

開発担当者などといった権限のない者が合意をしても、契約変更は成立しないため注意が必要です。

実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>

システム納品・検収時のチェックポイント

システムが完成したら、ようやく発注者にシステムが納品されます。早く検収を終わらせて実務で使いたいところですが、チェック漏れがあると大変です。抜け漏れがないか、チェックポイントに沿って確認をしましょう。

納品時

成果物の納品時にチェックすべきポイントは以下の3点です。

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

特に、足りない成果物がないかよく確認しましょう。

検収時

成果物の検収でチェックすべきポイントは以下の3点です。

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

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

実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>

システム開発の契約書：参考にしたいひな形

この記事では、契約書のチェックポイントについてフォーカスを当てて解説してきました。実際に契約書を作成する場合は、詳細を明確に定義し記載する必要があります。

文言や盛り込むべき情報など、具体的に契約書を書く時はどのようにすればよいでしょうか。

モデル契約書

経済産業省が作成した「情報システム・モデル取引・契約書」が参考になります。これは、発注側の企業と受注側のシステム開発会社のいずれかにメリットが偏らない契約書が作成できるよう、さまざまな立場の方々（ユーザ企業・ITベンダ・関連業界団体・法律専門家）が議論を重ねて作成したひな形です。

第一版は2007年に公開されました。2020年の民法改正を踏まえて見直しを行った第二版がIPA（独立行政法人情報処理推進機構）、JEITA（電子情報技術産業協会）、JISA（情報サービス産業協会）から公開されています。現在はこちらのいずれかを活用すると参考になるかと思います。

IPA版：https://www.ipa.go.jp/ikc/reports/20201222.html
JEITA版：https://home.jeita.or.jp/cgi-bin/page/detail.cgi?n=1124&ca=1
JISA版（有料冊子）：https://www.jisa.or.jp/publication/tabid/272/pdid/30-J002/Default.aspx

IPA版は徹底的に網羅された内容が特徴です。JEITA版は主にITベンダ側からの視点を重視して作成しています。細かすぎる定義をカットし、実務で問題となる部分を詳しく解説しているため、IPA版よりも読みやすい印象を受けます。どちらも無償ダウンロードが可能です。

システム開発の契約で注意すべきポイントは？まとめ

かなり情報を盛り込んで解説をしてきましたので、改めて重要なポイントをまとめます。

契約書を用意する1番の目的は、発注者と受注者の認識のずれをなくし、トラブルなくスムーズに開発をすることです。

• 成果物を明確に定めること
• 契約書内で使われる言葉の定義を定めること
• 責任の所在を明確にすること
• 契約書の内容をよく読んで理解すること

上記4つを抑えることで認識ずれをなくし、不備のない契約書を作成することができます。また、両者がよく理解したうえで契約締結することで、いずれかにメリットが偏ることなく公正な良い契約書を作成することができます。

最後に、関連して役立ちそうな記事をいくつか紹介いたします。システム開発に関する皆様の疑問が解決されましたら幸いです。もしも不明点がありましたら、お気軽にお問い合わせくださいませ。

システム開発とは？エンジニアに聞いてみた
システム開発依頼の流れは？開発会社の選び方から運用開始後までポイントを解説！
システム開発でドキュメントが必要な理由と、短時間でわかりやすく書くコツ
下請法を知らないと発注側も受注側も本当にヤバイですよ！

実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>