業務委託エンジニアのトラブル事例10選｜発注企業の解決・予防策

社内のエンジニアリソースが足りず、業務委託で外部エンジニアを使い始める。あるいは、これから使おうとしている。そんなとき、頭をよぎるのが「外注は揉めやすいと聞くけれど、何が地雷になるのか分からない」という漠然とした不安ではないでしょうか。

発注側として委託契約を主導した経験が浅いと、契約形態の違いや指揮命令の線引き、成果物の受け入れ基準といった論点が「言われてみればそうだけれど、実務でどう手を打てばいいのか分からない」状態になりがちです。実際、業務委託エンジニアをめぐるトラブルの多くは、特別に悪意があって起きるわけではなく、契約や運用の「決めていなかったこと」から構造的に発生します。

逆に言えば、典型的なトラブルのパターンと、それぞれの予防策をあらかじめ押さえておけば、その大半は未然に防げます。大切なのは「何が起きうるか」を具体例で知り、「なぜ起きるか」「起きたらどう収めるか」「事前に何をすれば防げるか」をセットで理解しておくことです。

本記事では、業務委託エンジニアで起こりやすいトラブルを発注企業側の視点で10件取り上げ、それぞれの発生経緯・原因・解決策・予防策を整理します。さらに、2024年11月に施行されたフリーランス新法で発注者に課された義務、そして発注前に確認すべきチェックリストまで解説します。読み終えるころには、安心して外部エンジニア活用に踏み切れる体制づくりの全体像がつかめるはずです。

業務委託エンジニアでトラブルが起きやすい3つの構造的理由

個別のトラブル事例に入る前に、なぜ外部エンジニアの活用は揉めやすいのか、その構造を押さえておきましょう。トラブルを「運が悪かった」で片づけず、対処可能な課題として捉えるための土台になります。

請負契約と準委任契約の違いがトラブルの起点になる

業務委託契約は、大きく「請負契約」と「準委任契約」に分かれます。両者は責任範囲と報酬の考え方が異なり、ここの認識がズレるとトラブルの起点になります。

請負契約は、成果物の「完成」を約束する契約です。発注したシステムやプログラムが完成して初めて報酬が発生し、受注者は仕事の結果に責任（契約不適合責任）を負います。一方、準委任契約は、一定の業務を「遂行すること」を約束する契約で、必ずしも特定の成果物の完成を保証しません。エンジニアの稼働時間や作業の遂行そのものに対して報酬が発生します。

発注側が「成果物が完成して当然」と考えていたのに、契約が準委任だった、というすれ違いは典型的なパターンです。どちらの契約形態が案件に適しているかを最初に見極めることが、後段のトラブルを大きく減らします。

「指示してはいけない」線引きが曖昧だと偽装請負リスクが生まれる

業務委託では、発注者が受注者に対して、業務の進め方や勤務時間を直接細かく指示することはできません。これは雇用ではなく、独立した事業者同士の取引だからです。

ところが、社内のエンジニアと同じ感覚で「今日は何時まで」「この作業を先にやって」と日常的に指示を出してしまうと、実態が労働者派遣に近づき、いわゆる「偽装請負」と判断されるリスクが生まれます。この線引きが曖昧なまま運用が始まると、知らず知らずのうちに違法状態に陥っていることがあります。

社内開発と違い進捗・品質が見えにくい

外部エンジニアは物理的にもプロセス的にも社内から見えにくく、進捗や品質の状況がブラックボックス化しやすい点も、トラブルが起きやすい構造的な理由です。

社内開発であれば日々の様子から「なんとなく遅れている」「品質が怪しい」と気づけますが、外部委託では報告を受けるまで実態が分かりません。納期直前になって初めて大幅な遅れが発覚する、納品されたものが想定と違う、といった事態は、この「見えにくさ」から生まれます。可視化の仕組みを意図的に設計しないと、問題の発見が後手に回ります。

これら3つの構造を念頭に置きながら、次から具体的なトラブル事例を見ていきましょう。

