外注時によくあるトラブルと回避するための契約ポイント
- atsu wada
- 2025年10月20日
- 読了時間: 9分
「契約書はよく読まずにサインしてしまった」「こんなはずじゃなかった」。システム開発を外注した企業の担当者から、こんな後悔の声をよく聞きます。
開発会社との打ち合わせが順調に進み、見積もりにも納得して契約を結んだものの、いざプロジェクトが始まると「聞いていた話と違う」「追加費用が次々と発生する」「納期が大幅に遅れる」といったトラブルに見舞われるケースは少なくありません。
多くのトラブルは、契約段階での取り決めが曖昧だったことが原因です。逆に言えば、契約時にポイントを押さえておけば、大部分のトラブルは未然に防ぐことができるということです。
本記事では、実際に起こったトラブル事例をもとに、契約で必ず確認すべきポイントと具体的な対策をまとめました。「契約書なんて難しそう」と敬遠せず、最低限のポイントだけでも押さえて、安心してプロジェクトを進められるようになりましょう。
システム開発 外注でよくあるトラブル事例
システム開発の外注で起こるトラブルには、典型的なパターンがあります。まずは、実際にどんな問題が起こりやすいのかを具体的に見てみましょう。これらの事例を知っておくだけでも、同じ失敗を避けることができます。
予算トラブル：「300万円」が「800万円」になったケース
ある製造業では、当初300万円の見積もりでシステム開発をスタートしました。ところが、プロジェクトが進むにつれて「この機能は含まれていない」「要件が想定と違った」「この処理は別途費用が必要」と次々に追加費用が発生し、最終的に800万円を超えてしまいました。
原因は、見積もりが「システム開発一式 300万円」という大雑把な記載で、何が含まれて何が含まれないのかが明確になっていなかったことでした。開発会社側も「これは当然別料金」と考えていた部分を、発注側は「当然含まれている」と思い込んでいたのです。
納期トラブル：3ヶ月が6ヶ月になったケース
小売業の事例では、「3ヶ月で完成予定」だったシステムが、結局6ヶ月かかった上に、品質にも問題が残る結果となりました。
当初の契約では「○月末完成予定」という記載だけで、各工程の期間や、遅延が発生した場合の対応方法が決められていませんでした。途中で仕様変更もあったのですが、それがスケジュールにどう影響するかも曖昧なまま進行し、気がついたときには大幅な遅延となっていたのです。
品質トラブル：完成したが業務に使えないシステム
サービス業の事例では、システムは確かに「完成」したものの、実際の業務では使えないという問題が発生しました。
エラーが多発する、動作が重い、操作性が低いなど、様々な問題があったのですが、契約書には「システムが動作すること」としか書かれておらず、「使いやすさ」や「性能」についての具体的な基準がありませんでした。開発会社は「契約通りに動くシステムを納品した」と主張し、修正には追加費用が必要と言われてしまいました。
コミュニケーショントラブル：担当者交代で振り出しに戻る
IT企業の事例では、プロジェクト開始から2ヶ月後に開発会社の担当者が突然交代となりました。新しい担当者は、それまでの経緯や細かい要件を十分に理解しておらず、何度も同じ説明を繰り返す羽目になりました。
結果、スケジュールが大幅に遅れただけでなく、当初の仕様と異なるシステムが完成し、大幅な修正が必要になりました。
トラブルを招く3つの落とし穴
これらのトラブルに共通するのは、契約時の取り決めが曖昧だったということです。なぜこのような曖昧な契約になってしまうのでしょうか。
契約書の「曖昧な表現」への依存
「システム開発一式」「適宜対応」「協議の上決定」といった表現は、一見包括的で安心に見えます。しかし、実際には解釈の幅が広すぎて、後でトラブルの原因となります。
「お互いに常識的に判断すれば分かるだろう」という暗黙の期待が、認識のズレを生んでしまうのです。
「まあ何とかなるだろう」という楽観的な判断
初回の打ち合わせが順調だと、「この会社なら大丈夫」「細かいことは後で相談すれば良い」という気持ちになりがちです。しかし、プロジェクトが進むにつれて、お互いの「常識」が実は違っていたことが明らかになります。
特に、システム開発は長期間にわたるプロジェクトのため、途中で担当者が変わったり、当初の前提が変わったりすることも多く、曖昧な契約では対応できなくなってしまいます。
お互いの「常識」のズレ
発注側は「このくらいは当然やってもらえる」と思い、開発側は「ここまでは別料金」と考える。このような認識のギャップは、お互いの業界の常識や経験の違いから生まれます。
システム開発に慣れていない発注側と、多くのプロジェクトを経験している開発側では、「当たり前」の基準が大きく異なることがあるのです。
契約で必ず決めておくべき5つのポイント
トラブルを防ぐために、契約時に必ず確認・合意しておくべきポイントを5つに整理しました。すべてを完璧に決める必要はありませんが、少なくとも「どう決めるか」のルールは明確にしておきましょう。
1. 作業範囲の明確化
最も重要なのは、何をやってもらえて、何はやってもらえないのかを明確にすることです。
含むもの・含まないものを具体的に列記
要件定義、設計、プログラミング、テスト、導入支援など、各工程の範囲
データ移行、既存システムとの連携、ユーザー研修などの付帯作業
サーバー構築、ライセンス取得、保守・運用などのインフラ関連
グレーゾーンの扱い方を決める 「軽微な修正は無償対応」という場合は、「軽微」の基準を明確にします。「1人日以内の作業」「画面項目の追加・削除以外」など、具体的な線引きをしておきます。
2. 変更・追加時のルール
プロジェクト途中での仕様変更や機能追加は避けられません。変更が発生した場合のルールを事前に決めておくことで、スムーズに対応できます。
費用算定の方法
人日単価の設定（例：SE 8万円/日、PG 5万円/日）
見積もり提出のタイミング（変更依頼から○営業日以内）
最低請求単位（0.5人日単位など）
承認プロセスと責任者
誰が変更を承認する権限を持つのか
承認された変更はいつから作業開始するのか
変更による納期への影響をどう調整するか
3. 納期と品質の基準
「いつまでに」「どのレベルで」完成させるかを具体的に定義します。
納期の設定方法
各工程の完了予定日を明記
中間成果物の確認・承認期間も含めたスケジュール
遅延時のペナルティや対応方法
受け入れテストの具体的条件
テスト項目数や合格基準
不具合レベルの定義（致命的、重要、軽微など）
受け入れ完了の判定基準
4. コミュニケーションルール
定期的な報告と適切な情報共有は、プロジェクト成功の鍵です。
報告頻度と方法
進捗報告の頻度（週次、隔週など）
報告書のフォーマットと内容
課題やリスクの報告ルール
窓口の明確化
発注側、開発側それぞれの担当者と権限
担当者変更時の引き継ぎ方法
緊急時の連絡手段
5. トラブル時の対応
問題が発生した場合の責任範囲と対応方法を決めておきます。
責任範囲の線引き
開発側の責任範囲（バグ、仕様漏れ、納期遅延など）
発注側の責任範囲（仕様変更、情報提供遅延など）
双方の責任が曖昧な場合の対応方法
損害発生時の扱い
損害賠償の上限額
免責事項（天災、発注側都合の変更など）
解決手段（協議、調停、仲裁など）
契約書でチェックすべき危険な表現
契約書を確認する際は、以下のような曖昧な表現がないかをチェックしましょう。
危険な表現の例
危険な表現 | なぜ危険か | 改善例 |
「システム開発一式」 | 範囲が不明確 | 「要件定義、基本設計、詳細設計、プログラミング、テスト」 |
「適宜対応」 | 基準が曖昧 | 「月1回の定例会議で協議」 |
「協議の上決定」 | 決定方法が不明 | 「発注者の承認を得て決定」 |
「軽微な修正」 | 軽微の基準不明 | 「0.5人日以内の作業」 |
「完成時」 | 完成の定義不明 | 「受け入れテスト合格時」 |
修正を求めるべき条項
免責事項が広すぎる：「発注者都合による変更はすべて有償」など
責任制限が極端：「いかなる損害も責任を負わない」など
契約解除条件が一方的：開発側だけに有利な解除条件など
小さく始めてリスクを下げる方法
初めての外注や新しい開発会社との取引では、いきなり大きなプロジェクトを任せるのはリスクがあります。段階的に進めることで、リスクを最小限に抑えられます。
パイロット版での相性確認
まずは小規模な機能やプロトタイプの開発を依頼し、お互いの相性を確認します。
パイロット版のメリット
コミュニケーションの取りやすさを確認
技術力と品質レベルを実際に評価
契約条件や進行方法の改善点を発見
段階的発注のメリット
大きなシステムを段階に分けて発注することで、途中での軌道修正が可能になります。
第1期：基本機能の開発
最低限必要な機能に絞って開発
品質や進捗を確認してから次の段階へ
第2期以降：機能拡張
第1期の評価をもとに契約条件を見直し
より詳細な要件で品質向上を図る
チェックリスト：契約前の確認項目
□ 作業範囲が具体的に明記されている □ 含まれないものも明確に列記されている □ 変更時の費用算定方法が決まっている □ 各工程の完了予定日が明記されている □ 受け入れテストの基準が具体的が決まっている □ 担当者と権限が明確になっている □ 進捗報告の頻度と方法が決まっている □ トラブル時の責任範囲が明記されている □ 曖昧な表現（「一式」「適宜」など）がない □ 一方的に不利な条項がない |
10項目中8項目以上がクリアできていれば、安心して契約できるレベルです。
まとめ：契約は保険、大切なのは信頼関係
契約書で細かく取り決めることは重要ですが、それはあくまで「万が一の保険」です。最も大切なのは、お互いを信頼し、同じ目標に向かって協力できるパートナーシップを築くことです。
完璧な契約書を作るよりも、「困ったときに相談しやすい」「問題があったら一緒に解決してくれる」という関係性の方が、プロジェクト成功には重要です。
契約は信頼関係を支える最低限のセーフティネットです。お互いの「当たり前」を言葉にして、認識のズレを防ぐためのツールとして活用しましょう。
まずは今回紹介したチェックポイントを参考に、現在検討中の契約内容を見直してみてください。そして、契約書の条項よりも、「この会社となら問題が起きても一緒に解決できそうか」という感覚を大切にしてください。良いパートナーとしっかりした契約があれば、システム開発プロジェクトを成功に導くことができます。
