「IT屋のアプリ」が現場で嫌われる理由と、元大林組監督が見つけた突破口
ある建設会社の経営者からこんな相談を受けたことがあります。「去年、大手のDXコンサルに頼んでアプリを入れたんですが、3ヶ月で誰も使わなくなりました」。理由を聞くと、「現場の人間が入力するのに、画面の項目が多すぎて、スマホで操作しにくくて」という話でした。費用は数百万円。残ったのは、使われないアプリのライセンス料だけです。この話は、建設DXが抱える構造的な問題をそのまま映し出しています。
「解像度の低さ」が招く現場離れ
建設業界向けのITツールを開発する会社は、ここ数年で急増しました。しかし、そのほとんどが「建設業界向け」という看板だけで、実際には他業種向けのプラットフォームを転用したものです。開発側は現場に足を踏み入れたことがなく、図面の読み方も、元請けと協力会社の関係性も、職人気質の現場文化も理解していない。
私は大林組で現場監督を務め、実家の建設会社（創業70年）で育ちました。建設業の「レイヤー」というものを、制度の話ではなく体感として知っています。元請けが下請けに何を求めているか、職人が何を嫌がるか、現場の朝礼前の空気がどんなものか。これらを知らずに設計されたUIは、現場ではただの「邪魔な操作手順」になります。
解像度の低いシステムは、使われないのではなく、使う気を奪います。それが、建設DXの失敗の大半を占める本当の理由です。
現場で「動くAI」と「動かないAI」の違い
では、現場で実際に使われるシステムには何が必要か。私が東大松尾研究室出身のエンジニアチームと協働する中で気づいたのは、「技術の精度」よりも先に「問いの立て方」が重要だということでした。
松尾研のエンジニアたちは、世界最先端の論文を読み解き実装できる能力を持っています。ただ、彼らが最初に現場の課題を聞いたとき、こんな反応を示しました。「工程管理の『抜け』を検知したいというのは分かります。でも、その『抜け』がどの段階で、誰の責任範囲で起きやすいのか、もう少し具体的に教えてください」。これは正直な問いかけであり、非常に誠実な姿勢でした。
「一般的なAI会社には、建設業界の解像度がありません。元請けと協力会社の関係性、図面の読み方、現場特有の商慣習。これらを知らずに作られたシステムは、現場にとってただの邪魔者です。」
この「問いへの答え」を私が提供し、エンジニアが実装する。この分業こそが、現場で動くシステムを生む構造です。技術力だけでも、現場知識だけでも成立しない。両方が噛み合ったときに初めて、職人が自然に使い続けるツールができます。
- 「なぜそう使うのか」を前提に設計できるため、UIが現場の手順に沿う
- 業界特有の商慣習・商流を踏まえた機能設計が可能
- 職人・若手・管理職それぞれの操作負荷を事前に想定できる
- 現場ごとの慣習の差が大きく、汎用化には丁寧なヒアリングが必要
- 「他社がサジを投げた課題」ほど、要件整理に時間がかかる
「他社がサジを投げた課題」から見えた落とし穴
SUMITSUBO AIが受託開発を進める中で、複数の案件に共通する落とし穴があることが分かってきました。それは「現場の入力担当者が誰か」を最初に決めていない、という問題です。
多くの経営者は「現場管理者がスマホで入力する」と想定してシステムを発注します。しかし実際の現場では、管理者は常に動いており、定時に座ってデータを打ち込む時間がありません。入力が滞ると集計もできない。結果として、事務担当が後から紙の記録を見てまとめて入力するという、「デジタル化しているのに手間が増えた」状態が生まれます。
この落とし穴は、現場を実際に歩いたことがある人間にしか見えません。会議室でヒアリングをしても、「管理者が入力します」という回答は必ず返ってきます。しかし現場を見れば、それが非現実的だとすぐに気づきます。設計の前に、誰がいつどこで操作するかを現場の動線ごとに確認する。この一手間が、導入後の定着率を大きく左右します。
- 実際に入力するのは誰か（管理者・事務・職人のどれか）
- その人物がスマホを操作できる時間帯・場所はどこか
- 紙の運用と並行するフェーズを設けているか
建設DXに「業界経験者の翻訳」が必要な本当の理由
AIエンジニアと現場監督、この二者が直接話すと、最初は会話が噛み合いません。エンジニアは「データの形式と処理フロー」で考え、監督は「段取りと段階確認」で考えます。言葉も違えば、課題の粒度も違う。この溝を埋める役割が、私のような「業界経験者の翻訳者」です。
翻訳者がいないと、エンジニアは「とりあえず要望通りに作った」ものを納品し、現場は「これじゃない」と感じながら渋々使い、3ヶ月後に誰も触らなくなります。冒頭の経営者が経験したのと同じ結末です。翻訳者の存在は、コストではなく保険です。使われないシステムに数百万円を費やすリスクと比べれば、その価値は明らかです。
創業70年の三栄工業のDNAと、東大松尾研のAI技術が融合したのは、この翻訳機能を組織の中に内在させるためでした。「現場のプロが設計し、技術のプロが形にする」という構造を、会社の仕組みとして持っている。それが、外部のDXコンサルや汎用ツールとの、最も本質的な違いです。
経営者が次に取るべき一手
建設DXを検討している経営者が最初にすべきことは、ツールを選ぶことではありません。「自社の現場で、誰が何に困っているか」を言語化することです。この作業なしに導入したシステムは、どれだけ高性能でも現場に馴染みません。
言語化の方法はシンプルです。現場の管理者に「一週間で一番時間を取られている作業は何か」を3人に聞いてみてください。答えが3者3様であれば、課題の優先順位をまず整理する必要があります。答えが一致していれば、そこがDX化の起点です。
現場を知り尽くした視点と、世界水準のAI技術。この両輪が揃って初めて、建設DXは「投資」になります。それ以外は、高価な実験で終わります。自社の課題を言葉にできた段階で、初めて外部との対話が意味を持ちます。