維持DX｜建設側に立つ建設DX導入支援
維持DXは、建設側に立って、建設DXの導入を支援する技術・業務改善プロジェクトです。
地域の建設会社、建設コンサルタント、維持管理事業者などを中心に、
- どの業務を改善するべきか
- 既存のDX製品で解決できるか
- SaaS、BPO、Excel改善、個別開発のどれが合うか
- 導入後にどの作業が残るか
- 既存のExcel・Word・自治体独自帳票とどう接続するか
といった課題を、建設実務側から整理することを重視しています。
維持DXの立ち位置を一言で表すと、
「建設側に立つ、建設DXの目利き・通訳」
です。
IT製品を導入すること自体を目的にするのではなく、建設実務、成果品、発注条件、既存業務、責任範囲まで確認したうえで、実際に使える形へつなぐことを目指しています。
こんな課題を扱います
建設DXでは、製品そのものよりも、導入前後のつなぎ目で問題が残ることがあります。
たとえば、
- DX製品を探しているが、自社の業務に何が合うのか分からない
- 製品説明を聞いても、実際の建設業務で使えるか判断しにくい
- SaaSを導入したが、最後はExcelへ再入力している
- 自治体や発注者ごとの独自様式が残っている
- システムのデータと成果品の形式が一致しない
- Excel、Word、PDF、写真、CAD、既存システムが分断されている
- 過年度成果を持っているのに、毎回同じ情報を入力している
- AIや自動化を使いたいが、どこまで機械に判断させてよいか分からない
といった問題です。
維持DXでは、こうした課題を単なる「IT不足」として扱わず、
現在の業務 → 必要な状態 → 解決手段 → 導入後に残る作業
の順に整理します。
建設DX導入支援で行うこと
維持DXでは、製品ありきではなく、まず現在の業務を整理します。
1. 実務課題の整理
最初に確認するのは、
「何の製品を入れるか」
ではなく、
「誰の、どの業務を、どの状態へ変えたいのか」
です。
対象となる業務、利用者、既存システム、Excel・Word帳票、成果品、発注者条件などを確認し、問題の所在を整理します。
2. 解決手段の比較
課題に応じて、
- 既存の建設DX製品・SaaS
- BPO・外部支援
- Excel / VBAによる改善
- データ変換・帳票変換
- 小規模な個別開発
- 業務ルールの変更
- 現状運用の継続
などを比較します。
DX製品を導入しないことが合理的な場合も、選択肢から外しません。
3. 製品・ベンダーとの接続
製品を検討する場合は、
- 何ができるのか
- 何が対象外なのか
- どの企業・業務に向いているのか
- 導入条件や運用条件は何か
- 製品導入後も人間に残る作業は何か
を建設実務側から確認します。
ベンダーの機能説明をそのまま受け取るのではなく、建設実務、成果品、既存業務の条件へ置き換えて考えることを重視します。
4. 導入後のラストワンマイル対応
システムを導入しても、
- 発注者指定Excelへの転記
- 独自帳票への変換
- 写真整理
- PDF・Word成果品への反映
- 過年度成果との比較
- データ形式の変換
- Excel上での追加集計
などが残ることがあります。
維持DXでは、「システムを導入した後にも残る作業」まで含めて整理します。
DX製品を入れること自体が目的ではありません
維持DXは、
「新しいシステムですべてを置き換える」
ことを前提としていません。
実際の建設・維持管理業務では、
- 既存システム
- Excel
- Word
- CAD
- 写真
- 過年度成果
- 発注者独自様式
などが併存しています。
現実には、すべてを一度に置き換えるよりも、
既存資産を残しながら、重複入力や変換作業だけを減らす
方が合理的な場合もあります。
重要なのは、DX製品を導入したかどうかではなく、
建設実務全体として、作業・ミス・確認負担が本当に減ったか
だと考えています。
建設実務とITの間を翻訳します
維持DXの特徴は、単にExcelやプログラムを扱うことではありません。
建設実務では、
「このセルは何を意味しているのか」
「この評価は誰が決めたものなのか」
「写真と部材を何をキーに結び付けるのか」
「評価を変更したら、どの成果品まで修正する必要があるのか」
といった判断が必要になります。
一方、システム側では、
- 項目定義
- データ型
- キー
- 反復構造
- 入出力条件
- マッピング
- エラー処理
- 責任境界
として明確にする必要があります。
維持DXでは、
建設実務で人間が理解している意味を、ITで処理できる仕様へ翻訳すること
と、
IT製品の機能を、建設実務で本当に使える条件へ逆翻訳すること
の両方を扱います。
技術事例｜自治体独自の橋梁点検Excelを構造化
代表的な技術検証として、自治体独自の橋梁点検Excel帳票を対象としたBISTの内部PoCがあります。
このPoCでは、複数の点検Excelから、
- 橋梁基本情報
- 固定セル情報
- 写真メタ情報
- オートシェイプで表現された評価情報
- 径間・部材等の反復情報
- 構造化された点検評価
を読み取り、1橋1行・約1,900項目規模の統合マスタへ整理しました。
さらに、複数橋を一括取り込みし、統合データから点検結果一覧表へ再出力するところまでEnd-to-Endで検証しています。
この検証で分かったのは、Excelを読み取る技術だけでは十分ではないということです。
同じ意味の情報が、
- チェック欄
- 自由記述
- 所見
- 欄外注記
- 別様式
などへ分散している場合、機械的な変換だけでは処理できません。
そのため現行PoCでは、構造化された評価を機械処理し、自由記述から新しい技術判断を作ることは行わない設計としています。
建設DXで考えていること
維持DXでは、技術そのものだけでなく、建設DX導入時の考え方も記事として公開しています。
代表的なテーマには、
- DX製品を選ぶ前に何を整理するべきか
- SaaS導入後にもExcel作業が残る理由
- 自治体独自帳票をどう構造化するか
- 成果品の修正伝播をどう整理するか
- 神Excelや自由記述をどう扱うか
- AIへ任せる処理と人間判断の境界
- 橋梁維持管理・LCC・社会的割引率
- Excel / Word / VBAを使った実務改善
などがあります。
→ 建設DX製品を選ぶ前に整理する実務課題｜機能比較だけでは決まらない理由
→ SaaS導入後にもExcel作業が残る理由｜建設DXのラストワンマイル
→ 建設DXで神Excelを自動化して分かった本当の壁｜自由記述と欄外注記が生む非構造化
無料ツール・実装例
維持DXでは、実務で使用・検証しながら作成したExcel / VBAツールの一部を、無料・機能制限版として公開しています。
国交省様式を対象とした橋梁点検支援では、
- 点検調書作成支援
- 評価結果一覧生成
- 旧様式から現行様式への移行
- 成果品の整合確認
などを扱っています。
これらは無料ツールの配布自体を目的としたものではなく、建設実務上の問題をどのように整理し、データや処理へ落とし込んでいるかを確認できる実装例として公開しています。
主な対象領域
現在、主に扱っているのは次の領域です。
- 建設DX導入支援
- 建設DX製品の選定・適合確認
- 建設会社・建設コンサルタントの業務改善
- 橋梁点検・インフラ維持管理
- 自治体独自帳票
- Excel / VBA
- Word帳票
- 点検調書・成果品
- 写真・評価情報整理
- 過年度成果の再利用
- データ構造化・データ変換
- 帳票ローカライズ
- AIを利用した実務改善
- LCC・社会的割引率・維持管理計画
建設DXコンサルとの違い
一般に「建設DXコンサル」「建設DX導入コンサルタント」と呼ばれる領域に近い部分もあります。
ただし維持DXでは、抽象的なDX戦略だけではなく、
実際に残っているExcel、帳票、成果品、既存システム、現場運用まで確認すること
を重視しています。
製品選定だけで終わらず、
「導入したシステムと、手元に残る実務がつながっているか」
までを見ることが、維持DXの役割です。
お問い合わせ
次のような課題があれば、サイトのお問い合わせフォームよりご相談ください。
- 建設DXを進めたいが、何から整理すればよいか分からない
- 自社に合うDX製品・サービスを検討したい
- DX製品を導入したが、Excelや帳票作業が残っている
- ベンダーへ伝える実務要件を整理したい
- 自治体独自帳票や既存成果を活用したい
- 橋梁点検・維持管理業務のデータを整理したい
- Excel / VBAによる業務改善を検討したい
- 小規模なPoCで実現可能性を確認したい
- 建設実務とITの間をつなぐ技術支援が必要
大規模なシステム導入を前提とせず、現在の業務を確認するところから、小さく検討することができます。