積算システム開発/導入の失敗/課題/注意点/リスクについて

積算システム導入の失敗は、現場や目的を置き去りにすること、安さで選んで支援が不足すること、データ整備の軽視、要件の膨張に分けられます。防ぎ方は、それぞれ現場・目的、支援やデータ、要件膨張への備えで変わります。

共通構造を知ることは、再発を避けるうえで役立ちます。失敗事例を研究することは、投資する企業にとって保険の役割を果たします。全体像は積算システムの完全ガイドもご覧ください。

▼全体ガイドの記事
・積算システムの完全ガイド

現場無視・目的不在で頓挫する失敗

目的が曖昧な高機能導入と、現場の業務を理解して機能を絞る考え方を左右に比べた図。
機能の多さと現場で使われることは別の観点です。

積算システム導入でよく見られる失敗は、現場の業務を理解しないまま、目的が曖昧なまま導入することです。トップダウンで「DXが流行りだから」と高機能なシステムを入れても、現場の実態に合わなければ使われず、形骸化します。さらに、この失敗は積算に限らず、製造・物流・建設のシステム導入でも繰り返されてきた典型的なパターンです。

曖昧な目的での高機能導入と現場の反発

「とりあえず効率化のために」と多機能な積算システムを入れると、操作の習得が負担になり、現場が慣れたExcelに戻ることがあります。

業界調査では、工事管理アプリを導入した企業の約7割が十分な効果を実感できていません。このデータは、目的を明確にせず現場に寄り添わないと、システムが根づかないことを示しています。導入の出発点は、見積作成時間の短縮か、属人化の解消かといった目的を一点に絞ることです。

  • 目的を定める:必要な機能と、効果の測り方の明確化。
  • 機能を絞る:「あれもこれも」と盛り込まず、目的に合う機能に限る。

現場で使われるかどうかは、高機能であるかどうかとは別の問題です。目的に合う機能を選び、導入後に効果を確認できる状態にしておくことが大切です。

ベンダー丸投げとToBe不在で巨額を無駄にする失敗

他業界では、業務の姿を描かないまま1億円を投じたシステムが、2年間使われずに廃止された例もあります。

積算は、長年の慣行や工種ごとの取り決めが積み重なってできています。だからこそ、現場が日々どう積算し、何に困っているかを把握しないまま理想論で設計すると、従来のやり方に戻り、高価なシステムが使われなくなります。

失敗の本質は、現場の業務や困りごとを起点にしないことです。技術力や予算よりも、この点が問題になります。また、発注側が主体となって要件を考え、ベンダーと対話する姿勢が欠かせません。

  • 業務を可視化する:要件定義の前の現場調査と、ToBeの作成。
  • 現場適合を重視する:成否は投資額より、業務への寄り添い方で決まる。

発注側が内容を理解しないまま完成を迎えると、意図と違う成果物であっても差を判断できません。その影響は、後の改善や運用にも及びます。

ポイント

導入目的を一点に絞れているか、現場の業務を理解したうえで機能を選んでいるかを導入前に確かめることが、判断の目安になります。

安さ優先・サポート不足による定着失敗

「とにかく安く」という基準だけで選ぶと、サポート不足で定着せず、乗り換えで結局高くつくことがあります。積算システムは導入後の運用支援も品質を左右するため、安さの背景にある支援体制を確かめておく必要があります。

格安アプリのサポート遅延で二重コストになった失敗

ある工務店は、価格の安さだけで格安アプリを選びました。ところが導入後は、トラブルや不明点への返信に3日かかるなど、サポートが追いつかず、現場が立ち往生しました。

導入から1年未満で別システムへ乗り換え、初期費用と移行費用に加えて、混乱した期間の損失も負担しました。その結果、二重・三重のコストが発生しました。

サポートが薄いと、設定でつまずいた現場が利用をやめ、Excelに戻ることがあります。そのため、選定では価格以外の条件も確認しておくことが大切です。

  • 総額で評価する:初期費用とライセンス費に、支援品質と乗り換えリスクを加えたTCOでの比較。
  • 対応体制を確かめる:障害時の対応時間と、問い合わせへの返答目安。
  • 定着支援を確認する:導入後の伴走支援が、選定の段階で用意されているかどうか。

価格だけで決めないことが、定着失敗を避ける要点です。

現場のITリテラシーを無視した操作性の失敗

建設・リフォーム業界では高齢化が進み、ITに不慣れな担当者も少なくありません。そうした現場では、多機能で複雑なシステムを使いこなせず、混乱することがあります。

