また納期が延びました。開発会社からは「もう少しお待ちください」という連絡が来ています。先週も同じことを言われました。その前の週も同じでした。
契約時には見えていなかったことが、進めるうちに少しずつ見えてきます。中間成果物は届かず、連絡は減り、すでに支払った金額は小さくありません。こうした状況で、多くの経営者やプロジェクト担当者は同じ問いに突き当たります。
「このまま続けるべきか、それとも今からでも別の会社に切り替えるべきか。」
この記事では、その判断を下すための基準を整理します。個別状況への対応戦術よりも前に立つ問い、つまり「このプロジェクトを立て直す価値があるかどうか」という判断フレームが中心です。状況別の対応手順については外注プロジェクトが揺らいだときの状況別対応マニュアルで詳しく扱っています。
立ち止まって判断すべきタイミング
問題を先送りにし続けると、判断できるタイミングを逃します。以下のうち2つ以上が当てはまる場合、今すぐ立ち止まって判断を下すことが重要です。
スケジュール面
- 「今週中に対応します」という返答が3週間以上繰り返されている
- マイルストーンの日程がすでに2回以上変更されている
- 実際の作業状況の共有を求めても「整理中です」という回答が続いている
コミュニケーション面
- 説明なく連絡の頻度が落ちてきている（数日→1週間→それ以上）
- 具体的な質問をしても「確認します」という返答しか来ない
- 進捗報告が「順調に進んでいます」の一文で終わる日が続いている
成果物面
- 開発環境に直接アクセスしてみると、報告内容と実際の進捗に大きなズレがある
- 中間デモやテスト環境の共有を求めるたびに先送りされている
- 問題が発生したとき、原因がいつも「初期の要件変更」に帰結する
これらのシグナルを長く放置すると、取れる選択肢が狭まります。どこから手をつければよいか整理したい場合は、状況別対応マニュアルが具体的なチェックポイントの参考になります。
続けるか撤退するか: 判断の軸
「契約を打ち切るべきか」という考えが浮かんでも、多くの方が踏み切れません。その理由はたいていサンクコストです。これだけ時間とお金を使った、という感覚が判断を曇らせます。
ただし、意思決定の基準は「これまでいくら使ったか」ではなく、「これからいくらかかるか、そして成果が出る可能性があるか」であるべきです。
以下の4つの軸で現状を整理すると、判断が明確になります。
1. コード資産の状態
これまで作られたコードが実際に使える状態にあるかどうかが最初の確認事項です。ソースコードに直接アクセスして確認することが重要です。アクセス自体ができない状況であれば、それ自体が構造的な問題のシグナルです。
コードはあっても品質の評価が難しい場合は、外部の開発者に短期間の技術レビューを依頼するのが現実的です。全く再利用できない状態であれば、ゼロから作り直す方が経済的です。60〜70%でも再利用できる構造であれば、立て直しの方が合理的な判断になります。
2. データとインフラの状況
すでに実ユーザーがいる場合、データ移行のコストとサービス停止リスクが判断に加わります。まだ内部テスト段階であれば、この軸は比較的軽く見られます。いずれにしても、判断前に整理しておく価値があります。
3. 外注会社との信頼関係
これまでのやり取りを振り返ったとき、技術的な難しさに直面している会社なのか、それとも姿勢や能力自体に問題があるのかを区別することが重要です。
技術的な課題であれば、対話と調整で解決できる余地があります。一方、不誠実な対応、意図的な遅延、能力不足が根本にあるのであれば、信頼の回復は難しいと判断した方が現実的です。一度崩れた信頼を保ちながらプロジェクトを完走させることは、双方にとって消耗が大きくなります。
4. 残りのコストと機会費用
現時点からプロジェクトを完了させるために、現実的にいくらかかるかを試算します。それと並行して、会社を切り替えて新たに始めた場合のコスト（引き継ぎ、再オンボーディング、やり直しが発生する可能性）も比較対象に置きます。
残りのコストと作り直しのコストが近い水準であり、成果への確信が低い場合は、新しいスタートの方が経済的に合理的です。作業の大半が再利用可能で、信頼の問題が技術的な協議で解決できるレベルであれば、構造を整えて立て直す方がコスト面で優位なことが多いです。
判断の目安
立て直しが適切なケース: コード資産が部分的に再利用可能、コミュニケーション断絶の原因が意図ではなく構造にある、技術的な協議で解決できる見込みがある。
切り替えが適切なケース: 再利用できる成果物が少ない、納品能力への信頼が低い、残りのコストが新規スタートのコストに近い。
続けると決めた場合: 立て直しフレーム
続けると決めたなら、これまでと同じやり方で進めることに意味はありません。同じ構造が同じ問題を生み出します。立て直しは3つの軸を同時に動かす必要があります。
スコープの再定義
この時点で「当初計画したすべての機能」を維持しようとするのは現実的ではありません。現時点で完了しているもの、進行中のもの、着手前のものを書面で明確に整理し、今回のリリースに必須なものと次のフェーズに移せるものを分けます。
スコープを絞ることで、現実的な納期設定が可能になり、品質への集中度も上がります。当初より小さな形でリリースすることは失敗ではありません。リリースが一切ない状態よりも、はるかに意味があります。
検収サイクルの見直し
立て直し構造で最も重要な変化は、確認の頻度を上げることです。月次のマイルストーン確認より、週次の中間確認の方が実効性があります。
毎週の確認では3点を押さえます。今週完了したこと、来週の予定、現在の詰まりポイント。口頭の報告ではなく、実際の成果物（画面キャプチャ、動作映像、コード変更の概要）を根拠に進捗を判断します。報告ではなく、証拠を見る仕組みです。
状況別の詳細な対応手順（遅延時の具体的なエスカレーション方法、コミュニケーションが完全に止まった場合のアプローチなど）は状況別対応マニュアルにまとめています。
コミュニケーション経路の整理
複数のチャンネルに会話が分散していると、重要な情報が抜け落ちます。公式の連絡先を一本化し、決定事項はメールや書面で残すことを基本とします。口頭で合意した内容もテキストで整理して共有するルーティンが必要です。
撤退を選ぶ場合
撤退を決めたなら、まずソースコード、設計ドキュメント、インフラのアクセス情報、デザイン資産を確保することが優先事項です。次の開発チームが一から推測しなくても済むよう、これまでの文脈を適切に引き継ぐことが重要です。
会社の切り替え手順と引き継ぎ方法については、開発会社を切り替えるときに: 引き継ぎなしでプロジェクトを継続する方法で具体的に解説しています。
インテグラビットがこの問題に取り組む方法
外注プロジェクトにおけるコミュニケーション断絶や進捗不透明は、ほとんどの場合、構造の問題です。「もっと頻繁に確認する」という方法では根本的に解決しません。
インテグラビットは、クライアントにIntegrabbit Insightポータルを通じてプロジェクトの現状を直接確認できるアクセス権を提供します。進行中のタスク、完了状況、現在のブロッカーが何かを、担当者に問い合わせることなくポータルでリアルタイムに把握できます。
報告書ではなく、実際の作業データが直接見える構造です。問題が発生した後に「なぜこうなったのか」を振り返るのではなく、ブロッカーが発生した時点でポータルで確認して対応できます。
最初からこうした構造を持ってプロジェクトを始めることで、途中で「続けるべきか撤退すべきか」を悩む状況そのものが少なくなります。外注プロジェクト全体をどのように設計するかについては、スタートアップMVP外注の完全ガイドも参考になります。
現在進行中の外注プロジェクトが揺らいでいる場合は、30分の無料相談で現状を一緒に確認することができます。立て直せるかどうか、どこから手をつけるべきかを一緒に整理します。