大きな会社がERPをやめると、決算で何十億円もの損失として公表されます。中小企業ではそうなりません。上場していない会社は決算を公表しないので、失敗が表に出るのは、開発会社と裁判になったときか、上場している会社が開示したときくらいです。
5社の事例
負けた2件は会社から止め、勝った2件は開発会社が約束を守れていませんでした
5社を、判決・開示の年の順に並べます。
機械の据付・修理会社従業員130人・東京地裁 2009年
パッケージ（初期費用 約8,200万円）
要件定義を終えると、追加開発の費用が約3,200万円から約7,100万円に増えると分かり、会社が開発を止めました。
ねじ・自動車部品メーカー東京高裁 2014年
パッケージ＋追加機能（計画 9,800万円）
提案の「適合率73%」を、会社は業務全体に対する割合だと受け取っていました。確認項目が125から571に増え、計画を凍結しました。
足場のリース会社東京地裁 2016年
販売管理（2,310万円）
前のシステムのデータに約10万7,000件の食い違いがあり、予定の月に動きませんでした。データを移す作業は開発会社の担当と決めていました。
味噌メーカー東京地裁 2018年
販売・生産管理（総額 5,780万円）
値引きした総額で発注したあと追加の請求が重なり、生産管理を要件定義の段階で解約しました。判決は最初の総額を上限とみなしています。
ツインバード2025年に開示
新しい基幹システム（2024年12月に稼働）
動かしたあと原価の計算が合わず、決算が遅れました。原因は稼働前のテスト不足と、要件を知る担当者の退職だと開示しています。
※ 裁判の4社は、判決で社名が伏せられているため業種で書いています。
5社の失敗の原因は“あるある”だった
5社でつまずいた所は、システムの開発全体でよく起きることと重なります。日本情報システム・ユーザー協会（JUAS）が上場企業などのIT部門に毎年聞いている調査では、開発の規模が大きいほど、予算を超えた・期間が延びた割合が上がります。
※ 人月（にんげつ）：1人が1か月でこなす作業の量です。500人月は、50人で10か月かかる規模です。
予算を超えた会社に理由を聞くと（複数回答）、上位は次の4つでした。5社の事例も、どれもこの4つのどれかに当てはまります。
今の業務とシステムが、思ったより複雑
長年の例外や手作業、Excelでの調整、古いデータの食い違いは、どこにも書かれていないことが多く、作り始めてから見つかります（足場のリース会社）。
仕様の変更が続く
標準の機能で足りない所を足すたびに、確かめる項目も費用も増えます（ねじ・自動車部品メーカーは125→571項目。味噌メーカーは追加の請求が重なって解約）。
社内で判断できる人が足りない
何を作るかを社内で決めきれず、開発会社に任せきりになります。要件を分かる人が辞めると止まります（ツインバード）。
※ 割合はJUAS「企業IT動向調査報告書2026」図表7-1-7。調べた会社は上場企業などが中心です。
5社の失敗から分かった、実際に効く対処法5選
契約は、要件定義で一度切る
契約を「要件定義」と「開発」の2本に分けると、1本目が終わった時点の見積を見て、続けるかやめるかを選べます。やめられるのは2本の間だけです。ねじメーカーは途中で計画を止め、納品物を受け取らないまま、その段の代金を全額払いました。区切りごとに、そこまでで払う額を書面に残します。
パッケージの使用料は、要件定義のあとで払う
機械の据付・修理会社は、要件定義の前に使用料の契約を結んでいました。費用が倍になると分かって中止しても、契約はそれぞれ別に成り立っているとされ、支払いを命じられています。使用料は、見積を見てから払います。
「適合率◯%」は、何に対する割合かを書面で確かめる
提案書の「適合率73%」や「標準の機能で8割まかなえる」は、何を分母にしたかで意味が変わります。ねじメーカーは業務全体に対する割合だと考えていましたが、契約書にはその業務の流れが書かれていませんでした。分母にした一覧を、契約書に添付します。
古いデータの食い違いを数えて、直す人を見積書に書く
足場のリース会社が勝てたのは、データの移行を開発会社の仕事と決めていたからです。決めていなければ、食い違いを誰が直すかで争いになります。見積の前に食い違いの件数を数え、「移す」「直す」の担当を見積書に1行ずつ書きます。
前のシステムを残して、同じ月の数字を突き合わせる
ツインバードは、稼働後に原価が合わないと分かり、システムの外で計算し直しました。切り替えたあとも前のシステムを数か月残し、同じ月の売上・在庫・原価を両方で出して比べます。ずれがあるうちは前の数字で決算し、合ってから解約します。
まとめ
5社の失敗は、どれも「今の業務の複雑さ」「計画の見落とし」「仕様の変更」「社内で判断できる人の不足」のどれかに当てはまりました。防ぐ手は、システムの作り方より前の取り決めにあります。
- 契約は要件定義で一度切る
- パッケージの使用料は、要件定義のあとで払う
- 「適合率◯%」の分母を書面で確かめる
- 古いデータの食い違いを数え、直す人を見積書に書く
- 切り替えたあとも前のシステムを残し、同じ月の数字を突き合わせる
この記事を書いた会社の仕事
他の“あるある”や失敗の原因を知りたい方は、ご相談ください
私たちは、自社でERPを作って毎日使っている開発会社です。60分の無料相談で、5社以外の失敗例や、御社の計画で起きそうな落とし穴をお伝えします。いま使っているツールと、いちばん手間のかかっている作業を教えてください。
出典：ソフトウェア情報センター（SOFTIC）「判例で読み解くシステム開発紛争」（東京地判平21.9.4・東京高判平26.11.26・東京地判平28.11.30） ／IT・システム判例メモ「東京地判平28.11.30」 ／IT・システム判例メモ「東京地判平30.10.12」 ／ツインバード「財務報告に係る内部統制の開示すべき重要な不備に関するお知らせ」（2025年5月29日） ／日本情報システム・ユーザー協会「企業IT動向調査報告書2026」。金額は判決・開示の表記に合わせ、1万円未満を省いています（2026年11月2日時点）。
資料を