建設DXでは、クラウドサービスやSaaSを導入することで、現場入力、写真管理、工程管理、情報共有などを効率化できる場面が増えています。
それでも実務では、
「システムを導入したのに、最後はExcelで直している」
「クラウドから出したデータを、発注者様式へもう一度転記している」
「入力はデジタル化したが、提出前になると人手の確認作業が増える」
といったことが起こります。
これは、SaaSの導入に失敗したからとは限りません。
むしろ、製品が担当する範囲と、実際の建設業務で最終的に求められる成果品や運用の範囲が一致していないことで発生する場合があります。
この記事では、建設DX製品を導入した後にもExcel作業が残りやすい理由と、その「最後に残る作業」をどう考えるか整理します。
SaaSで効率化できる範囲と成果品の範囲は同じではない
SaaSは、対象とする業務を共通化して、多くの利用者へ同じ仕組みを提供することで大きな効果を発揮します。
たとえば、
- 現場写真を登録する
- 点検結果を入力する
- スマートフォンやタブレットから情報を共有する
- 作業状況を一覧化する
- データをクラウドへ集約する
といった処理です。
こうした部分は、複数の会社や現場に共通する業務なので、製品化との相性が良い領域です。
一方、建設コンサルや維持管理業務の最終段階では、
- 発注者指定のExcel様式
- 自治体独自の帳票
- 元請独自の管理表
- 過年度成果との比較
- 電子納品用のファイル構成
- 協議後に変更された評価の反映
などが求められることがあります。
ここは案件や発注者による差が大きく、すべてを一つの共通製品で吸収するのが難しい領域です。
つまり、
業務を進めるためのシステムと、最終的に提出する成果品は別の構造を持つことがある
ということです。
理由1 発注者ごとに成果品の形が違う
建設実務でExcel作業が残りやすい理由の一つが、成果品様式の違いです。
同じ橋梁点検でも、基本となる考え方が共通していても、実際の帳票を見ると、
- シート構成
- 項目位置
- セル結合
- 評価の表現方法
- 写真の配置
- コメント欄
- 一覧表の列構成
などが異なる場合があります。
システム側では共通データとして管理できても、提出するときには、
「A自治体の様式へ出す」 「元請指定のExcelへ整理する」 「既存の成果品と同じ並びにする」
といった変換が必要になります。
この変換部分が製品の標準機能に含まれていなければ、最後にExcelで調整する作業が残ります。
ここで重要なのは、Excelが古いから残っているとは限らないことです。
発注者ごとの成果品仕様を吸収するための最終インターフェースとしてExcelが使われている
場合があります。
理由2 システム内のデータと帳票上の情報が1対1ではない
システムからCSVを出力できれば、Excel帳票も簡単に作れるように見えます。
しかし、実際にはそう単純でないことがあります。
たとえば、システム側では、
- 橋梁ID
- 部材
- 損傷種類
- 損傷程度
- 写真番号
といったデータを整然と持っていても、提出帳票側では、一つのシート上に複数の情報が組み合わされて表示されることがあります。
反対に、帳票上では一つに見える情報が、データとしては複数の項目から構成されている場合もあります。
さらにExcel帳票では、
- 色
- セル位置
- 結合セル
- Shape
- オートシェイプ
- 印刷レイアウト
そのものが意味を持つことがあります。
そのため、
「CSVのA列をExcelのA列へ入れる」
という単純な変換では済みません。
必要になるのは、
システムのデータ構造と、成果品の帳票構造を対応させる作業
です。
理由3 過年度成果が別の形式で蓄積されている
新しいSaaSを導入しても、過去の成果まで同じシステムで作られているとは限りません。
長期間運用されている業務では、
- Excel
- CSV
- CAD
- Access
- 旧システムの出力ファイル
などが混在していることがあります。
新規データだけを考えれば新システム内で完結できても、
「前回点検と比較したい」 「過年度の損傷番号を確認したい」 「前回評価から何が変わったか確認したい」
となると、過去成果との接続が必要になります。
このとき、過年度成果を丸ごと新システムへ移行できるとは限りません。
結果として、
新しいシステム
↓
CSVやExcelへ出力
↓
過年度Excelと照合
↓
提出帳票へ反映
という中間作業が発生します。
DX導入後にもExcelが残るのは、こうした新旧データの橋渡しを担当している場合もあります。
理由4 発注者協議や技術確認の後に内容が変わる
建設成果品は、一度作ったらそのまま提出されるとは限りません。
たとえば橋梁点検では、
- 社内照査
- 元請確認
- 技術審査
- 発注者協議
などを経て、評価やコメントが変更されることがあります。
一つの評価を変更しただけでも、その情報が、
- 点検調書
- 写真
- 損傷番号
- コメント
- 評価結果一覧
- 健全性
- 過年度比較
- 損傷図
など複数箇所へ関係している場合があります。
システム内ですべてが連動していれば修正しやすいですが、現実には別のExcel、CAD、PDF、一覧表などへ成果が分かれていることがあります。
すると提出前には、
「ここの評価を変えたので、他の成果も直っているか」
という確認が必要になります。
この修正伝播と整合確認は、入力段階の効率化とは別の問題です。
現場入力をSaaS化しても、提出直前の変更管理まで同じ製品範囲に含まれているとは限らないため、Excelや人間による確認が残ることがあります。
理由5 例外処理を人間が吸収している
建設実務では、すべての案件が標準ケースになるとは限りません。
たとえば、
- 旧様式が一部だけ残っている
- 特殊な構造形式がある
- 前回成果に不足がある
- 一部の情報だけ別資料にある
- 発注者から個別指示が出る
といったことがあります。
SaaSは共通処理に強い一方、発生頻度の低い個別例外まで製品機能として持たせると、システム自体が複雑になります。
そのため、標準処理はシステムで効率化し、例外だけ人間が処理するという設計は合理的です。
問題は、
その例外処理がどれくらい残っているのか見えていないこと
です。
SaaS導入後も毎回かなりの時間をExcel修正へ使っているなら、その部分は別の改善対象として切り出せます。
Excelが残ること自体を失敗と考えない
建設DXでは、ときどき、
「Excelをなくすこと」
そのものがDXのように扱われることがあります。
しかし、Excelが残っているかどうかだけで導入効果を判断するのは少し乱暴です。
たとえば、
導入前に10時間かかっていた作業が、
- SaaSによる標準処理で7時間削減
- 最後のExcel調整が3時間残る
のであれば、十分な改善効果があります。
この場合に考えるべきなのは、
「Excelが残っているからシステム導入は失敗」
ではなく、
残った3時間をさらに改善する価値があるか
です。
件数が少なければ、人間がExcelで処理した方が安いかもしれません。
毎年数百件繰り返すのであれば、自動変換や個別ツールを作る価値が出るかもしれません。
重要なのは、残作業の量と性質です。
残った作業は5種類に分けて考える
SaaS導入後に作業が残った場合、いきなり追加システムを作る必要はありません。
まず、その作業が何に向いているかを分けて考えます。
SaaSの標準機能で解く
製品側に設定変更、帳票出力、API、CSV出力などの機能があるなら、まず標準機能で対応できるか確認します。
標準機能で解けるなら、個別開発より保守負担を抑えやすくなります。
Excel改善で解く
データはすでに出力できていて、
- 並べ替え
- 転記
- 集計
- 書式変換
- 指定帳票への配置
だけが残っているなら、Excel関数やVBAで十分な場合があります。
特に発注者ごとの差分が小さい場合は、小さなExcel処理の方が運用しやすいことがあります。
BPOで解く
処理自体は定型でも、件数が少ない、仕様変更が多い、判断が必要といった場合は、人による処理を外部化する方法もあります。
何でもシステム化するより合理的なことがあります。
個別開発で解く
件数が多く、ルールも安定していて、繰り返し工数が大きい場合は、個別ツールや連携処理を作る価値が出てきます。
この場合も、先にデータ構造や帳票仕様を固定する必要があります。
専門実務者の判断を残す
評価変更、技術判断、成果品の提出可否などは、単純な自動処理へ置き換えにくい領域があります。
この部分まで無理に自動化するより、
「機械で確認できるところまで絞り、人間が最後に判断する」
設計の方が扱いやすい場合があります。
製品選定時には「できること」だけでなく「残ること」を確認する
DX製品を検討するときは、機能一覧を見るだけでなく、
- 導入後もどの作業が残るか
- 発注者独自様式へどう対応するか
- CSVやExcelへデータを出せるか
- 過年度成果をどう扱うか
- 導入後の個別対応を誰が行うか
- 製品対象外の相談が出た場合にどうするか
まで確認すると、導入後の姿を想像しやすくなります。
製品にすべての機能を求めるという意味ではありません。
むしろ、
製品が担当する範囲と、それ以外を誰が担当するかを最初から分けておく
という考え方です。
建設DXのラストワンマイルは「製品の外側」に残る
建設DXでは、共通化しやすい部分ほど製品化しやすくなります。
一方で、
- 自治体ごとの成果品
- 元請ごとの運用
- 過年度データ
- 提出直前の修正
- 複数アプリ間の整合
- 個別例外
のような部分は、案件固有の条件を含みやすくなります。
この最後の部分を、ここでは建設DXの「ラストワンマイル」と考えています。
重要なのは、その領域をすべて一つのSaaSへ押し込むことではありません。
SaaS、Excel、BPO、個別開発、専門実務者を組み合わせて、
どこまでを共通化し、どこからを個別対応にするか
を整理することです。
建設DXでExcel作業が残ること自体は不思議ではありません。
むしろ、そのExcel作業を観察すると、
「現在の製品が担当している範囲」
と
「まだ人間が橋渡ししている範囲」
の境界が見えてきます。
そこを可視化することが、次の改善箇所を見つける入口になります。
ダウンロード
維持DXでは、国交省様式を対象とした橋梁点検支援ツールを無料・機能制限版として公開しています。
実際の処理イメージを確認したい方は、以下のフォームからお申し込みください。
フォーム送信後に、ダウンロード案内をお送りします。
ご注意
ダウンロードしたExcelでマクロが実行できない場合は、
右クリック → プロパティ →「許可する」 をチェック後、再度開いてください。Windowsのセキュリティ機能により、初回実行時にマクロがブロックされる場合があります。
