デジタル庁が手がける データ標準とオープンデータ / 20230118

風音屋TechTalk #3「デジタル庁のデータ標準やオープンデータの民間活用を考えよう」の登壇資料です。

風音屋TechTalkは、風音屋（@kazaneya_PR）のクライアントや社員が気になっているテーマについて有識者から話を聞いたり、最近の取り組みやテクノロジーについてカジュアルに話す勉強会です。
第3弾となる今回は、デジタル庁の長谷川様と株式会社バンダイナムコネクサスの吉村様をお招きして、デジタル庁が公開している政府相互運用性フレームワークやレジストリカタログを民間でどのように活かすか模索します。

Transcript

1. デジタル庁が手がける
 データ標準とオープンデータ
 2023-01-18
 風音屋TechTalk #3
 @hase-ryo

2. この発表の目的・対象
 • この発表の目的
 ◦ デジタル庁が手がけるデータ標準＆オープンデータの取り組みを知ってもらう こと
 ◦ データ標準の意義を伝え、データ基盤やデータ・ビジネスの設計に
 役立つヒントとしてもらう
 ◦ オープンデータ活用のきっかけを得る
 • 想定する聴衆の対象
 ◦ データ分析基盤に関わるデータエンジニア
 ◦ 社内外のデータを連携するプロダクトに関わるPdM、BizDev
 ◦ その他データから価値を取り出したい人全般

3. アジェンダ
 1. 自己紹介＆イントロダクション
 2. デジタル庁でデータ標準を作りました
 3. データ標準が必要になった背景
 4. データ標準を作って得られる効果とは
 5. オープンデータの現状

4. 1. 自己紹介
 • 経歴
 1. インテージでデータ整備とデータ基盤 
 2. Webメディア等をフラフラしてデータ分析 
 3. メルカリでデータ分析とデータマネジメント 
 4. デジタル庁（週４） + メルカリ（週１）
 ＆データ経営コンサル『風音屋』アドバイザー 
 • 現在の業務
 ◦ データ戦略に基づくデータマネジメント 
 ◦ 社会の基本的データ（ベースレジストリ）の開発 
 ◦ デジタル庁内のデータ分析基盤立ち上げ 
 ◦ その他オープンデータ施策など 
 長谷川　亮 / hase-ryo

5. デジタル庁 =
 デジタル社会を実現するための省庁
 主なプロダクト・政策としては
 • マイナンバー
 • 電子署名
 • ガバメントクラウド
 • サービスデザイン
 • 新型コロナウイルス接種証明書アプリ
 などなど・・
 デジタル庁の紹介
 トップは河野太郎デジタル大臣 
 毎週メッセージ配信中！ 

6. 最近の成果
 マイナンバーカードのダッシュボード
 
 
 
 
 
 
 構築・公開しました！主に基盤を担当
 （GCPでBigQueryを中心に構築）
 首相官邸HPにも掲載↑

7. 今日まず話すのはこちら
 政府相互運用性フレームワーク
 （Government Interoperability Framework; GIF)
 じー・あい・えふ

8. まずはデータ標準についてです
 https://www.meti.go.jp/policy/economy/hyojun-kijun/katsuyo/business-senryaku/pdf/001.pdf

9. 2. デジタル庁でデータ標準を作りました

10. GIF; 政府相互運用性フレームワーク
 • データの相互運用性を高めるため データ標準群を規定 = GIF
 • 行政間、官民間でデータ連携の
 基礎パーツとなることを想定
 • githubで公開しています
 https://github.com/JDA-DM/GIF

11. GIF; 政府相互運用性フレームワークの内容を紹介①
 • 基礎的な項目をコアデータモデルとして 策定
 ◦ 「個人」「法人」「住所」など
 • 個別の事物・事象をデータとしてモデリ ングする際、参考情報として利用される ことを想定
 https://github.com/JDA-DM/GIF/blob/main/430_コアデータモデル /md/431_core_datamodel_person.md
 ID 性別 氏 生年月日 名 世帯主 氏（カナ） 既婚・未婚 名（カナ） 配偶者 氏（英字） 子 名（英字） 連絡先情報 ・・・ ・・・ 「個人」データモデルの項目例

