「続」自治体システム標準化～データ要件・連携要件のキホンとギモン～

先日執筆した「データ要件・連携要件のキホンとギモン」

どうも、私に認識誤りがあることが発覚した。そこの訂正をしないのは、無責任と感じ予定はなかったが、続編を今回投稿することとした。

①「機能別連携仕様」私の認識誤り

社内メンバーと議論する中で、私の認識誤りが発覚した。「文字の印象」と「実装イメージ先行」で国の仕様を斜め読みした結果であると反省する。
どう認識を誤っていたのかは、下図の通りだ。

私の認識誤り

「機能別連携」という文字から、出力する側の各業務各処理で更新された（更新される可能性のある）データ項目すべてを処理のタイミングでCSV出力するものと思っていた。 しかし実際は、更新されるデータ項目の中で他業務が参照に必要な項目で出力タイミングは任意なのである。

②なぜ私は認識を誤ったのか

前回の投稿の通り、データ要件・連携要件を実現するために、弊社ではRDBを介して実現することとしている。そして、テーブル構造は基本データリストだ。国の仕様のイメージもRDBとなっている”ように見える”。前回、それをパッケージ内統合DBと称した。

国仕様のファイル連携イメージ図

パッケージ内統合DBには標準20業務すべてを定義。自社業務だろうが他社業務だろうが、このパッケージ内統合DBをシステムの最新マスターと位置づけ常に最新状態を保つ発想だった。そして、そのパッケージ内統合DBを利用して共通機能EUCのデータソースとする考えだ。

共通機能EUC弊社想定フロー

だから「機能別連携仕様」は、各業務各機能のトランザクションの一環でパッケージ内統合DBを更新するのに都合の良い振る舞いであるべきというフィルダーで仕様を読んでしまったのである。

③認識誤り解消で生まれる新たなギモン

参照側業務視点で言うと、住民異動云々は関係なく、「自業務が必要とする処理対象の住民データの最新があれば良い」だけではないのか？
ほぼほぼファイル連携となった現仕様。そして、即時性を仕様で強制されるのものは数える程度。だったら、「機能別連携仕様」で定義する意味はなんだろうか？ようは、出力側の処理単位のファイルを投げられても、参照側は困るのではないか？

― 国が当初想定のAPIメインから脱却できていない？

データ要件・連携要件の紆余曲折は以下の通りと推察している。
「API連携」と「ファイル連携」。似て非なるものだが、「API連携」前提の考えになっているのではないか？

推察する紆余曲折

― 即時性を謳わない以上、機能別連携ではなく基本データリストの差分でよいと考える

連携頻度（即時規定は僅か）

機能別＜処理単位（トランザクション単位）＞でPUSHし、相手方のマスターを更新させるという目的がない以上、機能別連携仕様のOUTPUTの存在意義をいまいち見出せない。だったら、任意のタイミグの基本データリストの差分授受で良くないか？

④まとめ

まず大前提としてまだまだ私の認識誤りがあると考える。当面の課題は、「機能別連携仕様」の存在意義を見出すことだ。ぜひ、ご教授いただける方はお願いしたい。一方で、前回投稿のアクセス情報を分析すると、早いペースで多くの方にご覧いただいた。が、他の案件に比べ反応が薄い。まだ時期尚早なのか？もう少し推移を見守り、次回は「シン」という冠で執筆でもしようかと考えている。