システム開発を外注するとき、多くの会社が「契約書はひとまず雛形のまま」「細かいことは口頭で」と進めてしまいます。しかし、開発の途中や納品後に揉めるケースの多くは、契約の段階で話し合っておけば防げたものです。この記事では、開発契約でよくあるトラブルを5つ取り上げ、それぞれの防ぎ方を整理します。法律の専門的な判断が必要な場面もあるため、最終的には専門家に確認することをおすすめします。
そもそも「開発契約」とは何か
開発契約とは、システムやアプリの開発を依頼する側（発注者）と、開発を行う側（受注者）の間で交わす約束事です。何を作るのか、いくらで、いつまでに、どこまで責任を持つのか、といった内容を文書にまとめたものです。
開発の契約は、Webサイトの制作や店舗の看板を頼むときの契約と比べて、目に見えない部分が多いのが特徴です。完成品を見てから判断しにくいため、「何を作るか」の認識がずれやすく、そこからトラブルが生まれやすくなります。
トラブル1：作るもの（範囲）が曖昧なまま契約する
もっとも多いのが、「どこまで作るのか」が決まらないまま契約してしまうケースです。発注側は「当然これも入っているだろう」と考え、受注側は「それは見積もりに含まれていない」と考える。このずれが、後から追加費用の話になります。
防ぎ方
- 機能の一覧を書き出し、「含むもの」と「含まないもの」を明記する
- 画面の数、帳票の種類、連携する外部サービスなどを具体的に並べる
- 仕様書や要件定義書を契約の附属資料として添付する
要件の整理が難しい場合は、契約前に「要件定義」だけを小さく分けて依頼する方法もあります。いきなり全体を契約するより、認識合わせのための期間を取る方が、結果的に安く済むことが少なくありません。
トラブル2：追加費用・変更時のルールが決まっていない
開発中に「やっぱりこの機能も欲しい」「この画面の並びを変えたい」という要望は、ほぼ必ず出てきます。これ自体は自然なことですが、変更の扱いが決まっていないと、受注側が「追加料金が必要です」と言い出した時点で関係がこじれます。
防ぎ方
- 変更を依頼する手順（書面やチャットでの申請など）を決める
- 変更の見積もりを出す期限と、承認の方法を決める
- 「どの程度の変更までは見積もりに含むか」の目安を話し合っておく
ここで大事なのは、変更を禁止することではなく、変更のたびに費用と期間の影響を見える化することです。発注側も、変更の影響を理解した上で判断できるようになります。
トラブル3：納期の遅れと責任の所在があいまい
「いつまでに完成するのか」は誰もが気にする点ですが、遅れたときに誰が何をするかまで決めていることは少ないものです。発注側が確認や素材の提供を遅らせたために納期がずれたのに、受注側だけが責められる、といった状況も起こります。
防ぎ方
- 各工程の期限（仕様確定、デザイン確認、テスト、納品など）を明記する
- 発注側が提供する資料や確認の期限も契約書に書く
- 遅延が発生した場合の連絡方法と、スケジュールの見直し手順を決める
納期は「完成日」だけでなく、「途中で確認してもらう日」も含めて管理すると、遅れの原因が双方から見えるようになります。
トラブル4：著作権・ソースコードの扱いが不明確
開発したプログラムの著作権を誰が持つのか、ソースコード（プログラムの設計図にあたるもの）を受け取れるのか。この点を決めていないと、納品後に「自社のシステムなのに改修できない」という事態になりかねません。
防ぎ方
- 著作権の帰属（発注者に移すか、受注者に残して利用許諾を受けるか）を明記する
- ソースコードや設計書を納品物に含めるかどうかを決める
- 受注側が使っている既存のライブラリやツールの扱いを確認する
著作権の条項は、一見して難しく感じられる部分です。ただ、「納品後に自社で直せるか」「別の会社に引き継げるか」に直結するため、経営判断として理解しておく価値があります。
トラブル5：納品後の保守・不具合対応の範囲が決まっていない
納品して終わりだと思っていたら、数週間後に不具合が出た。そのとき「保証期間はいつまでか」「無償で直す範囲はどこまでか」が決まっていなかった、という相談は非常に多いものです。
防ぎ方
- 契約不適合（納品物が契約内容と違う場合）への対応期間を決める
- 無償の不具合対応期間と、その後の保守契約の内容を分けて書く
- 保守費用の計算方法と、対応の窓口・時間帯を明記する
保守費用が毎月かかる理由は、サーバーの管理や法令・ OS の更新への対応など、目に見えにくい作業が続くからです。この点を契約前に説明してもらえるかどうかは、受注側の誠実さを見る良い材料にもなります。
契約前に確認したい3つの問い
最後に、契約前に発注側が自分に問いかけておきたいことをまとめます。
- この契約書を読んで、「作るもの」と「作らないもの」が第三者にも伝わるか
- 途中で要望が変わったとき、費用と期間の判断をどう行うかが書いてあるか
- 納品後、自社の人が改修や引き継ぎをできる状態になっているか
どれか一つでも「分からない」「書いていない」が含まれていれば、そこが将来のトラブルの種になっている可能性があります。
まとめ
開発契約のトラブルは、特別な出来事ではなく、「決めていなかったこと」が表に出たものがほとんどです。範囲、変更、納期、著作権、保守の5点を契約の段階で言葉にしておけば、多くの揉め事は防げます。
もし「何をどこまで決めればいいのか分からない」「見積もりや契約書の内容が妥当か自信がない」という状況であれば、一人で抱え込まず、LINEで気軽にご相談ください。発注の前段階の整理から一緒に考えることもできます。
