ソフトウェア開発の業務委託契約、ここが違う!IT案件で押さえたい条文まとめ

ソフトウェア開発やシステム保守など、IT系の案件を外注するときって、普通の業務委託契約とはちょっと違う注意点がいくつも出てきます。たとえば、ソースコードの著作権は誰が持つのか、バグ修正はどこまで面倒を見てくれるのか、など。実際にやってみると、意外と「ここがはっきりしていないせいで揉めてしまった…」のようなトラブルも少なくありません。
そこで今回は、「IT案件ならでは」の業務委託契約で気をつけたいポイントをまとめました。クラウドソーシングを使うときの注意点も含めて、なるべく分かりやすくお伝えしていきます。
もしあなたが「ソフトウェア開発の契約は初めて」「何を条文に入れたらいいか分からなくて不安…」と感じているなら、ぜひ参考にしてみてください。読めばきっと、「なるほど、ここは重要なんだな」と納得いただけると思います。
1. 著作権の帰属とソースコード管理
まず真っ先に考えたいのが、ソースコードや制作物の著作権をどちらが保有するのかというところです。
Web制作やアプリ開発などは、コードを書いた人が著作権を持つのが原則です。とはいえ、多くの場合は「納品後は発注者側に権利を移転する」か、「発注者が利用する範囲をしっかり明文化する」か、いずれかの取り決めをすることが多いです。

