「IT外注を頼んだら納期が守られず、請求だけ来た」「システムができあがったが、思っていたものと全然違う」——中小企業経営者がIT外注で経験するトラブルは後を絶ちません。多くの場合、原因は技術力の問題ではなく契約書の曖昧さにあります。
この記事では、IT外注で失敗した中小企業の実例を3つ取り上げ、それぞれの契約書における見落とし箇所を解説します。さらに、契約前・契約時・納品後の各フェーズで経営者や情シス兼任担当者が確認すべき観点を整理します。製造業の2代目経営者から士業事務所の所長まで、IT外注を検討しているすべての中小企業の経営者に読んでいただきたい内容です。
IT外注で失敗する中小企業に共通する3つの構造
中小企業のIT外注失敗は、特殊な事情によって起きるわけではありません。実際に複数の失敗事例を分析すると、以下の3つの構造が繰り返し登場します。
第1の構造：要件定義を業者任せにしている
「何を作ってほしいか」を言葉で伝えただけで、文書化せずに発注するケースが多くあります。この状態では、「言った・言わない」の水掛け論が必ず起きます。業者側は受け取った指示で開発を進め、発注者側は「頼んだものと違う」と感じます。どちらも嘘をついているわけではなく、認識がずれているだけ——この構造的なすれ違いが失敗の温床です。
要件定義とは、「何をどこまで作るか」を言語化して合意する作業です。これを省略すると、開発後に「ここまでやってくれると思っていた」「それは仕様外です」という対立が生まれます。発注金額が小さいほど要件定義をスキップしがちですが、金額の大小と要件定義の必要性は無関係です。
第2の構造：契約書を業者の雛形そのまま使っている
業者が用意した契約書はもちろん業者の利益を守るように設計されています。「瑕疵担保責任は引き渡しから3か月」「仕様変更は都度見積もり」などの条項が入っていても、「標準的な条件だから」と署名してしまう経営者は少なくありません。標準的と言われれば反論しにくいのが実態ですが、その「標準」が誰の標準かを考える必要があります。
特に中小の受託開発会社が使う雛形契約書は、過去のトラブルから自社を守るための蓄積が込められています。一方で、発注者を守る条項は最低限にとどまっている場合がほとんどです。
第3の構造：進捗管理の仕組みがない
週次報告も中間成果物の確認ルールもないまま開発を進めると、3か月後に「ほぼ動かないシステム」が納品されることがあります。その時点で契約書を見直しても、「仕様通りの納品」と主張されると反論できない条件になっていることがほとんどです。
進捗管理の不備は、問題の発見を遅らせます。早期に気づけば軌道修正できる問題も、完成直前に判明すれば作り直しのコストが発生します。定期報告と中間レビューの機会を契約に盛り込んでおくことが、後半フェーズでの問題発覚を防ぐ最も現実的な手段です。
これら3つの構造に共通するのは、「契約書と運用ルールの不備」です。技術力の問題を先に疑いがちですが、根本にある問題は経営者側の発注管理にあります。
IT外注失敗の実例3つ：契約書のどこで躓いたか
事例1：受発注管理システムの「仕様変更費用」が青天井になった製造業（従業員28名）
埼玉県の金属部品メーカーが、受発注管理の効率化を目的に130万円で社内システムを外注しました。開発が進む中で「やっぱり帳票の形式を変えたい」「在庫の計算方法が違った」などの修正が発生。業者からその都度「仕様変更費用」として請求が届き、最終的な総費用は320万円に膨らみました。当初見積もりの2.5倍です。
契約書を確認すると、「仕様変更は別途費用を協議する」とだけ記載されていました。協議の単価基準も、変更可能な上限回数も定めていなかったため、業者側が設定する金額に従うしかない状況でした。製造業2代目の経営者は「協議すると書いてあったから話し合えると思った。まさか協議のたびに業者の言い値になるとは思わなかった」と話しています。
・見落とし箇所：仕様変更の定義・単価・上限回数が未定義。「協議する」という言葉が業者の裁量を無制限に広げていた。
・教訓：「仕様変更1件あたりの単価上限」「変更対応の無償範囲（初期設計の誤りは無償修正）」を契約書に明記する。
事例2：ホームページ制作でサーバー費用の負担が不明確だったサービス業（従業員12名）
大阪市の整体院チェーン（3店舗）がコーポレートサイトとWeb予約システムを80万円で発注しました。納品後1年でサーバー会社から「契約名義を移してほしい」という連絡が届き、年間12万円のサーバー費用が突然自社負担になることが判明しました。業者は「サーバー費用は別途と説明した」と言いますが、契約書にはその旨の記載がありませんでした。
さらに、同時期に業者が廃業。保守サポートが受けられなくなりましたが、保守終了時の引き継ぎ手順も契約書に定められていなかったため、ソースコードの取得交渉も難航しました。最終的に別の業者にソースコードの解析から依頼することになり、追加で40万円の費用がかかりました。
・見落とし箇所：インフラ費用（サーバー・ドメイン）の負担区分が未定義。業者廃業・契約終了時の成果物（ソースコード・設計書）の引き渡し条件が未記載。
・教訓：「インフラ費用の負担者と継続条件」「業者廃業時のソースコード供託または自動引き渡し条項」を契約書に含める。
事例3：税理士事務所の顧客データが業者に残存していた士業（従業員8名）
東京都内の税理士事務所が、顧問先の決算書を管理するクラウドシステムを外注しました。2年後にシステムを別業者に切り替えた際、旧業者にデータの削除を求めましたが、「バックアップとして保持する義務がある」と主張され、削除を拒否されました。
顧問先の財務情報という機密性の高いデータが第三者の手元に残存するリスクを、事務所として顧問先に説明しなければならない事態になりました。税理士法上の守秘義務の観点から、顧問先から「なぜ報告が遅れたのか」と問い合わせを受けたケースもあります。契約書に「契約終了後のデータ取り扱い」の条項がなかったことが直接の原因です。
・見落とし箇所：契約終了後のデータ削除義務・消去証明の取得方法・情報管理責任が未定義。士業特有の守秘義務リスクが契約に反映されていなかった。
・教訓：「契約終了後○日以内にデータを削除し、消去証明書を交付すること」を明記する。顧客情報を扱う場合は秘密保持条項（NDA）を強化する。
IT外注の契約書レビューで確認すべき7つの観点
実例から浮かび上がった問題を整理すると、チェックすべき観点は以下の7つに集約されます。経営者自身が全条項を熟読する必要はありませんが、以下の観点が「ある・ない・曖昧」のどれに当たるかは必ず確認してください。
| 観点 | 確認すべき内容 | 記載がない場合のリスク |
|---|---|---|
| ①成果物の定義 | 「何をもって完成とするか」が文書で明示されているか | 「言った・言わない」で水掛け論になる |
| ②仕様変更の取り決め | 変更単価・変更手続き・上限回数が定義されているか | 追加費用が青天井になる |
| ③納期と遅延時の対応 | 中間マイルストーン・遅延ペナルティ・延長条件が明記されているか | 無限に延期されても手が打てない |
| ④瑕疵担保責任の期間 | バグ修正の保証期間と対応範囲が明確か（稼働後12か月以上が望ましい） | 短期間で保証が切れ、有償修正を求められる |
| ⑤インフラ・保守費用の区分 | サーバー費用・ライセンス料・保守料の負担区分が明確か | 見えないコストが後から発生する |
| ⑥成果物の著作権・所有権 | ソースコード・設計書・データの権利が自社に帰属するか | 他社に乗り換えができない状況になる |
| ⑦契約終了時のデータ取り扱い | データの削除義務・消去証明・引き渡し手順が明記されているか | 情報漏洩リスクが契約終了後も継続する |
特に④の瑕疵担保責任については、「引き渡しから3か月」という短期設定が業者側の雛形によく見られます。業務システムの場合、運用を開始してから3か月後にようやくバグが露見することも多く、この期間設定では実質的に保証がないに等しいケースがあります。最低でも「稼働後12か月」を求めることが妥当です。
⑥の著作権については、「業者が開発したソフトウェアの著作権は業者に帰属する」という条項が標準とされている場合があります。これはシステムの改修・乗り換え・第三者への提供を業者の許諾なしにできないことを意味します。自社のシステムは自社に権利が帰属するよう、発注段階で交渉することが重要です。なお、業者が既存のライブラリや共通部品を活用している場合、著作権を完全に自社に移転できないケースもあります。その場合は「利用ライセンスの永久・無償付与」を代替として求めてください。
契約書を業者から受け取ったら：自社でできる交渉の進め方
「弁護士に頼む費用もないし、自分で確認するしかない」という中小企業経営者のために、実際に使える交渉アプローチを整理します。
Step1：変更不可な条項と交渉できる条項を分ける
受け取った契約書を通読し、各条項が「弊社標準条件のため変更不可」と言われそうかどうかを仮評価します。大手IT企業との契約では変更できない条項が多い一方、中小のシステム会社では交渉に応じてもらいやすいケースも多くあります。「変えてもらえないか聞いてみる」というスタンスでまず相談することが第一歩です。
Step2：7観点の「ない・曖昧」をリストアップする
7観点の中で記載がない、または曖昧な表現にとどまっているものをリストアップします。「協議する」「双方の合意により」という表現は、合意できなかった場合のルールがない点で危険信号です。たとえば「協議の結果、合意に至らない場合は○円を上限として発注者が判断する」という表現に変えてもらうだけでもリスクが大幅に下がります。
Step3：追記・修正を文書で依頼する
口頭で交渉すると、後から「そんな約束はしていない」と言われます。必ずメールや書面で「○条の仕様変更費用について、変更単価の上限を1工数あたり○円以内とする条項を追加してください」と具体的に依頼します。業者の回答もメールで受け取ることで、後から証拠として使えます。
Step4：業者の交渉姿勢をスクリーニングとして使う
交渉に対して「弊社では一切対応できません」と取り合わない業者は、それ自体がリスク評価の材料です。優良な業者は「なぜその条項が必要か」を説明した上で代替案を出してきます。交渉プロセスは業者の誠実さと対応力を測るスクリーニングにもなります。
なお、契約金額が500万円を超える場合、または顧客データを扱うシステムを外注する士業・医療・金融業の場合は、IT専門の弁護士または法律に詳しいITコンサルタントに契約書レビューを依頼することを強く推奨します。1件10万円前後のレビュー費用で、数百万円規模のトラブルを防げる可能性があります。日本IT法務協会（2026年7月時点）などが専門家リストを公開しています。
IT外注契約前チェックリスト
発注前に以下の15項目を確認してください。「×」が3つ以上なら契約内容の見直しを優先します。チェックリストは印刷して打ち合わせに持参することを推奨します。
・成果物の定義：「何が完成品か」を文書で合意しているか
・仕様変更の単価と手続き：変更が発生したときの費用計算方法が明記されているか
・中間マイルストーンの設定：要件定義・設計・開発・テストの各納期が契約書に記載されているか
・遅延時のペナルティ：納期遅延が発生した場合の対応ルールがあるか
・バグ修正の保証期間：瑕疵担保責任の期間が「稼働後12か月以上」になっているか
・インフラ費用の負担区分：サーバー・ドメイン・ライセンスの費用負担者が明確か
・ソースコードの権利：開発成果物の著作権または利用ライセンスが自社に帰属する条項があるか
・設計書・仕様書の納品：ドキュメント類の納品が契約に含まれているか
・データの扱い：契約終了後にデータを削除・返却する義務と消去証明の取得が明記されているか
・秘密保持条項（NDA）：自社の情報を第三者に開示しない義務があるか
・再委託の制限：業者が作業を別会社に丸投げする際の事前同意ルールがあるか
・進捗報告の頻度：週次・月次など定期報告の義務が記載されているか
・解約時の費用精算：中途解約した場合の精算方法が明確か
・紛争解決の方法：トラブル時の解決手段（調停・仲裁・訴訟の管轄裁判所）が定められているか
・契約書の優先順位：口頭合意・見積書・提案書と契約書の優先関係が明確か
よくある質問
Q1. 小規模な発注（50万円以下）でも契約書は必要ですか？
必要です。金額の大小よりも「成果物の定義が曖昧な状態で発注する行為」がリスクの本質です。50万円の案件でトラブルになれば、追加費用や対応コストを含めてその倍以上の損失が発生することがあります。金額が小さい場合は、詳細な契約書の代わりに「発注書・仕様確認書」として1枚の文書を作成し、双方が署名する方法でも有効です。Wordで作った簡易書式でも、双方が合意の署名をすれば法的拘束力を持ちます。
Q2. 業者が「うちは標準契約書しか使えない」と言ってきたら？
標準契約書の内容を確認した上で、追加条項（覚書・特約）として別紙で追記する方法が有効です。「標準契約書に覚書を付けて、○条については以下の内容を優先する」とする形式は法的に有効です。標準契約書を変えることなく、自社に不利な条項の効力を覚書で上書きできます。覚書の追加に応じない業者は、交渉姿勢そのものを評価材料として業者選定に反映することを検討してください。
Q3. 発注後に「やっぱり要件を変えたい」となった場合はどうすればいいですか？
変更依頼を口頭で行うのは避けてください。必ず「変更依頼書」を作成し、変更内容・追加費用・スケジュール変更を書面で合意した後に作業を進めてもらいます。変更のたびに書面化する習慣が、後からの「言った・言わない」を防ぎます。変更依頼書のテンプレートは、IT専門の中小企業支援機関（独立行政法人情報処理推進機構が公開する参考資料など）が無償で提供しているものを活用できます。
Q4. 士業事務所が顧客データを扱うシステムを外注する場合、追加で確認すべきことはありますか？
守秘義務に関する条項を強化する必要があります。具体的には、①業者が顧客データを自社のAI学習や業務改善に使用しないこと、②再委託先に顧客データを渡す場合は事前承諾を得ること、③契約終了後のデータ削除を証明書付きで実施すること、の3点を必ず明記させてください。特に、クラウドシステムを利用する場合は「データの保管場所（国内か海外か）」も確認が必要です。海外サーバーに保存される場合、GDPRや各国のデータ規制が適用されるリスクがあります。
Q5. 一度失敗した業者との契約を継続するか切るかを判断する基準は何ですか？
3つのサインが継続困難の目安です。①報告書がない・報告が遅れる（透明性の欠如）、②問題が発生しても「仕様通り」と主張して修正に応じない（誠実さの欠如）、③追加費用の根拠説明が不十分（信頼性の欠如）。いずれか1つでも該当するなら、継続よりも切り替えの準備を先に始めることを推奨します。切り替え時は現業者から成果物・データ・ソースコードを取り戻す「引き継ぎ計画」から着手してください。データが取り戻せない状態での解約は、新業者への移行コストを大幅に増やします。
まとめ：IT外注の失敗は契約書の準備で防げる
IT外注の失敗事例を分析すると、技術力の問題よりも契約内容の不備が根本原因であるケースが大多数です。特に中小企業では、経営者や情シス兼任担当者が契約書の全条項を熟読する時間を確保するのは難しい現実があります。
それでも、本記事で解説した「7つの観点」と「15項目の契約前チェックリスト」を手元に置くだけで、見落としリスクを大幅に下げることができます。
・仕様変更費用の青天井：変更単価・上限回数を契約書に明記することで防げる
・インフラ費用の後出し：費用負担区分を発注前に書面で合意することで防げる
・データの残存リスク：契約終了後の削除義務と消去証明を条項に含めることで防げる
・著作権の問題：自社帰属または無償永久ライセンスを発注段階で交渉することで防げる
発注金額が大きい場合、または顧客データを扱う場合は、最初の1件だけでもIT専門のコンサルタントによる契約書レビューを受けることを検討してください。「最初から正しい契約書を作る習慣」が、外注コストを長期的に下げる最も確実な方法です。
IT外注の契約書に不安がある場合や、現在進行中の外注トラブルへの対応についてご相談は、株式会社イーネットマーキュリーの問い合わせフォームからお気軽にどうぞ。経営者・情シス兼任担当者の立場に立ったアドバイスを提供します。