業務委託エンジニアのトラブル事例10選と発注企業側の解決・予防策

ここからは、発注企業が実際に遭遇しやすいトラブルを10件取り上げます。それぞれ「発生経緯」「原因」「発生時の解決策」「事前の予防策」の4点で整理し、発注側として何をすべきか・何をしてはいけないかを明確にします。

1. 偽装請負トラブル

発生経緯：請負契約で常駐エンジニアに開発を任せていたところ、自社の開発リーダーが日々の朝会で作業順序を細かく指示し、勤務時間や休憩も社員と同様に管理していました。後にこの運用が問題となり、行政から是正指導を受けて派遣契約への切り替えを迫られた、というケースです。

原因：請負・準委任契約では、発注者は受注者に対して直接の指揮命令ができません。それにもかかわらず、社内エンジニアと同じ感覚でマネジメントしてしまうと、実態が労働者派遣とみなされます。労働者派遣は許可を受けた事業者しか行えないため、無許可での実質的な派遣は労働者派遣法違反となります。

解決策：偽装請負を指摘された、あるいはその疑いに気づいた場合は、まず指揮命令の実態を即座に見直します。日々の作業指示は受注者側の責任者（リーダー）を通す形に改め、勤務管理は受注者側に委ねます。必要に応じて契約形態そのものを準委任や労働者派遣に切り替え、弁護士など専門家に運用実態の適法性を確認することが望ましいでしょう。

予防策：契約締結時に「業務指示は誰を窓口に、どのように行うか」を明文化し、現場には「個々のエンジニアに直接細かい指示を出さない」ルールを徹底します。勤務時間・服務に関する管理は受注者側に委ねる運用を最初から設計しておくことが、最も確実な予防になります。偽装請負は発注側の認識不足で起きやすいトラブルの筆頭であり、ここを押さえるだけでリスクは大きく下がります。指揮命令の境界線については、偽装請負チェックリスト：業務委託で違法にならない指揮命令の境界線【IT現場版】で詳しく解説しています。

2. 報酬・支払い条件のトラブル

発生経緯：「だいたいこのくらいの金額で」と口頭で合意して開発を進めたところ、月末の請求段階で金額の認識が食い違い、さらに「支払いは翌々月末で」と発注側の慣行で処理したため、受注者から「支払いが遅すぎる」とクレームを受けた、というケースです。

原因：報酬の金額・算定方法・支払時期を契約書で明確に定めていないことが根本原因です。加えて、後述するフリーランス新法では、報酬の支払期日は「物品等を受領した日から起算して60日以内のできる限り短い期間内」で定めなければならないと義務づけられています（公正取引委員会 フリーランス法特設サイト）。自社の支払サイトが60日を超える慣行のままだと、この時点で法令違反となるおそれがあります。

解決策：認識違いが起きた場合は、まず契約書や見積書・発注書など合意の根拠となる書面を確認し、双方の認識を擦り合わせます。書面がなければ、メールやチャットのやり取りなど合意の経緯が分かる記録を整理します。支払期日が60日を超える運用になっている場合は、速やかに是正します。

予防策：発注時に報酬の金額・算定根拠・締め日・支払期日を書面で明示し、支払期日は受領から60日以内に設定します。請負か準委任かによって「何に対して」報酬が発生するか（成果物の完成か、稼働か）も明記しておくと、後の食い違いを防げます。報酬まわりは法令義務と直結する領域なので、自社の支払サイトを一度棚卸ししておくことをおすすめします。

3. 成果物の品質・バグのトラブル

発生経緯：納品されたシステムを動かしてみると、想定していた機能が一部動かず、バグも複数見つかりました。発注側は「これでは未完成だ」と主張し、受注側は「契約で合意した範囲は満たしている」と反論。「完成か未完成か」をめぐる論争に発展した、というケースです。

原因：「どの状態になれば完成・検収合格とするか」という受け入れ基準（受け入れテストの内容・合格条件）を事前に合意していないことが原因です。基準が曖昧だと、発注側と受注側で「完成」の定義がずれ、水掛け論になります。

