デジタル庁がすすめている地方公共団体情報システム標準化の文書を見て、気がついたことです。2024年2月14日に掲載されたものを読んでいます。
間違っていたら、指摘をお願いします。
最新の仕様書はこちらです。
データ要件・連携要件の標準仕様
全般
ウォーターフォール という開発手法である。
そして、「要求を事前に詳細に定義することは困難である」があてはまる。
仕様を作成したら、プロトタイプを作成して、その仕様の検証を行って、仕様の不具合を洗い出し、より良い仕様にするということが行われていないようだ。
GitHub や、GitLab に、今の仕様または、ちょっと前の仕様で作成されたプロトタイプが
ないかと探しても、まったく見つからない。
重複が多い
次の定義が、数10箇所で行われている。
私は、エクセルシートの中で、もう10回以上、見ています。
数10あるシステムで、性別のコードが異なることに対応するように、実装するのは、
困難だし、バグが入るもとです。
テーブル名、コラム名
テーブル名、コラム名が、日本語でしか示されていない。
これは、実装する時に、各自が、英数字のテーブル名、英数字のコラム名を決めることになる。
それでは、データベース単位で、互換性を維持するのは、困難です。
A 社のデータベースをダンプして、B 社のシステムに取り込むことは、ほぼ不可能です。
API の定義
RestAPI を使うと記述してあるが、
エンドポイント、引数が定義されていない。これでは、クライアントが、A 社と B社の
システムにアクセスする時、サーバー名の変更だけで対応できない。
例えば、県庁のシステムが、X 市と Y市から、API で情報をもらうとして、X 市がA社、
Y市が B社のシステムを使っていると、データの授受がかなり困難になる。
願望
2025年度末というデッドラインに対して、ITエンジニアの負荷を減らす方法です。
例えば、MariaDB に仕様を満たす、データベースを構築してそれを公開すること。
そうすれば、そのままデータベースのスキーマが使えます。
例えば、Web サーバーを立てて、そこの API をたたけるようにすること。
そうすれば、どういう JSON が返ってくるか明確になるし、わざわざ、異なるコラム名
の JSON 出力を作成する必要がなくなります。
仕様の不具合
ID の重複
012_固定資産税 内の
012_固定資産税_基本データリスト【第4.0版】_20240214.xlsx
で、
データ項目ID の重複があります。
012 00974 がふたつあります。
012_固定資産税
日付のデータ型
028_子ども・子育て支援_基本データリスト【第2.3版】_20240214.xlsx
で
028-02117 登録日の型が、S9 (符号付き整数）になっている。
セルの書式指定のばらつき
データ項目ID の書式は、ほぼテキストです。
ただし、
018_就学事務（就学援助）_基本データリスト【第3.0版】_20240214.xlsx
の
018-01159
018-01160
の 018 は数になっています。
月データのサンプルが日付になっている
018_就学事務（就学援助）_基本データリスト【第3.0版】_20240214.xlsx
の 支給開始年月 のサンプルが、
テキスト 7文字でなく、
日付を、形式 '1999-12' で表している。その為に、サンプルデータは、
1964年7月でなく、1964年7月1日を意味している。
不適切なサンプル
022_障害者福祉_基本データリスト【第2.2版】_20240214.xlsx
に日付のサンプルとして、
2021-10-00
が挙げられている。
地域区分コード
023_介護保険_基本データリスト【第3.1版】_20240214.xlsx
で 地域区分コード は一桁なのに、二桁のサンプルが示されている。
更に状況は悪化しました。
2024年4月30日に新しい版がでました。
zip ファイルを解凍するとこうなります。
$ unzip 20240430_policies_local_governments_specification_02.zip
Archive: 20240430_policies_local_governments_specification_02.zip
inflating: ГfБ[Г^ЧvМПБEШAМgЧvМПХWПАОdЧlПСБiСНШ_БjБyСц4.0Ф┼Бz/ГfБ[Г^ЧvМПБEШAМgЧvМПХWПАОdЧlПСБiСНШ_БjБyСц4.0Ф┼Бz .docx
inflating: ГfБ[Г^ЧvМПБEШAМgЧvМПХWПАОdЧlПСБiСНШ_БjБyСц4.0Ф┼Бz/ГfБ[Г^ЧvМПБEШAМgЧvМПХWПАОdЧlПСБiСНШ_БjБyСц4.0Ф┼Бz .pdf
inflating: ГfБ[Г^ЧvМПБEШAМgЧvМПХWПАОdЧlПСБiСНШ_БjБyСц4.0Ф┼Бz/ГfБ[Г^ЧvМПБEШAМgЧvМПХWПАОdЧlПСБiСНШ_БjВ╠Х╧НXЧЪЧЁ.xlsx
2月14日公開になった zip ファイルではこうでした。
$ unzip 20240214_policies_local_governments_specification_outline_00.zip
Archive: 20240214_policies_local_governments_specification_outline_00.zip
creating: データ要件・連携要件標準仕様書（総論）【第3.1版】/
inflating: データ要件・連携要件標準仕様書（総論）【第3.1版】/データ要件・連携要件標準仕様書（総論）【第3.1版】.docx
inflating: データ要件・連携要件標準仕様書（総論）【第3.1版】/データ要件・連携要件標準仕様書（総論）【第3.1版】.pdf
inflating: データ要件・連携要件標準仕様書（総論）【第3.1版】/データ要件・連携要件標準仕様書（総論）の変更履歴.xlsx
何故、文字コードを UTF8 にしないのか理解に苦しみます。
解決方法
unzip -O sjis ***.zip
$ unzip -O sjis 20240430_policies_local_governments_specification_02.zip
Archive: 20240430_policies_local_governments_specification_02.zip
inflating: データ要件・連携要件標準仕様書（総論）【第4.0版】/データ要件・連携要件標準仕様書（総論）【第4.0版】 .docx
inflating: データ要件・連携要件標準仕様書（総論）【第4.0版】/データ要件・連携要件標準仕様書（総論）【第4.0版】 .pdf
inflating: データ要件・連携要件標準仕様書（総論）【第4.0版】/データ要件・連携要件標準仕様書（総論）の変更履歴.xlsx
他システムの参照
次の書類の中に
025_後期高齢者医療_基本データリスト【第3.0版】_20240430.xlsx
こんな表現があります。
後期高齢者医療広域連合電算処理システム外部インターフェース仕様書を参照
あまりにも、曖昧な定義です。
データ項目IDが同じで、データ項目名が異なる （個人住民税 010o008）
FAQ にこんな記述がありました。
質問: 連携ID：010o008で、データ項目IDが重複しているのはなぜか。
回答: 「個人住民税所得情報」「個人住民税控除情報」「個人住民税課税標準情報」
「個人住民税税額控除情報」については、基本データリストに記載のとおり、
コード値による正規化を行っております。そのため、Output時のデータ項目ID
は同一となります。
データ項目ID 010 00480 の データ項目名は、基本データリストで、「所得金額」と定義されています。
機能の重複
滞納管理の次の連携IDは同じ機能です。（受け取りシステムが異なります。）
015o001
015o021
健康管理の次も同じ機能です。データ集合名は異なります。
019o014
019o015
ダブルフィットのリスク
データ項目ID と データ項目の対応を複数ヶ所で記述している
地方公共団体基幹業務システム_基本データリスト（戸籍附票）【第2.1版】
地方公共団体基幹業務システム_機能別連携仕様（戸籍附票）【第2.1版】
