建設DXが3回失敗する理由と、現場が動いた脱出策
「高いシステムを導入したのに、現場では誰も使っていない」。ある中堅建設会社の経営者からそう打ち明けられたのは、導入から8ヶ月が経った頃の話です。日報アプリへの入力が面倒になり、気づけば職人は全員LINEと電話に戻っていました。この出来事が示しているのは、ツールの善し悪しではなく、DX推進に潜む構造的な問題です。
「入力してください」と言った瞬間に失敗する
市場に流通している施工管理アプリの多くは、「現場監督がスマホでデータを入力する」ことを前提として設計されています。しかし雨風にさらされた現場で、常に動き回りながら小さな画面を操作するのは、想像以上のストレスです。ベテランの職人ほど、その違和感は強くなります。
問題の核心は、DXが「新しい入力作業」を現場に押し付けてしまっている点にあります。デジタル化の本来の目的は「楽になること」のはずです。「入力そのものを減らす、あるいはなくす」という発想がなければ、どれだけ高機能なシステムでも現場には根付きません。AIによる音声入力や、写真を撮るだけで情報を取得できる画像解析は、その文脈で初めて意味を持ちます。
ある塗装会社では、音声での日報入力を試験的に導入したところ、入力時間が一人あたり1日15分から3分に短縮されました。それだけの変化がなければ、現場のルーティンは変わりません。小さな摩擦を丁寧に取り除く設計が、使われるシステムとそうでないシステムを分ける最初の分岐点です。
パッケージソフトが会社の強みを削る理由
市販のパッケージソフトは、あらゆる会社に対応するために「最大公約数」の機能で作られています。それ自体は合理的な設計ですが、裏を返せば「その会社にしかない強み」には対応できないということでもあります。
「この帳票のレイアウトにこだわりがある」「積算の掛け率計算に独自のルールがある」「下請けとの連絡フローが他社と少し違う」。そうした細部の積み重ねが、実は利益の源泉になっていることは珍しくありません。パッケージソフトを入れると、業務をシステムに合わせなければならなくなり、その独自性が失われていきます。
- 初期費用を抑えやすく、導入スピードが速い
- サポート体制やアップデートが整っている
- 業界標準の帳票・フローに沿っている
- 自社独自の計算ロジックや帳票に対応できないことが多い
- 不要な機能が多く、画面が複雑になりやすい
- 業務フローをシステム側に合わせることで現場が混乱する
特に注意したいのが「カスタマイズ対応」を謳うパッケージです。追加費用を払えば独自対応できると聞いて契約したものの、実際には制約が多く、結果的に「使いにくいまま運用を続ける」状況になっているケースを何度も見てきました。導入前に「どこまでが標準機能で、どこからが有償カスタマイズか」を書面で確認することが最低限の自衛策です。
ITベンダーが建設業を知らないという根本問題
システム開発の担当者が、コンクリートの打設手順を知っているとは限りません。職人の気質や、元請けと下請けの間に流れる暗黙のコミュニケーションルールを理解しているとも限りません。そうした現場の文脈を知らないまま作られたシステムは、「理論上は正しいが、現場では絶対に使えない」仕様になりがちです。
「現場を知らない人間が作った道具を、プロの職人が使いたがるはずがない」
これは、ある現場監督が私に言った言葉です。10年選手の職人が、導入3日で使用をやめたシステムの話をしながら、そう呟いていました。ITの知識と建設の知識が同時に揃っていない限り、使われるシステムを設計することは難しいのです。
この問題を回避するには、発注側が「建設の言葉」でベンダーと対話できるか、あるいはベンダー自身が建設業の経験を持っているか、どちらかが必要になります。技術的なスペックだけで開発会社を選ぶのは、費用の無駄に直結する危うい選択です。
現場が動いた脱出策に共通する3つの条件
SUMITSUBO AIの代表は、大林組をはじめとする建設現場で18年のキャリアを持ちます。その経験から見えてきたのは、DXが実際に現場に根付いた事例には明確な共通点があるという事実です。
- 入力の手間が導入前より明らかに減っている(体感で半分以下)
- 自社の独自フローや帳票をそのまま維持できている
- 初期から現場担当者がテストに参加し、フィードバックが反映されている
特に3点目は見落とされがちです。経営者だけが意思決定してシステムを押し込むと、現場には「上から降ってきたもの」という認識が生まれます。現場の人間が「自分たちのために作られた道具」と感じられるかどうかが、定着率を大きく左右します。これは技術の問題ではなく、プロセスの設計の問題です。
「システムに人を合わせる」のではなく、「人にシステムを合わせる」。この原則を外さなければ、DXは必ず動き始めます。まず自社の現場で「どこに一番時間と手間がかかっているか」を書き出すことが、その第一歩になります。
失敗パターンを知れば、選択肢は絞られる
建設DXが失敗する理由は、ツールの性能の問題だけではありません。「入力の押し付け」「独自フローの破壊」「建設知識の欠如」という3つの構造的な問題が重なっています。それぞれを整理して見えてくるのは、パッケージか独自開発かという二択よりも先に、「誰が、誰のために、どんなプロセスで作るか」という問いに答えることが重要だということです。
導入費用の大小ではなく、現場の声がシステムに反映されているかどうか。その一点で、投資の成否はほぼ決まります。失敗した経験がある会社ほど、次の導入では「運用定着まで伴走してくれるか」をベンダー選定の最優先条件にしています。その問いを持つことが、同じ轍を踏まないための最も確実な方法です。