解決策：すでに論争になっている場合は、契約書の業務範囲・仕様書に立ち返り、「どこまでが合意された範囲か」を客観的に確認します。請負契約であれば契約不適合責任に基づき修補を求められる余地があるため、不具合が仕様と異なる点を具体的に整理して伝えます。準委任の場合は成果完成の保証がない点に留意し、追加作業として依頼するか交渉します。

予防策：契約段階で、機能要件・仕様書・受け入れテストの項目と合格条件を文書化し、双方で合意します。「検収期間」と「検収方法」も定めておくと、納品後の判断がスムーズです。受け入れ基準の明文化は、品質トラブルを防ぐ最も効果的な手段です。

4. 要件変更・スコープクリープのトラブル

発生経緯：開発が進むにつれ「ついでにこの機能も」「ここはこう変えてほしい」と追加・変更の依頼を重ねた結果、当初の想定を大きく超える作業量になりました。発注側は「契約の範囲内」と考え、受注側は「これは追加費用が必要」と主張し、費用負担をめぐって対立した、というケースです。これはスコープクリープ（業務範囲がなし崩しに膨らむ現象）と呼ばれる典型的な問題です。

原因：当初の業務範囲（スコープ）が契約書で明確に定義されておらず、変更が発生したときの取り扱いルールも決まっていないことが原因です。開発では仕様変更がつきものですが、その都度の費用・納期への影響を取り決めていないと、追加対応が無償で押し付けられたり、逆に想定外の追加請求が発生したりします。

解決策：対立が起きた場合は、まず当初契約の業務範囲を確認し、どこからが追加範囲かを線引きします。そのうえで、追加分について作業量・費用・納期を再見積もりし、変更内容を書面（変更合意書・追加発注書）として残します。感覚的な「ついで」のやり取りを、明示的な発注に切り替えることが収束への近道です。

予防策：契約書に業務範囲を具体的に明記し、あわせて「変更管理のルール」を定めておきます。仕様変更が発生したら必ず書面で変更内容・費用・納期影響を合意してから着手する、という運用を最初から組み込むことで、スコープクリープを防げます。発注側の「これくらいなら」という気軽な依頼が積み重なってトラブルになるため、変更を可視化する仕組みが重要です。

5. 納期遅延・進捗ブラックボックス化のトラブル

発生経緯：順調に進んでいると思っていたら、納期の直前になって「間に合いません」と連絡が入りました。それまで具体的な進捗報告がほとんどなく、遅れの兆候を発注側が把握できていなかった、というケースです。

原因：先に触れたとおり、外部委託では進捗が見えにくく、報告の頻度・形式を取り決めていないと状況がブラックボックス化します。問題が発生していても発注側に共有されず、リカバリーが効かない段階になって発覚します。

解決策：遅延が判明したら、まず残作業と遅れの原因を受注者から具体的に聞き取り、現実的なリスケジュールを合意します。クリティカルな機能を優先する、一部スコープを次フェーズに回すなど、被害を最小化する調整を行います。請負契約で納期遅延による損害が発生した場合は、契約書の遅延条項に基づき対応を協議します。

予防策：契約時に進捗報告の頻度・形式・タイミング（週次の進捗会、課題管理表の共有など）を定め、マイルストーンごとに中間成果物を確認する設計にします。タスク管理ツールやリポジトリを共有し、進捗を可視化することも有効です。遅延は早期発見できれば対処の選択肢が広がるため、見える化の仕組みづくりが鍵になります。

6. 途中解約・契約終了のトラブル

発生経緯：プロジェクトの途中で方針が変わり、契約を打ち切ることになりました。ところが、すでに支払った報酬の扱いや、未完成の成果物の引き渡しをめぐって、発注側と受注側の主張が対立した、というケースです。