操作性の面では、機能が多いことがかえって逆効果になることもあります。迷わず使える画面にならなければ、現場に定着しません。

  • 画面を分かりやすくする:入力項目を絞り、スマホやタブレットでも直感的に操作できる設計。
  • 利用を支援する:導入時の操作教育、マニュアル整備、初期の伴走支援。
  • 複雑化を避ける:過剰なカスタマイズを抑え、画面が込み入るのを防ぐ。

過剰なカスタマイズは、バージョンアップを難しくし、ベンダーロックインを招きます。現場のリテラシーに合う「使えるシンプルさ」こそが、定着失敗を防ぐ現実的な対策です。

要望の盛り込みすぎで複雑化・高止まりする失敗

安さ優先とは逆に、要望を盛り込みすぎて費用が高止まりし、使いこなせなくなる失敗もあります。多機能であることと、現場で使われることは別の問題です。

製造業では、カスタマイズを1件追加するだけで100万〜1,000万円規模になることもあります。要望を無批判に受け入れると、当初予算を大きく超える可能性があります。

  • 必要性で仕分ける:「業務に不可欠か」を基準にした要望の選別。
  • 標準機能や運用を使う:標準的なやり方で不要になる、慣習由来の要望のカスタマイズ見送り。
  • 独自性に投資する:業務のシステム適合と、本当に必要な機能への絞り込み。

線引きができないと、複雑で高価なのに使われないシステムになってしまいます。安さ偏重とは逆方向の失敗ですが、業務と目的を起点にすれば防げます。

ポイント

価格だけでなく、導入後の支援体制や障害時の対応、乗り換えのリスクまで含めて比べると、定着失敗や二重コストを避けやすくなります。

データ移行・マスタ整備を軽視したリスク

データ移行とマスタ整備について、データ整理、移行範囲、工数と担当を確認する3枚のチェックカード。
移行の準備を導入計画の中で順に確認できます。

機能ばかりに目が向いて、土台となるデータの整備を軽視すると、稼働後に使えない問題が起きます。単価マスタや過去見積が整っていなければ、優れたシステムでも実力を発揮できません。さらに、データ移行とマスタ整備の軽視は、目立ちにくい失敗要因です。

クレンジングを怠り「ゴミデータ」を高速処理する失敗

既存の単価表や過去見積をそのまま移すと、重複、表記揺れ、古い単価などの「ゴミデータ」が混ざり込みます。これを放置すると、システムはゴミデータを高速で処理するだけになってしまいます。

間違った単価で見積を作ったり、似た項目が乱立して選びにくくなったりします。誤った見積を高速で量産することは、手作業より危険な場合もあります。

本番運用の前に、データのクレンジング(整理)が必要です。作業の判断には発注側の知識が要る部分が多く、ベンダー任せにはできません。

  • データを整理する:工種コードの統一、廃番材料の除外、現行単価への更新。
  • 移行範囲を絞る:直近の有効な単価と、再利用頻度の高い見積を優先して移す。
  • 工数と担当を決める:移行・整備の工数と日程の見積もり、計画への担当者の記載。

データ整備は、入れて終わりではなく、整えて初めて価値が出るものです。そのため、この作業は導入計画の最初に組み込んでおきます。

クレンジングの工数は過小評価されがちです。重複や表記揺れが多いと、移行を始めてから問題が判明し、本番稼働の直前に慌てることになります。また、計画段階の見通しが甘いと、整備が後回しになり、稼働遅延や誤った単価での見積作成を招きます。

二重管理の放置と運用ルール不在の失敗

導入後もシステムと旧来のExcelを併用したまま、二重管理を放置する失敗があります。移行期の並行運用自体は可能ですが、終了時期を決めないと入力の手間が増え、データも分散します。その結果、どちらも中途半端になり、システムの効果が出ません。

単価マスタの更新担当、見積の承認フロー、入力ルールが決まっていないと、担当者ごとに使い方がばらつきます。こうなると、データの信頼性が下がり、新たな混乱を生みます。

  • 旧運用の終了を決める:誰がいつExcel運用をやめるかという目標の明記。
  • 運用ルールを定める:マスタ更新担当、見積承認フロー、入力ルールの取り決め。
  • 更新を継続する:誰がいつどの単価を見直すかの定めと、運用への組み込み。

資材価格や労務単価は変動します。マスタの更新が止まると、古い単価での見積作成が続き、時間とともに陳腐化します。

システムは、導入後も運用し続けてこそ価値を保てます。運用設計と定着支援を含めて、データを整備し続けることが前提になります。

ポイント

移行するデータの範囲と、マスタの更新担当を導入計画の段階で決められるかどうかが、稼働後に使えるかの分かれ目になります。

要件膨張と協力義務違反の法的リスク

開発の進め方、変更、運用費の3観点を、段階導入、要件の文書化、数年分のTCOのパネルで示した図。
備えを分けて考えると、見落としやすい論点を並べて確認できます。

