「あの500万円は、どぶに捨てたようなものだった」——中小企業の社長から、こうした告白を聞くことが少なくありません。鳴り物入りで導入したシステムが、2年も持たずに破棄される。社内では『あの件には触れない』空気が漂い、次のシステム検討の話題すら出てこなくなる。本記事では実際にシステム導入を後悔した経営者の声を起点に、後悔が生まれる構造と、同じ轍を踏まないための経営判断のポイントを整理します。
この記事の結論（3行）
- 後悔の発生源は『発注先選定』『要件定義』『運用設計』の3段階。どこか1つを甘くすると2年で破棄になる
- 500万円のシステム破棄の本質は、発注先のスキル不足ではなく『経営者が判断を委ねすぎたこと』
- 解決の方向性は『経営者が3つの判断軸を持って発注に臨むこと』。技術知識は不要、判断軸だけでよい
『2年で破棄した500万円』の実例から見える構造
ある製造業A社の社長から聞いた事例です。社員30名、年商5億円のメーカーで、生産管理と在庫管理を統合するシステムを500万円で導入しました。導入から2年後、稼働率は20%を切り、現場ではExcel管理に戻り、最終的にシステムを破棄しました。社長の言葉は重く、「もう二度とシステム導入はしたくない」とまで漏らしていました。
この事例を分解すると、後悔の発生源は3つの段階に分かれていました。
- 発注先選定で『ブランド名』を重視した
- 要件定義で『現場に丸投げ』した
- 運用設計で『稼働開始がゴール』と思っていた
A社の社長は「ベンダーが悪かった」と言いたい気持ちもあったそうですが、振り返ると経営判断のミスが連鎖していたと認めています。500万円という金額が悲劇を増幅させましたが、構造は中小企業のシステム導入で繰り返し起きるパターンです。
発注先選定で『ブランド名』を重視した
A社は『大手ITベンダーなら安心』という発想で発注先を選びました。実際には大手ベンダーの担当営業は基幹システムが本業で、A社のような30名規模の業務システムは『下請け再委託』が標準動線です。社長は『大手と契約した』感覚でしたが、実際の開発は名前も聞いたことのない再委託先が担当していました。コミュニケーションが間接化し、要件のニュアンスが伝わらない構図が初期から発生していました。再委託の存在は契約書上は明記されていても、経営者は『大手の社員が作っている』と思い込んでいたのです。
要件定義で『現場に丸投げ』した
A社の社長は要件定義の段階で「現場が困っていることを全部入れてください」とベンダーに伝えました。これが致命傷でした。現場の声には『あったらいいですね』レベルの希望が大量に含まれており、それを全部仕様に組み込んだ結果、画面数が50を超え、入力項目が二重三重に重複する設計になりました。経営者が『何を作らないか』を決めていれば、ここまでの肥大化は起きなかったはずです。社長自身は『現場の意見を尊重した』つもりでしたが、結果として現場も使えない巨大システムができてしまいました。要件定義は経営の意思決定の場であり、現場に委ねるべきものではありません。
運用設計で『稼働開始がゴール』と思っていた
稼働開始日には盛大なキックオフをしましたが、その後の運用支援契約は最小限でした。3ヶ月後に現場から不満が噴出した時、改修費用は別契約で都度見積もりが必要で、1件あたり30〜80万円という見積もりが続きました。経営者は『追加で出すか我慢するか』の選択を毎月迫られ、結果として改修が止まり、システムは現場で使われなくなりました。稼働半年で稼働率は30%を切り、1年で20%、2年目には完全に Excelへ戻る——緩やかな撤退劇が静かに進みました。
後悔を生む3段階を比較表で整理
A社の事例は珍しいケースではありません。同じ構造で500万〜2000万円規模のシステムが破棄される事例が、中小企業で繰り返し起きています。3段階それぞれで起きやすい失敗を整理します。
| 段階 | やりがちな判断 | 起きる結果 | 経営判断の原則 | |---|---|---|---| | 発注先選定 | ブランド名で選ぶ・1社見積もりで決める | 実開発担当が見えず要件ズレが発生 | 実開発担当との直接対話を契約条件にする | | 要件定義 | 現場に丸投げ・全要望を取り入れる | 仕様が肥大化、納期と予算が破綻 | 経営者が『作らない機能』を決める | | 運用設計 | 稼働日をゴールとする・運用予算を切る | 改修が止まり3〜6ヶ月で使われなくなる | 稼働後6ヶ月の改修予算を初期契約に含める |
3段階のうち1つでも甘い判断をすると、後悔の確率は跳ね上がります。経営者が事前に業務改善・システム見積もりAI適正診断で各段階の判断軸を整理すると、後悔の構造を回避しやすくなります。
後悔を回避する経営者の判断軸：発注先選定編
発注先選定の段階で押さえるべきポイントを整理します。中小企業の業務システムでは、ベンダー規模よりも『実開発担当者との距離』が重要です。
実開発担当者と直接話せるか
提案フェーズで実際にコードを書く担当者と話せるベンダーを選んでください。営業だけが窓口で、エンジニアが見えないベンダーは、要件のニュアンスが伝わりにくくなります。プロジェクトマネージャーだけでなく、実開発担当者の名前と経歴を契約前に確認することをお勧めします。下請け再委託の有無、再委託先の社名、担当エンジニアの実在確認まで、契約前に書面で押さえておくと安全です。
過去の中小企業向け実績の中身
『中小企業向け実績多数』という文言ではなく、具体的な事例3つを聞いてください。業種・規模・予算・期間・成果物の5点で説明できないベンダーは、実績が薄いと判断していい目安です。守秘義務で言えない部分があっても、概要は説明できるはずです。可能であれば過去顧客への問い合わせを許可してくれるベンダーが理想で、ここを渋るベンダーは実績の内実が不安定な可能性があります。
見積もりの内訳を1行ずつ説明できるか
500万円の見積もりに対して『要件定義一式200万円、開発一式250万円、その他50万円』という粗い内訳を出してくるベンダーは要注意です。要件定義の何時間で何を作るのか、開発のどの画面に何人月かけるのか、行単位で説明できるベンダーを選んでください。
後悔を回避する経営者の判断軸：要件定義編
要件定義は経営者が最も関与すべきフェーズです。現場任せにすると仕様は肥大化し、ベンダー任せにすると安全側に倒した過剰見積もりが返ってきます。
『作らない機能』を経営者が決める
要件定義の最初に、経営者が『これは作らない』リストを作ってください。現場から上がった要望のうち、3割は『あったらいい』レベルで、2割は『今のExcelで十分』なものが混ざります。これらを発注前に削るだけで、見積もりが3割以上下がります。経営者がこの判断をしないと、現場とベンダーの間で要望が膨らみ続けます。
業務動線で要件を語る
「顧客管理機能が欲しい」のような抽象的な要件は危険です。「営業が外出先で名刺をスキャンして、その場で過去取引履歴を確認したい」のように業務動線で語ると、本当に必要な機能だけが浮かび上がります。発注前に業務動線シナリオを5〜10本書いておくと、要件定義の質が大きく上がります。シナリオを書くことで、現場の人が普段意識していない業務の流れが言語化され、隠れた要件も拾えます。
数値で測れる成功基準を1つ決める
「業務効率化」のような曖昧なゴールではなく、「月次集計作業を10時間→3時間に短縮」のような数値で測れる成功基準を1つ決めてください。これがあると、稼働後に『成功したか失敗したか』を経営者が判断でき、改修や撤退の意思決定もしやすくなります。複数の成功基準を立てると判断が複雑化するため、最も重要な業務効果を1つに絞るのがコツです。1つの基準で勝てれば、他の改善は段階的に進められます。
後悔を回避する経営者の判断軸：運用設計編
稼働開始は『ゴール』ではなく『スタート』です。中小企業のシステム導入で破棄に至る事例の多くは、稼働後6ヶ月の運用設計が甘いことが原因です。
稼働後6ヶ月の改修予算を初期契約に含める
稼働後6ヶ月以内に必ず改修要望が出ます。1件30〜80万円を都度見積もりで進めると、経営判断が後ろ向きになり、改修が止まります。最初の契約に『月10時間の改修保守』のような枠を含めることで、改修判断のハードルが下がります。総額で50〜100万円の追加ですが、システム破棄を防げる費用対効果は十分です。
現場のフィードバック窓口を稼働初日から用意する
Slackや専用フォームで構わないので、現場が『困った』と声を上げられる窓口を稼働初日から用意してください。声を上げた人が2週間以内に何らかの改善を体感できる回転速度が、システムが使われ続ける条件です。
撤退基準も最初に決めておく
稼働後3ヶ月で稼働率が30%を切ったら撤退検討、6ヶ月で50%を切ったら撤退決断、のような数値基準を最初に決めてください。基準なしで運用すると、「もう少し様子を見よう」が2年続き、結果として500万円が無駄になります。撤退判断も経営の責任です。判断材料を項目別に整理できれば、感情論ではなく数値で意思決定ができます。撤退基準を最初に決めておくと、現場側も『改善する時間にはタイムリミットがある』と理解し、フィードバックが具体化する副次効果もあります。
経営者目線で考える『後悔しないシステム導入』の本質
A社の社長が後日談で語った言葉が印象的でした。「次にシステムを入れるとしたら、自分が判断軸を持って臨む。技術は分からないままでいいから、判断軸だけは持つ」。これは中小企業のシステム導入における本質を突いています。
経営者に必要なのは技術知識ではなく『判断軸』です。ベンダー選定の判断軸、要件定義の判断軸、運用設計の判断軸——この3つを持っていれば、技術が分からなくてもプロジェクトをコントロールできます。逆に判断軸がなければ、どれだけ優秀なベンダーに発注しても、プロジェクトはベンダーの都合で進み、経営の意図とずれていきます。
500万円のシステム破棄は、ベンダーのスキル不足ではなく経営者の判断軸不足が本質です。これを認められると、次のシステム導入で同じ轍を踏まずに済みます。
ぷらすわんの実例：判断軸のある発注がもたらすコスト圧縮
ぷらすわんが日々接している中小企業の経営者の中には、最初の1〜2回でシステム導入を後悔し、3回目で判断軸を持って臨むことで成功するケースがあります。ある製造業B社の経営者は、過去2回の失敗で合計1500万円を浪費した後、3回目の発注では『作らない機能リスト』を発注前に完成させ、改修保守枠も契約に含め、結果として400万円規模で実用システムを稼働させました。
このB社の経営者が言っていたのは「失敗の経験は授業料だった。でも授業料は1回で済むほうがいい」という言葉です。最初の発注の段階で、経営者が判断軸を持って臨むこと、必要なら外部の目線を入れて判断軸を整えてから発注すること——これが授業料を節約する近道です。手元の発注計画について判断軸を診断する場合、3段階それぞれで整理した形で進められます。
まとめ
システム導入で後悔する経営者の事例を分解すると、後悔の発生源は『発注先選定』『要件定義』『運用設計』の3段階に集約されます。500万円のシステムを2年で破棄したA社の本質は、ベンダーのスキル不足ではなく、経営者が判断を委ねすぎたことでした。
中小企業の経営者がシステム導入で後悔しないためには、技術知識ではなく『判断軸』を持つことが本質です。ベンダー選定では実開発担当者との距離を、要件定義では『作らない機能』の決定を、運用設計では稼働後6ヶ月の改修予算化を——この3つの判断軸を発注前に持って臨めば、500万円規模の浪費は構造的に避けられます。後悔の構造を理解した上で、次の一手を比較を依頼する流れで複数視点を入れることをお勧めします。