「費用を半分以上払ったのに、画面が3枚しか動いていない」「ベンダーから連絡が途絶え、開発が止まったまま1年経過」——システム開発で完成に至らないまま終わってしまうケースは、中小企業の発注では意外と多くあります。本記事では未完成のまま終わる典型4パターンを整理し、発注前の初期段階で押さえるべき6つのチェックポイントを経営者目線で解説します。
この記事の結論（3行）
- 未完成のまま終わるシステムは「ベンダー破綻」「要件爆発」「発注者撤退」「品質崩壊」の4類型
- 4類型のうち3つは、発注前のチェック6項目で兆候を見抜ける
- 完成定義を「動く画面数」ではなく「業務シナリオ完遂」で書くと、完成率が上がる
なぜシステム開発が完成しないまま終わるのか
完成に至らないシステム案件には、共通する初期兆候があります。発注時点では分からなくても、振り返ると「あの時点で気付けた」サインが存在することがほとんどです。完成しない構造的な要因は3つあります。
- ベンダー選定が「価格と提案書」だけで決まっている
- 完成定義が「動くシステム」程度の抽象表現で止まっている
- リリース後の運用体制が発注時に設計されていない
この3つは技術的な問題ではなく、発注プロセスの問題です。発注プロセスを整えるだけで、完成に至らないリスクは大きく下がります。
ベンダー選定が価格と提案書だけで決まっている
中小企業の発注では、3社見積もりを取り、価格が安く提案書の見栄えが良いベンダーを選ぶケースが多いです。提案書は営業担当者が作成するため、実際の開発体制とは乖離していることが珍しくありません。選定時に「実際に開発を担当するエンジニアと話す」工程を入れていないと、提案と現場の乖離を見抜けません。
完成定義が抽象的すぎる
契約書に「動く受発注システムを納品する」とだけ書かれている場合、ベンダーは「契約書記載の機能が動作する状態」を完成と考え、発注者は「業務で実際に使える状態」を完成と考えます。この認識ギャップが、検収を巡る紛争・未完成リリースの原因になります。完成定義を「業務シナリオ5件が連続で完遂可能」のように具体化する必要があります。
リリース後の運用体制が設計されていない
リリースさえすれば終わり、という前提で発注すると、リリース直前に運用面の課題が次々に発覚します。データ移行・ユーザートレーニング・障害時の連絡体制・バックアップ手順——これらが整理されていないと、リリース直前で開発が止まり、未完成のまま放置される結末になりがちです。
未完成のまま終わる典型4パターン
実際に完成に至らなかった案件を、典型4パターンに整理します。
| パターン | 主な原因 | 発生時期 | 回収可能性 | |---|---|---|---| | ベンダー破綻型 | 受注社の経営悪化・倒産 | 開発中盤〜終盤 | 困難（10〜30%） | | 要件爆発型 | 追加要求の積み重ね | 開発中盤〜終盤 | 部分的（40〜60%） | | 発注者撤退型 | 経営判断による開発中止 | 開発初期〜中盤 | 高い（60〜80%） | | 品質崩壊型 | バグ多発・修正対応の連鎖 | 終盤・リリース直前 | 部分的（30〜50%） |
「回収可能性」は、既支払い分から実用可能な成果物として回収できる割合の目安です。4類型のうち3つ（ベンダー破綻・要件爆発・品質崩壊）は、発注前の初期チェックで兆候を見抜ける可能性があります。発注前にチェック項目を整理したい経営者の方は、業務改善・システム見積もりAI適正診断で点検項目から始める流れがお勧めです。
パターン1：ベンダー破綻型
受注したベンダーの経営状況が悪化し、開発体制を維持できなくなるパターンです。フリーランス・小規模ベンダーで起きやすく、主担当エンジニアの離脱で実質的に開発が止まります。発注前にベンダーの財務状況・組織体制・主要担当者の所属期間などを確認していれば、リスクを下げられます。
パターン2：要件爆発型
開発中に発注者からの追加要望が積み重なり、当初予定の2〜3倍の規模に膨らんで完了しなくなるパターンです。発注者側の要件管理プロセスが弱い場合に起きます。追加要望の取り扱いルール（月間で対応する変更工数の上限など）を契約段階で決めていれば、回避できます。
パターン3：発注者撤退型
発注者側の経営判断（予算削減・事業撤退・経営者交代）でプロジェクトが中止されるパターンです。ベンダー側に問題はなく、社内事情で開発が止まります。事業全体のリスク管理の問題で、システム発注の問題ではないこともありますが、発注タイミングの判断ミスが背景にあるケースもあります。
パターン4：品質崩壊型
開発は進んだものの、終盤になってバグが多発し、修正対応の連鎖でリリースに至らないパターンです。テスト工程を軽く見積もっていた、開発と並行したテストが行われていない、品質基準が定義されていない——こうした要因が複合します。発注者側が「リリース日に間に合わせるためにテストを省略する」判断をしてしまうと、リリース後の障害が連鎖し、結果的にリリース取り下げ→未完成扱いという結末になることもあります。
なお4類型のうち、最も予防が難しいのは発注者撤退型です。発注者側の経営状況や事業判断に左右されるため、発注前のチェックでは見抜きにくい性質があります。一方でベンダー破綻型・要件爆発型・品質崩壊型は、発注前のチェックと契約条項の整備で大きくリスクを下げられます。
発注前に押さえるべき6つの初期チェックポイント
未完成リスクを下げるための、発注前の初期チェック6項目を整理します。
チェック1：ベンダーの組織体制と主要担当者の所属期間
ベンダー選定時に「実際に開発を担当するPM・主担当エンジニアと面談する」「主要担当者の所属期間と過去案件数を確認する」の2点を必ず実施してください。営業担当者からの提案書だけで判断すると、現場の体制が想定と異なる可能性があります。所属3年未満のメンバー中心の体制は、離脱リスクが高めです。
チェック2：ベンダーの財務状況
中小ベンダーの場合、財務状況をある程度確認しておくと安心です。帝国データバンクの簡易レポート（数千円〜）、ベンダーの公開決算情報、年間売上規模に対する受注予定金額の比率を確認してください。年間売上の30%を超える受注は、ベンダーの体力を超えている可能性があります。
チェック3：完成定義を業務シナリオで書く
契約書の完成定義を「機能の動作確認」ではなく「業務シナリオの完遂」で書いてください。例えば「受発注業務シナリオ5件（新規受注・受注変更・在庫引当・出荷指示・請求書発行）が連続して完遂可能であること」のような形です。シナリオベースの定義は、検収判定が明確になります。
チェック4：追加要件の取り扱いルール
開発中に発生する追加要件の取り扱いを契約書で明文化してください。「軽微な変更は契約範囲内、月20時間を超える変更は別途見積もり」のようなルールを入れておきます。ルールが無いと、要件爆発型の未完成パターンに陥りやすくなります。
チェック5：マイルストーンと支払い条件の連動
支払いを「契約時30%・中間40%・検収30%」のような形で、マイルストーン達成と連動させてください。マイルストーン未達のまま支払いが進むと、ベンダー側の納期に対する緊張感が薄れます。マイルストーンには「動作する画面5枚以上」「主要業務シナリオの動作確認完了」のような数値・行動ベースの基準を設定します。
チェック6：リリース後の運用設計を発注段階で整理
リリース後の運用体制（運用担当者・障害時の連絡体制・バックアップ手順・ユーザートレーニング計画）を、発注段階で整理してください。リリース直前に整理し始めると、開発と運用準備の両方を同時に走らせることになり、未完成リリースの原因になります。発注時点で運用設計まで項目別に整理しておく流れをお勧めします。
6項目のうち、特にチェック3（業務シナリオでの完成定義）とチェック5（マイルストーンと支払い条件の連動）は、追加コストなしで実施できる効果の高い項目です。中小企業の経営者が最初に取り入れるべき2点として位置付けてください。
経営者目線で考える「完成しないシステム」を生まない発注
ここからは経営の話です。完成しないシステムを発注してしまう経営者には、共通する判断パターンがあります。経営者が見直すべき視点は3つです。
第一に、「発注したら現場任せ」の姿勢です。契約締結後は現場担当者に任せ、経営者は月次の進捗報告だけ受ける——この姿勢では、火種の段階で気付けません。経営者が四半期に1度は実際の画面・成果物を確認する習慣を作ってください。
第二に、「安いベンダーを選ぶ」発想です。安さ最優先の発注は、未完成リスクを大きく上げます。同じ機能を300万円と800万円で提案された場合、300万円側は「未完成リスク・品質リスク・運用負荷の転嫁」を含んでいる可能性が高くなります。総額だけでなく、リスク込みの期待コストで比較する視点が必要です。
第三に、「リリースが目的」になっている発注です。本来の目的は「業務改善」「売上向上」「コスト削減」のはずですが、いつの間にか「とにかくリリースする」が目的化することがあります。目的が曖昧になると、リリース直前で「これは違う」となり、未完成のまま終わることがあります。発注前に「このシステムで実現したい業務上のゴール」を1行で書き出し、関係者全員で共有してください。1行で書けないゴールは、ベンダーにも伝わりません。
この3点を意識しておくと、ベンダー側にも「真剣な発注者」として認識され、現場のエンジニアの取り組み姿勢にも好影響が出ます。発注者の関与度合いは、開発現場の品質にも反映される領域です。
ぷらすわん実例：ある製造業A社の未完成案件再生
ぷらすわんが相談を受けたある製造業A社の事例をお伝えします。A社は前ベンダーに在庫管理システムを発注し、12か月時点で動作する画面が5枚のみという未完成状態でした。既支払いは900万円。ベンダー側はメイン担当エンジニアの離脱を理由に開発継続が困難との回答でした。
ぷらすわんが取った再生アプローチは2段階です。第一段階として、既存成果物を第三者視点でレビューし、要件定義書の60%とコードの30%は再利用可能と判定しました。残りは作り直しが必要との結論でした。第二段階として、業務シナリオを5件に絞り込み、Next.js + Supabaseの構成で再設計しました。再発注金額は650万円、4か月でリリースに到達しました。
トータルとしてA社は1,550万円を投じる形になりましたが、未完成のまま放棄した場合は900万円の損失で何も残らなかった状況です。再生案件を進めるうえで効いたのは、「業務シナリオで完成定義を書く」「マイルストーン毎の動作確認を必須にする」「リリース後の運用設計を発注時から含める」の3点でした。同じような状況の経営者は、まず診断する流れで再生可能性の判定から入ってください。再生可能性の判定は、既存成果物のレビューと業務側の最低限要件の棚卸しを並行で進めるのが一般的な手順です。
まとめ
システム開発が完成しないまま終わる典型パターンは、「ベンダー破綻」「要件爆発」「発注者撤退」「品質崩壊」の4類型です。このうち3類型は、発注前の初期チェック6項目（組織体制・財務状況・完成定義・追加要件ルール・マイルストーン連動・運用設計）で兆候を見抜ける可能性があります。
特に「完成定義を業務シナリオで書く」「リリース後の運用設計を発注時から含める」の2点は、多くの中小企業の発注で抜けがちなポイントです。発注前にチェック項目を比較を依頼する流れで点検しておくと、未完成リスクを大きく下げられます。発注プロセスの整備自体が、長期的なシステム投資の最大のリスク低減策になります。