デジタル庁のデータ分析基盤「sukuna」の変化：Agile&FragileからTrust&Robustへ
はじめまして。デジタル庁ファクト＆データユニット所属、データエンジニアの長谷川です。
本記事ではデジタル庁内でデータ活用を取り巻く環境の変化に対応していくためデータ活用組織が重要視している二つのスタンス「Agile ＆
Fragile」「Trust & Robust」、デジタル庁が内製で開発・運用しているデータ分析基盤「sukuna（スクナ）」の今後について紹介します。
※後半では技術的な用語が増えることをご容赦ください。
※デジタル庁のデータ分析基盤「sukuna」の詳細や、私たちファクト＆データユニットの目的等については前回のnote記事をご参照ください。
ファクト＆データユニットのこれまでの成果と政府のデータ見える化方針
まず、デジタル庁内のデータ利活用の専門組織であるファクト＆データユニットがこれまで実施してきた成果について、その一部をご紹介します。
政策データダッシュボードの拡充
デジタル庁では、データと根拠に基づいた政策判断（EBPM：Evidence Based Policy Making）を推進する一環として、重要な施策についてデータを「政策データダッシュボード」として公開しています。
これまでもマイナンバーカードの普及に関するダッシュボードを公開していましたが、2023年9月には追加で複数の政策についてデータ公開をおこないました。
いずれも各政策を担当するチームと連携の上、庁内のデザイナーにも尽力いただき、可視化すべき情報をわかりやすくまとめることができました。
これら外部に向かって公開しているダッシュボード以外にも、庁内向けのダッシュボードを作成し、政策の進捗状況のモニタリングなどに活用しています。
活用の範囲はデジタル庁が国民や事業者に向けて直接提供しているサービスのモニタリングのほか、地方公共団体のように実際のサービスを届ける組織（サービサー）の状況を中央省庁から把握しやすくするためのデータ収集・可視化などもおこなっています。
政府とデータ見える化に関する方針
2023年秋に岸田総理大臣直轄の会議として発足した「デジタル行財政改革会議」においても、「政府活動のデータによる見える化」の必要性が会議の議題として取り上げられています。
会議の中では、まず政策の進捗状況を見える化することをEBPMの第一歩(EBPM Type1)として位置付け、これを徹底することが必要と提言されました。こうした「政策見える化」の取り組みの参考例として、デジタル庁の政策データダッシュボードプロジェクトが取り上げられ、紹介されています。
下の二つの図はデジタル行財政改革会議にて実際に使われた資料のページを抜粋したものです。資料の中で進捗状況の見える化の重要性が説かれています。
こうした政府全体の方針については、引き続き議論・検討が行われています。私たちファクト＆データユニットでは、「データによる政策の見える化」などのデジタル庁の新しい取り組みが、政府全体の活動方針に影響を及ぼす可能性を持っていると考えています。
※参考：
・デジタル行財政改革会議｜内閣官房ホームページ
・PDF「デジタル行財政改革のこれまでの取組等について」（第二回デジタル行財政改革会議：2023年11月22日）｜内閣官房ホームページ
ファクト＆データユニットが重視している二つのスタンス「Agile & Fragile」と「Trust & Robust」
「データの見える化」についての需要がデジタル庁内外から高まる中、ファクト＆データユニットはダッシュボードを中心としたデータによる価値提供を引き続きおこなっていきます。
データを通じて様々な政策プロジェクトと関わるにあたり、ファクト＆データユニットでは二つのスタンスを軸にしてチーム内の意思決定をしています。
一つは、素早く柔軟な価値創出を表す「Agile & Fragile」。もう一つは、安定性と信頼性を表す「Trust & Robust」です。特に出典はなく、ファクト＆データユニット内で作り出された標語に近い概念です。
Agile & Fragile：素早く柔軟な価値創出
「Agile」はアジャイル開発などと同じ意味で「素早く作ること」、「Fragile」は「壊れやすい」という意味ですが、ここでは「最初はハリボテでも良いのでさくっと作る。完成度を求めすぎない」というニュアンスで使っています。
二つを合わせて「素早く、とりあえずでもよいので形にするべき」というスタンスを表現しています。
こうしたスタンスが求められる背景としては、データ活用そのものが初めてであったり、具体的なデータの貢献がイメージできていない段階のプロジェクトでは、粗いレベルでもダッシュボード等でデータを表現し、完成系のイメージを関係者間で共有することの重要性が大きいためです。
関係者が同じイメージを持っていることを「アタマがあう」と表現することもありますが、まさにその効果を狙っています。
Agile＆Fragileのフェーズにおいて、ファクト＆データユニットは素早く価値を届けることに注力します。素早さ重視で、データ集計の細かい定義や表現すべきデータが揃わない段階からダッシュボードを作ろうとするため、仮の数値を埋め込んで表現することも多くなります。
もちろん仮数値が埋め込まれたままでは完全なモニタリングに使うことはできませんが、それでも利用者間で具体的な完成系に近い形をイメージできることには大きなメリットがあり、以下の効果が期待できます。
複数のKPIに優先度をつけ、重要なものと補足的なものを分けて理解する
具体的な業務執行の中でどのようにダッシュボードを使うかイメージできる
実際にダッシュボード上でデータを見る担当者の反応を予想できる
完成系に至るまでに足りていない部分と、すでに充足している部分を把握できる
特に行政においては施策の立案から実行までのタイムスパンが長く、データで振り返るのが半年後、一年後というケースが少なくありません。
そうした環境において、「少なくともデータさえあるならば素早くそれを可視化できる」という状況を作り出すことで、施策の効果検証と意思決定の高速化に寄与することを狙いとしています。
Trust & Robust：安定性と信頼性
「Trust」は「信頼できること」を意味し、「Robust」は「丈夫でブレがない、安定している」という意味合いで使っています。二つを合わせて「安定して価値を出し、信頼できる」というスタンスを表現しています。
ほとんどのデータ活用はAgile & Fragileのフェーズから始まりますが、フェーズが進むとデータの価値を安定して提供できることが求められます。これはダッシュボードによるモニタリングやデータ分析結果を元にした意思決定が定常化した頃に起こる変化です。
データを使って事業の健康状態を測って終わりではなく、その状態を維持する必要があります。一過性のEBPMで一時的に業務効率化を進めても、元に戻っては意味がありません。そのため、持続的にデータを使い続けられることが求められるようになります。
Trust & Robustのフェーズに差し掛かったプロジェクトについて、ファクト＆データユニットは安定した価値提供に主眼を置きます。
まず取り組むことは属人性の排除です。Agile & Fragileのフェーズでは速度を重視するため、データの取得・加工・可視化までのパイプラインについても人の手で解決するケースが多くなります。
具体的にはExcelデータを人力で加工して取り込む、データの加工はBIツール側のロジックで簡易におこなうなどです。しかし、人力解決のパフォーマンスは流動的であり、横展開にも限界があります。そのため、データのパイプラインの最初から最後までをシステムが担うように組み換え、自動化を進めます。
その他、セキュリティやプライバシーの観点からもデータの持ち方、提供の仕方を変更し、守りを固めます。これにより、データを活用し続けることのリスクを低減し、利用者から信頼を得ていくのがTrust & Robustのフェーズです。
各フェーズに求められるチーム体制
ファクト＆データユニットではデータ活用プロジェクトの始まりから安定稼働までの全域をサポートするため、各フェーズに応じた適切な人材配置をおこなっています。
上の図は各フェーズのおおまかなプロセスごとに必要な人材をマッピングしたものです。Agile & FragileフェーズではデータPM（プロジェクトマネージャー）を中心として、案件開拓のBizDev、デザイナー、データエンジニアなどが協働してアウトプットの作成にあたります。
その後、データが現場で使われ始めてからは徐々にTrust & Robustフェーズに移行し、アナリティクスエンジニア、BIエンジニアなどのエンジニア職を中心に自動化・安定化を進めています。
もちろん私たちは行政組織ですので、予算編成や各省・各部局との調整に行政官メンバー等のサポートも必要となります。
「sukuna」のリアーキテクチャ
※注：ここからは技術的な内容が続きます。sukunaで採用しているパブリッククラウドや、その中で使用しているサービスの名称、技術スタック等については、sukunaに関する以下の紹介記事をご参照ください。
Trust & Robustを支えるデータ分析基盤のあり方
データ分析基盤としてTrust & Robustフェーズを支えるということは、簡単に言えばデータ活用を途切れさせないということです。
EBPMが単発の打ち上げ花火で終わらないように、データを継続的に利用し、データを使った効率的な意思決定を当たり前にしていく必要があります。そのためには、データ活用にまつわる様々な不確実性を潰していく必要があります。
例えば、データの入力、加工などを人間が実施している場合、操作間違いや認識違いによるミスが発生します。作業者の異動、退職などによる引き継ぎリスクも発生するでしょう。もちろん日々の体調にも影響を受けます。
これらの要素は基本的にコントロールできないため、データによる価値提供をコントロール可能、かつ安定させるためにパイプラインの完全機械化・自動化を行います。
パイプラインを機械化する一方で、データの価値を受け取る側は人間であることが多いです。そのため、事業や世論の状況によって、利用者が見たいデータは徐々に変化していきます。
データ利用者側の需要をパイプラインが満たし続けるためには、新しいデータの取得であったり、既存の加工ロジックの変更であったりといった、細かな修正を続ける必要があります。
また、データの供給が需要に追いつけるように、パイプラインは適度に分割し、変更が容易で、メンテナンス性が高い状態を維持する必要があります。
さらに、データは資産であると同時にリスクを含みます。個人情報や要配慮情報などに代表される機密情報の権限管理は必須事項です。これまで人間がコントロールしていた「見せるべきデータ、見せるべき人の選択」を言語化・明確化し、システムとして落とし込み、セキュリティとプライバシーの観点からも信頼できる基盤とする必要があります。
これらの要素を満たすTrust & Robustなデータ分析基盤として、sukunaのアーキテクチャを進化させる計画、「sukunaリアーキテクチャ」が現在進行中です。
ここからはリアーキテクチャの一部についてその概要をご紹介します。
現在のアーキテクチャは1つの環境で全てをまかなえる構成
まず、現在のsukunaのアーキテクチャについて概要図に記すと以下のようになります。
データの入力・保存から加工・蓄積、最終成果物であるダッシュボードから参照されるデータマートに、これら全体を管理・運用するためのサービス群まで、すべて一つのGoogle Cloud Platformプロジェクト内で実現しています。
一つの環境内でデータの入力・保存や参照の権限を管理できるため、特にデータ活用の初期段階で一時的にデータを保存・可視化を試みたり、活用の方向性を見定めるための試行錯誤をおこなう際には適しています。
具体的には、案件初期に受け取った仮データを、データPMが自らGCS上にアップロードしてBigQueryで読み取り、さらにPowerBIでダッシュボードのモック作りに活かす等の検証工程が一つの環境内部で完結します。
データPMがダッシュボード上のグラフを見ながら、元であるデータを直接修正するなどの柔軟な対応も行いやすくなります。
そのため、このアーキテクチャはデータ活用の要件が完全に固まり切っていないAgile & Fragileフェーズのデータ分析基盤として適しています。
次期アーキテクチャは複数の環境を組み合わせる形でリスク対策と開発速度を両立する
sukunaのリアーキテクチャ後の構成について概要図に記すと以下のようになります。
これまで一つのGCPプロジェクトで管理していたデータ入力・保存、加工・蓄積、ダッシュボードからの参照、そして管理・運用系サービスをそれぞれ役割別のGCPプロジェクトに分割し、それぞれで権限管理と開発を行います。その狙いは以下の通りです。
1：プロジェクトを分割した上で権限管理することでリスクを減らす
プロジェクトを分割したことで、利用者や利用システムに付与される権限の範囲が限定されます。権限の範囲が限定されることで、例えばダッシュボードが本来参照すべきでないデータを参照し、公開すべきでないデータがダッシュボード上に表示されてしまうなどの事故が起こりづらくなります。
具体的には、ダッシュボードが参照する出口側のプロジェクトで、ダッシュボードごとに参照できる範囲を定め、適切な権限管理をおこなうことで「欲しいものだけを見る、それ以外は見られない」状態を作って対処します。
権限管理についてはプロジェクトが一つの場合においても、Dataset ACL、Table ACL、Column ACLなどのGCPの権限管理機能を細かく使い分ければ実現可能です。
むしろ環境を一つにしてこれらの権限管理機能で管理したほうがSingle Source of Truth（信頼できる唯一の情報源）の観点から望ましいと言われています。
ただし、これらの権限管理機能を十全に機能させるにはデータのメタデータ管理の徹底が条件となります。例えばデータの機密性、利用用途、ビジネス価値、データのオーナー情報など、データを説明するために必要なメタデータを管理する必要があります。
逆に言えばこれらのメタデータ管理をおこなうためのルールや運用体制が整っていない場合、細やかな権限管理には穴が空きやすくなります。sukunaにおいてはまだまだ少人数体制で運用をおこなっているため、環境を切り分けた上でプロジェクト単位での権限管理を徹底するシンプルな方向に舵を切っています。
2：入り口側プロジェクトでデータ品質のチェック
見るべきでないデータを見てしまう出口側の事故とは反対に、取り込むべきでないデータを取り込んでしまう入り口側の事故もあります。こちらについてもデータ参照と同様に、データを入力・保存する側について権限管理を徹底することで、誤ったデータを誤った場所に保存するリスクを減らすことができます。
また、入力・保存する場所は正しいが、中身が間違っていたり、データが古かったりというデータ品質の課題についても、データの入り口側プロジェクトで対処します。データの有効性や最新性などの品質を入り口側プロジェクトにおいてチェックすることで、品質の事故をある程度防ぐことができます。
特に頻発するのはデータ取得が遅れるケースです。日ごと、週ごと、月ごとなど、ユースケースによってデータの最新性に求める基準は異なります。そのため、データの利用ニーズに応じて適切にパイプラインのチェック基準を設定し、最新性について適切なアラートを挙げられる仕組みを導入する必要があります。
3：プロジェクトごとの開発・デプロイによる開発速度の向上
分割により得られる別のメリットとして、プロジェクトごとの開発・デプロイが行いやすくなることが挙げられます。一つの環境で全てを管理している構成に比べて、システム開発の影響範囲を限定しながら試行錯誤ができるため、利用者だけでなく開発者の体験も改善されます。
特に一つの環境でまかなっていたパイプラインが肥大化してきた場合、適切なサイズに分割して開発の焦点を絞ることは開発速度の増加に繋がります。これにより、全体としてメンテナンス性の向上が期待できます。
自分で開発し、自分で運用するメンバーを募集中
ここまでsukunaのリアーキテクチャ計画について簡単にご紹介してきました。
行政においてはシステムの開発・運用ともに民間企業に外注することが一般的ですが、sukunaについてはデジタル庁職員である民間出身の専門人材が開発と運用を担っています。内製だからこそできる柔軟で高速な意思決定と開発速度はまさにAgile & Fragileフェーズのデータ活用にマッチしています。
一方、今後データを政策意思決定のインフラとして当たり前のものにしていくためには、その基盤として安定性と信頼性を獲得し、素早さと両立する形でTrust & Robustを実現しなければなりません。
自分で作ったものは自分で運用する、だからこそ管理しやすく、リスクを抑え、かつ効率的に運用できるように組み替えていく必要があります。
デジタル庁ファクト＆データユニットでは、こうした当たり前の運用を、責任感をもって実行できるデータ人材を募集しています。民間等で培ったデータ関連のスキルや経験を活かしてみたい方は、下記リンクから詳細をご確認の上、ご応募ください。
◆デジタル庁Techブログの記事一覧はこちら。
◆デジタル庁の職員/チームを紹介する記事はこちら。
◆デジタル庁の採用に関する情報はこちら。