原因：契約形態によって途中解約のルールが異なるにもかかわらず、契約書に解約条件を定めていないことが原因です。準委任契約では、原則として各当事者がいつでも解除できますが、相手に不利な時期の解除では損害賠償が問題になることがあります。請負契約では、注文者は受注者に生じた損害を賠償すれば契約を解除できますが、完成途中の出来高分の扱いが論点になります。

解決策：解約に至った場合は、契約書の解約条項を確認したうえで、既払報酬・出来高・未完成成果物の引き渡しについて協議します。途中までの成果物に価値がある場合は、その引き渡しと対価を整理し、書面で合意します。条項がなければ、民法の原則と作業の実態に基づいて精算方法を取り決めます。

予防策：契約締結時に、解約の条件（予告期間・解約事由）、解約時の報酬精算方法、作成済み成果物の引き渡しについて明記しておきます。フリーランス新法では、6か月以上の継続的な業務委託を中途解除する場合、原則30日前までの予告が義務づけられている点にも留意が必要です（公正取引委員会 フリーランス法特設サイト）。

7. 成果物の権利帰属（著作権・ソースコード）のトラブル

発生経緯：開発が完了し運用に移った後、別のベンダーに改修を依頼しようとしたところ、ソースコードの著作権が受注者側に残っていることが判明。「改修や転用には別途許諾が必要」と言われ、想定外の制約に直面した、というケースです。

原因：プログラムの著作権は、契約で特段の取り決めがなければ、原則として制作した受注者側に帰属します。発注側が「お金を払ったのだから当然自社のもの」と考えていても、権利帰属の取り決めを契約書に入れていないと、自由に改修・転用できないことがあります。

解決策：すでに権利が受注者に残っている場合は、著作権の譲渡または利用許諾（改修・複製・第三者への委託を含む範囲）について、追加で交渉し書面化します。ソースコードや設計書などの納品物一式の引き渡しも併せて確認します。

予防策：契約段階で、成果物（ソースコード・ドキュメント・デザイン等）の著作権の帰属、または利用範囲を明記します。「著作権を発注者に譲渡する」「著作者人格権を行使しない」といった条項を入れておくと、後の改修・転用が円滑になります。OSSなど第三者の権利が含まれる場合の取り扱いも確認しておきましょう。権利帰属・知財管理の実務については、フリーランス業務委託で著作権・知財を守る契約と運用の実践ガイドも参考にしてください。

8. 秘密情報・個人情報の漏洩トラブル

発生経緯：委託先のエンジニアが、開発過程で知り得た自社の機密情報や顧客データを、十分な管理なく扱っていたことが判明しました。さらに、その作業の一部が無断で別の事業者に再委託されていた、というケースです。

原因：秘密保持契約（NDA）を結んでいない、または再委託の可否・条件を取り決めていないことが原因です。委託先の情報管理体制が見えないまま機密情報を渡すと、漏洩リスクをコントロールできません。

解決策：漏洩や不適切な取り扱いが判明した場合は、ただちに該当情報へのアクセスを制限し、被害範囲を特定します。個人情報が関わる場合は、法令に基づく対応（必要に応じて関係機関への報告）を検討します。再委託が無断で行われていた場合は契約違反として是正を求めます。

予防策：委託開始前にNDAを締結し、再委託の可否・条件、情報の管理・廃棄ルールを契約に盛り込みます。アクセス権限を必要最小限にする運用も有効です。

9. キーパーソン依存・属人化のトラブル

発生経緯：開発を一手に担っていたエンジニアが契約終了で離脱した途端、システムの保守ができなくなりました。仕様書やコメントが残っておらず、誰も中身を把握できない、というケースです。

原因：特定のエンジニアに業務が集中し、ドキュメントが整備されないまま属人化したことが原因です。外部委託では担当者の離脱が起きやすく、引き継ぎの準備がないと保守不能に陥ります。

解決策：すでに離脱してしまった場合は、可能であれば一時的な引き継ぎ支援を依頼し、現存するコードや資料から仕様を復元します。再発防止のため、後任体制とドキュメント整備を最優先で進めます。

