建設DX製品を導入したのに、最後はExcelへ転記している。
現場ではタブレットから入力できるようになった。
写真もクラウドで整理できるようになった。
案件情報も一元管理できるようになった。
それでも提出前になると、
「発注者指定のExcelへ入力する」
「元請の様式へ並べ替える」
「既存の一覧表へコピーする」
「Word報告書へ貼り直す」
といった作業が残ることがあります。
これは、DX製品で管理するデータと、最終的に提出する既存様式の構造が同じとは限らないためです。
問題はExcelを使っていること自体ではありません。
製品内ですでに持っている情報を、別の様式へもう一度人が転記していること
です。
この記事では、建設DX製品を導入した後にもExcel転記が残る理由と、既存様式への変換でどこが詰まりやすいのかを整理します。
- DX製品の中で業務が終わるとは限らない
- 「Excel出力できます」だけでは足りない
- 最初に「最終的に何へ転記しているか」を見る
- 既存様式への変換は単純なコピーとは限らない
- セル位置が違うだけなら比較的対応しやすい
- データ構造が違うと変換ロジックが必要になる
- 写真が入るとさらに変換工程が増える
- Excel転記の後に「書式調整」が残ることもある
- 変更が入ると同じ転記をもう一度行うことになる
- 手作業を残すなら「どこまで残すか」を決める
- Excel転記が残る場合の主な解決方法
- 製品選定時に確認したい7項目
- 実際の既存Excelを見た方が早い
- 製品側へすべて実装してもらう必要はない
- Excelを残しても二重入力をなくせれば意味がある
- 既存様式への変換が建設DXのラストワンマイルになる
- まとめ
- ダウンロード
DX製品の中で業務が終わるとは限らない
建設DX製品には、それぞれ対象とする業務があります。
たとえば、
- 現場入力
- 写真管理
- 工程管理
- 点検記録
- 案件共有
- データ集計
- 報告書作成
などです。
製品の対象範囲では、入力や整理を効率化できる場合があります。
しかし建設実務では、製品上の処理が完了したことと、業務成果が完成したことが同じとは限りません。
最終的に、
- 自治体指定Excel
- 発注者指定様式
- 元請指定帳票
- 社内既存Excel
- Word報告書
- 写真台帳
- CSV
- 電子納品用データ
などが必要になることがあります。
つまり、
DX製品内のデータと、最終成果品との間に変換工程が存在する
ということです。
ここを導入前に確認していないと、製品を使い始めてから「最後だけ従来どおり手作業」という状態が残ります。
「Excel出力できます」だけでは足りない
製品選定時に、
「Excelへ出力できますか」
と確認することがあります。
しかし、「Excel出力可能」だけでは、既存様式への転記がなくなるかどうかは分かりません。
たとえば製品から、
一覧データを.xlsx形式で出せる。
CSVへ出せる。
標準帳票をExcelで出せる。
という場合があります。
一方、実際に必要なのは、
「発注者から指定された既存Excelファイルの、この位置へ値を入れること」
かもしれません。
この二つは別の機能です。
製品からExcelを出せても、そのExcelと提出様式の構造が違えば、
出力
↓
並べ替え
↓
コピー
↓
貼り付け
↓
書式調整
が残ります。
そのため確認したいのは、
Excelへ出せるかではなく、必要な既存様式までどう到達するか
です。
最初に「最終的に何へ転記しているか」を見る
Excel転記を減らしたい場合、最初に確認したいのはDX製品ではありません。
現在、最後に使っている様式です。
たとえば、
現場アプリ
↓
CSV出力
↓
社内集計Excel
↓
自治体指定Excel
↓
PDF化して提出
という流れなら、製品導入後にも二段階のExcel加工があります。
このとき、
「アプリを導入したのでDXは完了」
と考えると、後半の作業が評価対象から抜けます。
まず、
- 製品から何が出てくるか
- 最終的に何を作る必要があるか
- その間で何を人が変換しているか
を確認します。
この三つを並べると、Excel転記が残る場所を特定しやすくなります。
既存様式への変換は単純なコピーとは限らない
Excel転記というと、
A列をB列へコピーするだけ
に見えることがあります。
実際には、それより複雑な場合があります。
たとえば製品側では、
| 項目 | 値 |
|---|---|
| 橋梁名 | ○○橋 |
| 部材番号 | G1 |
| 損傷種類 | 腐食 |
| 評価 | c |
| 写真番号 | 12 |
という整理されたデータを持っているとします。
一方、提出用Excelでは、
橋梁名は別シートのC5。
部材番号は複数行の一覧。
評価は記号として配置。
写真は別の台帳へ貼付。
所見は複数項目から文章化。
という構造かもしれません。
この場合は、
データを持っていることと、帳票を完成できることは別問題
になります。
製品データと既存様式の間に、対応関係を定義する必要があります。
セル位置が違うだけなら比較的対応しやすい
既存様式との差が、
シート名。
セル位置。
開始行。
列順。
程度であれば、比較的整理しやすい場合があります。
たとえば、
橋梁名 → 基本情報!C5
路線名 → 基本情報!C7
評価 → 点検結果!H25のように対応関係を持たせます。
自治体や発注者によって位置が違うなら、
自治体AではC5。
自治体BではD6。
というように設定を切り替える方法もあります。
この種の違いは、セルマッピングや設定値として管理できる可能性があります。
問題は、既存様式の違いがセル番地だけではない場合です。
データ構造が違うと変換ロジックが必要になる
製品と既存様式でデータの持ち方そのものが異なる場合、単純転記では対応できません。
たとえば、
製品側では1損傷1行。
既存Excelでは1部材の複数損傷を横並び。
という違いがあるとします。
この場合、
どの損傷を何列目へ配置するか。
件数が増えたらどうするか。
空欄をどう扱うか。
を決めなければなりません。
また、
製品側では評価を文字列で持っている。
既存帳票では丸印やShapeの位置で評価を示す。
というケースなら、セルへ値を書くだけでは完成しません。
既存様式への変換では、
レイアウト差なのか、データ構造差なのか、表現方法の差なのか
を分けて確認することが重要です。
写真が入るとさらに変換工程が増える
建設関係の帳票では、写真を扱うことがあります。
製品内では、
写真ファイル。
撮影日時。
写真番号。
対象部材。
コメント。
などをデータとして管理できても、既存Excel側では、
指定枠へ写真を貼る。
縦横比を調整する。
写真番号を表示する。
コメントを配置する。
ページを増やす。
という処理が必要になることがあります。
この場合、
「写真データを出力できる」
ことと、
「提出用写真台帳を完成できる」
ことは別です。
製品選定時には、写真そのものだけでなく、
写真を既存成果へどう配置するか
まで確認します。
Excel転記の後に「書式調整」が残ることもある
既存様式への変換では、値を入れれば終わりとは限りません。
たとえば、
- 行の追加
- 不要行の非表示
- セル結合
- 印刷範囲
- 改ページ
- 行高
- 写真サイズ
- フォント
- A4・A3の混在
- PDF化
などがあります。
つまり、人が行っている作業を分解すると、
データ転記。
帳票生成。
レイアウト調整。
成果確認。
に分かれることがあります。
「転記作業を自動化したのに思ったほど工数が減らない」という場合、実際には後半のレイアウト調整や確認が多く残っていることがあります。
そのため改善対象は、
転記時間だけではなく、最終成果になるまでの全工程
で見る必要があります。
変更が入ると同じ転記をもう一度行うことになる
建設実務では、一度作った成果に後から修正が入ることがあります。
たとえば、
評価変更。
部材番号修正。
写真差替え。
コメント修正。
発注者協議による修正。
などです。
製品側の情報を修正した後、既存様式へ自動的に再反映できなければ、
再びExcelを開いて転記。
一覧表を修正。
写真台帳を修正。
関連箇所を確認。
という作業が発生します。
しかも、このとき怖いのは工数だけではありません。
製品上は新しい値なのに、提出用Excelには古い値が残る。
という不整合が起こる可能性があります。
したがって、既存様式への変換を考えるときは、
初回作成だけでなく、変更後に再生成できるか
も重要です。
手作業を残すなら「どこまで残すか」を決める
すべての既存様式を完全自動化する必要はありません。
たとえば年1回しか使わない特殊様式なら、自動化を作るより人が処理した方が合理的な場合があります。
一方、
毎案件。
毎月。
数百件。
と繰り返す転記なら、自動化効果が大きくなる可能性があります。
そこで、
頻度。
件数。
1回あたりの時間。
ミス発生時の影響。
様式変更頻度。
を見ます。
その結果、
標準部分は自動変換。
例外だけ人が確認。
特殊様式だけ手作業。
という分担もできます。
DXの目的は、人間作業をゼロにすることではありません。
繰り返し発生する機械的作業を減らし、人間が見るべき場所を明確にすること
です。
Excel転記が残る場合の主な解決方法
既存様式への変換が残った場合、解決手段は一つではありません。
製品の標準帳票を使う
発注者や社内ルールとして変更可能なら、製品標準の出力へ統一できる場合があります。
これが最も単純です。
ただし指定様式なら変更できません。
CSVやExcel出力を加工する
製品から構造化データを出せるなら、
Excel関数。
Power Query。
VBA。
Python等の変換処理。
などで既存様式へ変換できます。
APIで連携する
製品にAPIがあり、継続的な連携が必要なら、外部処理からデータを取得して帳票生成する方法もあります。
BPOへ回す
件数が少なく、変換ルールが複雑なら、人による処理を外部委託する選択もあります。
現状のExcelを部分的に改善する
既存Excel自体が十分機能しているなら、全部を置き換えず、二重入力部分だけ自動化する方法もあります。
重要なのは、
SaaSかExcelかという二択にしないこと
です。
製品選定時に確認したい7項目
DX製品を選ぶ段階で既存様式への転記を確認するなら、少なくとも次の7項目を見ておくと整理しやすくなります。
1. 最終的に必要な様式は何か
Excel。
Word。
PDF。
CSV。
電子納品。
などを整理します。
2. その様式は変更可能か
社内任意様式なのか。
元請指定なのか。
発注者指定なのか。
自治体様式なのか。
を確認します。
3. 製品から何を出せるか
Excel出力。
CSV。
API。
PDF。
画像。
など、形式だけでなく項目内容も確認します。
4. 製品データと既存様式の対応関係はどうなっているか
一つの製品項目がそのまま一つのセルへ入るのか。
加工や結合が必要なのか。
確認します。
5. 写真・図形・書式はどうするか
セル値以外の情報も成果品に必要か確認します。
6. 修正時に再出力できるか
データ修正後に帳票を作り直せるのか。
手修正したExcelとの整合をどう取るのか。
確認します。
7. 最後に人が確認するものは何か
技術判断。
所見。
写真の妥当性。
レイアウト。
発注条件。
など、人が責任を持つ部分を明確にします。
この7項目を見ると、
製品導入後にどのExcel作業が残るのかを事前に把握しやすくなります。
実際の既存Excelを見た方が早い
業務担当者へ、
「特殊な帳票はありますか」
と聞いても、
「普通のExcelです」
と言われることがあります。
しかし実際に見ると、
結合セル。
数式。
非表示行列。
複数シート。
Shape。
写真。
マクロ。
複雑な印刷設定。
が入っていることがあります。
日常的に使っている担当者にとっては、それが「普通」だからです。
そのため既存様式への変換が重要な業務では、
実際のExcelを見ながら製品との接続方法を確認する
方が正確です。
機密情報を外部へ出せない場合は、内容を伏せたサンプル帳票や空様式でも構造確認はできます。
製品側へすべて実装してもらう必要はない
既存様式への変換が残ると、
「このExcelも製品へ対応してもらえばよい」
と考えることがあります。
しかし顧客ごと、自治体ごと、元請ごとに異なる様式を、すべて標準製品の中へ実装することが適切とは限りません。
製品本体は共通部分を担当。
顧客固有の様式変換は外側で担当。
という役割分担もあります。
たとえば、
DX製品
↓
CSV・API
↓
変換処理
↓
既存Excel様式という構成です。
この方が、製品本体と個別仕様を分離できる場合があります。
Excelを残しても二重入力をなくせれば意味がある
既存Excelを使い続けること自体を失敗と考える必要はありません。
たとえば、
データ入力はDX製品で1回だけ。
最終成果は既存Excel。
そのExcelは製品データから自動生成。
最後に技術者が確認。
という構成なら、人が同じ内容を再入力する必要はありません。
ここで重要なのは、
Excelが残ったかどうか
ではなく、
Excelへ人がもう一度入力しているかどうか
です。
建設実務では最終成果品の制約があるため、既存Excelを完全に廃止できない場合があります。
それでも、その手前までデータを構造化し、最後の変換を自動化できれば改善余地はあります。
既存様式への変換が建設DXのラストワンマイルになる
DX製品で、
入力。
保存。
共有。
集計。
まで効率化できても、
最後に発注者・元請・社内の既存様式へ合わせる工程が残ることがあります。
この工程は、製品の標準機能から外れるほど顧客固有になっていきます。
そこで、
標準化できる部分は製品。
データ接続はCSVやAPI。
既存様式への変換はExcel VBA等。
少量の例外はBPO。
技術判断は人間。
というように役割を分けます。
維持DXでは、このような、
製品で処理できる標準領域と、実際の成果品との間に残る工程
を建設DXのラストワンマイルとして整理しています。
製品を選ぶときからこの部分を確認しておけば、
導入後に初めて「結局Excel転記が大量に残った」と気付く状態を減らせます。
まとめ
建設DX製品を導入しても、既存様式へのExcel転記が残ることがあります。
原因は、製品の機能不足とは限りません。
製品が管理するデータ構造と、発注者・元請・社内で必要な既存様式の構造が異なるからです。
そのため、
製品から何を出力できるか。
最終的に何を提出するか。
その間でどんな変換をしているか。
セル位置だけの違いか。
データ構造まで違うか。
写真や書式処理があるか。
修正時に再生成できるか。
人間判断をどこへ残すか。
を確認します。
重要なのは、
「Excelをなくすこと」ではなく、「すでに存在するデータを人がもう一度入力しないこと」
です。
DX製品と既存様式の間にある変換工程を独立して見ることで、SaaS、Excel/VBA、API、BPO、人間判断を適切に組み合わせやすくなります。
製品導入後にもExcel転記が残るなら、その部分は導入失敗として片付けるのではなく、次に改善すべきラストワンマイルとして分解してみる価値があります。
ダウンロード
維持DXでは、国交省様式を対象とした橋梁点検支援ツールを無料・機能制限版として公開しています。
実際の処理イメージを確認したい方は、以下のフォームからお申し込みください。
フォーム送信後に、ダウンロード案内をお送りします。
ご注意
ダウンロードしたExcelでマクロが実行できない場合は、
右クリック → プロパティ →「許可する」 をチェック後、再度開いてください。Windowsのセキュリティ機能により、初回実行時にマクロがブロックされる場合があります。
