行政書士 樋口智大 
エンジニアとの業務委託契約を締結する際、契約内容を適切に定めておくことは、発注者・受託者の双方にとって重要です。
特に、システム開発やアプリ開発の案件では、仕様変更や追加費用、納期遅延、著作権の帰属問題など、契約時にしっかりと取り決めておかないとトラブルが発生しやすい分野です。
実際、IT・Web業界では「事前に契約書を作成しておらず納品時にトラブルになった」「無料のひな形を使ったら自社に不利な契約になってしまった」というケースが少なくありません。
また、契約の種類（請負契約・準委任契約）によっても、エンジニアが負う責任や発注者のリスクが変わるため、契約内容を理解した上で適切な契約書を作成する必要があります。
本記事では、エンジニアとの業務委託契約を締結する際のポイント、契約書の必須項目、トラブルを防ぐための注意点について解説します。
また、ひな形（テンプレート）の活用時のリスクについても説明し、企業がどのように契約書を準備すべきかを解説します。
なお、アロー行政書士事務所では、エンジニアとの業務委託契約書の作成サポートを行っています。
私自身も以前はフリーランスとしてWeb制作やコンサルティング業務を行っていたことがあり、契約関係で苦労した経験がございます。そうした経験を活かしたサポートをしております。発注者・受託者双方にとって納得のいく契約書を作成し、契約リスクを最小限に抑えたい場合は、ぜひご相談ください。
料金体系を含めた契約書作成サービス詳細はこちらからご覧いただけます。
エンジニアとの契約形態：請負契約と準委任契約
エンジニアとの業務委託契約を結ぶ際、契約の種類によって発注者・受託者の責任範囲が大きく異なります。主に「請負契約」と「準委任契約」の2つの形態があり（複合の場合もあります）、それぞれの特徴を理解した上で契約を締結することが重要です。
請負契約とは？
請負契約（民法第632条）とは、受託者（エンジニア）が特定の成果物を完成させ、それに対して報酬を受け取る契約です。
例えば、「指定されたシステムを完成させ、納品すること」を条件に契約するケースが典型的な請負契約に該当します。
請負契約の特徴
- 成果物の完成が前提
→ エンジニアは契約で定めたシステムやアプリを完成させる義務を負う - 納品物に対して報酬が支払われる
→ 仕様通りに完成しなければ、報酬を受け取れない - 契約不適合責任を負う
→ 納品したシステムに不具合（仕様通りに動かないバグや動作不良）があれば、修正責任を負う場合がある
請負契約が適しているケース
- システムやアプリの開発を「納品物」として完成形が明確に定義（イメージ）できる場合（経理システムのようなものなど）
- 発注者が納品後の検収を実施し、品質を確認したい場合
- 受託者（エンジニア）に一定の納期と完成責任を課したい場合
注意点
- 仕様変更が発生した場合、新たに契約変更や追加費用の合意が必要
- 受託者に完成責任があるため、エンジニア側の負担が大きい
- 発注者が「検収」を適切に行わないと、完成したにもかかわらず報酬が支払われないリスクがある
準委任契約とは？
準委任契約（民法第656条）とは、エンジニアが一定の業務を遂行することを目的とし、その結果に関わらず報酬を受け取る契約です。
例えば、「システムの運用保守」「アジャイル開発におけるエンジニアの技術提供」などが典型的な準委任契約に該当します。
準委任契約の特徴
- 業務の遂行が主な目的
→ 成果物の完成は必須ではない - 時間単位・稼働ベースで報酬が支払われる
→ 作業時間に応じた報酬支払いが多い（時間単価契約など） - 契約不適合責任を負わない
→ 成果物に対する責任がなく、納品物の品質保証義務がない（負う場合が全くないわけではありません）
準委任契約が適しているケース
- エンジニアがプロジェクトに一定期間関与し、継続的な業務を行う場合
- アジャイル開発のように、成果物の完成ではなく、開発プロセスを重視する場合
- システムの運用・保守、ITコンサルティング、技術支援など「知的労働」が主な業務となる場合
注意点
- 成果物の完成が前提ではないため、発注者の期待と異なる場合がある
- 発注者側は「どこまでが業務範囲なのか」を明確にしないと、不要な追加費用が発生する可能性がある
- 請負契約とは異なり、報酬が「業務の遂行」に対して支払われるため、進捗管理が重要
「請負契約」と「準委任契約」の違いまとめ
| 項目 | 請負契約 | 準委任契約 |
|---|---|---|
| 目的 | 成果物の完成 | 業務の遂行 |
| 報酬発生条件 | 納品・検収完了後 | 業務遂行の過程で発生 |
| 発注者の管理義務 | 完成品の品質管理（検収） | 作業状況の進捗管理 |
| 契約不適合責任 | 発生する（瑕疵担保責任） | 発生しない（絶対ではありません） |
| 適用場面 | 完成形がイメージできる、見えるシステム開発等 | 運用・保守、技術支援 |
このように、契約の種類によってエンジニアが負う責任や発注者の管理方法が異なります。
そのため、契約前にどちらの契約形態が適しているのかを慎重に判断しましょう。
なお、契約書に、これは準委任契約、請負契約と記載しても、現実問題としては実態の方が重視されますので、記載したらそれでいいのかというとそうでもありません。ただ、お互いの認識のすり合わせという意味でも確認しておくべきだと言えるでしょう。
契約書作成時の注意点
エンジニアとの業務委託契約を締結する際には、契約内容を明確にし、トラブルを未然に防ぐための条項をしっかりと定めることが重要です。
特に、報酬の支払い条件・納期・仕様変更の取り扱い・知的財産権の帰属・再委託・秘密保持・契約解除条件など、契約の重要ポイントについて適切に定めておくことで、発注者・受託者双方にとって納得のいく取引が可能となります。
報酬の支払い条件
契約書には、報酬の支払いタイミングや金額を明確に記載することが不可欠です。特に、請負契約と準委任契約では、報酬の支払い条件が異なるため注意が必要です。
報酬の支払い条件のポイントとして、以下の点を考慮する必要があります。
- 請負契約の場合、納品・検収完了後に支払いが行われるのが一般的
- 準委任契約の場合、月額・時間単価ベースで定期的に支払う契約形態が多い
- 分割払い（マイルストーン払い）を設定することで、受託者側の資金繰りリスクを軽減可能
- 着手金を設定し、初期費用を確保することも検討する
発注者の一方的な都合による支払い遅延や減額を防ぐため、報酬の支払い期限や支払方法を契約書で明確にしておくことが望ましいといえます。
納期と検収のルール
納期に関する取り決めは、契約上の重要なポイントです。特に請負契約では、納品後の検収が契約の履行に直結するため、具体的なルールを定める必要があります。
納期・検収に関する契約のポイントとして、以下の点を考慮するとよいでしょう。
- 納期を明確にし、遅延が発生した場合の対応（遅延損害金の有無）を定める
- 検収期間を設定し、発注者が納品物を確認する期間を確保する
- 検収基準を明確化（「動作テストをクリアすれば検収完了」など）
- 検収完了後の修正対応の範囲（軽微な修正・バグ修正は無償対応、仕様変更は別料金など）
発注者が検収を放置した場合、受託者が不利益を被る可能性があるため、「検収期間が過ぎたら自動的に検収完了とみなす」といった条項を入れることも検討すべきです。
仕様変更の取り扱い
システム・アプリ開発の現場では、発注者の要望変更や追加機能の依頼が発生しやすく、仕様変更のルールを契約で明確にしておかないとトラブルの原因となります。
仕様変更の取り決めに関する契約のポイントとして、以下が挙げられます。
- 仕様変更が発生した場合、その都度書面で合意するルールを明記する
- 追加費用の発生条件（「〇〇の変更は無料、それ以外は有料」など）を契約に盛り込む
- ウォーターフォール開発（計画・設計重視）とアジャイル開発（柔軟な仕様変更が前提）で契約内容を調整する
口頭で仕様変更を受けた場合、後で「そんな約束はしていない」といったトラブルになりやすいため、必ず書面（メールなどの記録でも可）で合意を残すことが重要です。
知的財産権（著作権）の帰属
ソフトウェア開発においては、知的財産権（著作権）の帰属を契約で明確に定めておくことが不可欠です。
知的財産権の契約ポイントとして、以下の点が重要になります。
- 発注者に著作権を譲渡するのか、受託者が持ち続けるのかを明記する
- 著作権を発注者に譲渡する場合、対価をどう設定するか
- OSS（オープンソースソフトウェア）の利用がある場合、その扱いを明確にする
著作権法上、プログラムの著作権は原則として作成者（エンジニア側）に帰属するため、発注者が著作権を取得する場合は契約で明確に定める必要があります。
秘密保持（NDA）
開発案件では、発注者が事業の機密情報を受託者に提供するケースが多く、秘密保持条項を契約に含めることが必須です。
秘密保持契約（NDA）の契約ポイントとして、以下が挙げられます。
- 受託者が知り得た情報の使用範囲を限定する
- NDAの対象とする情報の範囲を具体的に記載する
- 契約終了後も一定期間、秘密保持義務を継続させる条項を入れる
NDAの内容が曖昧な場合、情報流出が発生しても責任の所在が不明確になる可能性があるため、具体的な情報の取り扱いを契約で明記することが重要です。
なお、再委託がある場合、再委託先から情報漏洩するケースが非常に多くなっているため、再委託の際のルールも定めておきましょう。
再委託のルール
受託者がさらに外部のエンジニアに作業を再委託する場合のルールも契約で決めておく必要があります。
再委託に関する契約のポイントとして、以下が挙げられます。
- 再委託の可否を契約書に明記する
- 再委託を認める場合、「発注者の書面等による承諾が必要」とするかどうか
- 再委託先の責任の所在（発注者が直接責任を問えるか、受託者の責任にするか）
無断で再委託された場合、発注者が望まない第三者に機密情報が渡るリスクがあるため、契約でルールを決めておくことが重要です。秘密保持義務を課すようにしましょう。
契約解除と損害賠償
トラブルが発生した際の契約解除や損害賠償のルールを定めておくことで、万が一の際のリスクを回避できます。
契約解除・損害賠償のポイントとして、以下を考慮すべきです。
- 一方的な契約解除を防ぐため、「やむを得ない事由がある場合のみ解除可能」とする
- 損害賠償の範囲と上限を設定する
- 紛争解決の方法（裁判、調停など）を明記する
フリーランスエンジニアの契約書作成とフリーランス新法対応
近年、フリーランスのエンジニアを活用する企業が増えており、特にシステム開発・アプリ開発の分野では、フリーランスとの業務委託契約が一般的になっています。フリーランスのエンジニアを活用することで、専門的な技術を持つ人材を柔軟に確保できる一方で、契約の取り決めを曖昧にするとトラブルに発展する可能性があるため注意が必要です。
また、フリーランス新法（フリーランス保護法）が施行されたことにより、発注者側にはフリーランスとの契約において一定の義務が課されるようになりました。特に、以下の点に注意が必要です。
- 書面または電子データによる契約内容の明示（契約条件を曖昧にしない）
- 一方的な不利益変更の禁止（報酬の減額や過度な仕様変更は認められない）
- 支払い遅延の防止（契約で定めた期日（60日以内）までに報酬を支払う義務）
- ハラスメント防止措置（業務委託契約に基づく業務でも、ハラスメント対策が求められる）
- 介護や育児への配慮
フリーランスエンジニアとの契約では、発注者側が法令に基づいた適切な契約を締結することが求められます。企業として契約リスクを最小限に抑えつつ、フリーランスとの良好な関係を築くためにも、契約書の作成時には新法の要件を考慮したうえで対応を進めることが重要です。
フリーランス新法については以下の記事で詳細に解説しておりますので、そちらも合わせてご覧ください。
エンジニア（開発関係）の業務委託契約書のひな形（テンプレート）と注意点
契約書を作成する際、ゼロからすべてを作成するのは手間がかかるため、ひな形（テンプレート）を活用することが一般的です。しかし、ひな形をそのまま利用することにはリスクも伴います。特に、エンジニアとの業務委託契約では、プロジェクトの内容や契約形態（請負・準委任）に応じて適切にカスタマイズしなければ、後々のトラブルにつながる可能性があります。
IPA（情報処理推進機構）が提供する「ソフトウェア開発委託モデル契約書」など、公的機関が作成した契約書ひな形は、一定の標準性を持っており、企業間の取引でも活用しやすいものとなっています。
ひな形参考：情報システム・モデル取引・契約書
エンジニア向けといっても、小規模な開発案件しかやらないような場合と大規模な開発とでは利用すべき契約書のひな形も変わってくるため、あくまで参考としてご覧いただければと思います。
ひな形（テンプレート）のメリット
契約書のひな形を活用することで、以下のようなメリットがあります。
- 契約の抜け漏れを防げる（基本的な条項が網羅されている）
- 作成時間を短縮できる（一から作る必要がない）
- 法的リスクの軽減（信頼性のあるひな形を使うことで、一定のリスクヘッジになる）
ひな形をそのまま使うリスク
一方で、ひな形をそのまま使用することで、以下のようなリスクが生じる可能性があります。
- 自社の契約形態に合わない（企業・案件ごとで個別の事情は多く発生します）
- 業界特有のリスクに対応できていない（著作権の取り扱い、検収基準など）
- 発注者または受託者に不利な内容になっている可能性がある（特定の立場に偏った内容）
例えば、IPAのモデル契約書は比較的バランスの取れた内容ですが、すべての開発案件に適しているわけではありません。特に、スタートアップ企業や個人事業主がフリーランスエンジニアに発注する場合、契約条件を柔軟に調整する必要があります。
また、エンジニアとの契約書といっても、それほど規模の大きな開発ではない場合も多いかと思いますので、案件にあった形の契約書が意外と見つからない場合も多くあります。
ひな形を適切に活用するためのポイント
ひな形を活用する際には、以下のポイントを押さえておくと良いでしょう。
- 契約形態（請負・準委任）を明確にする（報酬・納品責任の違いを理解する）
- プロジェクトの特性に合わせてカスタマイズする（アジャイル開発・ウォーターフォール開発の違いなど）
- 専門家にチェックしてもらう（弁護士や行政書士の助言を得ることでリスクを回避）
システム・アプリ開発の契約書は、プロジェクトの成功を左右する重要な要素です。テンプレートを活用することは有効ですが、それだけでは十分ではなく、各案件に応じた適切な修正・カスタマイズを行うことが必要になります。
ひな形をそのまま使うリスク（小規模案件の場合）
IPA（情報処理推進機構）の「ソフトウェア開発委託モデル契約書」は、システム開発における契約の標準的な内容をまとめたもので、企業間（BtoB）の取引を前提に作られています。そのため、大規模案件や企業同士の取引では有用ですが、小規模案件やフリーランスエンジニアとの契約では、適さないケースもあります。
IPAのモデル契約書が小規模案件に向かない理由
- 契約条項が詳細すぎる → 小規模案件では簡潔な契約書の方が実務に適している
- 発注者側に厳しい条件も含まれる → 交渉力のある企業相手なら問題ないが、フリーランスとの契約では柔軟な対応が必要
- 契約手続きが煩雑になる → IPAの契約書はしっかりとした契約を想定しているため、簡易な契約を求める場合にはオーバースペック
特に、数十万円～百万円規模の案件や、短期間の開発業務を委託する場合、IPAの契約書をそのまま利用すると実務に合わない可能性があります。
小規模案件ではどうすべきか？
小規模案件では、以下のような対応が適切です。
- シンプルな契約書を作成する
- 契約条項を簡潔にし、必要最低限のリスクをカバーする
- 納品物・報酬・契約終了条件など、特に重要な部分を明確にする
- 発注側で汎用的な契約フォーマットを持っておく
- 案件ごとに一から契約書を作るのではなく、自社に合ったフォーマットを用意する
- 小規模案件用と中～大規模案件用の契約書を分ける
- フリーランス新法（フリーランス保護法）を考慮する
- フリーランスエンジニアとの契約では、発注者側に一定の義務が課される
- 不当に一方的な契約内容とならないよう注意が必要
IPAのモデル契約書は参考として活用しつつ、小規模案件に適した契約書を別途用意するのがベストな対応と言えるでしょう。
ひな形を利用する際の注意点
システム・アプリ開発の契約書を作成する際、ここで記載したような無料のひな形（テンプレート）を利用するケースも少なくありません。しかし、ひな形をそのまま使用すると、実際の開発内容やプロジェクトの特性に合わず、トラブルを招く可能性があります。
ひな形はあくまで参考として活用する
契約書のひな形は一般的な取引を想定したものであり、すべての案件に適用できるわけではありません。開発プロジェクトごとに仕様や納期、契約の種類（請負契約・準委任契約）が異なるため、そのまま利用すると実態に即さない契約になりかねません。
→ 必ずプロジェクトの内容に合わせてカスタマイズすることが重要です。
契約類型（請負契約 or 準委任契約）を誤るリスク
システム開発の契約では、契約の種類（請負契約・準委任契約）によって、発注者・受託者の責任が大きく異なります。
- 請負契約 → 完成物の納品が義務となるため、成果物の定義を明確にする必要がある
- 準委任契約 → 業務の遂行を委託する契約であり、成果物の納品義務はない
ひな形の中には、契約類型が明示されていないものや、不適切な条項が含まれていることがあります。そのため、契約類型を慎重に確認し、自社の案件に合った契約内容へ修正する必要があります。
3. 重要な契約条項が抜けている可能性がある
無料のひな形やテンプレートには、以下のような重要な契約条項が含まれていない場合があります。
- 仕様変更の取り扱い → 仕様変更の条件や追加費用の発生を明確にする
- 著作権の帰属 → ソースコードや開発成果物の権利をどちらが持つのかを明確にする
- 秘密保持（NDA） → 取引先の機密情報を守るための条項を設ける
- 検収基準 → どの時点で納品完了とするのかを明確に定める
- 損害賠償責任 → 何らかの問題が発生した場合の責任範囲を定める
特に、仕様変更の取り扱いや著作権の帰属は、システム開発において争いになりやすいポイントです。契約書を締結する際には、こうした条項が適切に設定されているか確認することが重要です。
企業側が独自の契約書フォーマットを持つ重要性
発注者側が適切な契約書のひな形を持っていれば、案件ごとに一から契約書を作成する手間を省きつつ、契約リスクを抑えることができます。また、ひな形を持つことで、受託者（エンジニア・開発会社）から提出された契約書と比較し、自社にとって不利な条項がないか確認しやすくなります。
そのため、ひな形を利用する場合でも、「自社向けにカスタマイズした契約フォーマットを持つ」ことが推奨されます。
適切な契約書を作成し、安全な取引を実現する
エンジニアとの業務委託契約は、システム・アプリ開発のプロジェクトを円滑に進めるために不可欠です。特に、契約内容を明確にしておくことで、仕様変更、納期遅延、著作権の帰属、報酬支払いなど、トラブルになりやすいポイントを事前に防ぐことができます。
本記事では、以下の重要なポイントを解説しました。
- 契約の種類（請負契約・準委任契約）を適切に選択する
- ウォーターフォール・アジャイルの開発手法による契約の違いを理解する
- フリーランスエンジニアとの契約では、フリーランス新法の適用にも注意する
- 契約書のひな形（テンプレート）はそのまま利用せず、プロジェクトに合わせてカスタマイズする
- 発注側も自社用の契約フォーマットを持ち、受託者から提示された契約書と比較できるようにする
- フリーランスエンジニアとの契約書の注意事項
特に、著作権の帰属や仕様変更の条件は、システム・アプリ開発においてよくトラブルになる部分 です。契約書を作成する際は、こうした点を明確にしておくことで、後から発生する無用な紛争を防ぐことができます。
また、IPAのソフトウェア開発委託モデル契約書 など、公的に推奨されている契約書のひな形を参考にしつつ、自社のプロジェクトに適した契約内容へカスタマイズすることが重要です。
アロー行政書士事務所にご相談ください
エンジニアとの契約書作成は、発注者・受託者双方にとって、ビジネスを円滑に進めるために重要な要素です。しかし、契約内容を適切に整えないと、以下のような問題が発生する可能性があります。
- 仕様変更の追加費用を請求できない
- 契約不適合責任の範囲が不明確でトラブルになる
- 著作権や知的財産の帰属が曖昧なまま契約を進めてしまう
アロー行政書士事務所では、IT・Web業界の契約書作成サポートを行っています。
- システム・アプリ開発の契約書作成
- フリーランスエンジニアとの契約書
- 発注者向けの契約フォーマット作成
など、契約リスクを回避するための適切な契約書作成をサポートします。
契約書作成についてお悩みの方は、気軽にご相談ください。
契約書作成サービスの詳細はこちらからご確認いただけます。