外注トラブルの対処方法：プロジェクトを立て直すやり方

外注トラブルは「よくある」—まず落ち着いて全体像を掴む

システム開発やWeb制作を外注したものの、「納期が延びる」「出来上がったものが想定と違う」「追加費用を求められる」「担当者が急に変わる」などの外注トラブルは、残念ながら珍しくありません。特に、社内に開発の専門家がいない中小企業や、情シスが兼務で回している大企業では、進め方の前提が揃わないまま走り出しやすく、トラブルが表面化したときにはすでに手遅れに見えることがあります。

ただし、外注トラブルの多くは「誰かが悪い」以前に、契約・要件・体制・コミュニケーションのどこかに穴がある状態です。感情的に責めるほど、ベンダー側も防御姿勢になり、情報が出てこなくなります。まずは「現状の事実」と「意思決定に必要な材料」を揃えることが、プロジェクトを立て直す最短ルートです。

ここでいう外注は、SIer、開発会社、制作会社、フリーランス、SES混在などを含みます。トラブルの種類も、品質（バグが多い・使いにくい）、スケジュール（遅延）、コスト（見積もりと違う）、運用（保守しない・引き継げない）、権利（ソースコードが渡らない）など幅広いです。本記事では、非エンジニアでも実務で使える「対処の手順」と「立て直しのやり方」を、具体的な成果物・会話例・判断基準まで落とし込みます。

外注トラブルが起きたときに最初にやりがちな失敗は、「急いで新しい会社に乗り換える」「とにかく納期を守らせようと詰める」「社内で根性対応する」の3つです。これらは一時的に前進したように見えても、仕様の不整合や技術的負債を増やし、結果的にコストと時間をさらに失います。まずは現状把握→原因の切り分け→再計画→合意形成→再実行、の順に進めましょう。

外注トラブルの典型パターンと原因：問題を切り分けるチェックリスト

外注トラブルの対処は、原因が「能力不足」なのか「前提の不一致」なのか「管理の欠落」なのかで打ち手が変わります。そこで、まずは症状をパターン化して切り分けます。原因が違うのに同じ薬を飲むと、立て直しは難しくなります。

よくある症状

• 納期遅延：スケジュールが毎週のように後ろ倒し／進捗報告が曖昧
• 品質不良：バグが減らない／テストしていない／操作が直感的でない
• 要件ズレ：頼んだはずの機能がない／使い方が現場に合わない
• 費用増：「追加開発です」と次々請求／見積もり根拠が不透明
• コミュニケーション不全：返事が遅い／言った言わない／議事録がない
• 引き継ぎ不可：ソースコードや設計書がない／属人化／パスワード不明

原因の切り分け（現場で使える観点）

• 要件の曖昧さ：目的・優先順位・業務フローが整理されていない
• 契約の弱さ：成果物定義・検収条件・変更手続きが書かれていない
• 体制のミスマッチ：PM不在、窓口が頻繁に変わる、レビューできる人がいない
• 見積もりの前提違い：「どこまで含むか」が一致していない（例：デザイン、テスト、移行、運用）
• 技術的負債：短期対応を積み重ねて、修正が雪だるま式に重くなっている

非エンジニアの方が判断するときは、「相手の言い分が専門的で分からない」こと自体がリスクになります。そこで、次の3点だけは必ず言語化して共有してください。①誰のどんな業務を、②何のために改善し、③成功をどう測るか。これがないと、外注先は“作れるもの”を作り、発注側は“欲しかったもの”を想像で求める構図になり、外注トラブルが繰り返されます。

初動でやるべき対処：証拠の確保、現状棚卸し、リスク止血

外注トラブルが発覚した直後は、まず「炎上を広げない」ことが最優先です。ここでの目的は犯人探しではなく、立て直しの材料（情報と権利）を確保することです。現場が混乱しているほど、ドキュメントやアカウント情報が散逸しやすいので、淡々と集めます。

必ず確保するもの（チェックリスト）

• 契約書・発注書・見積書・検収書・請求書（最新版だけでなく改訂履歴も）
• 要件定義書、仕様書、画面設計、API仕様、DB定義、インフラ構成図（あるもの全部）
• 議事録、チャットログ、メール（「合意」と「未合意」を分ける）
• ソースコードの所在（Git等のリポジトリURL）、ブランチ運用、権限
• 本番・検証環境のURL、クラウドアカウント、ドメイン、SSL、各種管理画面のログイン
• デザインデータ（Figma等）、画像素材、フォント、ライセンス
• 運用手順（障害対応、バックアップ、監視、リリース手順）

