中小企業のシステム導入、最多の失敗は「遅延」ではなく「後出しコスト」――3つの原因は発注側の“空席”に行き着く

1. 調査が示したこと――数字と回答者数

元になっているのは、中小企業のシステム開発・導入の支援を手がけるbtobee（ビートゥビー）が2026年7月31日に公表した自社調査です。調査主体が導入支援の当事者である点は念頭に置いておきたいところです。インターネット調査で、全国の経営者・役員3,000人（うち中小企業2,545人）に事前調査を行い、そのうちITシステムの導入などに関与する立場にある中小企業の経営者・役員300人に本調査を実施しています（事前調査2026年6月26〜28日、本調査7月4日）。

主な結果は次のとおりです。

読むときに押さえておきたいのが回答者数です。同じ調査では、300人のうち社内業務でITシステムを「ほぼ活用していない」と答えた層が53.0%を占め、何らかのシステムを導入している企業は47.0%でした。失敗経験の設問はシステムを導入している企業が対象です。公表値から逆算すると、導入企業は約141人、その53.2%にあたる失敗経験者は約75人で、トラブル内容や原因の割合（40.0%＝30人、34.7%＝26人、33.3%＝25人、29.3%＝22人、24.0%＝18人）もこの人数ときれいに一致します（人数は筆者の推計）。

つまり「40%」と「33%」の差は数人分です。順位を細かく論じるより、予算・品質・納期のどれもが3〜4割の経験者に起きている、そして原因の上位3つがすべて発注側の体制だという大づかみの傾向を読むのが妥当でしょう。また発注したシステムがSaaS（インターネット経由で使う既製のサービス）なのか独自開発なのかで経験は大きく違うはずで、この点は後で触れます。

出典：btobee「【中小企業のDX調査】5割超が経験するシステム導入の「失敗」、想定外のトラブルを引き起こす本当の原因とは？」（2026年7月31日） / キーマンズネット「中小企業のシステム導入、過半数が失敗を経験 トラブルの根本原因はどこにある」（2026年7月31日）

2. なぜ「遅延」は3番目なのか

「遅延が33%は意外に少ない」と感じた人もいるかもしれません。これには少なくとも2つの説明がつきます。

小さいプロジェクトほど遅れにくい

日本情報システム・ユーザー協会（JUAS）は、主に大手・中堅企業のIT部門を対象に、システム開発の工期・品質の達成状況を毎年調べています。2024年度調査（「企業IT動向調査2025」）では、開発規模（人月＝1人が1カ月でこなす作業量で表したもの）別に「予定より遅延」と答えた割合に大きな差があります。

中小企業のシステム導入は、多くがこの表の一番上の規模か、それよりさらに小さい案件です。SaaSの導入なら「開発」自体がほとんどないこともあります。規模が小さいほど遅延が起きにくいのは、関係者が少なく、工程が短く、遅れが出ても挽回しやすいからだと考えられます。ただしJUASでも、100人月未満で「予定どおり完了」は約3割にとどまり、10年間の推移ではすべての規模で「予定どおり完了」の割合が低下傾向にあると指摘されています。小さければ安全、というわけではありません。

中小企業は「期日」を動かさず、お金か機能で調整する

もう一つの説明は、プロジェクト管理でいうコスト・納期・範囲（機能）のトレードオフです。想定外の作業が見つかったとき、発注側が取れる手は「期日を延ばす」「追加でお金を払う」「機能をあきらめる」のどれかしかありません。繁忙期の前に切り替えたい、旧システムの契約が切れる、といった事情で期日が動かせない中小企業では、遅延として表に出る前に、追加費用（予算超過）か機能の削減（品質・機能不足）で吸収されやすいはずです。調査で予算超過と品質不足が遅延より上に来ているのは、この吸収の結果とも読めます（これは筆者の解釈で、調査が因果を示したものではありません）。

海外にも似た傾向があります。McKinseyとオックスフォード大学が5,400件超のITプロジェクトを分析した2012年の研究では、大規模IT案件（当初予算1,500万ドル超）は平均で予算を45%超過する一方、工期の超過は7%にとどまり、得られた価値は想定より56%少なかったと報告されています。規模も国も違いますが、「時間より先にお金と中身が崩れる」という点では、今回の中小企業の結果と同じ傾向を示しています。

出典：JUAS「企業IT動向調査2025（2024年度調査）」概要版（2025年4月10日） / McKinsey「Delivering large-scale IT projects on time, on budget, and on value」（2012年10月）

3. 「後出しコスト」の正体は、決まっていなかった範囲

「後出し」という言葉からは、ベンダーが最初に安く見せて後から上乗せした、という印象を受けます。そうした事例がないとは言えませんが、多くの場合、追加費用は見積もりの前提に入っていなかった作業に対して発生します。「このデータも移行してほしい」「この帳票も今の形のまま出したい」「この例外処理も必要だった」――発注時に決まっていなかった範囲が、進めるうちに見えてくるのです。

