自治体システム標準化～データ要件・連携要件のキホンとギモン～
自治体システム標準化の柱の一つとも言える、データ要件・連携要件。業務間のインターフェースを統一するものだ。この成功のカギが”標準化”成功のカギとも言えよう。ところが、このデータ要件・連携要件も後手後手で二転三転は当たり前。弊社内でも認識・解釈がバラバラ。マルチベンダーにおいて、この状態でのドッキングは今のところ無理に近いと言える。
私は、さまざまなプラットフォームでこの問題を定義しても食いつきが悪い。どうも、界隈の方々は、PKGを担いでいるベンダーや、PKGベンダーでもインフラ回りの村人がほとんどだ（と、推察している）。冷静に考えると、自治体システムのPKGなんてのは無数にあるわけではない。インフラ回りに比べれば対応するベンダーの人間の数は限られる。今回の執筆は、自分の頭の整理としたい。どうせ、食いつきが悪い案件なのだ。ちなみに、食いつてくれる方は大歓迎だ。ぜひ、コメントやXで反応していただきたい。
①データ要件・連携要件のキホン
体系図を作ってみた。簡単に説明すると「データ要件」には、基本データリストと文字要件の標準を定義。「連携要件」には、機能別連携仕様や連携技術仕様の標準が定義されている。ポイントが、基本データリストと機能別連携仕様だ。
②基本データリスト
各業務・機能単位で必要とする全データ項目が定義さている。主キーなどの表記もあるから、RDBのテーブルイメージだ。今回の標準化においてのデータはこれが全てと言え、ベンダーシフト時は、この基本データリストのデータを授受すれば完了という国の目論見だ（それでうまく行くかは別）。下に示した仕様の通り、この基本データリストは任意のタイミングで入出力できなければならない。
ー 基本データリストって何に使うの？
基本データリストはあくまでも、自治体標準システムで持つべきデータの項目を定義しているのであって、業務間連携のインターフェースではないとも読める。利用用途が明記さているのは、EUC機能だ。EUC機能のデータソースは、基本データリストが原則と記されている。さらには、差分連携も可とあることから、標準準拠システムは基本データリストを全件と差分を入出力する必要がありそうだ。
③機能別連携仕様
自分の言葉ではうまく説明できないため、仕様を以下に記載する。
機能別連携仕様とは、標準準拠システムが機能標準化基準を実現するため、 標準化対象事務ごとに、機能標準化基準が規定する連携に関するデータ連携の要件（(a)どのような場合に、(b)どのデータを、(c)どの標準準拠システム等 に対し、どのように提供（Output）又は照会（Input）するか）についての標準を定めたものである。
機能別連携仕様は、「1処理、1ファイルのCSVが作成され、そのファイルが各業務毎（必要な業務のみ）のフォルダにコピー」される。
上図の例では、出力したファイルを、どの業務にどの項目が参照されるかを意味する。機能別連携仕様はこのような連携仕様が数多くあるのだ。Inputはその逆で自業務フォルダに置かれたファイルを開き、参照すべき項目が記されている。
基本データリストと機能別連携仕様のデータ関連は上図の２パターン。
基本データリスト 1：1 機能別連携仕様
基本データリスト N：1 機能別連携仕様
1処理１ファイルの原則としたいのだろう。N:1の場合、Outputの場合は、JOINする仕様を。Inputの場合は、分割する仕様を考えて、実装する必要がある。そして、なにより、機能別連携仕様では絶対に登場しない基本データリストの項目が無数にある。
④社内で意見が一致していること
ー パッケージ内統合DB
標準化の連携メインはCSV連携となった。いわゆるオールインワンパッケージ開発の弊社では（どこもそうだろうが）、共通化できるところは自社製フレームワークに落とこみ全体的な生産性と品質を担保する。フレームワークの対応として、CSVファイル連携とパッケージとの間をRDBのテーブルで管理することにした。InputもOutputもRDBをいったん挟むことにしたのだ。統合DBという仕掛けも考えられているそうだが、いわばパッケージ内統合DB（以後、この表現で統一）と言えよう。ここの方針は一致している。
⑤社内で意見が分かれること
ー パッケージ内統合DBの初期状態と稼働後
＜私の想定＞
自社業務・他社業務問わずリフト＆シフト直後のパッケージ統合DBには全業務の基本データリスト全件をぶち込む。稼働後は、機能別連携仕様により吐かれるCSVファイルで追加・更新していく。
＜他メンバーの想定＞
最初に言っておくが、私は他メンバーの想定は納得していない。
初期状態は、自社業務は基本データリスト全件。ここは同じ。
他社業務は、
①基本データリストを全件もらえるなら、稼働後は基本データリストの差分のみもらいたい。
②基本データリストをもらえないなら、初期データは機能別連携仕様CSVの全件（主キーが足りない場合は、適当に補足）。稼働後は、機能別連携仕様により追加・更新。
ー なぜ他メンバーの想定はパターンが分かれるのか？
曰く。機能別連携仕様のファイルでは、基本データリストと紐づける「主キー」がないものがあるらしい。主キーがないから、追加・更新できないと言うのだ。主キーがないと言っても、履歴番号とか最新フラグがないものが多いらしい。個人や世帯などは特定できるらしい。もっと言うと、できないというより、既存データと照らし合わせてよしなにキーを振るのが面倒というのが本当のところ。なんとかなるかなるかもしれないが、膨大な工数が必要ということらしい。
ー なぜ機能別連携仕様には主キーがないのか？国の回答
あくまでも、参照する側が必要な項目のみ定義しているから。
だそうだ。国の肩を持つわけではないが、パッケージ内統合DB方式はベンダーの競争領域の範囲の中での弊社の考えだ。すべてを、リレーショナルにするべきだ！までは暴論かもしれない。
⑥私の主張
ここまで読んでいたただいた方はお分かりだろう。機能別連携仕様は兎に角実装が面倒（面倒というより数が膨大）だ。それは、膨大な工数を必要とする。その割に、EUC機能を考えたときにデータが足りない。「帯に短し襷に長し」と言える。ベンダー側の反対（うわさ）でPUSH型API連携が否定された以上、もはや即時性は失われた。※弊社は疎結合で現在の即時性を担保するならPUSH型API連携派である。いろいろ課題はあるのだろうが。
話がそれたが、データ量や負荷もかかるのだろうが私は、基本データリストの差分連携だけでよいと考える。少なくても、即時性が必要なものと、そうでないものを整理し、そうでないものは日次で差分の入出力が良いのではないか？
⑦各ベンダーさんへ
稼働時、基本データリストの全件をいただけますよね？
稼働後、日次で基本データリストの差分をいただけますよね？
おわりに
正直、こればっかりやっているわけではないので、理解の解像度は、私は低いと断言する。ぜひ、違う意見や考えを伺いたい。もっと言えば、根本的に私のみならず弊社の考えが違うのかもしれない。
APPLICのGitで議論されている、基本データリストの項目への各社からの問い合わせや異議はいまだに活発だ。この活発さだけ見ても、システムの根幹たるインターフェースがまだまだ揺らぎそうだ。今回のデータ要件・連携要件はシステム屋から見ると不安要素しかない。もっぱら、運用費のコストが高い安いの話で盛り上がりがちだが、そもそも"動くシステム"ができるのだろうか？
2024/01/22追記
私の認識誤りが発覚しました。続編を投稿しましたのでご一読いただければ幸いです。
この記事が気に入ったらサポートをしてみませんか？