「ソースコードは納品後に渡します」「クラウドはベンダーのアカウントで管理しています」と言われている場合は要注意です。立て直しや乗り換えの選択肢を持つために、発注側がアクセスできる状態を作ります。感情的に要求するのではなく、「事業継続のためのリスク管理として必要」と位置づけると通しやすいです。

止血（これ以上悪化させない）

次のいずれかに該当する場合は、いったん作業の流れを止め、現状確認会を設定します。止めるのは勇気が要りますが、曖昧なまま進むと損失が増えます。止める＝解約ではなく、再合意のための一時停止です。

• 「何がいつまでに終わるか」が週次で更新されない
• 追加費用が発生する条件が説明できない
• 品質問題が出ても再発防止策がない
• 成果物の受け入れ基準（検収条件）が決まっていない

現状確認会では、ベンダーに「進捗」「未完了の理由」「残作業」「リスク」「必要な意思決定」を出してもらいます。口頭説明ではなく、A4一枚でもよいので文書で提出してもらいましょう。文章にすると、認識のズレが可視化され、外注トラブルの原因が一気に明らかになります。

プロジェクトを立て直す実務手順：再計画・再合意・再始動

立て直しの核心は、「期待値を揃え直す」ことです。外注トラブルが起きている状態では、発注側は“全部直してほしい”、受注側は“契約範囲だけ対応したい”となりがちです。ここを放置すると、修羅場のまま終盤に突入します。やるべきは、スコープ（やる範囲）を再定義し、現実的な計画に引き直すことです。

立て直しの流れ（発注側が主導する）

1. 目的の再確認：「何のために作るか」「現場のどの課題を潰すか」を1〜3行で言える状態にする
2. 現状成果物の評価：使えるもの／作り直すもの／捨てるものを仕分け（技術判断は第三者を入れると早い）
3. 要件の再整理：Must（必須）/Should（できれば）/Could（余裕があれば）に分ける
4. 受け入れ基準の設定：「何ができたらOKか」をテスト観点で言語化（例：CSVが3分以内に取り込める）
5. 計画の引き直し：短いサイクルで出す（2〜4週間ごとに動くものを確認）
6. 変更手続きの整備：追加要望は「変更依頼→見積→合意→着手」の順で、例外を作らない

特に重要なのが「受け入れ基準」です。非エンジニアでも、業務目線なら基準を作れます。たとえば「検索が速い」ではなく「顧客名で検索して3秒以内に一覧が出る」、「帳票が出る」ではなく「A4縦で会社ロゴ入り、月次の合計が一致する」のように、測れる言葉に置き換えます。これがあると、外注先も迷いにくく、発注側も検収しやすくなり、外注トラブルの再発を防げます。

会議体とコミュニケーションの型

• 週次定例：進捗（完了/未完了/次週）・課題・リスク・意思決定事項だけに絞る
• 議事録：決定事項、宿題、期限、担当を必ず残す（テンプレ化すると楽）
• 窓口の一本化：発注側も受注側も「決める人」「まとめる人」を明確に
• デモ確認：資料ではなく実物（画面・動作）で確認し、早くズレに気づく

もし「専門的で判断できない」場合は、第三者のレビュー（スポットでも可）を入れるのが効果的です。ソースコードの品質、インフラ設計、セキュリティ、見積妥当性などは、経験がある人ほど短時間で異常に気づけます。費用はかかりますが、炎上を長引かせるより結果的に安いことが多いです。

契約・見積・検収で揉めないための実務：追加費用と責任範囲を明確にする

外注トラブルで多いのが「追加費用」の揉め事です。受注側は「仕様が増えたので追加」、発注側は「最初から想定していた」となり、平行線になります。ここを解決するには、契約形態の理解と、変更管理の運用が必要です。難しそうに見えますが、ポイントはシンプルで、成果物と検収条件を“文章で”固定することです。

契約形態の違い（最低限ここだけ）

• 請負契約：成果物の完成がゴール。検収に通れば支払い。要件が曖昧だと揉めやすい
• 準委任契約：作業時間・役務提供がゴール。成果物の完成保証は弱い。管理しないと延々続く

