デジタル庁のデータ分析基盤「sukuna」
はじめまして。デジタル庁ファクト＆データユニット所属、データエンジニアの長谷川です。
本記事ではデジタル庁内でデータ活用を推進するための組織と分析基盤についてご紹介します。 これまでのデジタル庁noteと比べると、技術寄りの話題が多い記事となりますが、庁内のデータ活用に興味のある方はぜひご覧ください。
デジタル庁のデータ活用組織「ファクト＆データユニット」
ファクト＆データユニットとは
デジタル庁の特徴の一つに、デジタル分野において各種の専門性をもつ「民間専門人材」が多く所属していることが挙げられます。
民間の専門人材は、デザイン、プロダクトマネジメント、エンジニアリングなど、領域ごとに「ユニット」と呼ばれる組織を構成しており（参考：デジタル庁 - 組織情報）、必要に応じてさまざまなプロジェクトにアサインされて業務を遂行する、人材プールのような役割を果たしています。
ファクト＆データユニットもそのうちのひとつであり、政府内におけるデータの分析・可視化といった利活用を専門的に行う役割を担っています。
組織上の構成としては、デジタル庁の事務方のトップである「デジタル監」の直属の組織であり、ユニット長以下10名弱（2023年6月時点）で構成されています。データエンジニアやデータPMを中心に、行政官やデザイナーなどと連携をしながら仕事を遂行しています。
業務について
データ分析の内製化による好影響
ファクト＆データユニットのスコープとして、データに基づく意思決定に関わる初期工程から最終工程全体を対象に、それらを一気通貫でカバーできる体制を取っています。具体的には以下の通りです。
政府内に散在するデータの収集
データの貯蓄・管理
分析向けのデータマートの設計・整備
そのためのデータ基盤の整備
データの可視化・分析プロジェクトの推進
そのため、これまで省庁がデータ活用を行う際に一般的な方法であった「ベンダーへの分析・レポーティング機能の委託」という手法に比べて、遥かに柔軟に、かつ俊敏に、また実情に沿ったデータ活用が可能になっています。
これは、デジタル庁および政府が掲げるデジタル原則の「データに基づくEBPM」「機動的・柔軟」といった理念を体現するものと考えています。
このようにデータ分析を内製化することで、デジタル庁や政府内での政策・プロジェクトにおいて、よりデータの利活用につながる機会が増えていくことを狙います。またそれにより、以下のような政策運営上のポジティブな効果が期待できます。
適時のデータの可視化・関係者間での同期的な共有を可能にする。それによって、大規模・複雑なプロジェクトにおいての状況の把握や関係者の共通認識の形成が行われ、より円滑な政策の進行が実現される。
政策に関して、万人に理解しやすい定量指標の可視化を行い、より更新性高くそれらの情報を公開することで、政策の透明性を担保する。それにより国民の政府への信頼性向上や、自治体への適切な情報共有などがはかられる。
データという「利用者の声」に基づく、利用者本位のサービス設計を推進する。
デジタル庁HPでは、定期的に「政策データダッシュボードの公開」を行っておりますが、まさにこちらはデータ分析の内製化によって実現できたことの一例です。
活動領域とミッション
民間企業では一般的に、「BtoC」「BtoB」などと、価値の受益者が誰かによって事業種別が区分されています。
一方で、政府およびデジタル庁においても、非常に幅広い政策プロジェクト・システムの運営が行われているため、これと近い整理をすることができます。以下にいくつか例をあげてみます。
C = 国民向け : マイナポータル、マイナンバーカードを使った認証など
B = 事業者向け：GビズID、事業者補助金申請、デジタル化のための制度改革 など
G = 行政向け：自治体のシステムの標準化、政府内の業務システムの管理、ガバメントクラウド など
ファクト＆データユニットは、これら各種の領域の中でも特にデータの可視化・分析によって付加価値をつくることができる分野を取捨選択し、データ活用や政策推進の支援を行っています。
前提として、先進的な民間企業等の水準と比べると、日本政府では「データを使うこと」の価値が浸透しているとは言い難い状況です。これは残念なことにも思えますが、一方で大きなポテンシャルがある、とも言えます。
その背景には、文化的な側面や、委託事業者との関係性、技術面や知識面のズレ、人材不足という課題など、さまざまな要因があって浸透していないものと考えられています。
ファクト＆データユニットは、そのような状況を打破するために、政府内で多くのデータ活用事例を創出し、「政府において、データを使うをアタリマエにする」というミッションのもと活動に取り組んでいきたいと考えています。
データ分析基盤「sukuna」
意思決定を支えるデータ分析基盤の内製
ここまで紹介したデータ活用のための活動を支えるのがデータ分析基盤です。 政府組織内の様々なデータを収集・統合し、ダッシュボードやデータ分析で参照できるように整備しておくためにはデータ分析基盤が欠かせません。
そこで、 ファクト＆データユニットでは、データ分析基盤を内製して運用しています。
データ分析基盤「sukuna」
ファクト＆データユニットで運用しているデータ分析基盤は「sukuna」と名付けられています。その役割は府省庁がもつデータの一部を収集・蓄積・加工し、データ分析可能な状態にすることです。
sukunaはガバメントクラウド（※1）のGCP(Google Cloud Platform) （※2） 上に構築されており、比較的モダンなサーバーレス構成としています。 GCPが提供するサービスをフル活用することで、民間専門人材が少人数で内製開発・運用できています。構成の詳細についてはこの後の章で詳しくご紹介します。
（※1）ガバメントクラウド：政府共通のクラウドサービス利用環境のこと。民間のパブリッククラウドサービスから公募・決定されたものを指す。
（※2）GCP(Google Cloud Platform) ：Google Cloud社が提供するクラウド環境プラットフォーム。
sukunaの命名理由
余談ですが、sukunaの名称は古事記や日本書紀などの日本神話に登場する少名毘古那神（スクナビコナノカミ、またはスクナビコナノミコト）から取っています。
少名毘古那神には日本神話の時代に地方視察をつぶさに行い、農耕、酒造、医療などの知識でもって国造りを助けたという逸話があります。
その姿勢が、「現場からファクトとデータを集め、より良い国づくりに貢献する」というファクト＆データユニットの方針と重なるところがあり、sukunaという名前をつけることにしました。
sukunaの構成と技術スタック
ここからはデータ分析基盤sukunaの機能と環境構成を全体のアーキテクチャを踏まえながら解説します。
技術的な内容が続きますので、データ分析基盤によって得られたメリットなどを知りたい方は、次章「sukunaによって得られたメリット」まで読み飛ばしてください。
環境とアーキテクチャ
こちらはsukunaの全体アーキテクチャの簡略図です。 sukunaはガバメントクラウドのGCP上に構築されており、GCPが提供している様々なマネージドサービスを活用しています。
sukuna上で処理されたデータは最終的にMicrosoft社のBIツールであるPowerBIでダッシュボード化され、デジタル庁内の関係職員が意思決定に活用しています。
一部は政策データダッシュボードのように国民向けに一般公開しているデータもあります。 活用しているサービスを含む技術スタックを列挙すると以下のようになります。
Google Cloud Platformのサービス群
Cloud Storage (ストレージ）
Cloud Pub/Sub (メッセージング）
Cloud function（簡易な関数処理）
Cloud Run（コンテナアプリ処理）
BigQuery（データウェアハウス）
Dataplex（メタデータ管理）
Cloud Monitoring（ログモニタリング）
Cloud Build（CI/CD）
その他、Cloud IAMやSecurity Command Centerなど管理系サービス
PowerBI（ダッシュボード）
dbt（データ加工処理管理）
Terraform（構成管理、IaC）
Docker（コンテナ）
Github Enterprise（コード管理）
python（メイン開発言語）
※上記内容は2023年6月時点の情報であり、今後変わる可能性があります。
sukunaの機能概要
データ分析基盤であるsukunaの主な機能はデータのパイプラインです。すなわち、sukunaはデータを取得し、蓄積・加工し、データアナリストやダッシュボードの元に届けるまでの一連の流れを担っています。
データパイプラインの各プロセスはGCPのサービスを組み合わせ、サーバーレス処理を採用しています。データ量や処理の数に従ってスケールしやすいこと、また運用負荷が低く、少人数でも運用しやすいといった点が採用理由です。
また、データをただ届けるだけでなく簡単にかつ高速に使えること、さらには、データアナリストが簡単にデータを扱えるようにするための適切な加工とモデリングも重要な要件となります。
こちらは、BigQueryという高速なデータウェアハウスを採用し、またBigQuery上でのデータの加工においてdbtというソフトウェアを使うことで実現しています。
sukunaの機能詳細① APIからExcelまで、様々なデータソースからデータを取得する
sukunaでデータを処理するには、まずデータを取得し、sukunaの環境内に取り込む必要があります。 データソースとなるのはデジタル庁や他省庁が運用している政府情報システムの一部です。
各情報システムが具備しているAPIから自動取得を試みることもあれば、クラウドサービス間のデータ連携サービスを使うこともあります。
また、半手動運用として、政府情報システムを運用している委託事業者から受領するExcelレポートをデータソースとして加工・取り込む場合もあるなど、データ取得部分は様々なパターンがあります。
それぞれのパターンごとにCloud functionを使ってデータを取得し、一定の前処理を挟んだ上でスナップショットとしてCloud Storageに保存しています。
ただし、API等で常にデータが取れる状態でない限り、データの取得が可能な時間帯は不定であることが多いです。特にExcelレポートなど人手を介して作られるデータソースの場合はその傾向が顕著となります。
そのため、バッチ処理的に決まった時間にデータ取得を試すというよりは、一定のトリガー条件に従って取得処理が行われるイベントドリブンな仕組みにしています。
sukunaの機能詳細② 取得したデータは高速なデータウェアハウスであるBigQueryに格納する
データの取得を検知し、データウェアハウスへ格納する処理が行われます。
データの格納部分は様々な理由でリトライが付きものなので、リトライを容易に行えるように、データ取得部分とデータ格納部分は疎結合な仕組みとしています。
処理の冪等性を担保しつつ、新しいデータが取得できてれば自動で格納処理やリトライが動くようにしています。 これにより、データ取得部分とあわせて大部分を自動化し、運用負荷を下げています。
格納先であるデータウェアハウスとしてはBigQueryを採用しています。 大規模データに対して高速にクエリを実行することができる強力なツールです。
BigQueryを使うことによるメリットについては後の章でも紹介します。
sukunaの機能詳細③ 取り込んだデータはdbtで使いやすい形に加工する
データ分析基盤の構造としてよく語られるのが、以下の３層に分ける構造です。
データレイク（データをそのまま貯めておく場所）
データウェアハウス（データを使いやすく加工・整理した上で貯めておく場所）
データマート（特定のビジネス目的にあわせて加工され、ダッシュボードなどから参照される場所）
sukunaではこれらを全てBigQuery上で実現しています。 データソースごとにこれら3層のデータの入れ物（データセット）を用意して、それぞれ分離できるような構成にしています。
このように分けているのは、データの整理整頓の意味もありますが、大きな理由はデータの権限管理を行いやすくするためです。
これらデータセット間および個別データ間の加工処理はdbtというソフトウェアで行っています。 dbtはData Build Toolの略であり、その名の通りデータウェアハウス全体をビルドする感覚で必要なデータの加工を行うことができます。
主な用途としてはデータマートの作成です。 PowerBIから参照されるデータであったり、データアナリストが参照するための使いやすいデータをdbtで作成しています。
これらデータの加工ロジックにはビジネス的な要求が組み込まれることが多く、属人化しやすい領域です。そのため、加工ロジックはdbtのコードとしてGithubで管理し、ロジックの書き方についても規約を定めるなど、属人化を軽減する仕組みを導入しています。
sukunaの非機能概要
ここまで紹介した機能以外にも、安心で安全なデータ分析基盤を運用するために様々な非機能群が必要となります。
開発を円滑に行うためのCI/CDパイプライン構築や、インフラ設定のコード管理などは、GCPのサービスや業界内でデファクトスタンダードとなる技術を採用し、運用負荷を下げつつ実装しています。
また、データは資産ですので、資産活用によるリターンと同時に、資産を盗まれたり流出するリスクが存在します。特に政府情報システムは様々な個人情報を保有していますので、それらシステムと連携するsukunaは常にリスクと隣合わせになっています。
詳細についてここでは触れませんが、これらリスクを統制するため、デジタル庁内のセキュリティやプライバシーの専門家チームと連携して様々なリスク低減措置を導入しています。
sukunaの非機能詳細① データの権限はメンバーごとに範囲を制御する
現状、sukunaの環境を直接利用できるのはファクト＆データユニットのメンバーのみとしています。
つまり、デジタル庁内の職員に向けて、広くデータ分析基盤を公開しているわけではありません。 Unitのメンバーに対して付与している権限もレベルを分け、メンバーごとに閲覧できるデータの範囲を制御できるようにしています。
データの取得・加工等に使用しているGCPのサービスアカウントについても細かめに権限を分け、強すぎる権限が付与されないように制御しています。
一方で活用できるデータの範囲が限定されすぎると、データの横断活用による価値創出ができなくなりますので、攻めと守りのバランスを取りながら、柔軟に権限管理を行えるようにしています。 これらの権限管理はCloud IAMと、後述するTerraformで行ってます。
sukunaの非機能詳細② 構成管理はTerraformでIaC管理、GithubとあわせてCI/CDを実現
sukunaで利用しているGCPの各サービスの設定はTerraformで管理し、IaC（インフラ設定のコード管理）を実現しています。 コードについてもGithub Enterpriseで管理していますので、Github ActionsとTerraformの組み合わせでCI/CD（自動化されたテストやデプロイ）環境を構築しています。
sukunaの非機能詳細③ Dataplexによるメタデータ管理
sukunaで扱うデータの種類が増えてくると、データを理解したり、適切にガバナンスを効かせて管理するためのコストが増大します。 そのため、データを説明するデータであるメタデータの管理が重要となります。
sukunaではシステム的なメタデータ管理にDataplexを採用しています。 データソースの在処やデータの取得時間、データの性質にあわせた権限管理のレベルなどのメタデータが対象となります。
sukunaの非機能詳細④ セキュリティとプライバシーのリスクを制御するプロセス・ルールと体制
sukunaではデジタル庁内のセキュリティ専門家チーム、プライバシー専門家チームと連携してデータ管理方法を決定しています。セキュリティ面ではガバメントクラウドとして求められるセキュリティ対策による予防とともに、リスクを早期発見するための施策を導入しています。
プライバシー面ではデータソースからデータを取得する際、個人情報やそれに類する機微情報が含まれる場合は、特定個人が識別不可能な状態に加工してからsukuna環境に入れるなど、リスクを低減する措置を各関係者と連携しながら決定・導入しています。
sukunaによって得られたメリット
前の章ではsukunaの技術的な構成について述べました。ここからは、 データ分析基盤を構築して得られた具体的なメリットについてご紹介します。
BigQueryによる高速なデータ集計
大きなメリットの一つは、データウェアハウスとして採用したBigQueryの性能です。 BigQueryは大量データの集計をとても得意としています。 これまでオンプレミスのデータベース上でデータの集計に数時間かかっていたところ、BigQueryでは同じかそれを遥かに超えるデータ量の集計が数秒で終わります。
集計が高速に終わるということは、データとのやり取りが素早く終わるということです。 これにより探索的なデータ分析が行いやすくなり、試行錯誤が容易になります。 試行錯誤の回数は良いダッシュボード、つまり意思決定に寄与するダッシュボード作りに役立ちます。
全量データを持っていることによる多角的な分析と時間効率の向上
sukunaではデータソースから出来るだけ全量のデータを受領するようにしています。いわゆるローデータと呼ばれるものです。
実際には個人情報を非識別化するなどの処置を行った後のデータですが、レコード単位ではローデータと対応する量を受領しています。 統計化されたレポートと異なり、全量データは様々な分析軸で集計しなおすことが可能です。
前述したBigQueryの高速集計能力とあわせて、データを多角的に、様々な方向から分析することができます。 これにより、トップラインのKPIだけでなく、KPIに寄与する要素を深掘りしたり、これまで発見できていなかったファクトを見つけやすくなります。
また、従来の省庁で慣例的に行われていたベンダーへの分析・レポーティングの委託に比べて、データ分析のリードタイムが遥かに短くなります。
これまでであれば分析仕様の検討、集計仕様の確定、委託ベンダーへの相談、場合によっては契約内容の更新など、一回のデータ分析に要する時間的コストが大きく、それ故に十分に中身を検討してからでないと動けない背景がありました。
一方でsukunaのように全量データが手元にあり、高速なデータ集計が可能な環境ならば、試行錯誤を思いついた瞬間にデータ集計を行い、結果から素早くフィードバックを得ることが可能です。
このため、ファクト＆データユニットのデータアナリストはただデータの可視化を委託される関係というよりも、プロジェクト担当者と近い距離で共に政策の方向性を検討し、データから得られる知見でもって意思決定をサポートするコンサルタントのような働きが可能となっています。
GCPのマネージドサービスを使うことによる運用負荷軽減
データ分析におけるメリットはもちろんのこと、sukunaはフルクラウド環境で構築していることで、運用面でもメリットがあります。 ストレージ、アプリ実行、デプロイ、監視、カタログ管理など、様々な箇所でGCPが提供するマネージドサービスを多く導入しています。
また、構成管理やコード管理のソフトウェアとあわせてCI/CD、IaCを実現し、主要なデータのパイプラインはサーバーレスかつイベントドリブンアーキテクチャを採用しています。 これによりデプロイやバッチ処理の成否に気を遣う必要があまりないため、少人数での開発と運用が可能になっています。
もちろん現在の構成で完成形ではなく、今後増加していくであろう様々なデータを、より効率的に活用するために日々sukuna環境の改良を続けています。
sukunaの運用体制と人材募集について
チーム構成
ファクト＆データユニットのチーム構成は上図のようになっています。
sukunaの開発と運用は現在データエンジニアが2名で行っています。 アナリストおよびその先にある庁内・庁外のデータ可視化ニーズに応えるため、各案件ごとに要件の把握やそれにあわせた実装を行っています。
マイナンバーダッシュボードのように一般国民向けに公開している部分もあるため、運用面でも一定の品質を保つ必要があります。 前述のとおり、GCPのマネージドサービスをフル活用しなければ少人数体制での開発・運用は難しく、その意味でもクラウド技術には助けられています。
採用情報
データを活用したいという案件は増えていきますので、sukunaの開発・運用およびファクト＆データユニットが価値を創出し続けるためにはまだまだ人材が必要です。
デジタル庁ではデータ分析やデータ分析基盤の運用に関わるポジションを複数募集しております。
データアナリスト（戦略・企画）
データエンジニア
アナリティクスエンジニア
データ関連のスキルや経験を、日本国のデジタル化・効率化に活かしてみたい方は、ぜひ下記リンクから詳細をご確認の上、ご応募ください。
◆これまでの「デジタル庁Techブログ」の記事は以下のリンクをご覧ください。
◆デジタル庁の中途採用に関する情報は以下のリンクをご覧ください。