いずれの方式にしても、「コードを改変したり再利用する場合はどんな条件なのか」をはっきりさせておかないと、後々「改変したら開発者が怒ってきた…」なんて話に発展することがあります。特に保守・運用で別会社に委託するときに混乱しないよう、契約書で明示しておくのがおすすめです。
あとは、ソースコードの受け渡し方法や管理体制も意外と盲点になります。たとえば「GitHubなどのリポジトリを共有して、発注側もいつでも参照できる状態にしておく」、「納品時点で最新のソースとドキュメントをきちんと引き渡す」など。
ここを曖昧にしていると、リポジトリが開発者しか見られなかったり、納品がファイル一式だけで動作環境の設定情報が抜けていたりして、保守のたびに苦労することになりかねません。
2. “完成”の基準とバグ対応範囲
IT案件でとくにトラブルになりやすいのが、「いつをもって納品完了とするか」という“完成基準”です。
ソフトウェア開発は、プログラムが動きはするけどバグが残っているケースが往々にしてあります。後になってから「まだバグが残っているんだから、ちゃんとした納品じゃないでしょ」と発注者が主張すると、逆に開発側が「いや、これは仕様の範囲内ですよ。追加要件なら別料金です」と返して揉める…なんてことが起きがちです。
そのため、納品基準を契約書に盛り込むのはかなり重要。
たとえば、
- テスト環境で動作確認を実施し、契約書に定めた機能要件をすべて満たした時点。
- 致命的バグ(クリティカルバグ)がない状態。小さなバグはバージョンアップで対応。
- UAT(ユーザー受入テスト)を実施し、発注者から“承認”を得たタイミング。
…などのように、どんな検証ステップを踏んで「完成」とみなすのかあらかじめ決めておくと、双方が納得しやすいです。
さらに、バグ対応範囲も重要な論点です。納品後どこまで無償で修正してくれるのか、軽微な不具合はリリース後も何日間かサポートしてくれるのかなど、サポート期間や追加料金の有無を明確にしておかないと「こんなにバグ修正かかるなんて聞いていない!」と驚くことになります。
システム保守の契約を別に作成するのか、それとも開発契約に盛り込むのか、といった判断も必要ですね。
3. オンラインで完結するクラウドソーシングの落とし穴
最近は、クラウドソーシングを利用して個人のエンジニアやデザイナーと直接取引をするケースも増えています。大変便利なシステムなのですが、オンラインだけのやりとりだからこそ発生しやすい注意点があります。
❶ やり取りの履歴が散らばりがち
プロジェクト管理ツールやチャットツールなど、複数のツールを使っていると、契約内容の肝心な部分がメールに残っていなかったりする場合があります。曖昧な合意で作業が進み、後から「いや、その仕様変更は聞いてません」と揉めるのもよくあるパターンです。
契約に関する大切な決定事項は、メッセージやメールでエビデンスをしっかり残すことを意識しましょう。
❷ 発注者・受注者の実態が見えにくい
クラウドソーシングだと、相手が個人事業主なのか、海外在住のフリーランスなのか、法人なのか、はたまた実態のよく分からない組織なのか、表面上は分かりにくいことがあります。
もし高額案件の場合は、最低限の身元確認をしたり、実績やポートフォリオを細かくチェックしたり、ビデオチャットで打ち合わせするなどの工夫が必要です。
❸ 書面の契約を交わさずにスタートするリスク
当然ながら、オンラインだけで完結できてしまうぶん、契約書も作らず「とりあえずやりましょう!」で仕事が始まることも珍しくありません。
プラットフォームの利用規約だけでは十分カバーできない箇所(ソースコードの取り扱いとかバグ修正範囲など)は、簡易でもいいので別途契約書を取り交わすか、最低限、チャットで明文化しておくことをおすすめします。
4. IT業界ならではの条文まとめ
ここで改めて、IT案件で盛り込んでおきたい条文のポイントを箇条書きにしてみました。もし契約書を作るときに抜けがないか、ざっとチェックしてみてください。
条文ポイント | 詳細 |
著作権・知的財産権の帰属先 | ・ソースコードやドキュメントをどちらが所有するか ・改変や再配布の許可範囲 |
納品基準と検収方法 | ・どの段階で検収(納品完了)となるか ・致命的バグの定義と無償修正期間のルール |
保守・運用の対応範囲 | ・バグ修正や更新作業は別契約か、 それとも本契約に含むのか ・追加機能を頼む場合の料金体系 |
支払い条件 | ・完全成果型(納品後一括)か、 開発フェーズごとの段階支払いか ・着手金や中途金の扱い |
秘密保持やセキュリティ対策 | ・ソースコードの閲覧範囲、リポジトリへのアクセス権限 ・顧客情報や機密データの取り扱い方法 |
契約解除や損害賠償に関する 条項 | ・開発が途中で頓挫した場合の対応 ・受託者側の過失による損害はどこまで補償するか |
もちろん、案件の規模や性質によって必要な条文は変わりますが、「とりあえず上記を網羅しておけば大きな見落としは少ない」という基礎ラインかなと思います。
まとめ:手間を惜しまず“事前ルール”を固めておくことが大事
IT案件の業務委託契約は、他の業務委託と比べると「動くもの」を納品するための複雑さが絡んできます。バグや仕様変更はどうしても避けられないものなので、「じゃあどこまでが無料で、どこからが追加料金?」という話は、事前に決めておかないと揉めやすいです。
また、ソースコードやデータ類は企業にとって大事な資産なので、納品後に自由に使えないなんてことにならないよう、著作権の帰属や改変権はしっかり契約書で押さえておきましょう。クラウドソーシングを使う場合も、相手の実態や実力が見えにくいぶん、なおさら慎重になるに越したことはありません。
契約を結ぶのは手間がかかりますがしっかりルールを決めた上で外注を始めるのと、そうでないのとでは、後々のトラブル発生率が段違いです。もし分からないことがあれば、行政書士など専門家に相談するのがおすすめです。
お問い合わせ・ご相談はこちら
「自分のビジネスを守るために、今すぐ行動したい」と思われた方は、ぜひご連絡を。
あなたにピッタリの条項が盛り込まれた、安心の契約書をご提供いたします。
\ ご相談・お見積りは無料です /
当オフィスでは生成AIを適切・安全に使用することにより、詳細までカスタマイズ可能な書面を、スピーディかつ低価格で作成できます。
料金の詳細についてはこちらのページからご確認ください。
契約書など文面作成 (Word納品) | 定型的な契約書・基本契約書 ※業務委託・秘密保持など | 11,000円~ |
プライバシーポリシー・ 利用規約 | ||
専門性の高い複雑な契約書 | 22,000円~ | |
内容証明作成 | 8,800円 | |
オプション | 契約書の製本 | +3,850円(1部につき) |
特急(24時間以内)対応 | +8,800円 | |
契約書などレビュー | 契約書などのチェック (A4 5~6枚程度) | 8,800円 |
※税込価格