「開発を依頼したシステムが、半年経っても完成しない」「納品されたが、要件と全く違うものが出てきた」「開発会社と連絡が取りづらくなった」——システム開発の失敗は、決して珍しいことではない。

IPA（情報処理推進機構）の「ソフトウェア開発分析データ集2025」によると、システム開発プロジェクトの約30%がQCD（品質・コスト・納期）のいずれかで目標未達となっている。中小企業に限れば、この数字はさらに高いとされる。総務省「令和6年版 情報通信白書」でも、中小企業のIT投資における「期待した効果が得られなかった」という回答は52%を超えている。

しかし、プロジェクトが失敗したからといって、そこで終わりではない。適切な対処を行えば、失敗プロジェクトからリカバリーし、当初の目的を達成することは十分に可能だ。本記事では、失敗パターン別の対処法、ベンダー変更の判断基準、引き継ぎの進め方、費用の目安を解説する。

目次

  1. システム開発の失敗パターンと深刻度判定
  2. ベンダー変更の判断基準——続行か撤退か
  3. ベンダー変更の具体的な進め方
  4. リカバリーにかかる費用の目安
  5. 二度と失敗しないための予防策
  6. FAQ（よくある質問）

システム開発の失敗パターンと深刻度判定

7つの失敗パターンと対処法

システム開発の失敗にはさまざまな形態があるが、代表的なパターンを7つに分類し、それぞれの深刻度と対処法を整理する。

#失敗パターン深刻度主な原因推奨対処
1納期が大幅に遅延している中要件の膨張、PM能力不足、人員不足ベンダーとのスコープ再定義、段階リリースへの切替
2予算が大幅に超過している中〜高見積もり精度の低さ、スコープクリープ変更管理プロセスの導入、残予算での優先機能の特定
3品質が著しく低い高技術力不足、テスト不足、コードレビュー未実施第三者によるコードレビュー、ベンダー変更の検討
4要件と異なるものが納品された高要件定義の不備、コミュニケーション不足要件の再確認、差分の特定と改修交渉
5ベンダーの対応が悪化・音信不通最高ベンダーの経営問題、人員流出即座にベンダー変更の準備開始
6途中でプロジェクトが停止した最高資金ショート、要件の合意不能、技術的な行き詰まり原因の特定 → ベンダー変更 or プロジェクト再定義
7納品後にシステムが使われていない中ユーザビリティの問題、現場への周知不足UX改善、研修の実施、段階的な機能導入

深刻度の判定基準

自社のプロジェクトがどの段階にあるかを判定するために、以下のチェックリストを使ってほしい。

チェック項目該当する場合の深刻度
ベンダーからの週次報告が2週間以上途絶えている最高
プロジェクトの進捗が3ヶ月以上停滞している最高
当初予算の150%以上を既に消化している高
納品されたコードの品質が明らかに低い（バグ多発、動作不安定）高
要件定義書と納品物の乖離が大きい高
納期が当初計画の2倍以上に延びている中〜高
担当PMが変更された、または退職した中
追加費用の請求が3回以上あった中
ベンダーとのコミュニケーションにストレスを感じている中
「最高」が1つでも該当する場合は、即座にベンダー変更を検討すべきだ。「高」が2つ以上該当する場合も、ベンダー変更を視野に入れた対策が必要。

ベンダー変更の判断基準——続行か撤退か

続行すべきケース

以下の条件を全て満たす場合は、現ベンダーとの関係を維持しつつ改善を図るほうが合理的だ。

  • ベンダーが問題を認識し、改善の意思を示している
  • 具体的な改善計画（人員増強、PM変更等）が提示されている
  • プロジェクトの進捗率が50%以上であり、残りの開発ボリュームが少ない
  • コードベースの品質が一定水準を満たしている
  • 契約上、中途解約のペナルティが大きい

ベンダー変更すべきケース

以下のいずれかに該当する場合は、ベンダー変更を真剣に検討すべきだ。

  • ベンダーが問題を認識していない、または認めない
  • コミュニケーションが成立しない（音信不通、責任転嫁）
  • コードベースの品質が低く、改修するよりも作り直したほうが安い
  • プロジェクトの進捗率が30%未満で、既に当初予算の大半を消化している
  • 技術力不足が明らかで、今後の改善が見込めない

「損切り」の考え方

ベンダー変更は、これまでに投じた費用の一部を「埋没コスト（サンクコスト）」として受け入れる決断だ。「もったいないから」と続行しても、追加の費用と時間を失うだけのケースが多い。

判断ポイント続行ベンダー変更
残りの追加費用見積もり当初予算の30%以内で完了見込み当初予算の50%以上が追加で必要
納品物の流用可能性既存コードの80%以上が流用可能コードの大部分が作り直し必要
ベンダーの改善意思具体的な改善計画を提示問題を認めない or 改善計画が曖昧
プロジェクト停止期間1ヶ月以内の遅延3ヶ月以上停滞

ベンダー変更の具体的な進め方

ステップ1：現状の資産を棚卸しする

