大量列そのものが目的ではない
福島県版橋梁点検調書を対象にした内部PoCでは、統合マスタのヘッダーが約1,900列規模になった。
この数字だけを見ると、単に巨大なExcelを作ったように見えるかもしれない。しかし、重要なのは列数そのものではない。
本質は、自治体独自の橋梁点検調書に含まれる固定情報、写真情報、評価情報、径間・部材・損傷の反復構造を、後段処理で扱えるスキーマとして展開した点にある。
約1,900列を手で入力したわけではない。帳票に存在する反復規則を抽出し、列名の命名規則として定義し、機械的に生成した。
この記事では、福島BISTの内部PoCで扱ったヘッダー生成と反復構造解析の考え方を整理する。現時点のヘッダー構造は、単一橋・3径間サンプルに基づく候補構造であり、福島県様式全体へ完全確定したスキーマではない。
なぜ約1,900列規模になったのか
橋梁点検調書には、1つの橋梁に対して多くの情報が含まれる。
基本情報だけであれば、列数はそれほど多くならない。橋梁名、所在地、橋長、幅員、竣工年、管理者などを並べれば済む。
しかし、点検調書にはそれだけでなく、径間、部材、損傷種類、評価、写真、コメントが含まれる。これらは1回だけ出てくる情報ではなく、同じ構造が繰り返される。
列数が増える理由は、次のような反復単位が重なるためである。
- 径間ごとの反復
- 部材ごとの反復
- 損傷種類ごとの反復
- 写真情報の反復
- 評価項目の反復
- コメントやメタ情報の反復
たとえば、1つの部材に対して複数の損傷種類があり、それぞれに評価情報や写真情報が紐づく場合、単純な固定列では表現しにくい。
このような情報を1行の統合マスタへ展開すると、列数は自然に増える。
ただし、列数が多いこと自体を価値と見なしてはいない。必要だったのは、帳票上の反復構造を、後段処理で参照可能な列構造へ変換することである。
基本項目と反復項目を分ける
ヘッダー設計では、最初に基本項目と反復項目を分ける必要がある。
基本項目は、橋梁単位で1回だけ出てくる情報である。橋梁名、所在地、橋長、幅員などがこれにあたる。
反復項目は、径間、部材、損傷、写真などの単位で繰り返される情報である。
この2つを同じ扱いにすると、列名の設計が崩れる。
基本項目は、そのまま列名にできることが多い。一方で、反復項目は、何番目の径間なのか、どの部材なのか、どの損傷種類なのか、どの写真なのかを列名に含める必要がある。
たとえば、概念としては次のように分けられる。
- bridge_name
- bridge_length
- inspection_date
- span_01_member_x_damage_y_eval
- span_01_member_x_damage_y_photo_no
- span_02_member_x_damage_y_eval
- photo_001_file_name
- photo_001_comment
実際の列名は帳票構造に合わせて設計する必要があるが、考え方としては、固定項目と反復項目を同じ平面に雑に並べないことが重要である。
反復構造をスキーマとして捉える
Excel帳票では、反復構造が明示的なデータベースとして表現されているとは限らない。
見出し、罫線、結合セル、空白行、表の位置、写真欄の配置などから、人間が読み取ることで反復単位が分かる場合がある。
このような帳票では、反復構造を見つけた上で、どの単位をスキーマへ展開するかを決める必要がある。
たとえば、径間ごとに同じ評価欄が繰り返されている場合、単にセル番地を列へ変換するのではなく、「径間番号」という概念を列名へ反映する必要がある。
部材や損傷種類についても同じである。
帳票上では縦に並んでいるだけでも、データ上は次のような階層を持つ可能性がある。
- 橋梁
- 径間
- 部材
- 損傷種類
- 評価
- 写真
- コメント
Excelの統合マスタでは、これを横方向の列へ展開する必要がある。そのためには、階層構造を列名の命名規則へ変換する設計が必要になる。
手入力ではなく規則生成へ切り替える理由
約1,900列規模のヘッダーを人力で入力することは現実的ではない。
入力ミス、命名揺れ、順序の不整合が起きやすく、後から実装側で参照する際にも事故が増える。
特に、反復項目では、1つの命名ミスが後段処理の列参照ミスにつながる。
そのため、ヘッダーは手入力ではなく、生成規則から作る方が安全である。
規則生成へ切り替えることで、次の利点がある。
- 命名規則を一貫させられる
- 反復項目の順序を管理しやすい
- 生成対象を変更したときの差分を追いやすい
- 実装側の列参照と対応させやすい
- 将来別様式へ展開するときに設計思想を流用できる
ただし、すべてを機械生成すればよいわけではない。
何を反復単位とするか、どの情報を列へ展開するか、どの粒度で保持するかは、人間が決める必要がある。
人間が定義する部分と機械生成する部分
ヘッダー生成では、人間が定義すべき部分と機械生成できる部分を分けることが重要である。
人間が定義すべきなのは、業務上の意味を持つ構造である。
- 基本項目の一覧
- 反復単位の種類
- 径間、部材、損傷、写真の関係
- 評価項目として保持する粒度
- 後段処理に必要な列
- 対象外、未評価、空欄の扱い
一方、機械生成できるのは、定義済みの規則に基づく列名展開である。
- 径間番号の展開
- 部材種別ごとの展開
- 損傷項目ごとの展開
- 写真番号の展開
- 評価項目の反復展開
- 共通接頭辞・接尾辞の付与
この分離により、人間は1,900列すべてを入力する必要がなくなる。代わりに、反復構造と命名規則を定義し、その規則からヘッダーを生成する。
列名は後段処理との契約である
統合マスタの列名は、見た目のラベルではなく、後段処理との契約である。
一覧生成、差分抽出、整合確認、過年度比較、帳票再出力を行う場合、処理側は統合マスタの列を参照する。
列名が曖昧だったり、途中で規則が変わったりすると、後段処理が壊れる。
そのため、ヘッダー生成では、次の点を意識する必要がある。
- 同じ意味の項目は同じ命名規則にする
- 反復番号の桁や表記を揃える
- 後から列を追加する場合の位置を考える
- 手修正で列名を変えない
- 候補段階の列と確定列を混同しない
福島BISTの内部PoCでは、約1,900列規模のヘッダーを生成したが、現時点ではヘッダー構造全体を福島県様式として完全確定したものとは扱っていない。
単一橋・3径間サンプルでEnd-to-Endの取込を確認した段階であり、径間4〜6や複数橋を含む横展開の検証は行っていない。
反復構造とShape読取の関係
ヘッダー生成は、オートシェイプ座標解析とも関係する。
Shape座標から評価を読み取るだけでは、統合マスタへ格納できない。読み取った評価が、どの列に入るべきかが必要である。
そのため、評価表の行・列方向の意味と、統合マスタ側の列名が対応していなければならない。
たとえば、あるShapeが「径間1の特定部材の特定損傷評価」を示しているなら、その評価を格納する列が統合マスタに存在する必要がある。
この意味で、Shape読取処理とヘッダー生成は独立した処理ではあるが、仕様上はつながっている。
Shapeが意味する評価項目を列として受け止めるために、事前にスキーマが必要になる。
他自治体へ展開する場合の一般化
他自治体の橋梁点検調書へ展開する場合、同じヘッダーをそのまま流用できるとは限らない。
様式、評価項目、写真欄、部材構成、反復単位が異なる可能性があるためである。
一方で、一般化できる考え方はある。
- 固定項目と反復項目を分ける
- 反復単位を明示する
- 列名を手入力ではなく規則生成する
- 生成規則と実装処理を対応させる
- 候補マッピングと確定マッピングを分ける
- 人間が意味を定義し、機械が列を展開する
この考え方を使えば、自治体ごとにゼロから手入力でヘッダーを作るのではなく、帳票構造を解析し、規則として定義し、ヘッダーを生成する流れを作れる。
実装済みと未実装の境界
今回確認したのは、福島県版橋梁点検調書の単一橋・3径間サンプルを対象に、約1,900列規模の統合マスタヘッダーを生成し、既存成果から情報を取り込むところまでである。
複数橋、径間4〜6、別年度、別様式への完全なヘッダー確定は行っていない。
また、生成したヘッダーを使った評価結果一覧、差分抽出、整合確認、帳票再出力は未実装である。
したがって、この記事で扱っているのは、完成したスキーマ仕様の発表ではなく、自治体独自帳票の反復構造をどのようにデータモデルへ展開したかという設計実例である。
候補ヘッダーと確定ヘッダーを分ける
約1,900列規模のヘッダーを生成したとしても、それを直ちに最終スキーマとして扱うべきではない。
今回のPoCでは、単一橋・3径間サンプルを対象にしている。したがって、生成されたヘッダーは、少なくともその範囲で取込処理を受け止める候補構造であり、福島県様式全体に対する確定スキーマではない。
この区別は、製品実装では特に重要になる。候補段階のヘッダーを確定扱いにすると、後から別パターンの帳票が出たときに、列追加、列名変更、順序変更が発生しやすい。
一方で、候補ヘッダーとして明示しておけば、追加検証で何を確認すべきかが見える。径間数が増えた場合、写真数が増えた場合、部材構成が異なる場合、評価欄の使われ方が異なる場合に、どの反復規則を見直す必要があるかを整理できる。
ヘッダー生成は、単に列を作る処理ではなく、スキーマ候補を検証可能な形にする作業でもある。
まとめ
福島県版橋梁点検調書の内部PoCでは、約1,900列規模の統合マスタヘッダーを生成した。
重要なのは列数ではなく、固定項目と反復項目を分け、径間、部材、損傷、写真、評価といった反復構造を命名規則へ落とし込んだ点である。
ヘッダーは単なる見出しではなく、後段処理との契約である。Shape座標から読み取った評価情報、写真メタ情報、固定セル情報を受け止めるためには、業務上の意味を保った列構造が必要になる。
このPoCは福島県様式の完成スキーマではない。単一橋・3径間サンプルに基づく内部実証である。
それでも、自治体独自の神Excelを機械処理可能なスキーマへ翻訳する手順として、固定項目、反復構造、命名規則、機械生成の分離は、他の帳票対応でも再利用できる考え方である。