このことを裏づけるのが、同じ調査でbtobeeが限定公開している追加データです。btobeeによると、予算超過を経験した割合は、SaaSを中心に使う層で30.8%だったのに対し、独自システムを開発した層では60.9%と約2倍でした（各層の回答者数は公表されておらず、少人数の比較である可能性が高い点に注意が必要です）。SaaSは機能と料金があらかじめ決まっていて、「できないこと」は最初から見えます。独自開発は「何を作るか」を決めながら進むので、決めきれていない部分がそのまま費用の振れ幅になります。

もう一つ気になるのは、同じ調査でパートナー選びの重視点を聞いた設問で、最多が「適正なコスト」33.0%だったことです。「業務内容・課題の深い理解」「導入後のアフターフォロー・定着支援」はいずれも20.3%でした。コストを重視すること自体は当然ですが、前提条件が異なる見積もりを金額だけで比べると、作業範囲を狭く想定したものほど安く見えます。その差額は、後で「追加」として戻ってきやすいお金です。

出典：btobee「【中小企業のDX調査】5割超が経験するシステム導入の「失敗」、想定外のトラブルを引き起こす本当の原因とは？」（2026年7月31日）

4. 3つの原因は、発注側の同じ「空席」を指している

失敗の根本原因の上位は「IT人材の不足」33.3%、「経営と現場の目的共有不足」29.3%、「PM（プロジェクトを統括する人）の不在」24.0%でした。別々の問題に見えますが、並べてみると、いずれも発注側で「何のために、何を、どこまで作るか」を決めて守る人がいないという一つの欠落の、違う側面だと読めます。

• IT人材の不足：ベンダーの提案や見積もりの前提を読み解き、「それは本当に必要か」「その範囲で足りるか」を判断できる人がいない。
• 目的の共有不足：経営は「コスト削減」、現場は「今の作業をそのまま楽にしたい」と考えていると、要件は両方の足し算になり、範囲が膨らむ。
• PMの不在：途中で出てくる追加要望を「今回やる／やらない」と裁く人がいないため、要望がそのまま追加費用や機能の未達になる。

ここで大事なのは、この空席はベンダー側では埋められないということです。ベンダーは作る専門家ですが、自社の業務のどこを変え、どこを残すかを決める権限はありません。情報処理推進機構（IPA）の「ユーザのための要件定義ガイド 第2版」も、ITベンダーやシステム部門が中心になって要件定義を進めるスタイルから、業務部門のユーザーが主体的に関与するスタイルへの転換が必要だとしています。

この悩みは中小企業に限りません。JUASの同じ調査では、大手・中堅企業でもシステム開発の内製化を阻む要因として「開発人材の量の不足」50.8%、「現行業務への理解不足」38.7%、「プロジェクトマネジメント人材の不足」38.3%が挙がっています。IPAの「DX動向2025」では、日本企業の85.1%がDXを推進する人材が不足していると回答しており、この割合は米国・ドイツと比べて著しく高い水準でした。「ITに詳しい人を採用すれば解決する」と考えたくなりますが、採用市場で奪い合いになっている以上、中小企業が現実的に打てる手は、ITの専門家でなくてもよいので、自社側で決める役割の人をはっきり置くことです。

当サイトでは、AIで開発そのものが速くなってもリリースが速くならない理由として、ボトルネックが「作る」から「決める」へ移っていることを別のコラムで取り上げました。中小企業のシステム導入でも、足りていないのは作る力より、決める力のほうだと考えられます。

出典：IPA「ユーザのための要件定義ガイド 第2版」（2019年9月12日） / JUAS「企業IT動向調査2025（2024年度調査）」概要版（2025年4月10日） / IPA「DX動向2025－AI時代のデジタル人材育成」（2025年10月9日）

5. 契約前に決めておく5つのこと

以上を踏まえ、見積もりを取る前、少なくとも契約する前に社内で決めておきたいことを5つに絞りました。調査で挙がった3つの原因や、予算超過・品質不足などの症状のうち、どれに効くかを併記しています。

④と⑤については、IPAが公開している「情報システム・モデル取引・契約書（第二版）」が参考になります。成果物がはっきりしない要件定義の段階は準委任契約（作業に対して支払う契約）で進め、要件が固まってから開発を請負（完成した成果物に対して支払う契約）で発注するといった多段階契約の考え方が示されており、途中で仕様が変わったときの影響を小さくできます。そのまま使うにはやや重い書式ですが、「どの段階で何が決まっていれば、次の見積もりが確定するのか」を整理する材料として読む価値があります。

なお、予備費の水準や責任者に割く時間は、案件の規模や業務の複雑さによって変わるため、この記事では一律の目安を示していません。大事なのは、それを契約後に慌てて決めるのではなく、契約前に社内で決めておくことです。

出典：IPA「情報システム・モデル取引・契約書（第二版）」（2020年12月22日） / IPA「ユーザのための要件定義ガイド 第2版」（2019年9月12日）