システム開発が途中で止まる——ベンダーの倒産、社内体制の崩壊、市場環境の変化など、要因はいくつもあります。中小企業の経営者がここで判断を誤ると、これまでの投資が完全に水泡に帰すか、止めるべきところで継続して傷を深めるかのどちらかに陥ります。本記事では中断の3パターンを整理し、止まった時の選択肢として「別ベンダー引き継ぎ」「スコープ縮小して仕上げる」「凍結して保全する」「中止して損失確定する」の4つを判断軸とともに解説します。中断を未然に防ぐ契約と進捗管理の実践策も合わせて整理します。
この記事の結論（3行）
- 中断リスクはベンダー側・自社側・外部環境の3パターン。それぞれ予兆と対応が違う
- 止まった時の選択肢は4つ。進捗率・残予算・市場環境・社内体制で振り分ける
- 中断を防ぐ最大の備えは「契約書の知的財産権条項」と「週次30分の進捗確認」
システム開発の中断リスクの3パターン
開発中断は不運な出来事に見えますが、構造としては3つのパターンに分けられます。
- パターン1：ベンダー側の崩壊（倒産・人員流出・経営悪化）
- パターン2：自社側の崩壊（担当者退職・経営方針転換・予算撤退）
- パターン3：外部環境の変化（法改正・取引先変動・市場シフト）
それぞれのパターンによって、予兆の見え方と取るべき対応が変わります。発注前に3パターンを意識した契約条件を整えておくことで、止まった時の選択肢が大きく広がります。
パターン1：ベンダー側の崩壊
ベンダーの倒産・主要技術者の離職・経営状況の悪化が引き金になります。予兆として「請求のタイミングが不規則になる」「担当者の交代が頻繁」「進捗報告の質が落ちる」が見られたら警戒してください。中小ベンダーは大手より中断リスクが高い傾向があります。
パターン2：自社側の崩壊
社内のキーマン担当者が退職、経営方針の急な転換、業績悪化による予算撤退などが要因です。「プロジェクトを推進していた人がいなくなった」状態は、ベンダー側からは外から見えにくく、結果として要件凍結ができないまま開発が漂流します。
パターン3：外部環境の変化
法改正で要件が大きく変わる、主要取引先が変動して業務フローを見直す必要が出る、市場シフトでそもそも企画自体が陳腐化する——こうした要因で開発が止まることがあります。発注後12カ月以上のプロジェクトはこのリスクが特に大きくなります。
中断時の4つの選択肢
開発が止まった時、経営者が選べる選択肢は大きく4つです。それぞれの特性を整理します。
| 選択肢 | 期間 | 費用感 | 適用条件 | |---|---|---|---| | 別ベンダー引き継ぎ | 3〜9カ月 | 残予算の1.2〜2倍 | 進捗30〜70%、技術スタック汎用 | | スコープ縮小して仕上げる | 1〜3カ月 | 残予算の0.5〜0.8倍 | 進捗70%以上、機能の切り出し可能 | | 凍結して保全する | 不定 | 月額1〜5万円 | 市場環境待ち、再開可能性あり | | 中止して損失確定 | 即時 | 撤収費のみ | 企画自体が陳腐化、再開見込みなし |
4つの選択肢は組み合わせも可能です。「いったん凍結→3カ月後に別ベンダー引き継ぎ」のような時間差の組み合わせも実務でよく使われます。判断に迷う場合は業務改善・システム見積もりAI適正診断で第三者の整理を入れる手も有効です。
選択肢1：別ベンダー引き継ぎ
別ベンダーに残工程を引き継ぐ選択肢です。進捗30〜70%で、技術スタックが汎用的（Next.js・Supabase・Laravel等）であれば現実的な選択になります。引き継ぎ費用は残予算の1.2〜2倍が一般的で、コードの解読工数とテスト再実施が乗ります。知的財産権が自社にある契約条件が前提です。
選択肢2：スコープ縮小して仕上げる
機能を絞り込んで、残った機能だけで仕上げて稼働させる選択肢です。進捗70%以上で、機能の切り出しが可能な構造であれば適用できます。「全60機能のうち、コア20機能だけリリース」のような形で、残予算の50〜80%で稼働状態に持っていきます。残機能は次フェーズ送りです。
選択肢3：凍結して保全する
開発を一旦止めて、現状を保全する選択肢です。市場環境の変化や社内体制の整備を待つ間、月額1〜5万円程度でサーバー・コード・データを保全しておきます。半年〜1年後に再開する見込みがある場合に有効です。凍結期間中の技術陳腐化リスクは残ります。
選択肢4：中止して損失確定
開発を中止し、これまでの投資を損失として確定する選択肢です。企画自体が陳腐化、市場環境が大きく変わり再開見込みがない場合の最終手段です。痛みは大きいですが、ずるずると追加費用を払い続けるよりも経営的に合理的なケースが多くなります。中止判断には会計上の処理（仕掛中ソフトウェア資産の損失計上）が伴うため、税理士・会計士と並行して進めることをお勧めします。
4つの選択肢を組み合わせる発想
実務では、4つを単独で選ぶよりも組み合わせるほうが現実的な場面が多くなります。「2カ月だけ凍結して市場環境を見極め、再開判断時に別ベンダー引き継ぎへ動く」「コア機能だけスコープ縮小でリリースし、残機能は半年凍結して別ベンダー検討」のような時間差・組み合わせ方が、損失最小化につながります。固定的に1つの選択肢に絞らない柔軟性が、経営判断の余地を残します。
選択肢を判断する3つの軸
4つの選択肢から1つを選ぶ判断軸は、進捗率・残予算・市場環境の3つです。
| 判断軸 | 別ベンダー引き継ぎ | スコープ縮小 | 凍結 | 中止 | |---|---|---|---|---| | 進捗率 | 30〜70% | 70%以上 | 不問 | 不問 | | 残予算 | 1.5倍まで許容 | 残予算内 | 月額小額 | ゼロ | | 市場環境 | 安定 | 安定 | 変化中 | 陳腐化 | | 社内体制 | あり | あり | 不問 | 撤退 |
3軸全てを満たす選択肢が1つあれば、それを選んでください。複数該当する場合は、より少ない損失で済むほうを選びます。
進捗率による振り分け
進捗30%以下なら新規開発に近い形で別ベンダーへ、30〜70%なら引き継ぎが現実的、70%以上ならスコープ縮小で仕上げる選択肢が有力です。進捗評価は機能別で見ること、ベンダー報告を鵜呑みにせず実物コードで第三者確認することが重要です。
残予算による振り分け
残予算が当初予算の30%以下なら、別ベンダー引き継ぎは難しくなります。スコープ縮小か、いったん凍結して予算を確保し直すかの選択になります。残予算50%以上あれば、引き継ぎを含めた選択肢が広がります。
市場環境による振り分け
市場環境が変化中で「いま完成しても使われない可能性がある」場合は、凍結か中止が現実的です。市場が安定しているなら引き継ぎやスコープ縮小で前へ進める判断が合理的です。外部環境の見立ては経営者の判断領域で、ベンダーには判断できません。
社内体制という第4の軸
3軸に加えて、社内の運用体制が整っているかという視点も重要です。完成したシステムを使いこなす担当者が社内にいない、または運用ルールが固まっていない状態だと、引き継ぎやスコープ縮小で稼働させても結局活用されません。社内体制が崩壊している場合は、凍結を選んで体制再構築を優先するほうが、長期的には合理的な選択になります。
経営者目線で考える「中断を経営判断に変える」発想
ここからは経営の話です。開発中断は失敗ですが、見方を変えれば「投じた予算と時間を、いま冷静に振り返るタイミング」でもあります。日常運用していると振り返れない論点が、強制的に俎上に乗ります。
経営者として持っておきたい視点は3つです。第一に、「中断は痛みを伴うが、ずるずる継続より損失は小さい」という現実認識。第二に、「4つの選択肢のうち、感情で『継続したい』に引っ張られていないか」というセルフチェック。第三に、「中断の経験を契約条件として次の発注に反映させる」という学びの定着。
特に2つ目が肝心です。これまで投じた費用を「無駄にしたくない」感情は、サンクコストの罠です。経営判断としては「いま新規でやり直すのと、継続するのとでどちらが安いか」だけを比較すべきで、過去の投資は判断材料から外す冷徹さが必要です。
ぷらすわんの実例：「けんぞくん」を支えた中断回避の設計
ぷらすわんが構築する「けんぞくん」は建設業マッチングサービスで、市場相場2,500〜4,000万円規模を2,000万円規模で立ち上げた事例です。57機能・30.8人月という規模感を中断させずに完走できた背景には、発注時点での中断回避設計がありました。
具体的には、開発を3フェーズに分割し、各フェーズ単体でも業務価値が出る構造にしました。フェーズ1（コア15機能）が完成すれば、その時点で部分稼働が可能。フェーズ2(中位20機能)が完成すれば本格運用、フェーズ3（残22機能）でフル機能化、という設計です。各フェーズ間で中断しても、それまでの投資が無駄にならない構造を最初から組み込みました。
中小企業の発注でも、この「フェーズ分割で各段階に業務価値を持たせる」設計は応用できます。一度に全機能を作る発注より中断リスクが大幅に下がります。手元のプロジェクトの中断リスクを診断する場合は、フェーズ分割可能性から確認することをお勧めします。
中断を未然に防ぐ5つの実践
最後に、中断リスクを未然に下げるための5つの実践ポイントをまとめます。
- 知的財産権を自社帰属で契約する
- 開発を3フェーズに分割し各段階で業務価値を持たせる
- 技術スタックを汎用的なもので選定する
- 週次30分の進捗確認で予兆を捕捉する
- 中途解約条項を契約書に明記する
この5つを発注時点から実行することで、中断リスクは大きく下がります。万が一中断が起きても、選択肢が広がる状態になります。
知的財産権を自社帰属で契約する
ソースコード、設計書、ドキュメント類の知的財産権を自社帰属にしてください。これがベンダー帰属だと、別ベンダーへの引き継ぎや継続改修自体が困難になります。発注書・契約書の明文化が必須です。条文例としては「本契約に基づきベンダーが作成した成果物の著作権（著作権法第27条および第28条の権利を含む）は、検収完了時に発注者へ譲渡される」のような書きぶりが標準です。OSSライブラリのライセンス条件は別途整理が必要ですが、自社作成部分の権利帰属が明確になっていれば、引き継ぎ時の交渉余地が大きく広がります。
開発を3フェーズに分割し各段階で業務価値を持たせる
全機能を一度に作る発注を避け、3フェーズに分割してください。各フェーズ単体で業務価値が出る設計にすることで、フェーズ間で中断が起きても投資が無駄になりません。フェーズ間の判定タイミングで継続/中止判断ができます。
技術スタックを汎用的なもので選定する
Next.js、Laravel、Rails、Supabase、AWS、Vercel など、市場で扱える技術者が多い技術スタックを選定してください。独自フレームワークや特殊技術は、ベンダーが対応できなくなった時に引き継ぎ先が見つからない問題を生みます。発注前に他社見積もりとの比較を依頼する際は、技術スタックの汎用性も比較項目に含めてください。
週次30分の進捗確認で予兆を捕捉する
ベンダーの体制悪化、進捗遅延、課題滞留などの予兆を週次で捕捉する場を設けてください。1〜2週間の予兆段階で察知できれば、中断前に手を打てます。経営者自身が出席することで緊張感が保たれます。
中途解約条項を契約書に明記する
「○○日前の書面通知で解約可能」のような中途解約条項を契約書に明記してください。条項がない場合、中断時の引き継ぎ判断で交渉が難航し、損害賠償リスクも抱えます。発注時点で必ず盛り込んでください。整理に迷う場合は項目別に整理した形で第三者の支援を入れる手も使えます。
まとめ
システム開発の中断リスクは、ベンダー側・自社側・外部環境の3パターンで顕在化します。止まった時の選択肢は別ベンダー引き継ぎ・スコープ縮小・凍結・中止の4つで、進捗率・残予算・市場環境の3軸で振り分けて判断します。
中断を未然に防ぐ最大の備えは、発注時点での契約条件です。知的財産権の自社帰属、3フェーズ分割設計、汎用技術スタック、週次30分の進捗確認、中途解約条項——これらを揃えておけば、万が一中断が起きても選択肢が広がります。手元のプロジェクトを項目別に整理してから判断する流れをお勧めします。