システム開発の契約書で必ずチェックすべき10項目｜準委任・請負それぞれのポイント

システム開発の契約書で必ずチェックすべき10項目

「よくわからないまま契約してしまった」——その一言が、すべてのトラブルの始まり

「ベンダーから出された契約書に、そのままハンコを押してしまった」

中小工務店や設計事務所でシステム開発を外注する際、こうした経験はありませんか？

業務効率化のために基幹システムを導入したい。施工管理や図面管理をデジタル化したい。積算ソフトをカスタマイズしたい。——IT化・DXの必要性は、規模の大小を問わず切実な課題になっています。

しかし、いざシステム開発をベンダーに依頼するとなると、こんな悩みが出てきます。

• 「契約書の内容が専門用語だらけで、何が書いてあるのかわからない」
• 「準委任契約と請負契約の違いを説明されたが、結局どっちがいいのかわからない」
• 「完成したシステムが使い物にならなかったのに、追加費用を請求された」
• 「データの所有権がベンダー側にあると後から言われた」
• 「契約書を見返したら、自社に不利な条項ばかりだった」

建設業界の方は建設工事の契約書には慣れていても、IT・システム開発の契約書は「畑違い」です。ベンダー側が用意した契約書をそのまま受け入れてしまい、後からトラブルになるケースが後を絶ちません。

この記事では、システム開発の契約書で必ずチェックすべき10項目を、準委任契約・請負契約それぞれの特徴を踏まえて解説します。

「建設の契約はわかるのに、ITの契約はなぜこんなに難しいのか」

この悩みを抱えているのは、あなただけではありません。

中小工務店や設計事務所は、建築工事の請負契約であれば何十年もの経験があります。約款の意味もわかるし、トラブルになりそうなポイントも肌感覚で理解しているでしょう。

しかし、システム開発の契約となると事情が違います。

• そもそも「何を作るのか」が曖昧なまま契約が始まる
• 「完成」の定義が建築のように明確ではない
• 目に見えないソフトウェアに数百万円を払うことへの不安
• ベンダーの言い値が適正なのか判断できない

建設工事なら「図面通りにできているか」を目視で確認できますが、システム開発では動かしてみるまでわからないことがほとんどです。そして、動かしてから「思っていたのと違う」となっても、契約書の内容次第ではやり直しを求められない場合があります。

さらに厄介なのが、ベンダー側の契約書はベンダーに有利にできているのが一般的だということ。これは悪意があるわけではなく、ベンダーも自社のリスクを最小限にしたいからです。だからこそ、発注者側がチェックポイントを知っておくことが不可欠なのです。

まずは基本を押さえる——準委任契約と請負契約の違い

システム開発の契約は、大きく**「準委任契約」と「請負契約」**の2種類に分かれます。チェック項目を見る前に、この違いを正確に理解しておきましょう。

準委任契約と請負契約の違い

請負契約——「完成」に責任を持つ

請負契約は、ベンダーが**「仕事の完成」を約束する**契約です。

• 成果物（完成したシステム）の引き渡し義務がある
• 完成しなければ報酬を請求できないのが原則
• 契約不適合責任（旧：瑕疵担保責任）を負う
• 建設工事の請負契約と基本構造は同じ

中小工務店・設計事務所の方にとっては、建設工事の請負と同じ枠組みなので理解しやすいはずです。ただし、ソフトウェアの「完成」は建築物の「完成」よりも定義が曖昧になりやすい点に注意が必要です。

準委任契約——「作業の遂行」に責任を持つ

準委任契約は、ベンダーが**「善管注意義務をもって作業を遂行する」**ことを約束する契約です。

• 完成義務がない（ベストを尽くす義務はある）
• 作業時間や工数に対して報酬が発生する
• いつでも解約できる（ただし損害賠償が発生する場合あり）
• 要件定義やコンサルティングなど**「何を作るか決める段階」**で多く使われる

どちらを選ぶべきか？

実務では、フェーズごとに契約形態を変えるのが一般的です。

**「全部まとめて請負契約で」**とするのは危険です。要件定義の段階で完成義務を課すと、何を完成させるのかが不明確なまま契約することになり、トラブルの元になります。

契約書で必ずチェックすべき10項目——これを見落とすと致命傷になる

ここからが本題です。システム開発の契約書で必ず確認すべき10の項目を、準委任・請負それぞれの注意点とともに解説します。

契約書チェックリスト10項目

項目1：業務範囲（スコープ）の定義

最も重要な項目です。「何をやるのか」「何をやらないのか」が明確に書かれているか確認してください。

請負契約の場合：

