小規模なシステム開発で契約書は必要か｜数万円〜30万円の依頼で実際に取り交わしているものと、揉める本当の原因

「この規模なら契約書はいらないですよね」。小さな開発依頼では、発注する側も受ける側も、この曖昧さの上で仕事が進んでいることがあります。この記事は、FUNBREWが数万円から30万円規模の依頼で実際に何を取り交わしているか、そして契約書の有無とは別のところで食い違いが起きるという実務をまとめたものです。書式や条項の解説ではなく、発注側が「何を残しておくと認識のズレが起きにくいか」に絞って書きます。

数万円〜30万円の依頼で、実際には何を取り交わしているのか

先に本来の話をしておくと、数万円の依頼であっても契約書は作成すべきものです。そのうえで実務の話をすると、内容が明確で規模の小さい依頼では、見積もりと簡単なドキュメントだけで進むことがあります。業界的にも、小粒な案件で契約書が交わされないことは珍しくありません。

あるべき論と、小規模案件の実情はずれている

なぜ「作るべき」と「作られていない」がずれるのか。理由は単純で、契約書を整えるコストが開発そのもののリソースを圧迫するからです。30万円の案件で、要件を詰め、書面を起こし、修正のやりとりをすると、その時間だけで案件の利益が消えます。受注に至らない見積もり作成に時間を費やす、いわゆる見積もり貧乏の状態にも近づきます。

これは「だから契約書はいらない」という話ではありません。小規模案件では、契約書を作る手間そのものが有限の予算を食うという構造があり、その中で何を優先するかという問題だ、ということです。

取り交わしているものの実際

後者はきちんとした進め方ですが、30万円規模の案件でこれをやると、今度はコストに見合わなくなります。金額の大小で機械的に線を引いているのではなく、内容が明確かどうかと、その作業がコストに見合うかどうかで運用が変わっている、というのが実態に近い説明です。

揉めるのは契約書の有無ではなく「開発の範囲」

ここがこの記事でいちばん伝えたい点です。FUNBREWの経験では、契約書が無いことが原因で揉めたことはありません。揉めるのは、ほぼ例外なく開発の範囲です。「これは入っていると思っていた」「そこは別のお見積もりになります」という食い違いで、これは規模の大小にかかわらずよく起きます。

なぜ範囲でずれるのか

発注側が言葉で指定する機能と、開発側がその言葉から読み取る作業量が一致しないためです。たとえば「ユーザー管理」という一語には、一覧と登録だけを想像する人もいれば、CSVでの入出力、二要素認証、パスワードポリシーまで含まれていると解釈する人もいます。どちらが間違っているという話ではなく、言葉が同じでも中身が違うまま契約書だけを交わしても、この食い違いは残ります。

逆に言えば、範囲さえ明確なら、書面が簡素でも揉めにくいということでもあります。開発中に要望が増えたときにどこから追加費用になるかは、開発中に要望が増えたとき、追加費用の境目はどこかで詳しく書いています。

契約書が無くても揉めなかったのは、どういうときか

共通しているのは、依頼の内容が本当に明確だったときです。

• 「今起きているバグを解消してほしい」 —— 不具合が直ることがそのまま納品基準になるため、完了の判断で揉めようがありません。
• 「これと全く同じものを作ってほしい」 —— 完成形が非常に分かりやすく、コストに見合えば認識がずれません。

どちらも、「何をもって終わりとするか」が最初から一つに決まっているという共通点があります。逆に、作りながら決めていく性質の依頼ほど、範囲の話は避けて通れなくなります。

発注側が最低限やっておくと得をすること

ここからは、発注する立場の方に向けた実務的な話です。順番に意味があります。

1. 契約書を作ることを厭わない

まず、契約書を作ること自体を面倒がらないでください。そのうえで、次の視点を持っておくと、開発会社との関係がかなり楽になります。

2. 開発会社が契約書を出してくるのは「要求が増えること」への備え

開発会社が書面を求めるのは、多くの場合、発注側を縛りたいからではありません。着手後に要求が増えていくことへの備えです。裏を返せば、作りたいものが明確であるほど、相手は安心して受けられます。書面を厚くするより、作りたいものを具体的にする方が、結果として双方の守りになります。

3. 相談しながら作りたいなら、その相談にもコストがかかる

「一緒に考えながら作りたい」という進め方自体は問題ありません。ただし、その打ち合わせや調査には工数がかかっています。ここを見えないサービスとして期待すると、範囲の食い違いが起きやすくなります。相談ベースで進めたい場合は、その分の費用が乗ることを前提に相談するのが、結局はいちばん早く進みます。

何をどう書いて相談すれば話が早いかは、開発の相談メールに何を書けば話が早いかにまとめています。また、営業担当と実際に手を動かす担当が分かれている会社に発注する場合の注意点は、営業と実務が分離した開発会社に発注するときを参照してください。契約の一般的な考え方についてはシステム開発の契約ガイドもあわせてどうぞ。

まとめ

小規模なシステム開発では、見積もりと簡単な資料だけで進むことがあります。本来は数万円でも契約書を作るべきですが、その作業コストが案件の予算を圧迫するという実情があり、内容の明確さとコストのバランスで運用が決まっています。

そして、実際に揉める原因は契約書の有無ではなく開発の範囲です。「今あるバグを直す」「これと同じものを作る」のように終わりが一つに決まっている依頼は、書面が簡素でも揉めません。発注側にできる最善は、書式を整えることよりも先に、作りたいものを明確にすることです。

小規模な依頼でも、範囲の整理から相談を受け付けています。お問い合わせからお気軽にご連絡ください。

支払いをどのタイミングで区切るのか、開発会社が工数を先に持ち出す構造については、システム開発の支払いはなぜ着手金から始まるのかもあわせてご覧ください。