少し誤字を修正し、参照リンクなどを追記しました。（2024/03/02 23:02）

デジタル行財政改革会議の、課題発掘対話（第6回）の内容について、の補足記事です。自治体毎にシステムを作ることが、システム的な観点からはもう限界なのではないか？という主張です。各回の記事へのリンクは以下。

第１回：デジタル行財政改革　課題発掘対話（第６回）に参加してきました
第２回：自治体の人材育成とシビックテックの関係
第３回：自治体毎にシステムを作るのは限界（本記事）
第４回：自治体のインセンティブ設計を見直そう

課題発掘対話の模様と各構成員の発表資料は、デジタル行財政改革会議のHPで公開されています。

ちなみに、本稿では自治体側の話だけではなくデジタル庁の政策に関する話も多く出てきますが、以下で書かれていることは全て関個人の考えであり、特定の組織の立場で発言するものではありません。また、論旨は公開情報のみから構成されており、内部情報は一切利用していません。

前半パートの2回の記事では、自治体のデジタル人材育成の難しさについて触れました。課題発掘対話の後半は、システムの共同化や共通化といった部分が論点でした。私からは、そもそも1741 + 47 の自治体それぞれにシステムを設計し調達するのはもう限界なのではないかという主張をしています。

本当に自治体毎にシステムを作る必要があるのか

本来、ここは丁寧な議論が必要で、たくさん反論が来そうです。私もここまで言い切るかは悩みましたが、大変限られた時間での発表でもあったため、ある程度論点を絞り込まざるを得ませんでした。

小さな自治体に行って話を聞いていると、「人もいないし予算も無く、ベンダーも提案しに来てくれないので何をして良いか分からない」といった悩みをよく聞きます。
潤沢な予算が無かったとしても、申請に取り組む時間やアイデアがあれば、デジタル田園都市都市国家構想などの国の交付金メニューを使って独自の施策を考えていくこともできるのですが、正直、小さな自治体ではそんな余裕もありません。
実際、デジタル化が進んでいる自治体とそうでない自治体の差が開いていっていると感じます。市民サービスの違いもそうですが、職員側の働き方についても、自治体ごとにだいぶ差がある状況です。生産性もだいぶ違っているはずです。
（小さい自治体でもデジタル化が進んでいるところもあれば、逆に大きな自治体でもデジタル化が進んでいない所もあるので、必ずしも規模だけが原因では無いですが。）

一方、電子行政を語るときによく引き合いにだされる韓国（デジタル政府指数１位。日本は31位※1）では、広域自治体・基礎自治体ごとに、全国的に一つの行政システムを開発・適用しており、運用・管理や年ごとのシステム改修も、全国一元的に行われていますので、比較してみましょう。
財団法人自治体国際化協会が2010年に出しているレポートによると、システムの導入費や維持費には大きな差があるのは事実です。日本と韓国の人口比を考慮したとしても、かなりの開きがあります。

また、システム水準による比較でも、まさに今の日本が苦しんでいる課題が書かれてしまっています。

この報告書では様々な点から日韓の比較をしているのでぜひご覧いただきたいところですが、システムの開発や保守を政府の傘下機関である韓国地域情報開発院が担当し、実質的には委託によって民間企業が担当する仕組みや、著作権についての考え方、「行政情報共同利用センター」による行政情報の共同利用、継続的で安定した運用のための「統合運用支援センター」やコールセンターの設置、行政職員のためのコミュニケーションチャネル「セオル広場」など、様々な工夫がされているのがわかります。

もちろん、比較的中央集権型の制度設計をしてきた韓国と、地方分権色が強い日本では、そもそもの行政システムの考え方自体違うのは理解していますし、韓国のマネをすべきだと言っているわけでもありません。
シビックテックを推進する立場としても、憲法92条から参照されている、地方自治の本旨には大いに賛同します。

その上であえて考えたいのは、決まった手続きを決まったやり方でやるような創意工夫の余地の少ないシステムを開発・運用・保守する負担を、自治体がそれぞれ追うべきなのだろうか？という点と、これだけの非効率をずっと温存しつづけて、付加価値を生まない部分に税金を投入した上に、自治体間の格差が開いていくのが良いことなのか？という点です。
それは本当に市民が望む地方自治なのでしょうか。効率化すべきところはして、もっと他のことに投資ができる方が良いという考え方もあるのではないでしょうか。

