デジタル庁が手がける
 データ標準の取り組みについて
 2023-01-26
 10X 社会課題に挑むデータマネジメント
 @hase-ryo


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


！注意！　先週に似たような話をしています
 ● 1/18に開催された別イベントと
 8割は同じ内容です
 ● 前回発表時の質問等を踏まえ、標準を
 実装する時の考え方などを追加しました
 ● 今回はオープンデータの話はしません
 風音屋TechTalk #3 デジタル庁のデータ標準や
 オープンデータの民間活用を考えよう


アジェンダ
 1. 自己紹介＆イントロダクション
 2. デジタル庁でデータ標準を作りました
 3. データ標準が必要になった背景
 4. データ標準を作って得られる効果＆浸透施策
 5. さいごに　デジタル庁の目指す社会と宣伝


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


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


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


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


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


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


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


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


● 日付
 ○ 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
 コアデータパーツの記載ルールの例


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


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


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


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


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


自治体によって申請書の項目が違う！
 項目名の揺れ （異動日/転出日） アパート・ マンション名の有無 メールアドレスの 記載条件 ふりがなの有無 郵便番号の有無 続柄の有無

申請・認可などの行政事務は自治体ごとに独自設計
 ● 自治体ごとにシステムがある
 ○ DBなども自治体ごとに設計
 ○ データのフォーマットも自治体ごと
 ● 自治体を跨いだデータ連携の障害に
 ○ 活用が自治体内に閉じるなら問題ない 
 ● 標準がないことによる弊害
 ◯◯県△△市 オンプレ DB システムA 氏名 氏名カナ 住所 ××県□□市 システムB 姓名 住所 クラウド DB 変換が必要
 変換が必要


● 1対1ならばデータ変換を行なう
 コンバーターを介して連携可能
 ● しかし自治体の数は1700以上
 ○ それぞれの間にコンバーターを挟む のは現実的でない
 データ連携時に相互にデータ変換を行うにも限界がある
 A B C D E F

一方、地方業務標準化という大きな転換点が近づいている
 ● 自治体が行う基幹20業務を2025年 までに統一・標準化
 ● システムおよびデータを統一する千 載一遇のチャンス！
 2025
 基幹20業務 住民基本台帳、戸籍、戸籍の附 票、固定資産税、個人住民税、法 人住民税、軽自動車税、印鑑登 録、選挙人名簿管理、子ども・子 育て支援、就学、 児童手当、児童 扶養手当、国民健康保険、 国民 年金、障害者福祉、後期高齢者 医療、介護保険、生活保護、健康 管理 移行 ガバメントクラウド 共通基盤・機能 標準仕様 IaaS、SaaS、PaaS 標準準拠アプリ https://www.digital.go.jp/policies/local_governments/


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


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


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


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


4. データ標準を作って得られる効果＆浸透施策


相互運用性
 A B C D E F Standards

標準に従うと全員が受け取りやすくなる
 ● 一対一でその都度データの変換をするよりも、 連携の場に出す前に一度だけ変換をするほう が楽
 ● 標準に従った形式で場に出ると、データをやり 取りする主体が受け取りやすい
 ● 各システムの結合度も低くなる
 A B C D E F ポーカーのチップのように同じ形式で場 に出すと全員が受け取れる


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


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


既存システムに適用するならデータのアウトプット時に
 ● 既にシステムがある場合は、システムの外 側とデータ連携する際に標準形式に変換す るとよい
 ● システム内部の変更を最小にしつつ、他シ ステムとの相互運用性を高めることができる
 ● 設計段階から標準に準拠できるとより楽
 micro service A AccountId micro service B Standards user_id user_id 外側とやりとりする時に標準化する


標準はデータガバナンス施策の一つとして推進すべき
 ● 標準はデータガバナンスの１要素
 ● 全社への適用にはトップダウンの意 思決定と権限が大事
 ○ 行政は最強のトップダウンとして法律 を作るという手段がある
 標準化 標準化 ボトムアップで標準化を浸透させるのは中々難しい 
 トップダウンで広めるほうが結果的にコストが低い 


データガバナンスの推進には経営層の理解と投資が必要
 ● 標準に限らず、データガバナンスの推進 には少なからずトップダウンの力が必要に なる
 ○ 経営層の理解と投資が必要
 ○ ステークホルダーの巻き込み力、 
 プレゼン力などのソフトスキルが重要 
 データガバナンスが中央にあるのは大事かつ大変だから・・ 


5. さいごに　デジタル庁の目指す社会と宣伝


データの連携とオープンデータで次の段階の社会へ
 ● 現在は情報社会（Society4.0）
 ● 次の段階であるSociety5.0
 ○ 様々なデータがオープン化
 ○ それぞれが容易に連携
 ○ データを活用する製品の開発も容易 
 ○ 豊富なデータによるAIの生活実装
 ○ 情報リテラシーのハードルが下がる 
 ○ 社会システム全体の最適化
 ○ （・・になるかもしれない）
 
 
 https://www8.cao.go.jp/cstp/society5_0/


標準を作ったが、課題は山積み！
 ● 普及
 ○ 地方標準化には連携し、地方業務が GIFに沿って設計される流れに 
 ○ 国等の情報システムの統括・監理 の一環として標準を原則採用することが明記された 
 ○ しかし法律には書いてないので強制力はないのがネック 
 ● 簡素化＆サポート体制
 ○ データモデルなんて誰も知らない問題 
 ○ HowTo、メリット含めて個別にサポートしないと現場装着が難しい 
 ○ ガイドブックも難しい 
 ■ もっとシンプルに伝えやすいものを作る必要性あり 
 ● 継続的なアップデート
 ○ 教育、防災、医療など各分野に拡張した実装データモデルがないとすぐに使えない 
 ○ 既存モデルを実装する上でわかった問題点の修正。 
 ■ 1年経ってないが既に 11回改定リリース（政府文書としては異例？） 
 ● 推進体制
 ○ 進んでいる欧州と比べて貧弱な体制 


宣伝です
 デジタル庁
 中途採用やってます！
 https://herp.careers/v1/digitalsaiyo
 


Thank you!!!