データ要件の検討について

Transcript

1. 1 データ要件の検討について 2021.4.2 APPLIC 吉本明平 1 データ要件の現状 自治体に対するデータ要件を定める仕様として、現在主に l 特定個人情報データ標準レイアウト l 地域情報プラットフォーム標準仕様 l 中間標準レイアウト の三つの規格が存在する。 1.1 特定個人情報データ標準レイアウト 1.1.1 概要 行政手続における特定の個人を識別するための番号の利用等に関する法律（以下、番号法とい う）において定義された「情報提供ネットワークシステム」を介して交換される「特定個人情報」の データレイアウトを定義する規格。 番号法が対象とする事務手続きに関して法令所管の府省が調査、作成したデータレイアウトで ある。「地方公共団体における番号制度の活用に関する研究会」の検討による「地方公共団体に おける番号制度の導入ガイドライン」などの影響を受けている。 地域情報プラットフォーム標準仕様や中間標準レイアウトはデータ項目作成時に参照されている が、基本的に新たに作られたデータ項目標準であり、完全な互換性はない。 1.1.2 保守 番号法及び主務省令の改正にあわせて毎年 7 月に公開される「年次改版」と、番号法の根拠 法令改正に伴う情報連携対象機関の追加等に合わせて必要に応じて 4 か月おきに実施される 「定期改版」がある。 年次改版では各年度当初にβ版が公開され、自治体の意見を照会したのち、主務省令の交付 に合わせて 7 月に公開される。改定は主務省令の所管省庁が担当し、総務省個人番号企画室が 取りまとめる。自治体への交付は総務省によってデジタル PMO を介して行われる。 1.2 地域情報プラットフォーム標準仕様 1.2.1 概要 市区町村が利用している業務システム間のデータ連携を実現する標準仕様。マルチベンダー間 での情報連携を実現するために連携手順と連携対象のデータ項目を規定している。 市区町村が運用している各種業務は相互にデータ連携が必要である。従来、この連携について の基準がなかったため、同一ベンダーでシステムをそろえない場合、連携のための機能を個別実装 段階で構築する必要があった。結果、コスト高となりマルチベンダー化の障壁となっていた。この問 題を解決するための標準仕様である。
2. 2 当初、SOA(Service Oriented Architecture)を目指していたため、原則、オンラインによる即 時連携となっている。さらに全体最適化の観点から一つの情報は基本的にどれか一つの業務が保 有しており、他の業務は必要に応じて都度情報を取得するアーキテクチャである。 1.2.2 保守 一般財団法人全国地域情報化推進協会（APPLIC）において保守されている。APPLIC はパッ ケージベンダーなどの事業者と、地方公共団体の有志から構成される委員会体制を構築しており、 委員会における合議によって標準仕様が更新されている。 毎年、法改正などによる修正がなされており、原則年に一回、3 月頃確定し 5 月ころ公開され る。公開は同協会の Web サイトより会員向けに行われている。なお、過去年度の仕様については一 般公開されている。 1.3 中間標準レイアウト 1.3.1 概要 市区町村の業務システム更新時における円滑なデータ移行を可能とするための移行フォーマッ ト。自治体クラウドにおいて実装されているクラウドシステムへの移行を想定している。 業務システムを他ベンダーのシステムへと乗り換える際、既存のデータベースから新規のデータ ベースへデータを移行する必要がある。従来はシステム構築段階に個別対応であったが、コスト高 でありシステム移行の弊害となっていた。そこで移行対象データの標準レイアウトが作成された。 特定個人情報データ標準レイアウトや地域情報プラットフォーム標準仕様が異なる業務や事務 間のデータ連携フォーマットであるのに対し、中間標準レイアウトは同じ業務間のシステム移行 フォーマットである。前者が外部に提供する出力データの標準化であるのに対して、後者はシステム 内部で持つマスターデータベースの標準化に相当する。 1.3.2 保守 地方公共団体情報システム機構によって保守されている。実際には毎年度、同機構から委託さ れた事業者によって保守されている。 毎年、法改正などによる修正がなされており、原則年に一回 4 月に公開されている。公開は総務 省の自治体クラウドポータルサイトから行われている。 2 データ要件の課題 2.1 行政語彙の定義がない 上述の三規格はいずれもボトムアップに作成されたものである。すなわち、個々の業務が扱う情 報をそれぞれに整理、定義したものを集約して全体を作成している。逆に言えば、行政が利用する データ項目の全体像（以下、「行政語彙」という）を整理し、トップダウンの形で、その中から連携に 使われるもの、各業務で管理されるものを振り分ける形式をとっていない。 個別に整理したものの集約として全体像が作られているため、全体としての網羅性、整合性に不 十分な点がある。例えば、地域情報プラットフォーム標準仕様では業務ごとのインタフェースで定義 されているデータ項目について、同じ項目名称でも業務が異なれば違った意味内容になっている 可能性がある。特定個人情報標準レイアウトでは、同じデータ構造の連携データでも事務が異なれ
3. 3 ば違った連携データ種別として扱われている。 2.2 運用が統一されていない 三規格の運用はボトムアップが継承されており、個々の業務ごとの法改正対応などを都度行い、 改めて集約している。結果、全体としての整合性確認は厳密に行われていない。 さらに、三規格それぞれが別々に対応しているため、規格間の整合性確認も十分ではない。比較 チェックは行われているが、運用が個別であるため不要の手間がかかっている。 3 理想的なデータ運用 3.1 行政語彙の整理 行政で利用される語彙の全体体系（行政語彙）が整理されておれば全体整合性の確保は容易 になる。個々の仕様で利用するデータ項目は行政語彙の中から選択する運用とすれば仕様間の整 合確認はほぼ不要とできる。 ただし、行政語彙の整備は簡単ではない。“行政”の守備範囲は不明確であり、どこまでを全体 とするかの定義は難しい。また、異なる制度で利用されているデータ項目が同一意味内容のものな のか、関連性があるものなのか、独立したものなのかなどの判断も複雑である。民間との連携も多 く、官民どちらに決定権があるかも自明ではない。 少なくとも、 l 行政事務で利用されているデータ項目の洗い出し l それらの同一性・関連性の分析 l データ項目の集約、関連付け を実施し、全体語彙体系を整理する必要がある。 データ項目間の関係性表現などの表記法として情報共有基盤（以下、「IMI(Infrastructure for Multilayer Interoperability)」という）の成果が活用できる。 3.2 トップダウンの運用 行政語彙の整備は困難であるが、全体を整理し、そこから各仕様で利用するデータ項目を払い 出すトップダウン運用の効果は大きい。 特に、法改正や制度追加の対応において、個々の業務でデータ項目を検討するのではなく、行政 語彙全体のなかで整理できる。新規事務で必要となるデータ項目がすでに他の事務で定義されて いないか、初めてのデータ項目だったとしても既存項目と関連性、上下関係などはないのかといっ たデータ間整合性の確認を行いつつ業務横断の定義が可能となる。 そこから業務で管理するデータ、業務間で連携すべきデータといった視点で各仕様に反映させ ていけば全体としての整合性が確実なものとなる。 3.3 民間とのインタオペラビリティ確保 民間とのインタオペラビリティを考えると、すべてを行政側で決定することは困難である。民間と連 携するデータ項目は多く、発生源が民間である項目も多数存在する。それらを行政語彙として行政 主体にすべてコントロールすることは現実的ではない。 実際には、各業種（ドメイン）単位に語彙は整理され、それらの相互変換を可能とする方式が必
4. 4 要となる。ようするにドメイン間でデータ交換される場合、語彙を翻訳可能とする方式である。これに は IMI の成果の活用が考えられる。 行政語彙の観点では制度設計段階から行政語彙を十分検討し、さらに民間とのインタオペラビ リティについても並行して定義できれば制度導入をスムーズとすることが期待できる。 4 自治体業務システム標準化との関係 17 業務を手始めとした自治体業務システム標準化の検討とデータ要件の関係について整理す る。今後のデータ要件の整理は自治体業務システムの機能面は標準化される前提で議論する必 要がある。 4.1 システム標準によって確定するデータ要件 システム標準によって各業務システムが持つ“機能”が標準化されることでデータ要件の多くが 確定する。機能を実現するために必要なデータが合理的に定まる。さらに、機能の実現として例えば 帳票などの形でデータの入出力が具現化される。 ただし、システム標準としてのデータ要件の具体性は標準仕様の規定度合いに依存する。標準 仕様が抽象的な定義の場合、データ要件もおのずと抽象的になる。例えば、〇〇証明書といったレ ベルにとどまり個別の項目まで具体化しないといった場合が考えられる。 データ要件に求められる具体性の水準から逆に機能要件の具体化を求めるフィードバックも必 要となる。行政語彙として体系立てるデータ要件の定義と標準仕様としての機能要件の定義は相 互連携しながら進める必要がある。 なお、業務間連携データについてはデータの出し側、受け側双方の標準が確定しないと決定しな い。よって、17 業務全体の標準化が完了するまで完成しない部分がでる。 4.2 システムアーククチャに依存するデータ要件 自治体業務システム標準化は現時点ではシステムアーキテクチャまでは定めていない。今後、業 務要件や運用フローが定義され、ガバメントクラウドなどの検討が進むにしたがってシステムアーキ テクチャについても明確になることが期待されている。 データ要件はシステムアーキテクチャに直接依存することはない。論理的な設計はシステムの構 造に寄らず決定されるからである。標準仕様に定められた機能がどのような形で実現されるかに よって必要なデータ項目が変化するものでもない。 しかし、システム上データ項目をどこに実装するかはシステムアーキテクチャによって異なってく る。またデータ連携を合理化するにはアーキテクチャに最適化されたデータ要件の検討も可能であ る。この点については 6 トータルデザインとの関係に記述する。 5 行政語彙体系の整理 次に、具体的に行政語彙を整理する方法について検討する。行政語彙を体系的に整理するに は、全語彙の洗い出し、関係性の整理、取捨選択が必要である。 なお、行政語彙は行政で利用される帳票や連携データ項目などに現れる“制度上の語彙”であ る。よって、業務システムがどのようなデータベースでそのデータ項目を保持するかという“実装上
5. 5 の定義”とは独立して整理する必要がある。 5.1 全語彙の洗い出し まず、現在使われている語彙の洗い出しが必要である。 洗い出しには既存の標準仕様（特定個人情報データ標準レイアウト、地域情報プラットフォーム 標準仕様、中間標準レイアウト）や、機能標準で定義された帳票の諸元表、現行パッケージのデー タベース項目などが情報源となる。 これらの情報源から語彙に相当する候補をすべて洗い出す。名称だけでなく、意味内容について もこの後の判断に必要となる最低限の情報を合わせて抽出する必要がある。 5.2 関係性の整理 洗いだした語彙に対して関係性を整理する必要がある。関係性の定義については IMI の整理 方法が参考となる。 関係性には l 同一語彙 l 同一内容だが異なる名称 l 異なる内容だが同一名称 l ある語彙の内部構造（プロパティ） などが考えられる。 これらの整理はあくまで語彙としての整理であり、制度上の定義や意味内容をもとに実施すべき である。システムとしてどのように実装されているか、システム実装上の ER 図としてどのようになっ ているかとは本質的に別の整理である。 5.3 取捨選択 洗いだされた語彙は取捨選択を行い体系整理する必要がある。 まず、すべての語彙について行政制度上必要な語彙であったか精査する必要がある。不要なも のはできるだけ削除する。 同一内容で異なる名称のものについては統一する。その際、旧名称を同義語として管理するかは 要検討である。 一つの名称が異なる意味で使われていたものについては名称を分離する必要がある。その際に 分離された語彙の必要性について改めて吟味する必要がある。 5.4 システム実装との分離 これらの作業において語彙としての構造とシステム上の実装を混同してはならない。 たとえば、「住民基本台帳」という語彙は内部構造として「住所」という語彙を持っている。これは 制度上の「住民基本台帳」という語彙の定義である。 一方で、システム実装としての「住記マスタ」が「住所」を持たなければならないという制約はな い。もしかすると「住記マスタ」には「住所コード」を持ち、別に「住所辞書」に住所コードと日本語表 記の住所の対応表を保持するという実装も可能である。 この時、「住所コード」「住所辞書」はシステム実装上の工夫であり、行政語彙として収録すべき 名称ではない。もちろん、「住記マスタ」と「住所辞書」の間の ER 図などは語彙とは無関係である。
6. 6 一方で、たとえば「住所辞書」がベースレジストリとして整理されることになったとする。この時に は「住所辞書」や「住所コード」がベースレジストリから供給される情報として“行政語彙”に収録さ れることとなるだろう。 6 トータルデザインとの関係 データ要件とその実装方式にあたるトータルデザインとの関係整理が必要となる。行政語彙の定 義は論理的なデータ要件定義である。一方で、ガバメントクラウドやベースレジストリ、公共サービス メッシュなどの連携機構を含めたトータルデザインは、データをシステムに実装するアーキテクチャ にあたる。 論理的な定義と実装上の規定は階層が異なるため、同列に議論すべきものではない。しかしな がら、トータルデザインの整理の影響は大きいため、少なくとも以下の観点での確認が必要となる。 6.1 データ管理主体の決定 論理的に整理された行政語彙をシステムに実装するにあたって、どのシステムに実装するかは重 要である。それは制度上の管理主体と一致する場合もあれば、異なる場合もある。 制度上の業務とシステムが一対一対応の場合、データは管理主体となる業務を担うシステムに 実装されるのが通常である。地域情報プラットフォーム標準仕様における“業務ユニット”の定義が これに近い。ただし、業務ユニットはシステム実装を抽象化した概念のため、システムと単純に一対 一とはならない。例えば住民基本台帳と印鑑登録の両機能をもったシステムが実装可能で、この場 合そのシステムは一システムで住民基本台帳ユニットと印鑑登録ユニットを包含する。 さらに、業務システムから独立した“共通基盤”などと言われるシステム共通の機能部分にデー タを実装する場合も考えられる。ベースレジストリがこのような存在となるのか現段階では未確定で ある。しかし、業務システムとは別の実装という方式も整理しておく必要がある。 業務システムと別にデータが実装される場合、そのデータの登録、更新、削除などの運用フロー を明確に定義する必要がある。業務と独立しているため、一連の事務処理のどこがその情報を保 守するのかが不明確となるためである。 実装方式の設計がデータ要件に影響することは通常ない。データ要件は論理的なデータ構造の 定義であり、物理的な定義である実装方式はそれと独立に設計されるからである。しかし、データの 運用フローと整合性をとり、合理的な運用を実現するデータ要件の最適化という観点では影響を 受ける可能性もある。 たとえば、帳票の中に内部帳票と呼ばれるものがある。これは事務間の引継ぎのための帳票で ある。事務間の引継ぎ必要性や引継ぎ内容は業務フローや実装アーキテクチャに依存する部分が 大きい。これらの合理化、最適化に資するデータ要件のありようは検討可能である。 6.2 データ連携内容の定義方法 データ連携におけるプロトコル要件などの技術要素とデータ要件のような論理要素は本来、分 離すべきである。しかし、地域情報プラットフォーム標準仕様はデータ連携自体が目的のため、標準 仕様として技術要件も内包している。ただし、SOAP とか XML といった要件はプラットフォーム通信 標準として標準仕様内では独立させている。特定個人情報データ標準レイアウトも技術要件として は情報提供ネットワークが当然の前提となっている。
7. 7 トータルデザインにおける公共サービスメッシュや各種 API の定義方式は技術要素であり、デー タ要件とは独立したものであることが望ましい。しかし、地域情報プラットフォーム標準仕様や特定 個人情報データ標準レイアウトが実質的に技術要素を内包すること、技術要件がデータ定義の自 由度（データの型定義など）について実質的に制約要件となることなどをふまえ、トータルデザイン におけるデータ連携機能についても十分に確認しつつデータ要件の整理を行う必要がある。 以上