標準化の先にある、公共サービスメッシュ

基幹系の20業務についてはまさに標準化が待ったなしで進んでいる状況で、自治体の皆さんもベンダーさんも大変苦労している最中であるわけですが、あえて、もう少し先を見てみます。この章は私もまだまだ勉強不足な部分も多いので、認識におかしな点があればぜひ教えていただきたいと思います。

まず、現在標準化対象の業務以外にも、集約することで効果のあるサービスは多くあるはずです。

デジタル庁のサイトには、公共サービスメッシュについて以下のように書かれています。

簡単に言えば、行政フロントサービスへデータ連携するタテの連携と、自治体間で連携するヨコの連携がよりやりやすくなるというコンセプトです。標準化ができ、共通のデータ構造を持つサービスができたら、その次はそのデータを活用したフロントサービスが色々出てくるということになります。同じデータインターフェースが使えるので、自治体間での相互運用性が高まります。
公共サービスメッシュの仕様をどう作っていくのか、どのようなサービスと連携できるのか、といった点がとても重要になってきますので、できるだけ前広に、多くの人を巻き込んだ形で仕様策定をしていってほしいと思っています。
さらに言えば、官民APIゲートウェイを通じてデータ連携基盤とも繋がり、準公共サービスからもデータが使えるようになるのが良いでしょう。

システムの集約パターン

自治体が提供する行政サービスを分類し、パターンごとにいくつかの方式で集約をしていくのが良いのではないでしょうか。

①国が作る

国が開発・運用する一つのサービスを使うパターン。マイナポータルやVRSといったものはこれにあたります。開発自体はベンダーに委託しても良いですが、国が仕様を策定し、自治体に使ってもらう形になります。
あまり自治体毎に差異が無く、創意工夫や競争性も無い分野や、法律・政令により事務処理が義務付けられるものが中心になるかと思います。

②国が仕様書を作りベンダーが作る

今の標準化の進め方にあたります。必ず守るべき部分を国が定義し、それに対応するサービスをベンダーが作ります。創意工夫を発揮する余地があります。SaaS サービスが基本で、Digital Market Place に掲載されており、自治体が選定します。
相互運用性が重要である、データ連携基盤なんかも、このカテゴリに入るべきなのではないでしょうか。
運用費やカスタマイズ費用、利用率、アップデート情報などの情報は公開されており、自治体はそれらの情報を参考にして選定することができるのが理想です。
このような世界観を実現するには地方自治法施行令第167条の2(随契条項)を改正する必要があるかと思っていたのですが、法改正までしなくても、第167条の２の２号で対応できるという話もあるようです。

また、仕様を作る際には、国が一方的に決めるのではなく、自治体と共に作るべきです。窓口DX SaaS が比較的うまくいっているのは、自治体の創意工夫で生まれたシステムを国が吸い上げ、仕様化したところだと思っているからです。（前述の韓国の場合も、同様のケースがあります）
1741の自治体がある、ということは逆に言えばそれだけPoCをする場所があるということでもあります。適切に情報共有ができ、フィードバックを元に機動的に改善できる体制があれば、その多様性が強みになり得ます。
そのためには、自治体と国が対等に、オープンに仕様策定について話せることが必要です。

ベンダーのタイプも、SI一択ではなく、自社でSaaSを作って伸ばしていく側と、そのSaaSを利用してインテグレーションをしたりカスタマイズをしたりしていく側に分かれていくと思います。今まではグループ会社の中で閉じた役割分担が、より広がり市場が活性化することが期待できます。スタートアップや、技術力のある中小ベンダーの活躍の場も増えるでしょう。

③自治体が独自で作る

もちろん、こういった領域も必要です。引き続き、自治体毎の創意工夫をしながら、新たなサービスを生み出していくことができます。
本来②でやるべきことも、ある程度良いユースケースが出てくるまでは各自治体で実証をするほうが良いかもしれません。その中である程度ユースケースが見えてきたものから、②へ移行していくイメージです。
その際、②に採用されるようなシステムを作った自治体には何らかのインセンティブがあったりすると良いですね。
共同調達などもやりやすくすると良さそうです。

デジタル公共財の活用

最後に、日本ではあまり概念として広まっていない、デジタル公共財という考え方について説明しておきます。

デジタル公共財は、国連事務総長の「デジタル協力のためのロードマップ」では次のように定義されています。

