建設DXが現場で死ぬ理由。元大林組監督と松尾研エンジニアが組んでわかったこと
「高い金を払って入れたシステムが、誰も使っていない」という話を、建設会社の経営者から聞いたのは一度や二度ではありません。導入直後は研修も実施した。マニュアルも作った。それでも現場には定着しなかった。この失敗が繰り返される理由は、じつは道具の良し悪しではなく、開発側と使用側の間にある「現場感覚のズレ」にあります。
なぜ建設DXは現場で死ぬのか
システムが使われなくなる瞬間は、たいてい最初の数日で決まります。手袋をしたまま操作できないボタン配置、4Gが届かない現場でタイムアウトする入力画面、昼休みの10分で覚えられないほど多い機能。どれも、IT企業のオフィスで設計された画面には起きないことが、泥と粉塵と時間的プレッシャーの中では頻発します。
現場監督として18年間、大林組の建設現場に立ってきた代表の軽部は、こうした「使えないツール」への怒りを誰よりも肌で知っています。「現場で1秒でも迷うUIなら、リリースさせない」というのが口癖です。逆に言えば、その感覚を持たない開発者が作ったシステムは、どれほど機能が豊富でも現場では死にます。
建設DXの失敗を構造的に整理すると、原因はほぼ二つに集約されます。「現場を知らないIT屋が作る」か、「技術を知らないコンサルが絵を描く」か。どちらも悪意はありません。ただ、経験していないことを想像だけで補うには限界があります。
開発会議での「喧嘩」が品質をつくる
SUMITSUBO AIの開発会議は、通常のシステム会社とは少し様子が違います。松尾研究室出身のエンジニアが「最新のモデルでこんな機能が実装できます」と提案すると、軽部が「現場の手袋をしていたら、そのボタンは押せない」と即座に返します。議論は毎回白熱します。
逆のパターンもあります。軽部が「工程の抜け漏れを自動で検知したい」と言えば、エンジニアが「今のLLM(大規模言語モデル)をRAGと組み合わせれば実現可能です」と技術的な解を出します。「現場のリアリティ」と「アカデミックな技術力」の衝突が、中途半端な妥協を生まない理由です。
この構造は、一見非効率に見えます。合議ではなく衝突に近いやり取りが続くため、開発スピードが落ちる局面もあります。ただ、その摩擦の中でしか生まれない仕様があります。「現場で本当に使えるか」という問いを、開発プロセスの中心に置き続けることができるのは、現場経験者が社内に実在しているからこそです。
- 代表・軽部 治の経歴
- 元大林組現場監督。18年間、建設現場の最前線に立ち続けた。
- 開発チームの出自
- 東京大学・松尾研究室出身のエンジニアで構成。世界最先端の論文レベルのアルゴリズムを実装する。
- 開発方針
- 現場側のダメ出しを経ずにリリースしない。UIの操作性は実際の作業環境で検証する。
「現場で動くAI」に必要な3つの条件
これまでの開発と運用を振り返ると、建設現場で定着するシステムには共通する条件があります。技術的な高度さよりも先に、この3点を満たしているかどうかが定着率を左右します。
- 操作が「片手・手袋あり・立ちながら」でも完結する設計になっている
- オフライン環境や低速回線でも最低限の機能が動作する
- 使い始めに必要な入力項目が5つ以内に絞られている
これを見て「当たり前では」と思う方もいるかもしれません。ところが実際の建設DX製品の多くは、これらを満たしていません。デスクトップでは快適に動くが屋外の強い日差しで画面が見えない、設定項目が多すぎて初期セットアップだけで半日かかる、といった問題が現場でよく報告されます。
一つ、使い分けの落とし穴を挙げておきます。AIの精度が高いシステムほど、サーバーとの通信量が増える傾向があります。精度を取るか、オフライン耐性を取るか。この選択は現場の通信環境によって正解が異なるため、導入前に「現場の電波状況を測定してから仕様を決める」というプロセスが欠かせません。この工程を省くと、高性能なシステムがただの重いアプリになります。
技術力だけでも、現場知識だけでも足りない理由
建設DXの文脈でよく耳にする失敗パターンは二種類あります。一つは、IT企業が建設業界に参入し、現場の感覚を持たないまま機能を積み上げた結果、誰も使わないシステムができあがるケース。もう一つは、建設会社が自社でシステムを内製しようとしたが、技術的な深みが出せず途中で頓挫するケースです。
- 「現場では使えない」という仕様の誤りを、リリース前に潰せる
- 技術的な制約を知っているため、実現不可能な要求を早期に整理できる
- 現場の言語でヒアリングし、技術の言語で設計するため、翻訳コストがかからない
- 双方の専門家が社内にいると、意見の衝突が増え開発サイクルが延びることがある
- 現場経験者とエンジニアでは給与水準や働き方が異なり、採用・組織設計が複雑になる
これはSUMITSUBO AIに限った話ではなく、建設DXに取り組む企業全般に当てはまります。内製化を目指すならば、現場経験者とエンジニアの両方を同じプロジェクトに置く体制が必要です。外注するならば、発注先に「現場の言語で話せる担当者がいるか」を確認することが、失敗を避ける第一歩になります。
「ITアレルギーがある現場には入れられない」と言う経営者は多い。しかし実際に話を聞くと、アレルギーの原因は技術への拒否感ではなく、「使えないものを使わされた過去の経験」であることがほとんどだ。
本物のDXは、パートナー選びから始まる
システムの失敗を「現場のITリテラシーが低いせい」と片付ける経営者を、私はこれまで何人も見てきました。しかし多くの場合、問題は使う側ではなく、作る側と使う側の間にある溝にあります。その溝を埋めるのは研修でも強制でもなく、最初から溝が生まれない設計をすることです。
DXを検討している建設会社の経営者に、まず問いかけたいのはこの一点です。相談相手に、現場で働いた経験がありますか。「技術的には可能です」という言葉と、「現場でも動きます」という言葉は、まったく別の重みを持っています。この違いを理解しているパートナーと進めるか否かが、DXの成否を分ける最初の分岐点です。