ベンダー変更を決断したら、まず現在のプロジェクトで生成された資産（成果物）を棚卸しする。

棚卸しチェックリスト

#棚卸し項目確認ポイント取得状態
1ソースコードリポジトリへのアクセス権、最新版の確保□
2要件定義書最新版の有無、内容の妥当性□
3基本設計書・詳細設計書最新版の有無、コードとの整合性□
4テスト仕様書・テスト結果テストケースの網羅性□
5データベース設計（ER図等）最新の定義、テストデータ□
6インフラ構成図サーバー構成、ネットワーク設計□
7API仕様書外部連携の仕様□
8議事録・メール履歴合意事項の証跡□
9契約書・見積書権利関係の確認□
10ライセンス情報使用しているOSS・商用ライセンスの一覧□

ステップ2：契約・権利関係を確認する

ベンダー変更に際して、以下の法的・契約的な確認が必要だ。

確認事項注意点
ソースコードの著作権契約書で「発注者に帰属」と明記されているか確認。記載がない場合、著作権は開発者（ベンダー）に帰属する可能性がある
中途解約条項契約書の中途解約条件（違約金、通知期間等）を確認
成果物の引き渡し義務解約時に成果物（ソースコード、設計書等）を引き渡す義務がベンダーにあるか
秘密保持義務プロジェクト情報の第三者への開示に制約がないか
競業避止義務新ベンダーへの乗り換えを制限する条項がないか
重要: 契約書の確認は、必要に応じて弁護士に相談する。特にソースコードの著作権は、後から争いになるケースが多いため、早い段階で確認しておく。

ステップ3：新ベンダーを選定する

リカバリープロジェクトのベンダー選定では、通常の新規開発とは異なる視点が必要だ。

選定基準通常の新規開発リカバリープロジェクト
技術力重要最重要（既存コードの評価・改修能力が必要）
PM能力重要最重要（混乱したプロジェクトを立て直す能力が必要）
コミュニケーション重要最重要（信頼関係の再構築が必要）
費用重要中（安さよりも確実性を優先）
引き継ぎ経験不問必須（他社コードの読解・引き継ぎ経験）

関連記事: ベンダー選定の詳細な基準は「システム開発会社の選び方完全ガイド」で解説している。

ステップ4：引き継ぎを実施する

引き継ぎは、新ベンダーが既存の資産を理解し、開発を再開できる状態にするプロセスだ。

理想的な引き継ぎプロセス

段階内容期間目安参加者
① 資料レビュー設計書・コードの事前レビュー1〜2週間新ベンダー
② 旧ベンダーとの引き継ぎ会技術仕様、設計意図、既知の問題の共有1〜3回新旧ベンダー、発注者
③ コードの技術調査既存コードの品質評価、流用可否の判定1〜2週間新ベンダー
④ リカバリー計画策定作り直す範囲、改修する範囲の決定1週間新ベンダー、発注者
⑤ 開発再開リカバリー計画に基づく開発着手—新ベンダー
旧ベンダーが引き継ぎに非協力的な場合: 旧ベンダーが引き継ぎに応じないケースもある。その場合、新ベンダーが既存のソースコードと設計書（あれば）だけで理解を深める「リバースエンジニアリング」アプローチを取る。費用と時間は余分にかかるが、不可能ではない。

ステップ5：プロジェクトを再定義する

ベンダー変更は、単に「作業者を入れ替える」のではなく、「プロジェクトを再定義する」機会でもある。以下の点を新ベンダーと再検討する。

  • スコープの見直し: 当初の要件は本当に全て必要か。80:20の法則で、重要な20%の機能から優先的に実装する
  • 技術スタックの見直し: 既存のコードベースを継続するか、技術スタックを変更して作り直すか
  • 開発手法の見直し: ウォーターフォールで失敗したなら、アジャイル（スクラム）に切り替えることで進捗の可視化とリスクの早期発見を図る

リカバリーにかかる費用の目安

ケース別の費用比較

リカバリーの費用は「何をどこまでやるか」によって大きく異なる。以下に代表的なケースの費用目安を示す。

リカバリーケース費用目安期間目安適用条件
A: 既存コードの改修で対応当初見積もりの30〜50%1〜3ヶ月コード品質が一定水準以上、要件の乖離が小さい
B: 部分的に作り直し当初見積もりの50〜80%2〜5ヶ月コアモジュールは使えるが、一部は作り直し
C: フルスクラッチで作り直し当初見積もりの80〜120%3〜8ヶ月コード品質が低く流用不可、または技術スタックを変更
D: 要件から再定義して作り直し当初見積もりの100〜150%4〜10ヶ月要件自体に問題があった場合

費用を最小化するための3つのポイント

  1. 「作り直す範囲」と「流用する範囲」を明確にする: 新ベンダーにコード品質の評価を依頼し、流用可能な部分と作り直すべき部分を判定してもらう
  2. スコープを絞る: リカバリーの最初のフェーズでは、最も重要な機能だけに絞って早期にリリースし、残りの機能は後続フェーズで対応する
  3. 補助金を活用する: IT導入補助金やものづくり補助金は、「新規開発」だけでなく「既存システムの刷新」にも適用できる場合がある