12. • 日付
 ◦ YYYY-MM-DD
 ▪ YYYY: 西暦年4桁
 ▪ MM: 月2桁（1桁の場合は0埋め）
 ▪ DD: 日2桁（1桁の場合は0埋め）
 • 曜日
 ◦ 月曜日を1、・・・、日曜日を7
 • 住所
 ◦ 都道府県
 ▪ 東京都
 ◦ 市区町村
 ▪ 千代田区
 ◦ 町字
 ▪ 紀尾井町
 ◦ 番地以下
 ▪ 1-2
 ◦ 建物名等（方書）
 ▪ 紀尾井町ガーデンテラス19F
 GIF; 政府相互運用性フレームワークの内容を紹介②
 • 細かな記載ルールはコアデータパーツ として策定
 ◦ 日付や電話番号の記述形式など 
 • データフォーマットのルールとして利活 用されることを想定
 https://github.com/JDA-DM/GIF/blob/main/440_コアデータパーツ /md/441_core_dataparts_datetime.md
 コアデータパーツの記載ルールの例

13. コアデータパーツ 日付 住所 GIF; 政府相互運用性フレームワークの内容を紹介③
 • 各分野に向けた実践データモデル を策定
 ◦ コア要素を組み合わせて構成
 ◦ 行政事務、教育、防災など
 • 各分野のモデリングが必要な場合 に参考情報として活用
 ◦ 分野ごと、個別事例ごとにカスタマ イズして活用する
 https://github.com/JDA-DM/GIF/blob/main/410_全体説明 /md/410_overview.md
 個人コアデータモデル 氏 名 連絡先 ・・・ 性別 生年月日 コアデータパーツ 日付 住所 法人コアデータモデル 法人番号 正社員数 ・・・ 商号 組織種別 実践データモデル行政 : 申請データモデル 宛先 申請日 内容 申請者 ・・・ 申請データモデルの例

14. GIF; 政府相互運用性フレームワークの内容を紹介④
 https://github.com/JDA-DM/GIF/blob/main/460_実践ガイドブック /md/468-1_guidebook_dataquality.md
 • その他ガイドブックを策定
 ◦ データ品質
 ◦ 行政向けの・・
 ▪ データマネジメント
 ▪ マスターデータ
 ▪ コード分類体系
 ◦ データ人材体系
 ◦ メタデータ体系
 ◦ などなど・・

15. なんでそんな地味なもの作ってるの？

16. 3. データ標準が必要になった背景

17. つらい現状を紹介：引越し時の転出届（例）

18. 自治体によって申請書の項目が違う！
 項目名の揺れ （異動日/転出日） アパート・ マンション名の有無 メールアドレスの 記載条件 ふりがなの有無 郵便番号の有無 続柄の有無
19. 申請・認可などの行政事務は自治体ごとに独自設計
 • 自治体ごとにシステムがある
 ◦ DBなども自治体ごとに設計
 ◦ データのフォーマットも自治体ごと
 • 自治体を跨いだデータ連携の障害に
 ◦ 活用が自治体内に閉じるなら問題ない 
 • 標準がないことによる弊害
 ◯◯県△△市 オンプレ DB システムA 氏名 氏名カナ 住所 ××県□□市 システムB 姓名 住所 クラウド DB 変換が必要
 変換が必要

20. • 1対1ならばデータ変換を行なう
 コンバーターを介して連携可能
 • しかし自治体の数は1700以上
 ◦ それぞれの間にコンバーターを挟む のは現実的でない
 データ連携時に相互にデータ変換を行うにも限界がある
 A B C D E F
21. 一方、地方業務標準化という大きな転換点が近づいている
 • 自治体が行う基幹20業務を2025年 までに統一・標準化
 • システムおよびデータを統一する千 載一遇のチャンス！
 2025
 基幹20業務 住民基本台帳、戸籍、戸籍の附 票、固定資産税、個人住民税、法 人住民税、軽自動車税、印鑑登 録、選挙人名簿管理、子ども・子 育て支援、就学、 児童手当、児童 扶養手当、国民健康保険、 国民 年金、障害者福祉、後期高齢者 医療、介護保険、生活保護、健康 管理 移行 ガバメントクラウド 共通基盤・機能 標準仕様 IaaS、SaaS、PaaS 標準準拠アプリ https://www.digital.go.jp/policies/local_governments/

22. さらに、国内で行政のデータ連携が活発になる（予定）
 • 地方創生施策の一つにデータ 連携基盤の構築がある
 ◦ デジタル田園都市国家構想
 • 地方自治体を国が支援（💰）
 • 官民相互のサービス利活用促 進のインフラとする（予定）
 https://www.cas.go.jp/jp/seisaku/digitaldenen/

23. • 標準がないことによるデータ連携時の弊 害は民間企業の内でも起こる
 ◦ 特にマイクロサービスアーキテクチャ 
 • 標準がないと各開発チーム、各サービス ごとに独自規格で開発されがち
 ◦ 各サービス単位では問題ない
 ◦ 横断的なデータ連携を考えると課題に 
 似たようなことは企業内データ連携でも起こりうる
 micro service A micro service B micro service C user_id Customer_id AccountId convert convert convert サービス間で表現が違うと、連携のたびに変換が必要 