• 成果物の一覧が具体的に記載されているか
• 「○○システム一式」のような曖昧な表現になっていないか
• 画面数、帳票数、機能一覧が添付されているか

準委任契約の場合：

• 作業内容が具体的に定義されているか
• 「支援」「助言」など抽象的な表現だけになっていないか
• 成果物（ドキュメント等）の有無が明記されているか

実務のポイント： 建設工事であれば図面と仕様書で「何を作るか」が明確ですが、システム開発では**「要件定義書」や「機能仕様書」が契約書の別紙として添付されているか**が生命線です。口頭の打ち合わせだけで合意した内容は、法的には極めて弱いと考えてください。

項目2：報酬・費用の条件

金額だけでなく、支払い条件と追加費用の扱いを確認します。

請負契約の場合：

• 総額固定か、単価×工数か
• 追加開発が発生した場合の費用算定方法
• 中間払い・マイルストーン払いの条件

準委任契約の場合：

• 月額固定か、時間単価か
• 精算条件（上限・下限の工数幅）
• 稼働報告の方法と頻度

実務のポイント： 中小工務店がよく遭遇するのが、**「当初の見積もりにない機能を追加したら、追加費用が見積もりの倍になった」**というケース。追加開発の単価や、変更管理のルールを契約時に決めておくことが重要です。

項目3：納期・スケジュール

請負契約の場合：

• 最終納期だけでなく、中間マイルストーンが設定されているか
• 納期遅延時のペナルティ（遅延損害金等）の有無
• 発注者側の確認・フィードバック期限も明記されているか

準委任契約の場合：

• 契約期間の開始日・終了日
• 自動更新条項の有無と解約予告期間
• 作業報告のタイミング

実務のポイント： 注意すべきは、発注者側にも期限があるということ。「○月○日までに資料を提出すること」「○営業日以内にフィードバックすること」という条項が入っている場合、発注者が期限を守らなかったことを理由に納期が延びることがあります。これは発注者にとって不利になりうるため、現実的に対応可能なスケジュールかを確認してください。

項目4：検収条件

請負契約で最も重要な項目の一つです。

• 検収の基準（何をもって「合格」とするか）
• 検収期間（引き渡しから何営業日以内に検収するか）
• 「みなし検収」条項の有無——検収期間内に合否を通知しなかった場合、自動的に検収合格とみなす条項

実務のポイント： 建設工事の完成検査に相当しますが、システム開発では**「使ってみたら問題が見つかった」**というケースが非常に多いです。検収期間が短すぎると十分なテストができません。最低でも2週間、できれば1か月の検収期間を確保することをお勧めします。

また、みなし検収条項は要注意です。忙しくてテストする時間がなかったら、自動的に「問題なし」として確定してしまいます。

項目5：契約不適合責任（旧：瑕疵担保責任）

請負契約の場合に特に重要です（前回の記事「請負契約の瑕疵担保責任が変わった？」も参照してください）。

• 契約不適合責任の期間（民法上は引き渡しから1年以内に通知が必要）
• 責任の内容（修補請求・代金減額・損害賠償・契約解除）
• 責任を制限する条項がないか（「軽微な不具合は対象外」等）

実務のポイント： ベンダー側の契約書では、契約不適合責任の期間が**「検収後3か月」**など短く設定されていることがあります。民法の原則では「知った時から1年以内に通知」ですが、契約で短縮することは可能です。システムの性質上、季節業務（年末調整、決算処理など）を経て初めて発覚する不具合もあるため、最低でも1年間の責任期間を確保したいところです。

項目6：知的財産権の帰属

見落としがちだが、後から大きな問題になる項目です。

• 開発されたシステムの著作権は誰に帰属するか
• ソースコードの引き渡しはあるか
• ベンダーが他案件で同様のシステムを開発することへの制限

実務のポイント： 多くのベンダー契約書では、**「著作権はベンダーに帰属する」**と書かれています。これは、発注者がお金を払って作らせたシステムなのに、ベンダーを変更する際にソースコードを持ち出せないことを意味します。

中小工務店・設計事務所にとっては、**ベンダーロックイン（特定ベンダーからの乗り換えが困難になること）が最大のリスクです。最低でも、「発注者は自社利用の範囲で自由に利用できる」「ソースコードは引き渡す」**という条項を入れることを交渉してください。

項目7：損害賠償の範囲と上限

• 損害賠償の上限額（契約金額を上限とするのが一般的）
• 間接損害・逸失利益の扱い（多くの契約書で免責とされている）
• 発注者側の損害賠償責任の有無