二度と失敗しないための予防策

予防策1：要件定義を丁寧に行う

失敗の35%は要件定義の不備に起因する（IPA調べ）。次のプロジェクトでは、要件定義に十分な時間と費用を確保する。

関連記事: 要件定義の進め方は「業務システムの要件定義テンプレート」で解説している。

予防策2：ベンダー選定を慎重に行う

「安いから」「知り合いだから」で選ぶのではなく、技術力・PM能力・コミュニケーション品質・保守体制を総合的に評価する。

予防策3：段階的にリリースする

一度に全ての機能を開発するのではなく、フェーズを分けて段階的にリリースする。これにより、各フェーズの終了時点で軌道修正が可能になる。

アプローチリスクメリット
一括開発・一括リリース高（失敗時のダメージが大きい）全機能が揃った状態で使い始められる
段階的リリース低（フェーズごとに軌道修正可能）早期に成果が見える、フィードバックを次フェーズに反映できる

予防策4：週次で進捗を確認する

月次報告だけでは、問題の発見が遅れる。週次でベンダーとの進捗確認の場を設け、小さな問題のうちに対処する。

予防策5：契約書でリスクを管理する

以下の項目を契約書に明記する。

  • ソースコードの著作権は発注者に帰属する
  • 中途解約時の成果物引き渡し義務
  • 瑕疵担保責任（契約不適合責任）の範囲と期間
  • 変更管理のプロセス
  • 検収基準と検収期間

FAQ（よくある質問）

Q1. 失敗したプロジェクトの費用は取り戻せますか？

A. 契約内容と失敗の原因による。ベンダー側の瑕疵（バグ、仕様不適合など）が明確であれば、損害賠償や返金を求めることは可能だ。ただし、法的手続きには時間とコストがかかるため、弁護士に相談の上で費用対効果を判断する。要件定義の不備など「発注者側にも原因がある」場合は、全額回収は難しいケースが多い。

Q2. 旧ベンダーのコードをそのまま新ベンダーに渡してよいですか？

A. 契約書でソースコードの著作権が発注者に帰属すると定められている場合は問題ない。著作権の帰属が不明確な場合は、旧ベンダーに確認し、必要に応じて書面で合意を得る。

Q3. ベンダー変更にはどのくらいの期間がかかりますか？

A. 引き継ぎ期間を含めると、一般的には1〜3ヶ月が目安だ。内訳は、新ベンダーの選定（2〜4週間）、引き継ぎ・技術調査（2〜4週間）、リカバリー計画策定（1〜2週間）。旧ベンダーが引き継ぎに協力的であれば短縮でき、非協力的であれば長引く。

Q4. 部分的に完成しているシステムを別のベンダーに引き継ぐことは技術的に可能ですか？

A. 可能だ。ただし、以下の条件を満たしているほどスムーズに引き継げる。(1) ソースコードにアクセスできる、(2) 設計書が存在する、(3) コーディング規約が守られている、(4) テストコードが存在する。これらが欠けている場合、新ベンダーによるリバースエンジニアリング（コードから仕様を読み解く作業）が必要になり、追加の費用と時間がかかる。

Q5. 「セカンドオピニオン」として第三者に現状を評価してもらうことはできますか？

A. 可能であり、推奨する。GXOでは「セカンドオピニオンサービス」として、進行中のプロジェクトの現状評価を提供している。具体的には、(1) コード品質の評価、(2) プロジェクト進行の妥当性評価、(3) リスクの特定と対策提案——を行い、「続行すべきか、ベンダー変更すべきか」の判断材料を提供する。

まとめ——失敗は終わりではない。適切なリカバリーで目的を達成できる

システム開発の失敗は、精神的にも金銭的にも大きなダメージを伴う。しかし、「失敗したからもう諦める」のは最悪の選択だ。当初の目的——業務効率化、コスト削減、売上向上——は依然として有効であり、アプローチを変えて再挑戦する価値がある。

重要なのは、(1) 現状を正確に把握し、(2) 感情ではなくデータに基づいて判断し、(3) 適切なパートナーと再スタートを切ることだ。

セカンドオピニオンとしてGXOに相談してください

>

GXO株式会社は、システム開発の「セカンドオピニオン」として、進行中プロジェクトの現状評価やリカバリー支援を提供しています。

>

- 進行中プロジェクトの客観的な評価（コード品質、進捗妥当性、リスク特定）

  • ベンダー変更が必要かどうかの判断支援
  • 引き継ぎ・リカバリープロジェクトの計画策定と実行
  • 過去の失敗原因を踏まえた再発防止策の提案

>

「今のプロジェクトが正しい方向に進んでいるのか不安」「ベンダーを変えるべきか迷っている」——そのような状況でこそ、第三者の視点が役に立ちます。

>

セカンドオピニオンを申し込む →