何かがおかしい。進捗報告が曖昧になってきた。期日が近づいているのに成果物が見えない。依頼した機能が「後で」に先送りされ続けている。契約を打ち切るにはここまでの投資が惜しいし、放置するには不安すぎる。
こうした状況で多くの経営者が「もう少し待とう」を繰り返し、手が打てない段階まで進んでしまいます。早期に動くか、遅れて動くかでは、後から振り返ったとき全く違う結果になります。このガイドは、外注プロジェクトに異変を感じたとき、状況ごとに何をすべきかをまとめた実務マニュアルです。
問題の兆候を見逃さない
プロジェクトの失敗はほとんどの場合、突然起きません。後から振り返ると、兆候はあった——ただそれが見過ごされていたというケースが大半です。
スケジュールに関する兆候
- 「ほぼ完成です」「今週中に」という返答が2週間以上続いている
- マイルストーンの日付が理由の説明なく後ろに動いた
- 中間成果物の共有を求めると「整理できたらお送りします」が繰り返される
コミュニケーションに関する兆候
- 返信のペースが徐々に遅くなっている（翌日→数日→1週間）
- 質問に対して具体的な回答ではなく「確認します」だけが返ってくる
- 進捗報告が「順調に進んでいます」の一文で終わる
成果物に関する兆候
- 開発環境にアクセスしてみると、報告されている進捗と実態が一致しない
- デモや動作確認できるテスト環境の共有が先送りされ続けている
- 問題を指摘すると「クライアント側の要件変更が原因」という話になる
兆候が一つだけなら即危機ではありません。ただし二つ以上が重なったら、来週ではなく今週中に、直接話し合いの場を設けることが必要です。
納期が遅れているとき
ソフトウェア開発における納期の遅れ自体は珍しいことではありません。問題は「なぜ遅れているのか」と「その対応が誠実かどうか」です。
まず原因を切り分ける
技術的な難易度の見積もりミス、担当者の変更、要件の解釈ズレといった明確な原因がある場合は、協議で解決できることが多い。一方、そもそも作業が進んでいなかった、複数案件を並行していて優先度が後回しになっていた、という場合は別のアプローチが必要です。
対処の手順
-
具体的な状況確認を求める: 「今週完了したこと・進行中のこと・止まっていることを教えてください」という聞き方をします。「どうですか」ではなく、数字や具体的な内容で答えられる質問にします。
-
修正スケジュールを書面で確定する: 「来週金曜までに」を口頭で終わらせず、メールやチャットで文字として残してもらいます。「ログイン・会員登録・トップ画面を◯月◯日までに完了」のような粒度が理想です。
-
中間チェックポイントを入れる: 期日を再設定したら、そこまでの中間地点でも一度確認する機会を入れます。「水曜に中間の進捗を共有してください」という短サイクルで可視性を高めます。
-
契約書を確認する: 遅延に対するペナルティ条項があれば、この時点で確認を促すことが適切なタイミングです。脅しではなく、「契約書の内容に沿って今の状況をどう対処すべきか一緒に確認しましょう」というトーンで切り出します。
遅れが繰り返され、説明に納得感がない場合は、後述のコミュニケーション断絶・ベンダーリスクの項目も合わせて確認してください。
「これも追加してほしい」が続くとき
開発が進む中で新しい機能のアイデアが出てくることは自然です。実際に画面を見ると、思っていたよりも必要なものが見えてきます。問題は、その追加要求がスケジュールと予算に与える影響を把握しないまま積み重なることです。
ベンダー側もこの状況は難しい。断れば関係が壊れる。受ければ工数が足りなくなる。結果として小さな追加要求が無言のまま積み上がり、納期直前に爆発します。
今すぐやること
- 完了済みまたは進行中の機能のリストを書面で確認する
- 非公式に追加依頼した機能を一覧化し、それぞれがスケジュール・費用にどう影響するかをベンダーに問い合わせる
- 追加機能を「今回のバージョンに含めるもの」と「次のバージョンに回すもの」に仕分ける
こうした積み重ねが最終的にどれだけプロジェクトを圧迫するかは、外注プロジェクトで「これだけ追加して」が繰り返されるコストで詳しく解説しています。
連絡が取れなくなったとき
進捗の共有がなく、質問しても返答が遅く、打ち合わせの日程調整が進まない——これが連絡途絶の状態です。放置すると、最終的に受け取った成果物が「依頼した内容と違う」という事態に発展しやすくなります。
コミュニケーション体制を立て直す方法
まず連絡チャネルを一本化します。メール・LINE・Slack・電話が混在していると、確認漏れが生まれます。どこで連絡を取るかを合意した上で、週次の定例確認を固定化します。15分で十分です。「今週完了したこと・来週の予定・懸念点」という構成で情報を共有する習慣を作ります。
進捗が言葉からは見えにくい場合は、開発環境への直接アクセスを依頼するか、作業中の画面のキャプチャや短い操作動画を送ってもらいます。進捗報告を10回受けるより、実際に動くものを1回確認する方が正確です。
透明性のある外注管理をどう実現するかは、外注の透明な進行管理とクライアントポータルで詳しく解説しています。
当初から「おまかせします」という形で委任していたプロジェクトは、こうした断絶が構造的に起きやすい。
ベンダー自体が不安定なとき
プロジェクトの問題ではなく、外注先の会社自体が不安定になっているケースがあります。担当者の急な交代、連絡の途絶、チーム構成の変化——こうした状況は、ベンダー側の内部問題を示していることがあります。
危険な兆候
- 担当者が変わった、またはキーパーソンが退職したことをあとから知った
- 当初提示されていたチーム構成から実際のメンバーが変わっている（シニア→ジュニア、専門家→別の担当者）
- ベンダーのSNSやウェブサイト上の活動が突然止まった
- 電話が繋がらず、メールの返信に数日かかるようになった
今すぐ確保すべきもの
ベンダーの状況に不安を感じたら、以下を優先して確認・取得してください。
-
ソースコードへのアクセス権: 開発中のコードが保存されているリポジトリ（GitHub、GitLabなど）に、クライアント自身がアクセスできている必要があります。ベンダー側だけが管理している状態は、何かあったときに自社のコードにアクセスできなくなるリスクをはらんでいます。
-
サーバー・ドメインの管理情報: サービスが稼働するサーバー、ドメイン、関連アカウント情報はクライアント側が保有または直接アクセスできる状態にしておく必要があります。ベンダーのアカウントで一元管理されている場合、ベンダーが機能しなくなった瞬間に自社サービスへのアクセスを失います。
-
中間成果物の受領: 画面設計書、API仕様書、データ設計書（ER図など）、テスト環境——こうした開発過程で生まれた資料は、定期的にクライアントへ共有・受け渡しをしておく必要があります。別のチームが引き継ぐことになっても対応できる状態を維持してください。
これらの権利を契約時に確認しておくことが理想ですが、プロジェクト途中でも要求することは適切です。契約内容の確認については、外注見積書の正しい確認方法を参照してください。
紛争に発展させないために
外注トラブルの多くは、「依頼した内容」と「実際に受け取ったもの」とのズレに起因します。このズレを放置したまま時間が経つと、双方が損失を被ります。感情的な対立になる前に、事実関係を客観的に整理することが最も早い解決策です。
まず、契約範囲と成果物を並べて比較してください
契約書に記載された作業範囲と、実際の成果物を一つの表に整理します。途中で合意した変更事項があれば、それも併せて記録してください。多くの場合、この表を作成する過程でどこからズレが生じたのかが明確になり、その一点を協議し直すだけで解決します。
大半は交渉のテーブルで解決できます
完了済みの作業と未完了の作業を区別したうえで、残りの作業について日程調整・範囲の縮小・補完作業のうちどれが現実的な代案かを先に提示してください。対応可能な線を先に示した側が交渉の主導権を握ります。すべての協議はメールで記録し、口頭で合意した内容も簡潔に文書化しておくことで、同じ議論の繰り返しを防げます。
判断がつかない場合は、第三者の視点が必要です
現在の成果物が契約上の要件を満たしているかどうかは、発注者が単独で判断するのは困難です。この場合、利害関係のない開発の専門家にコードと成果物のレビューを依頼するのが最も確実です。客観的な診断が出れば、双方とも次の段階を明確に決められます。
紛争を防ぐ最良のタイミングは契約前です。 外注の全体像を正しく理解してから始めることが、リスク軽減の基本です。スタートアップのMVP外注完全ガイドで、外注開始前に押さえておくべきことをまとめています。
今進行中の外注に不安を感じているなら — 30分の無料相談で状況を一緒に確認しましょう。どの段階でどんな問題が起きているのか、今何をすべきかをお伝えします。