こんにちは、千葉県の行政書士むらた事務所です。

ITシステムやWebサービスの開発において、プロジェクトが炎上し、裁判などの深刻なトラブルに発展する原因のほとんどは 「仕様変更のルール」 と 「検収の基準」 が契約書で明確になっていないことにあります。

「言った・言わない」の口頭でのやり取りや、ネットで拾った古い契約書のひな形をそのまま使い回していると、受注者は「タダ働き」を強いられ、発注者は「希望したものができない」という、誰にとっても不幸な結果を招きます。

この記事は、以下のような方に向けて書いています。

• システム開発やWeb制作を受注・発注する事業主様
• 「後からの追加要望（仕様変更）」が無料で当たり前だと思われて悩んでいる方
• 納品したのに「確認する時間がない」と検収を後回しにされ、支払いが遅れた経験がある方

今回は、ITシステム開発契約において絶対に外してはならない、「仕様変更」と「検収」のルール化のポイントについて詳しく解説します。

お急ぎの方は一度以下HPまたはLINEから、お気軽にお問い合わせください。

なぜシステム開発契約は揉めやすいのか？

システム開発は、目に見えないものをゼロから作り上げるという性質上、他のビジネスに比べて認識のズレが起きやすい分野です。

「請負契約」か「準委任契約」かの曖昧さ

システム開発契約には、大きく分けて 「請負（うけおい）契約」と 「準委任（じゅんいにん）契約」 の2種類があります。

請負契約は「システムを完成させること」に責任を持ち、完成してはじめて報酬が支払われます。
一方、準委任契約は「専門知識を提供して作業すること」自体に報酬が支払われ、完成の義務は負いません。

ここを契約書で明確にしておかないと、「完成するまで何度でも無料で修正してくれるはずだ（請負）」と考える発注者と、「これ以上の作業は追加費用がかかる（準委任）」と考える受注者の間で、激しい衝突が起きてしまいます。

「仕様変更」は必ず起きるという前提

開発を進めるうちに、「やっぱりこの機能も追加したい」「画面のデザインを変えたい」という要望（仕様変更）は、ほぼ100％の確率で発生します。
問題なのは、変更が起きること自体ではなく、 「その変更に伴う追加費用やスケジュールの延期を、どうやって決めるか」のルールが存在しないこと なのです。

【図解】揉めないための「仕様変更」ルールの作り方

仕様変更のトラブルを防ぐためには、契約書の中に「変更管理手順（チェンジマネジメント）」を明記することが必須です。
見やすい表で、理想的なルール化のステップを整理しました。

ステップ	アクションと契約書に定めるべきルール	注意点
1. 変更の要請	発注者は、仕様変更の要望を 必ず「書面（メールやチャットツール等の電磁的記録を含む）」 で受注者に通知する。	「打ち合わせでの口頭のお願い」は仕様変更として受け付けないルールにします。
2. 影響度の提示	受注者は、その変更を行った場合の 「追加費用の見積もり」と「納期の変更スケジュール」 を書面で発注者に提示する。	軽微な変更であっても、必ず費用とスケジュールの影響を提示するプロセスを挟みます。
3. 変更の合意	発注者と受注者の双方が、提示された追加費用と納期に 合意（承認）した時点で、初めて仕様変更が確定 し、作業を開始する。	合意が形成されるまでは、受注者は「変更前の元の仕様」で開発を進める権利を持ちます。

このように、「勝手に仕様が追加されること」を防ぎ、 追加作業には必ず追加費用と納期の見直しがセットになる仕組み を契約書に組み込むことが、自社を守る最強の盾となります。

トラブルを防ぐ「検収」の明確化と「みなし検収」

システムが完成し、納品された後に行われるのが「検収（要求した通りに動くかどうかのテスト・確認）」です。
この検収に合格して初めて、代金の支払い義務が確定します。（請負契約の場合）

しかし、ここにも大きな落とし穴があります。

「検収基準（ゴール）」を事前に定義する