オープンデータは日本でも政策化され、多くの自治体で公開されていますが、公共サービスとデジタル公共財は非常に良くマッチします。EUは、政府が使うGIS（地理空間情報システム）はオープンソースであることを条件としてきましたし、最近日本でデータ連携基盤のベースとして使われているFIWAREも、EUが多大な金額を投資して開発されたオープンソースソフトウェアスタックです。
米国も、People's code（※2） というコンセプトで、政府が調達するソフトウェアのうち、最低20%はオープンソースにすることが大統領令で示されています。
前述の韓国もシステムをオープンソース化していますし、オープンソース化していないものも、政府が著作権を持ち、自治体が無償でカスタマイズできるようにしています。

EUがオープンソースを積極的に活用している理由には、主に以下のようなものがあります。

• 米国 Big Tech への対抗：Facebook、Googleといった米国のBig Techに対して、自国の産業を守るために、オープンソースソフトウェアを振興している

• デジタル独立（digital sovereignty）：IDマネジメントやデータストアなどを特定企業のサービスにロックインされないように、オープンスタンダードや保護規制を敷くことで独立性を高める

• 地域間格差の縮小：財政規模の小さな国でも、他国が開発したソフトウェアを活用し、公共サービスの質を向上することができる

• イノベーション：特定のベンダーのみが行政システムを寡占するのではなく、スタートアップを含めた様々な企業が市場に参入でき、共創やイノベーションが期待できる

これらのメリットは、日本でも有益に働くのではないでしょうか。
こういったことを書いた場合の反論は以下のようなものがあります。

ベンダーが対応してくれない

これは、市場に競争が無い、ベンダーロックインされている、などの裏返しでもあります。DMPなどにより市場が広がり健全な競争環境が生まれれば、解消される可能性があります。
そもそもSaaSなどを使う部分以外は著作権を譲渡する契約が多いので、自治体がソースコードを公開しようが自由なはずです。
一方で、住基側のサービスなど、新規参入が難しい分野では相当思いきらないとオープンソース化は難しいかもしれません。
ベンダー側は、ノウハウをオープンソースにしてしまうとビジネスモデルが成り立たないから価格が上がる、と言うかもしれません。コストが効率化されるので、従来のビジネスモデルが通用しなくなる面はあるでしょう。
自治体単体の狭い世界で見てしまうとそのような不整合が発生する可能性はありますが、全体でのコストが下がるはずなので、国の方でサポートがあっても良いかもしれません。

SaaS サービスはオープンソースにできない

最近はサービスにSaaSを使うことも増えてきており、それらのソースコードを公開させるわけにはいかないというものです。これはもっともな指摘です。私も全てのものをオープンソースにしろと言っているわけではありません。とはいえ、例えば kintone を使って申請システムを作ったとした場合、フォームのテンプレートなどはオープンソースにすることが可能なはずです。
また、データ変換ライブラリやユーティリティなど、一部の機能だけでもオープンにすることは十分有益です。

地方自治法で禁止されている

スライドの最後のページに書いてあることですが、このエントリで紹介します。地自法238条の解釈次第で、オープンソースは行政財産となってしまい、無償で貸し付けたりすることが難しくなります。
詳しく書くと長くなるのでシンプルに書くと、総務省が「国有財産法の解釈と同じく、デジタルデータの著作物は行政財産ではなく、インターネット公開することは可能」という技術的助言を出していただくのが一番です。
詳しく知りたい人はこちらをどうぞ

オープンソースソフトウェアを使うことで、地方自治体同士の共創はもっと進みます。スタートアップの参入余地も増えます。
一方で、内製力が求められたり、場合によってはOSPO（Open Source Program Office）などの組織が必要となるかもしれません。
まずは国が必要なライブラリなどをオープンソース化したり、体力のある都道府県や政令市などから始めるのが良いのではないでしょうか。
東京都はOSS公開ガイドラインを作成しています。

公共とオープンソースについてもっと知りたい方はこちらの記事もどうぞ

2分くらいの発言を補足するのに、6,500文字も使ってしまいました。
今回の記事は、いろいろな反論もあるのではないかと思います。ぜひ忌憚のないフィードバックをお願いいたします。

次の記事は、本シリーズのラスト「自治体のインセンティブ設計を見直す必要」です。

※1： 2023年 OECD デジタル政府指数
※2：People's Code