500万円のシステムが使われない。建設DX失敗の本質は「機能の多すぎ」だった
「これで現場の全てが見えるようになりますよ」。大手ベンダーの営業担当者の言葉を信じ、500万円をかけて導入した統合管理システム。しかし半年後に現場を訪ねると、職人は誰もタブレットを持っていない。事務所の隅で埃を被ったまま、日報は今日もLINEと紙で回っている。笑い話のようで、これが建設DXに取り組んだ企業の半数以上が経験する失敗の典型だ、というところに、この問題の核心がある。
高機能なシステムほど現場で使われない理由
なぜ高額なシステムが現場に根付かないのか。答えはシンプルで、「現場の仕事の邪魔になるから」に尽きる。システム開発会社は「機能が多いほど価値が高い」という論理で動く。あれもこれも詰め込んだ結果、画面にはメニューが20個以上並ぶ。日報を送りたいだけなのに、どこを押せばいいかが分からない。
現場の職人が置かれた状況を想像してほしい。軍手をした指で小さなボタンを押す。老眼のベテランには、スマホの細かい文字は読めない。アプリを開くたびにIDとパスワードの入力を求められる。作業の手を止め、マニュアルを確認する時間などない。こうした積み重ねが「使わない」という選択につながる。
経営者の側から見ると、「職人がITに不慣れだから」という結論に落ち着きがちだ。しかし実態は逆で、システムの設計が現場の実態から乖離しているだけのことが多い。使われないシステムの責任は、使う側にではなく、作った側にある。
- メニューが多すぎて、目的の操作にたどり着けない
- 文字とボタンが小さく、屋外や軍手では操作できない
- 毎回のログインが手間で、急ぎの場面では紙に戻る
「大は小を兼ねない」という設計思想
汎用の統合管理システムを導入するとき、多くの企業は「自社の業務フローをシステムに合わせる」という本末転倒な作業を強いられる。システムに合わせるための入力作業が発生し、現場に余計な仕事が増える。これでは生産性が上がるどころか、下がる一方だ。
重要なのは、機能の数ではなく、使われるかどうかという一点だ。「日報ならば日報だけ」「写真ならば写真だけ」という絞り込みが、現場への定着を決める。余計なメニューを排除し、画面に大きなボタンが一つあって、押せば完了する。この単純さが、現場浸透率を左右する。
ここで一つ、落とし穴を指摘しておきたい。「シンプルなシステム」と「安価なシステム」を混同する経営者が多い。機能を絞り込む設計は、むしろ丁寧なヒアリングと試作を繰り返すため、開発コストが低いわけではない。安さを優先して「なんでもできます」という製品を選ぶと、結局また使われないシステムを抱えることになる。
スモールスタートが「使われるDX」への近道
いきなり500万円の統合管理システムを入れる必要はない。まず「一番困っている作業を一つだけアプリ化する」ことから始める方が、長期的に見てコストも手戻りも少ない。現場が「これなら便利だ」と体感する成功体験を積み重ねることが、DX定着の本当の入り口だ。
例えば、毎日の日報提出に30分かかっているならば、日報の送信だけに特化したアプリを50万円前後で作る。写真の整理に時間を取られているならば、現場写真の撮影・分類だけをワンタップでできる仕組みにする。一つの改善が現場に受け入れられれば、次のステップへの合意も格段に取りやすくなる。
- 「一番困っている作業」を一つ選んでアプリ化する
- 職人に実際に触ってもらい、不満を潰してから本格運用に移る
- 成功体験を社内で共有してから、次の機能拡張を検討する
ここで一つ例外を挙げる。業務の種類によっては、最初から複数機能を連携させなければ意味をなさないケースもある。工程管理と原価管理は、切り離すと二重入力が発生してかえって手間が増えることがある。「何でも分けて始めれば良い」ではなく、業務の連鎖を事前に整理した上でスコープを決めることが前提だ。
「現場の声」を設計に組み込む仕組みが決め手
使われるシステムと使われないシステムを分ける最後の要因は、開発プロセスに現場が関与しているかどうかだ。経営者や管理部門の要望だけをヒアリングして作ったシステムは、実際の操作者である職人の動線と合わないことが多い。設計段階で実際に使う職人に触ってもらい、「ここが分からない」「この順番が違う」という声を全て拾ってから完成させる。この工程を省くと、どれほど機能を絞り込んでも定着しない。
職人がITを使えないのではなく、職人が使えないシステムを作ってしまっているだけだ。この認識の転換が、建設DXを失敗から救う最初の一歩になる。高機能な統合管理システムへの投資を検討している経営者ほど、まず「現場が今日どんな手順で仕事をしているか」を観察するところから始めてほしい。
- 現場への定着が早く、研修コストがほぼゼロになる
- 入力ミスと離脱が少なく、データの信頼性が上がる
- スコープが小さいため、開発期間と修正コストが読みやすい
- 業務拡張時に追加開発費が発生する場合がある
- 汎用パッケージと異なり、ベンダー依存度が高まりやすい
- 業務の連鎖を事前に整理しないと、二重入力が残るリスクがある
まとめ：「機能を足す」より「使われる設計」を選ぶ
建設DXが失敗する最大の理由は、機能の多さではなく、現場の実態から設計が乖離していることだ。汎用の統合システムに業務を合わせようとすれば、現場に余計な仕事が増えるだけで終わる。逆に、一つの作業に絞り込んだ設計から始め、職人の声で磨き上げれば、500万円のシステムが達成できなかった定着を50万円で実現できる場合もある。
今使っているシステムが現場で「使われているか」を、今週確認してみてほしい。タブレットが事務所の引き出しに入っていたなら、問題は職人ではなく設計にある。その気づきが、次の投資判断の出発点になる。