橋梁点検Excelを統合して見えた建設DXの現実｜BISTで切り分けた自動化と人間判断
ここまで3回にわたり、既存のExcel帳票をDXするときに出てくる問題を書いてきました。
1回目は、いわゆる「神Excel」を自動化すると、セル結合やレイアウト以上に、自由記述や欄外注記へ意味が分散していることが壁になるという話。
2回目は、その背景にある属人化と、データ正規化の必要性。
3回目は、自由記述をAIで読めるようになっても、情報抽出と技術判断は同じではないという話です。
今回は、その元になった実際のPoCへ戻ります。
維持DXでは、ある自治体独自の橋梁点検Excelを対象に、
複数の点検Excelを読み込み、橋梁単位の統合データへ整理し、一覧表まで再出力する
PoCを開発しました。
ここではこの仕組みをBISTと呼んでいます。
作る前は、
「複雑なExcelをプログラムで読めれば、かなり自動化できるだろう」
と考えていました。
実際、それ自体はかなりできました。
一方で、実装を進めるほど、
自動化できることと、自動化してよいことは違う
という問題がはっきりしてきました。
BISTで最終的に重要になったのは、機能を増やすことよりも、
システムが処理する範囲と、人間が判断する範囲を切り分けること
でした。
やりたかったのは「複数Excelを一つのデータとして扱う」こと
橋梁点検業務では、橋ごとにExcel成果が存在することがあります。
1橋なら、人間がファイルを開いて確認できます。
しかし対象橋梁が増えてくると、
- 各Excelを順番に開く
- 必要な評価を探す
- 別の一覧表へ転記する
- 橋梁ごとに表現差を確認する
- 修正があれば再度転記する
といった作業が発生します。
データはすでにExcelの中にあるのに、
一覧化するためにもう一度人間が読み直している。
そこでBISTでは、
複数の橋梁点検Excelから必要な情報を取得し、
一度、共通の統合マスタへ整理する設計を取りました。
元Excelを直接一覧表へ書き写すのではなく、
元帳票 → 統合データ → 出力帳票
という中間層を作る考え方です。
この中間層を持つことで、
元帳票のレイアウトと、
最終的な一覧表のレイアウトを分離できます。
Excelの構造差は、面倒だが処理できた
実装前に一番不安だったのは、元Excelの構造でした。
橋梁点検のExcelは、単純な表形式とは限りません。
基本情報は固定セル。
点検結果は複数の領域。
径間ごとに繰り返す項目。
図形やShapeとして保持される情報。
写真。
印刷を前提とした複雑なレイアウト。
こうしたものがあります。
一般的なデータベースのように、
「この列には必ずこの値」
とはいきません。
ただし実際に作ってみると、
これらの多くは、
ルールが分かれば処理できる
ものでした。
橋梁名はこのセル。
この範囲は径間ごとの評価。
このShapeはこの項目。
径間数に応じて同じ処理を繰り返す。
というように、帳票構造を仕様化していけば機械処理できます。
もちろん帳票変更への追従は必要です。
しかし少なくとも、
「Excelの見た目が複雑だから自動化できない」
という話ではありませんでした。
本当に難しかったのは「どの情報を正式データとするか」
実装が進むと、別の問題が出てきました。
同じ橋梁の状態について、
情報が一か所に存在しないことがあります。
正式な評価欄。
自由記述。
備考。
所見。
欄外注記。
別様式のコメント。
写真に付けられた説明。
人間なら、これらを全部見て意味を理解できます。
しかしシステム化すると、
「どれを正式な値として採用するのか」
を決める必要があります。
ここで初めて、
問題がExcel処理から業務設計へ変わります。
たとえば正式な評価欄にはある値が入力されている。
一方で自由記述には、それを補足する文章がある。
その文章を読めば、人間なら、
「この評価にはこういう背景がある」
と理解できます。
ではシステムは、その文章を読んで評価を書き換えるべきでしょうか。
ここでBISTでは、
書き換えない
という境界を取りました。
BISTで自動化したのは「すでに決まっている情報」の処理
BISTが基本的に扱うのは、
元帳票ですでに構造化されている情報です。
たとえば、
- 橋梁の基本情報
- 径間情報
- 元帳票上ですでに入力されている評価
- 一定のルールで集約できる項目
- 一覧表へ再配置できる情報
です。
つまり、
人間がすでに決めた結果を、機械が整理する
ところを主な対象にしています。
ここで機械が新しい技術判断を作る必要はありません。
元帳票でAならA。
元帳票でCならC。
橋梁名があるなら、その橋梁名。
対象径間が決まっているなら、その径間。
この範囲なら、
システムに求められるのは主に、
正しく読む。
正しく保持する。
正しく集約する。
正しく出力する。
という処理です。
これは自動化と相性がいい領域です。
一方で「自由記述から新しい評価を作る」ことはしなかった
逆に、
自由記述だけを読んで、
「これはこの変状に該当する」
「この記述なら評価を変更する」
「この所見を一覧表へ正式値として反映する」
といった処理は、現段階では対象外にしました。
技術的には、辞書処理やAIを使えば実装の余地はあります。
しかし、それを行うとBISTは、
単なる統合・集約ツールではなく、
技術判断支援システム
へ性質が変わります。
その場合、
判定基準。
再現性。
誤判断時の扱い。
確認者。
履歴。
説明責任。
などを別途設計する必要があります。
これは単にプログラムへ条件分岐を一つ追加する話ではありません。
システムの責任範囲そのものが変わります。
だから、
できそうだから実装する
のではなく、
どこまでをこのツールの責任にするのか
から決めました。
表示を整えることと、判断を変えることも分けた
統合データを一覧表へ出すときには、
元帳票の文言が長すぎる場合があります。
点検用の設問文を、そのまま一覧表へ出すと読みづらい。
そこで、
元の意味を変えない範囲で、
一般的な変状名称へ表示を整理することがあります。
これは、
表示上の正規化
です。
ここでも境界が重要です。
長い設問を、
「漏水・遊離石灰」
のように短く見せることと、
別の判定体系へ自動変換することは同じではありません。
前者は表示整理。
後者は技術判断を伴う可能性があります。
BISTでは、この二つを混ぜないようにしました。
統合マスタを作ったことで「業務の仕様」が見えるようになった
PoCで特に意味があったのは、
複数のExcelを読む処理そのものより、
共通の統合マスタを設計したこと
だったかもしれません。
元Excelを一つのデータへまとめようとすると、
必ず、
「この情報は何なのか」
を決める必要があります。
橋梁単位なのか。
径間単位なのか。
部材単位なのか。
変状単位なのか。
評価なのか。
説明文なのか。
表示用の文字なのか。
こうした整理をしていくと、
これまでExcelのレイアウトに隠れていた業務構造が見えてきます。
つまり統合マスタは、
単なる中間ファイルではありません。
帳票の中に埋まっていた業務仕様を外へ出したもの
でもあります。
DXでは「今の作業をそのまま自動化」しない方がいいことがある
既存業務をDXするとき、
今、人間がやっている操作をそのまま機械へ置き換えたくなります。
人間がこのセルを見る。
次にこの文章を読む。
その後この一覧へ転記する。
なら、全部自動化しよう。
という発想です。
しかし今回のPoCでは、
人間の作業の中に、
単純処理と技術判断が混在している
ことが分かりました。
同じ「Excelを見て転記する」という操作でも、
実際には、
値を読むだけの場面。
意味を解釈している場面。
例外を判断している場面。
があります。
ここを分けずに全部自動化すると、
どこからシステムが判断したのか分からなくなります。
だからDXでは、
操作単位ではなく、
判断の種類で業務を分解する
必要があります。
自動化の対象を狭くすることは、後退ではない
システム開発では、
できるだけ多くの機能を入れることが進歩に見えます。
しかし実務ツールでは、
あえて処理しない部分を決めることも重要です。
BISTでは、
自由記述から新しい評価を作らない。
元帳票に存在しない技術判断を勝手に追加しない。
という境界を置きました。
一見すると、機能制限です。
しかし実務上は、
その方がシステムの役割が明確になります。
自動処理された値は、
元データから機械的に取得・集約したもの。
人間が判断したものは、
人間が確認した結果。
この区別がつきます。
責任境界が見えること自体が、システム品質の一部
だと考えています。
BISTで見えた建設DXの「現実的な形」
今回のPoCを通して、
建設DXは、
何でも一つのシステムで完結させること
ではないと改めて感じました。
既存Excelには、長年の業務知識が入っています。
一方で、
非構造化。
表記揺れ。
属人化。
暗黙判断。
も一緒に入っています。
だから現実的には、
構造化された部分は機械で読む。
共通データへ整理する。
繰り返し転記は自動化する。
表示は必要に応じて正規化する。
自由記述は残す。
必要な判断は人間へ戻す。
という分業になります。
これは「完全自動化」ほど派手ではありません。
しかし、
人間がやる必要のない作業だけを確実に減らす
という意味では、かなり現実的です。
既存Excelを残してもDXはできる
DXというと、
Excelを廃止し、
すべて新しいクラウドシステムへ移す姿が想像されがちです。
もちろん、それが最適な場合もあります。
ただし自治体独自様式や既存成果品のように、
簡単にはなくせないExcelもあります。
その場合は、
Excelをなくすことではなく、
Excelの前後にある人間の重複作業を減らす
という方法があります。
入力様式は既存Excel。
その情報を機械で取得。
内部では共通構造へ変換。
必要な成果へ再出力。
この構成なら、
既存運用との互換性を保ちながらDXできます。
維持DXで以前から考えている「ラストワンマイル」は、まさにこの部分です。
新しい製品やシステムを入れた後にも、
最後に残る既存帳票。
個別様式。
転記。
成果整理。
そこを接続する仕組みです。
今後AIを入れるとしても、境界は残る
将来的に、
BISTのような仕組みへAIを組み合わせる余地はあります。
自由記述から候補を抽出する。
表記揺れを検出する。
要確認箇所を提示する。
構造化された評価と所見の矛盾候補を探す。
こうした用途です。
ただし、その場合でも、
最終判断を誰が確定するのか
という問題は残ります。
むしろAIが高性能になるほど、
「AIができるか」
ではなく、
AIにどこまで決めさせるか
の設計が重要になると思います。
まとめ
橋梁点検Excelを複数まとめて処理するPoCを作る前は、
難しいのはExcelの複雑な構造だと思っていました。
実際には、
セル。
Shape。
径間ごとの繰り返し。
複数シート。
といった問題は、仕様を定義することでかなり処理できます。
その先で出てきたのが、
人間が暗黙に行っていた判断を、どこまでシステムへ渡すのか
という問題でした。
BISTでは、
元帳票ですでに構造化されている情報は自動化する。
統合・集約・再出力できるものは機械へ任せる。
一方、
自由記述から新しい技術判断は作らない。
という境界を取りました。
これは処理能力の限界ではなく、
責任範囲の設計
です。
建設DXでは、
何でも自動化することが目的ではありません。
人間が行うべき判断と、
機械で十分な処理を分ける。
そして、
人間がやらなくていい転記・整理・再入力を減らす。
今回のPoCで一番大きかったのは、
ツールを一つ作れたこと以上に、
「どこまでがデータで、どこからが人間の判断なのか」を実装を通して切り分けられたこと
だったと思います。
ダウンロード
維持DXでは、国交省様式を対象とした橋梁点検支援ツールを無料・機能制限版として公開しています。
実際の処理イメージを確認したい方は、以下のフォームからお申し込みください。
フォーム送信後に、ダウンロード案内をお送りします。
ご注意
ダウンロードしたExcelでマクロが実行できない場合は、
右クリック → プロパティ →「許可する」 をチェック後、再度開いてください。Windowsのセキュリティ機能により、初回実行時にマクロがブロックされる場合があります。