情シスや発注担当としては、どちらが良い悪いではなく、目的に合わせて選びます。要件が固いなら請負、要件が変わりやすいなら準委任＋短いサイクルの合意が向きます。外注トラブルが起きているときは、途中から契約形態を変えるのが難しいこともあるため、まずは「現契約で何が合意されているか」を読み解き、足りない部分を覚書や変更合意書で補います。

見積もりで必ず確認したい項目

• 前提条件：データ量、利用ユーザー数、対応ブラウザ、対応端末、稼働時間
• 範囲：要件定義、設計、開発、テスト、移行、運用保守、監視、ドキュメント作成
• 除外事項：「含まない」を明記（例：既存データクレンジング、マニュアル作成）
• 成果物一覧：ソースコード、設計書、手順書、アカウント情報の引き渡し条件

「一式」見積もりは、スピードは出ますが揉めやすいです。外注トラブルの火種がすでにあるなら、タスク粒度を上げ、見積根拠（人日、単価、作業内容）を出してもらいましょう。発注側が技術を知らなくても、「何にいくら」が見えるだけで、意思決定ができます。

検収（受け入れ）の設計

検収は「動いたからOK」ではなく、業務で使えるかどうかです。おすすめは、受け入れテスト（UAT）を発注側主導で設計すること。たとえば、請求業務なら「締め→集計→請求書発行→送付→入金消込」まで、実データに近いサンプルで通す。これにより、外注トラブルでありがちな「納品されたが使えない」を避けられます。

続けるか、変えるか、止めるか：外注先の見直し判断と引き継ぎの現実

立て直し局面で最も悩ましいのが、「この外注先と続けるべきか」です。結論としては、感情ではなく、リスクと回収可能性で判断します。外注トラブルが起きても、立て直しが成功するケースはあります。一方で、構造的に無理な場合は、早期に切り替えた方が損失が小さいです。

続ける判断ができる条件

• 進捗・課題・リスクが文書で出てくるようになった
• 品質問題に対し、原因分析と再発防止策が提示されている
• 変更管理（追加費用の条件）が運用できる
• 成果物（ソースコード・設計書・環境情報）の引き渡しに協力的

切り替え・中断を検討すべきサイン

• 説明責任が果たされない：質問に答えない、根拠がない、話が毎回変わる
• 隠蔽が疑われる：リポジトリを見せない、進捗を数値で示せない
• 属人化が深刻：特定の1人しか分からず、休むと止まる
• セキュリティが危険：パスワード共有、権限管理なし、個人PCだけで運用

切り替えの最大の壁は「引き継ぎ」です。現実には、ドキュメントが不十分だったり、クラウドアカウントが相手名義だったりします。だからこそ、初動の段階で情報と権利を確保しておく必要があります。切り替えを進めるなら、次の順で進めると事故が減ります。

1. 引き継ぎ対象の確定：コード、環境、データ、アカウント、手順、未解決課題
2. 現状診断：第三者に「引き継げる状態か」を見てもらう（1〜2週間で可能なことが多い）
3. 引き継ぎ計画：停止時間、データ移行、権限移譲の手順を決める
4. リリース凍結：移行期間は変更を止め、差分地獄を避ける

なお、法務判断が絡む（損害賠償、著作権、検収拒否など）場合は、社内法務や弁護士への相談も検討してください。ただし、訴訟・紛争対応は時間がかかり、プロジェクトの再開が遅れやすいです。事業優先で「まず動く状態に戻す」ことと、「責任の整理」を分けて進めると、現場が前に進みやすくなります。

まとめ

外注トラブルは、突然の事故というより「前提のズレが積み重なった結果」として起きることが多いです。だからこそ、対処方法も精神論ではなく、情報を揃え、合意を作り直し、再計画で立て直すのが王道です。ポイントを整理します。

• 初動：契約・成果物・アカウント・ログを確保し、事実ベースで現状を棚卸しする
• 切り分け：品質・納期・費用・コミュニケーションのどこが破綻しているかを見える化する
• 立て直し：目的、Must/Should/Could、受け入れ基準、短いサイクルの計画に引き直す
• 揉めない運用：変更管理（追加費用の条件）と検収（UAT）を仕組みにする
• 判断：続ける/変える/止めるを、リスクと回収可能性で決め、引き継ぎ計画を持つ

「何から手を付ければいいか分からない」「いまの外注先の説明が妥当か判断できない」「引き継げる状態か診断してほしい」といった状況では、第三者の目線を入れるだけで状況が一気に整理されることがあります。最短で立て直すには、現場の混乱を減らし、意思決定の材料を揃えることが近道です。