「なんとなく使いにくいから検収不合格」といった発注者の主観で突き返されるのを防ぐため、 何をクリアすれば検収合格とするのか（テスト項目や基準） を、開発がスタートする段階で合意しておく必要があります。

最重要条項！「みなし検収」を必ず設定する

受注者にとって最も恐ろしいのが、 納品したのに発注者が忙しさを理由にいつまでも検収（確認作業）をしてくれないケース です。
検収が終わらないと、いつまで経っても請求書が出せません。

これを防ぐために、契約書には必ず以下のような 「みなし検収（自動検収）」 の条項を入れてください。

【みなし検収の記載例】

「発注者は、納品物を受領した後、〇日以内（例：14日以内）に検収を行わなければならない。もし期間内に発注者から合格・不合格の通知がなかった場合は、当該期間の満了をもって検収に合格したものとみなす。」

この一文があるだけで、発注者の放置による「支払い遅延」を完全にブロックすることができます。

当事務所にご相談いただいた柏市のWeb制作会社様は、過去の案件でクライアントから『やっぱりあそこの色を変えて』『このボタンも追加して』と口頭での変更依頼が無限に続き、納品後も1ヶ月以上検収してもらえず、資金繰りが悪化して赤字になりかけていました。
私たちがヒアリングを行い、契約書に『仕様変更の書面合意ルール』と『10日間のみなし検収条項』をガッチリと組み込んだところ、その後の案件では追加費用も適正に請求できるようになり、利益率がしっかりと改善しました。

よくある質問（FAQ）

Q. メールやSlack（チャットツール）でのやり取りも「書面での合意」に含まれますか？

A. 契約書の中に「本契約において書面とは、電子メールやチャットツール等の電磁的記録を含むものとする」という定義をしっかり記載しておけば、有効な合意として認められます。
現代の開発現場に合わせた柔軟な契約書作りが重要です。

Q. 検収後にバグが見つかった場合、どう対応すればいいですか？

A. システムに不具合（契約不適合）があった場合、法律上、受注者はそれを修正する責任（契約不適合責任）を負います。
しかし、これを「永久に無料で直す」とするのは受注者にとってリスクが大きすぎます。
契約書で「検収完了後〇ヶ月以内に発見されたものに限り、無償で修正する」と、責任を負う期間（保証期間）を明確に制限しておくことが鉄則です。

Q. ネットにある無料の「業務委託契約書」のひな形を使っても大丈夫ですか？

A. 非常に危険です。
無料のひな形は「誰にでも当てはまるように」書かれているため、あなたの会社特有の開発フローや、細かい仕様変更のルール、みなし検収の期間などが抜け落ちていることがほとんどです。
万が一のトラブル時に、自社を守りきれない可能性が高いです。

まとめ：流山・柏・松戸のIT契約書作成は行政書士むらた事務所へ！

システム開発やWeb制作の契約において、 「仕様変更」と「検収」のルールは、プロジェクトの利益と会社の命運を左右する最も重要なパーツ です。

「クライアントとの関係を悪くしたくないから」と契約書の整備を後回しにして、結果的に裁判沙汰になり、信用も利益もすべて失ってからご相談に来られる事業主様は後を絶ちません。

「今使っている契約書が、本当に自社を守れる内容になっているかチェックしてほしい」

「アジャイル開発（少しずつ作っていく手法）に合わせた契約書を作りたい」

「トラブルになったクライアントとのやり取りについて、法的な視点からアドバイスがほしい」

そんなお悩みをお持ちのIT事業主様・発注者様は、ぜひ行政書士むらた事務所にお任せください！

千葉県の流山市・柏市・松戸市周辺の中小企業法務に強い私たちが、 お客様の実際の開発フローや業界の慣習を丁寧にヒアリングし、あらゆるトラブルの芽を事前に摘み取る「完全オーダーメイドのシステム開発契約書」を作成 いたします。

ご相談やお問い合わせは、当事務所のホームページのお問い合わせフォーム、または公式LINEより 【24時間受付】 しております。

安心して開発に集中し、正当な利益をしっかりと確保するために。
不安なまま契約のハンコを押す前に、まずは今すぐ、お気軽にご連絡ください！