予防策：契約時に、設計書・運用手順書などのドキュメント納品を要件に含め、コードのコメントやリポジトリ管理のルールを定めます。重要な業務は複数人で共有する体制を求めることも、属人化リスクを下げます。

10. コミュニケーション齟齬・契約書記載不足のトラブル

発生経緯：「いい感じにお願いします」といった曖昧な口頭発注で進めた結果、出来上がったものが想定と大きく異なりました。契約書も簡素で、何をどこまで合意したのかが後から確認できない、というケースです。

原因：そもそも契約書の記載が不十分で、合意内容が口頭やニュアンスに依存していることが原因です。認識の前提が共有されないまま進むと、成果物の方向性がずれていきます。

解決策：齟齬が起きた場合は、現時点での合意事項を改めて書面で整理し、認識を揃え直します。残りの作業について、期待する成果のイメージを具体的に言語化して共有します。

予防策：契約書に業務内容・成果物・スケジュール・報酬・連絡体制を具体的に記載し、口頭発注は避けます。定例の連絡手段と窓口を決め、重要な合意は必ず文章で残す習慣をつけることが、最も基本的で効果の高い予防策です。

フリーランス新法で発注企業に課された義務とトラブル予防

ここまでのトラブルの多くは、2024年11月1日に施行された「フリーランス・事業者間取引適正化等法」（通称フリーランス新法）と深く関係しています。この法律は、従業員を雇わずに業務を受託するフリーランスを保護するもので、発注する企業側に新たな義務を課しています（公正取引委員会 フリーランス法特設サイト）。

知らずに従来どおりの運用を続けていると、行政指導や罰則の対象になりかねません。発注者の義務を正しく理解しておくことが、トラブル予防に直結します。

発注時に書面で明示すべき項目

発注事業者は、フリーランスに業務を委託する際、取引条件を書面または電磁的方法（メールやチャットのメッセージ等）で直ちに明示する義務があります。明示すべき主な項目は、業務の内容、報酬の額、支払期日、発注事業者・フリーランスの名称、業務委託をした日などです（公正取引委員会 フリーランス法特設サイト）。

口頭発注によるトラブル（先ほどの事例で挙げた認識齟齬や報酬の食い違い）は、この書面明示義務を守ることでそのまま予防できます。

報酬支払期日のルール（受領から60日以内）

発注事業者は、フリーランスから物品や成果物を受領した日から起算して60日以内の、できる限り短い期間内で報酬の支払期日を定め、その期日までに報酬を支払わなければなりません（公正取引委員会 フリーランス法特設サイト）。

自社の支払サイトが「翌々月末」など60日を超える慣行になっている場合は、この義務に抵触するおそれがあります。報酬トラブルを防ぐためにも、支払サイトの見直しは早めに行っておきましょう。

発注者に禁止される7つの行為と罰則

1か月以上にわたる業務委託について、従業員を使用する発注事業者には、次の7つの行為が禁止されています（公正取引委員会 フリーランス法特設サイト、中小企業庁 フリーランス取引適正化リーフレット）。

1. 受領拒否：フリーランスに責任がないのに、発注した成果物の受領を拒むこと
2. 報酬の減額：フリーランスに責任がないのに、あらかじめ定めた報酬を発注後に減額すること
3. 返品：フリーランスに責任がないのに返品すること
4. 買いたたき：通常相場に比べて著しく低い報酬を不当に定めること
5. 購入・利用強制：正当な理由なく、指定する物品の購入や役務の利用を強制すること
6. 不当な経済上の利益の提供要請：自己のために金銭・役務などの利益を提供させること
7. 不当な給付内容の変更・やり直し：フリーランスに責任がないのに、内容を変更させたり、やり直させたりすること

これらは、要件変更・スコープクリープや成果物の品質をめぐるトラブルとも密接に関わります。発注側が「ついでにやり直して」「やはり受け取れない」と気軽に求めた行為が、禁止行為に該当する可能性があるのです。