24. 結論：早めに標準を作っておかないと死ぬ
 （主に我々データエンジニアが）

25. 参考：EUは相互運用性のために法律まで作る勢い
 • EUは行政のデータ基盤開発が先行
 • 欧州相互運用性フレームワーク
 ◦ EIF（GIFの元ネタ）
 • EIFをベースとした法律を整備
 • 欧州各国間でのデータ連携の障壁を 取り除こうとしている
 https://joinup.ec.europa.eu/interoperable-europe/policy

26. 4. データ標準を作って得られる効果とは

27. 相互運用性
 A B C D E F Standards
28. データ標準は相互運用性を高め、データ連携に貢献するためにある
 A B C D E F A B C D E F Standards データが1対1で連携
 標準に従って連携
 相互運用性 高
 低
 システム結合度 低
 高

29. データ連携のコストを下げる相互運用性
 • 企業内でも標準ルールに従ってデー タの設計・開発を行うことでデータ連 携が楽になる
 ◦ 連携コストDOWN↓
 ◦ 解釈容易性UP↑
 ◦ 新規開発速度UP↑
 • 後から標準にあわせるのは難しい
 micro service A micro service B micro service C user_id user_id user_id 事前に標準が決まっていると連携が楽

30. データの連携とオープンデータで情報社会の次の段階へ
 • 現在は情報社会（Society4.0）
 • 次の段階であるSociety5.0
 ◦ 様々なデータがオープン化
 ◦ それぞれが容易に連携
 ◦ データを活用するサービス・製品開発 も容易
 ◦ （・・になるかもしれない）
 
 
 https://www8.cao.go.jp/cstp/society5_0/

31. 5. オープンデータの現状

32. 行政はオープンデータに積極的です
 • 官民データ活用推進基本法で国及び地方公 共団体はオープンデータに取り組むことが義 務付け
 • 様々な原則
 ◦ 府省庁が保有するデータは原則公開 
 ◦ 二次利用ルールやライセンス付与 
 ◦ CSVやXMLレベルの構造化データ
 ◦ 迅速に公開
 ◦ 適切に更新
 https://www.digital.go.jp/resources/open_data/
 府省庁 自治体 ・二次利用可能なルール ・機械判読に適した形式 ・無償 オープンデータ
33. オープンデータを探すならまずはカタログサイトから
 https://ckan.org/ ・WebUI / API ・検索 ・DL (Web & API) 自治体A カタログサイト 自治体B カタログサイト ・・・ • オープンデータの公開場所としてカタ ログサイトを導入する場合が多い
 • CKANというOSSが広く採用される
 • WebUIとAPI
 ◦ APIでデータセット単位の検索
 ◦ APIでDLも可能

34. 様々なカタログサイトでデータが公開されている
 • 各自治体や府省庁でCKANベースの カタログサイトが公開
 • 他のCKANと情報連携する機能（ハー ベスティング）がある
 • ハーベスティングをフル活用したデー タカタログ横断検索システムがおすす め
 https://search.ckan.jp/ データカタログ横断検索システム 
 DATA.GO.JPデータカタログサイト 
 https://www.data.go.jp/data/dataset レジストリカタログサイト 
 https://catalog.registries.digital.go.jp/ TOKYO OPEN DATA
 https://portal.data.metro.tokyo.lg.jp/
35. そんなオープンデータ提供者の実際は・・

36. 活用事例求ム！

37. すべてのオープンデータ提供者は活用事例を求めている
 • 事例の少なさによる負のサイクル
 ◦ 整備作業の負担
 ◦ 優先度の低下
 ◦ 量・質の担保停止
 ◦ （利用者側では）クレンジングの手間 やデータ品質の低下
 • オープンデータ100と題して活用事例を募 集中！
 ◦ 事業者や自治体による事例紹介する 企画
 https://form-www.digital.go.jp/resources/open_data/case_study_contact
38. オープンデータ ✖ データ標準 = Linked Dataという未来
 • データをグラフ構造で表現するRDF（Resource Description Framework）という仕組みがある
 • RDFで記述されたデータは機械可読性が高い 
 ◦ データとその定義（標準含む）がオープンになっ ている前提
 ◦ ネットワーク経由で全ての定義がわかる 
 ◦ 項目間の関係性もわかる
 • オープンデータの行き着く先はRDF形式の公開デー タ = Linked Dataと言われる
 リソースA 文字列α リソースB プロパティ①
 リソースC プロパティ②
 プロパティ③
 定義
39. 最後に宣伝です
 デジタル庁
 中途採用やってます！
 https://herp.careers/v1/digitalsaiyo
 

40. Thank you!!!