大規模な積算・基幹システム開発では、要件の膨張や発注側の協力不足が頓挫や訴訟に発展することがあります。中小規模では縁遠く見えても、規模が大きいほど現実味を帯びる、見落とせない注意点です。そこで、過去の判例から学び、要件と発注側の役割に備えることが重要です。

大型システム開発が頓挫した巨額損失の事例

大型システム開発の頓挫は、企業に大きな損失をもたらします。江崎グリコがデロイト、SAPと進めた基幹システム刷新では、遅延と費用膨張が起きました。同案件は、出荷遅延、一部商品の販売中止、生産停止にまで至りました。

  • 江崎グリコ:基幹刷新の遅延は1年3ヶ月、費用は215億円から342億円に増加。
  • 日本通運:アクセンチュアの案件をめぐる124億円の損害賠償請求の報道。
  • 米国のKmart:約14億ドル(約2,000億円)のIT計画が、18ヶ月でほぼ全損。

積算システムがこの規模になることは稀ですが、基幹システムや原価管理まで一体で大規模に作り込む場合は、相応のリスクがあります。

WMS(倉庫管理システム)の導入失敗率は業界全体で60%超とされ、大型システムほど失敗確率が上がります。そのため、一括開発は避けて、効果の出やすい工程から小さく作って広げる進め方が現実的です。規模が大きいほど、段階導入と要件凍結の規律が頓挫リスクを下げます。

協力義務違反で発注側が敗訴した判例の教訓

システム開発の失敗には、発注側の責任が問われる場合もあります。旭川医大病院とNTT東日本の事件では、控訴審(札幌高裁・平成29年8月31日)で発注側の協力義務違反が認定されました。

169項目の追加要望のうち124項目が開発対象外と判断され、ユーザー側だけに約14億1,500万円の支払いが命じられました。

要件確定後に大量の追加要望が出されたことや、仕様凍結に協力しなかったことが、発注側の責任とされました。積算でも、工種や様式を際限なく追加すると、費用と納期が膨らみ、法的に不利になる可能性があります。

  • 要件を固めて文書化する:意思決定者の要件定義への関与と、合意内容の凍結。
  • 変更を正式に管理する:影響範囲と追加費用を見積もったうえでの変更。

riplaは、フルスクラッチ受託と国内開発の立場から、現場の業務の可視化、要件の凍結、データ整備、定着支援まで伴走しています。こうした失敗やリスクを未然に防ぐ進め方を、一貫して重視しています。

失敗事例は、自社の予防策として読むことで大きな備えになります。

初期費用だけで判断し保守費で破綻するリスク

規模を問わず、初期費用だけで予算を組むと、運用段階で破綻するリスクがあります。数年後に資金繰りを圧迫する場合もあります。

  • 保守費:一般に開発費の15〜20%。開発費3,000万円なら年450〜600万円。
  • 隠れコスト:データ移行や教育、稼働後のExcel併用にかかる費用。
  • 追加カスタマイズ:1件100万〜1,000万円規模の費用になることもある。

導入計画では、数年分のTCO(総保有コスト)を見積もり、保守費と運用費を含む予算を確保しておきます。

安い導入費に惹かれて保守やサポートが薄いものを選ぶと、乗り換えで二重コストを払うことになります。格安アプリの失敗と同じ構造です。

費用は導入時の金額だけでなく、使い続けるための総額で評価することが大切です。この視点が、予算面の失敗を防ぐ最後の備えになります。

ポイント

要件を凍結する時期と、変更の影響範囲や追加費用を判断できる体制があるかを、規模の大きい案件ほど早い段階で確かめておく必要があります。

まとめ

失敗事例は、これから投資する企業にとって何よりの教科書です。

積算システム導入では、現場無視や目的不在、安さ優先とサポート不足、データ整備の軽視、要件膨張と協力義務違反が失敗につながります。

工事管理アプリ導入企業の約7割が効果を実感できていないというデータがあります。格安アプリの乗り換えによる二重コストも、定着支援の重要性を示しています。

グリコの342億円、日通の124億円、Kmartの約2,000億円といった頓挫の事例や、旭川医大の約14億円の協力義務違反の判決もあります。

現場と目的を起点にし、要件を凍結し、データを整えて段階的に進めることが重要です。

現場の業務を可視化し、目的を絞り、サポート体制を確認したうえでデータを整備します。要件を固めて凍結する基本が、失敗の確率を下げます。

riplaは、フルスクラッチ受託と国内開発を組み合わせ、これらのリスクを防ぐ進め方を伴走支援しています。費用相場やリスク回避を含む選び方は、完全ガイドでご確認ください。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。