実務のポイント： 例えば、導入したシステムの不具合で業務が1か月ストップした場合の売上損失は「間接損害」にあたり、多くの契約書ではベンダーは責任を負わないとされています。つまり、システムが原因で工事の受注機会を逃したとしても、賠償されるのはシステム開発費用の範囲内ということです。

この点は交渉で変えることが難しい項目ですが、リスクを認識しておくことが重要です。

項目8：秘密保持

• 秘密情報の定義と範囲
• 秘密保持の期間（契約終了後も継続するか）
• 施主の個人情報を含むデータの取り扱い

実務のポイント： 工務店や設計事務所のシステムには、施主の氏名・住所・家族構成・収入情報など、極めてセンシティブな個人情報が含まれます。ベンダーに開発やテストのためにこれらのデータを渡す場合、個人情報保護法に基づく適切な管理が求められます。契約書に秘密保持条項があるか、そしてその内容が十分かを必ず確認してください。

項目9：解約・中途終了の条件

• どのような場合に途中で解約できるか
• 解約時の費用精算方法（既に完了した作業の扱い）
• 成果物の引き渡し義務（途中まで作ったものは受け取れるか）

準委任契約の場合： 民法上、いつでも解約できますが、相手方に不利な時期に解約した場合は損害賠償の可能性があります。

請負契約の場合： 発注者はいつでも解約できますが、ベンダーの損害を賠償する必要があります（民法641条）。

実務のポイント： 「このベンダーではダメだ」と途中で判断した場合に、いくら払って解約できるのかを事前に把握しておくことが大切です。特に請負契約の場合、解約時に**「すでに投入した工数＋見込み利益」**を請求されることがあります。

項目10：紛争解決方法

• 管轄裁判所の指定
• ADR（裁判外紛争解決手続）の利用の有無
• 協議条項の有無

実務のポイント： 管轄裁判所がベンダーの本社所在地に指定されていることがあります。遠方の裁判所での訴訟は、移動コストだけでも大きな負担になります。自社の所在地を管轄する裁判所を指定するよう交渉してください。

こんな方は今すぐ契約書を見直してください

• これからシステム開発を外注しようとしている中小工務店・設計事務所の方
• すでにベンダーと契約中だが、契約書の内容をよく理解していない方
• 過去にシステム開発でトラブルになった経験がある方
• 業務のIT化・DX推進を検討しているが、何から始めればいいかわからない方
• ベンダーから提示された契約書をそのままサインしてしまいそうになっている方

システム開発のトラブルは、契約書の段階で防げるものがほとんどです。しかし、一度サインしてしまった契約を後から変更するのは極めて困難です。「今さら聞けない」ではなく「今だから確認する」——その行動が、数百万円のトラブルを未然に防ぎます。

まとめ

システム開発の契約で押さえるべきポイントまとめ

システム開発の契約書は、建設工事の契約書とは異なるポイントが多く、中小工務店・設計事務所の方にとってはハードルが高く感じられるものです。

しかし、押さえるべきポイントは決まっています。もう一度、10項目を振り返りましょう。

1. 業務範囲（スコープ）の定義——曖昧な表現を排除する
2. 報酬・費用の条件——追加費用のルールを事前に決める
3. 納期・スケジュール——発注者側の義務も確認する
4. 検収条件——みなし検収条項に注意する
5. 契約不適合責任——最低1年の責任期間を確保する
6. 知的財産権の帰属——ベンダーロックインを防ぐ
7. 損害賠償の範囲と上限——間接損害の免責を理解する
8. 秘密保持——施主の個人情報保護を徹底する
9. 解約・中途終了の条件——撤退コストを把握する
10. 紛争解決方法——管轄裁判所を確認する

準委任契約と請負契約では、それぞれ注意すべきポイントが異なります。特にシステム開発ではフェーズごとに契約形態を使い分けるのが一般的であるため、各フェーズの契約書を個別にチェックすることが重要です。

**「ITの契約書は難しい」**と感じるのは当然のことです。しかし、それを理由にチェックを怠ると、取り返しのつかないトラブルに発展しかねません。

私たちアトリエ・バイナリでは、中小工務店・設計事務所のIT導入やDX推進に伴う契約面でのご相談にも対応しています。「ベンダーから出された契約書の内容を確認してほしい」「自社に必要なシステムの要件整理から手伝ってほしい」——そうしたレガシーな業務環境から脱却したい方のお悩みに、建設業界の実務を理解したうえでIT・デジタルの専門知識を掛け合わせたアドバイスを提供しています。

まずは現在の契約書を手元に用意して、今回ご紹介した10項目に沿って一つひとつ確認してみてください。それだけで、リスクの大部分は可視化できます。 もし確認する中で不安な点があれば、お気軽にお問い合わせください。