監督は公正取引委員会・中小企業庁・厚生労働省が担い、違反が確認されると指導・助言・勧告が行われます。勧告に従わない場合は命令が出され、命令違反や検査拒否などには50万円以下の罰金が科されることがあります（公正取引委員会 フリーランス法特設サイト）。

法令を守ること自体が、結果的に最良のトラブル予防になります。

外部エンジニア活用を安心して進めるための発注前チェックリスト

ここまでの内容を、発注実務に落とし込んだチェックリストとしてまとめます。発注前にひとつずつ確認することで、紹介したトラブルの多くを未然に防げます。各項目には「これを満たすとどのトラブルを防げるか」を添えました。

• 契約形態（請負／準委任）を案件に合わせて選んでいるか → 成果物の完成を求めるなら請負、稼働や業務遂行を求めるなら準委任。契約形態の認識ズレによるトラブル（品質論争・途中解約の精算）を防げます。

• 業務範囲・成果物・受け入れ基準を契約書に明記しているか → 「どこまでやるか」「何をもって完成とするか」を文書化することで、品質トラブルとスコープクリープを防げます。

• 指揮命令を直接出さない運用ルールを決めているか → 業務指示の窓口を受注者側の責任者に一本化し、勤務管理を委ねることで、偽装請負リスクを防げます。

• 報酬の金額・支払期日をフリーランス新法に沿って設定しているか → 報酬条件を書面で明示し、支払期日を受領から60日以内にすることで、報酬トラブルと法令違反を防げます。

• 取引条件を書面（または電磁的方法）で明示しているか → 業務内容・報酬・支払期日などを発注時に書面で示すことで、口頭発注によるコミュニケーション齟齬を防げます。

• 成果物の権利帰属（著作権・ソースコード）を取り決めているか → 著作権の譲渡または利用範囲を明記することで、改修・転用時の権利トラブルを防げます。

• 秘密保持契約（NDA）と再委託のルールを定めているか → 情報管理・再委託の条件を契約に盛り込むことで、情報漏洩トラブルを防げます。

• 進捗報告の頻度・形式と連絡窓口を設計しているか → 週次報告・課題管理・マイルストーン確認を仕組み化することで、納期遅延と進捗ブラックボックス化を防げます。

• ドキュメント納品と属人化を避ける体制を要件に入れているか → 設計書・運用手順書の納品を求めることで、キーパーソン離脱による保守不能トラブルを防げます。

• 変更管理のルール（仕様変更時の費用・納期合意）を決めているか → 変更は必ず書面合意してから着手する運用にすることで、スコープクリープを防げます。

このチェックリストを発注前のテンプレートとして使えば、抜け漏れなく備えられます。契約書のテンプレートや必須記載事項については、業務委託契約書テンプレート（発注側）｜必須13項目とフリーランス新法対応を解説をあわせてご活用ください。

まとめ

業務委託エンジニアのトラブルは、契約形態の認識ズレ・指揮命令の曖昧さ・進捗の見えにくさという3つの構造から生まれます。本記事で取り上げた10の事例は、いずれも「決めていなかったこと」「明文化していなかったこと」が引き金になっていました。

裏を返せば、契約書に業務範囲・受け入れ基準・権利帰属・報酬条件を明記し、指揮命令を出さない運用ルールと進捗の可視化を設計し、フリーランス新法の義務（書面明示・60日以内の支払・禁止行為の回避）を守れば、トラブルの大半は予防できます。発注前チェックリストを手元に置いて、ひとつずつ確認していけば、過度に身構える必要はありません。

外部エンジニアの活用は、正しく備えれば社内リソース不足を補い、開発を加速させる有効な選択肢です。トラブルを恐れて踏み出せないのではなく、構造を理解し対策を講じたうえで、自信を持って前に進んでいただければと思います。

外部エンジニア活用や業務委託契約の実務に関するお役立ち資料を無料でダウンロードいただけます。発注前の準備や契約設計の参考に、あわせてご活用ください。