工事管理システムの失敗は、現場に定着しない、費用が膨らむ、要件が漏れるといった形で起きがちです。進め方を誤ると、多額の投資が無駄になり、現場の混乱やベテランの離職を招く場合もあります。先人のつまずきを知ることは、導入企業にとって何よりの保険です。現場と目的を共有し、段階的に導入すると防ぎやすくなります。
定着、コスト、要件定義、法的責任、データ移行・運用の5つに分けて、回避策とあわせて示します。全体像は工事管理システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・工事管理システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
現場を無視した導入で起きる定着失敗
工事管理システムでは、導入後に現場で使われなくなる失敗が多く見られます。約7割が効果を実感できない背景にも、多くの場合、この定着の失敗があります。だからこそ、典型例を知ることが回避の第一歩です。
トップダウンの曖昧な目的が招く失敗
「DXが流行っている」「他社が導入した」という曖昧な目的での導入は、定着失敗の原因になります。
高機能なシステムでも、現場が導入目的に納得できなければ、日々の手間を増やす邪魔者と受け止められてしまいます。
- 目的を絞る：導入目的は一つか二つまで。
- 現場を巻き込む：現場の代表者に、早い段階から加わってもらう。
- 納得を得る：現場の言葉に置き換えて、目的を共有する。
導入の担当者は、「残業を減らす」「写真整理の手間をなくす」のように、現場が自分のこととして考えられる目的に言い換えます。
業務の流れを理解しないままデジタル化を号令すると、現場の反発を招きます。
現場の納得を積み上げるボトムアップの進め方が、定着を支えます。
多機能すぎて現場が混乱する失敗
もう一つの定着失敗は、機能が多すぎて現場が使いこなせないことです。
建設業では作業員の高齢化が進み、ITリテラシーにも差があるため、機能の豊富さがそのまま現場の利益になるとは限りません。
機能を一度に渡されると、操作に迷って混乱し、従来の紙やFAXに戻ることがあります。
- 小さく始める：写真管理や日報など、少ない機能から導入する。
- 段階的に広げる：現場が慣れてから、工程管理や原価管理へ進める。
- 業務を標準化する：現場ごとに違うやり方をそろえておく。
業務の標準化（AX）を先に行うと、システムをシンプルに保てます。全機能を一度に使わせないという判断が、定着を左右します。
操作の分かりやすさも欠かせません。スマホやタブレットで直感的に操作でき、高齢の作業員も迷わず使えるサービスを選ぶ必要があります。
価格・過剰カスタマイズに起因するコストの失敗
コスト面では、安さを優先して二重に費用を払う失敗と、作り込みすぎて費用が高止まりする失敗があります。
二つの失敗は正反対に見えますが、どちらも適正な投資水準を見極められなかった結果です。
格安サービスで二重コストを払った失敗
象徴的な失敗が、価格の安さでサービスを選んだB工務店の事例です。
初期費用と月額は安かったものの、問い合わせへの返信に3日かかるなど、支援が不十分でした。
その結果、使い方が分からない現場で利用が止まり、1年も経たないうちに別サービスへ乗り換えました。さらに、最初の導入費用と移行費用が二重にかかり、安さを求めた結果、割高になりました。
- サポート体制：電話やチャットで相談できるか。
- 対応の速さ：問い合わせへの返信がどのくらい早いか。
- 導入支援：オンボーディング支援の有無。
工事管理システムの実質コストは、現場に定着するかどうかで決まります。月額の安さだけでは測れません。
ITに不慣れな現場は、つまずいたときにすぐ支援がないと利用が止まります。
伴走支援は、乗り換えの二重コストを防ぐ助けになります。
過剰カスタマイズで費用が高止まりする失敗
「うちのやり方は特殊だから」と現状の業務をすべてシステムに合わせ込むと、過剰なカスタマイズで費用が膨らみます。また、カスタマイズは初期費用を押し上げ、バージョンアップも難しくします。
改修のたびに特定ベンダーへ高額な費用を払うことになり、ベンダーロックインにもつながります。
保守費用は一般に開発費の15〜20%が相場です。たとえば3,000万円のシステムでは、年間450〜600万円が継続してかかります。
- 業務を標準化する：まず業務のやり方を整理する。
- 要件を絞る：標準機能に合わせられる業務を見直す。
- 独自要件に限定する：自社固有で本当に必要な部分だけを開発対象にする。
作り込みが増えるほど、保守のランニングコストも膨らみます。
発注側は、総保有コスト（TCO）で、適正な投資水準を見極める必要があります。
riplaはフルスクラッチ受託を行っていますが、標準で足りる部分はパッケージを活かし、独自要件だけを開発する、費用対効果を重視した設計を勧めています。
要求漏れ・要件凍結をめぐる開発の失敗
自社向けの工事管理システムでは、要件定義の失敗が手戻りやトラブルにつながります。要求の聞き漏らしと際限のない追加要望は、開発プロジェクトが頓挫する典型的な原因です。
要求のヒアリング漏れで使えないシステムになる失敗
要件定義での聞き漏らしは、現場で使えないシステムを生みます。
建設会社が顧客管理（CRM）を開発した例では、現場の要望が漏れていました。
完成したシステムは実務に合わず、最終的に使われなくなりました。
ヒアリングが浅いと、必要な機能や業務との整合が欠けます。
- 関係者全員に聞く：立場の異なる人の要求を、漏れなく集める。
- 業務を洗い出す：現状（AsIs）として一覧にする。
- あるべき姿を描く：ToBeを定めて、要件に反映する。
現場監督や職人、積算、経理、経営層それぞれに、実際の業務フローと困りごとを細かく聞き取ります。
現場の聞き取りを省くと、後から必要な機能が抜けていたと分かる致命的な漏れが起きます。
要件定義は、現場の業務を理解する作業でもあります。
発注側は、ベンダー任せにせず、主体性を持って自社の業務情報を正確に伝える必要があります。
仕様凍結後の追加要望で炎上する失敗
要件確定後に追加要望を重ねると、開発が炎上することがあります。進行後の機能追加や仕様変更は、遅延や費用増につながります。
最悪の場合、開発は頓挫します。そして裁判例には、仕様凍結後に大量の追加要望を出した発注者側が敗訴したケースもあります。
- 確定手続きを設ける：発注側の責任者が、要件定義書を承認する。
- 変更を管理する：費用と日程への影響を合意してから取り込む。
要件凍結の時期と変更管理のルールは、契約で明確にしておきます。変更管理は、チェンジコントロールとも呼ばれます。
規律ある変更管理は、際限のない追加開発を防ぎます。要件凍結は、双方が安心して開発を完遂するための約束です。
要求漏れは丁寧なヒアリングで防ぎ、要件凍結後は規律ある変更管理で追加要望を抑えます。
開発頓挫時に発注側が問われる法的リスク
発注側が見落としやすく重大なリスクは、開発頓挫時の法的責任です。発注したからといって、失敗の責任がすべてベンダーにあるとは限りません。大型案件の頓挫事例や判例を見ると、その責任の重さが分かります。
大型システム開発が頓挫した巨額損失の教訓
大型システム開発の失敗は、数十億〜数千億円規模の損失を生むことがあります。江崎グリコは、デロイト、SAPと組んで基幹システムを刷新しましたが、1年3ヶ月遅延しました。当初予算から215億円増え、最終的には342億円となりました。
出荷遅延、一部商品の販売中止、生産停止も発生し、事業に深刻な影響が出ました。また、日本通運とアクセンチュアの開発では、124億円の損害賠償が請求されました。
海外では、Kmartが約14億ドル（約2000億円）を投じたITプロジェクトが、18ヶ月でほぼ全損となった例もあります。
- 規模を抑えて始める：効果を確かめながら、段階的に広げる。
- 要件を絞る：業務との不整合や過剰な要件を避ける。
- 無理な日程を避ける：スケジュールを現実的に組む。
これらは工事管理システムより大規模ですが、業務との不整合、過剰要件、無理な日程が頓挫を招く点は共通します。
共通する原因は、技術力の不足ではなく、要件の肥大化とマネジメントの破綻です。また、事例は身の丈を超えた一気の投資の危険も示しています。
グリコの事例では、既存業務の複雑さをすべて作り込んだ結果、開発が膨張しました。本番稼働後も、出荷は安定しませんでした。
工事管理システムでも、業務をすべて作り込めば、費用が増え、納期が延び、品質が不安定になることがあります。
失敗の原因は規模だけではなく、業務の標準化を怠って要件を膨らませる進め方にもあります。そのため、まず業務を標準化し、本当に必要な要件に絞ることが、規模を問わず損失リスクを下げます。
協力義務違反で発注側が敗訴した判例
旭川医科大学病院とNTT東日本の開発をめぐる裁判では、発注側の法的責任が認められました。
具体的には、控訴審の札幌高裁が、平成29年8月31日の判決でユーザー側の協力義務違反を認定しました。
当初の要件169項目のうち124項目が開発対象外となり、ユーザー側だけに約14億1500万円の支払いが命じられました。
- 要件を適時に確定する：発注側の判断を遅らせないようにする。
- 情報を提供する：必要な業務情報をベンダーへ伝える。
- 役割を明文化する：契約で、双方の責任を定めておく。
発注者には、要件を確定し、情報を提供し、決定を遅らせない協力義務があります。怠ると、開発頓挫の責任を問われることになります。
発注側は社内の意思決定と情報提供の体制を整え、ベンダーから確認を求められたら速やかに応じる必要があります。
この判例は、「発注したのだから責任はベンダーにある」という常識が法廷では通用しないことを示しています。
riplaは、契約や要件管理も含めて支援します。さらに、フルスクラッチ受託と国内開発の立場から、現場ヒアリングから段階的な定着まで一貫して伴走します。
データ移行・運用フェーズで起きる失敗
開発や導入が終わった後でも、データ移行や運用開始でつまずくと、システムが台無しになることがあります。移行と運用は、導入後に残る失敗リスクを左右する最後の関門です。
クレンジングを怠り「ゴミデータ」を移行する失敗
この失敗を避けるには、移行前にデータクレンジング（清掃）を計画的に行う必要があります。
旧システムや表計算ソフトの協力会社マスタ、単価マスタ、過去の工事データには、重複や表記揺れが含まれます。すでに取引のない古い情報もあります。精査しないまま移すと、検索や集計が信頼できず、現場が混乱します。
- 移行範囲を決める：どのデータを移すかを明確にする。
- データを整える：重複を統合し、表記をそろえる。
- 不要情報を除く：取引のない古いデータを削除する。
クレンジングは地味で泥臭く、相応の工数がかかります。ただし、省くと新システムの価値が根本から損なわれます。
移行を担う担当者と時期を決め、移行スケジュールに組み込みます。また、移行費とクレンジング工数は、見積もりで漏れやすい隠れコストです。
要件定義の段階から作業を計画に明記しておくと、きれいなデータで稼働を始められ、運用の混乱を防げます。
二重管理が残り効果が出ない運用の失敗
運用効果を損なう失敗の一つが、従来の紙台帳や表計算ソフトとの二重管理です。
システムと旧来の方法を併用すると、入力の手間が二倍になり、現場の負担が増えます。
「念のため紙でも残す」という心理で二重管理が続くと、省力化できません。そのうえ、現場が「面倒だから」と使わなくなり、定着失敗につながります。
- 運用ルールを決める：システムへ一本化する日を定める。
- 旧来の方法を廃止する：移行期間の後、紙や表計算をやめる。
- 支援体制を整える：問い合わせ対応や操作研修を用意する。
経営層が一本化の方針を示し、全社で徹底します。
あわせて、現場がすぐ支援を得られる体制も必要です。
二重管理を廃止すれば、入力が一回で済み、データが一元化されます。
導入は、作って終わりではなく、使われて初めて成功です。
riplaは、構築に加えて、データ移行・クレンジング、二重管理廃止を含む運用設計、稼働後のサポートまで伴走します。
まとめ
失敗は、定着、コスト、開発、法的リスクに分かれます。なかでも、曖昧な目的や多機能すぎる導入では、約7割が効果を実感できない定着失敗が起きています。
格安サービスの乗り換えは二重コストを招き、過剰カスタマイズは費用を押し上げます。また、保守費用は開発費の15〜20%が相場です。
開発では、要求のヒアリング漏れや仕様凍結後の追加要望が失敗を招きます。法的リスクには、発注側の協力義務違反もあります。
グリコ342億円、日通124億円、旭川医大14.1億円判決は、法的リスクを示す事例です。共通の引き金は、現場理解の不足と一気の投資です。
発注側は、現場へのヒアリング、業務標準化、段階導入、要件凍結と協力義務の明文化を組み合わせて備えます。
効果を確かめながら広げる進め方は、巨額損失や定着失敗のリスクを抑えます。なお、riplaは要件整理と段階導入を支援します。
全体像の確認には、工事管理システムの完全ガイドをご活用ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。