編集部からのお知らせ
新着PDF集:データセンターの省電力化
「これからの企業IT」の記事はこちら
アジャイル開発を加速させるローコード技術の衝撃

第7回:「自治体向け給付管理システム」に必要なデータモデルとローコード開発

渡辺幸三

2020-06-18 07:00

 新型コロナ禍が広く世に示したことの一つが、自治体システムの出来の悪さだった。住民への10万円の一律給付の手続きが異様に複雑だったり、何度も申請できたり、申請してもなかなか入金されなかったりした。また、事業者に対する「持続化給付金」のために769億円もの事業委託費が執行されたことも驚きをもって伝えられた。コトが起こるたびに公共情報システムの使いにくさが問題になり、またその開発・維持・運用に想像をはるかに超えるコストがかかることが話題になる。そういった国や自治体向け情報管理システムの「不都合な真実」が明らかになった。

 そもそも、地震や台風をはじめとする大災害に毎年襲われるわが国において、住民や事業者に対する給付が決議されるたびに膨大な手間やコストがかかるような仕組みは根本的におかしい。その種の給付プログラムは本来「今後も何度も実施される日常的な自治体業務」であって、最小限の追加コストで淡々と実施できるようでなければいけない。もちろん給付だけではなく、これを含めたさまざまな住民サービスを効果的に支援できる自治体システムが求められている。

 しかもそれは日本国に1個あれば足りる。自治体ごとの独自性というものは、業務構成の観点で見れば大したものでない(むしろ大きく違っているのはおかしい)。それ故、全国の自治体(市区町村)が共通して使えるシステムを想定できる。

 そうなればさまざまな利点が生まれる。例えば、申請の様式や手続きが統一されるだけでなく、住民は旅行先や出張先の役場でも手続きできるようになる(そもそも、ほとんどの手続きは役場に出向かずに統一アプリを用いてオンラインでやれる)。また、災害時には被災自治体以外の職員がオペレーションを代行できるし、義援金の集約や分配も自治体システムを介してスマートに行えるようになる。

 何よりも、全国の自治体が似たようなシステムを個別発注するという恐るべき無駄が一掃される。「地元のソフト開発業界が栄えるための施策」などとも言っていられない。道路などの社会インフラの工事であれば地元の業者に活躍してもらえばいい。しかし、日本にたった1個あれば済む大規模ソフトウエアを、各自治体が重複的に委託開発することの理はどこにもない。第一、どの自治体の住民もそれは許容できないだろう。

 では、そのようなシステムを実現するためには何が必要なのだろう。「マイナンバー」の仕組みは何千億円もかけて実現されたという。自治体システムがマイナンバーの仕組みと連係する形で機能するはずなので、その開発にも何千億円もかかるのだろうか。

システム刷新のカギは「優れたデータモデル」

 理解されにくいことなのだが、システム刷新を成功させるためのカギは、膨大な予算や工数ではなく「優れたデータモデル」である。さすがに、優れたデータモデルが無料で手に入るわけではないが、札束さえ積めばまともなデータモデルが手に入ると考えてはいけない。システム要件に沿った的確なデータモデルを創造できる技術者が極めて少ないという現実があるからだ。巨額の予算を確保することよりも、そういった希少人材にリーチすることに知恵を絞った方が確実に良質なシステムが手に入る。

 実際のところ、的確なデータモデルを描き出せる人材の確保に取り組まなかったために、多くの開発プロジェクトが札束を濃硫酸で溶かし続けるような事態に陥ってきた。自治体システムの世界でも同様である。

 自治体システム向けの適切なデータモデル(と筆者が考えるもの)の一部を見てほしい(図1)。

図1.自治体・世帯・住民・事業所のデータモデル 図1.自治体・世帯・住民・事業所のデータモデル
※クリックすると拡大画像が見られます

 データモデルは「扱われるデータの論理関係を表す図面」を意味するが、この例では自治体システムで扱われるデータの中でも特に基本的な、自治体、世帯、住民、事業所の論理関係が示されている。

 現時点で日本には1741の自治体(市区町村)があるが、それらは自治体コードを主キーとする「自治体テーブル」に登録される。そして、国内に住民票を持つ住民は住民IDを主キーとする「住民テーブル」に登録される。論理的には、住民は自治体コードを直接持たず、代わりに世帯IDを属性として持つ。「世帯テーブル」には、国内に存在する全世帯のデータが登録されることになるが、それらは自治体コードを属性として持つ。つまり、住民がどの自治体の住民であるかは、どの世帯に所属する世帯人であるかによって決まる。

 データ項目間のこういった関係や制約を端的に視覚化した図面がデータモデルだ。データベースの論理的構造をデータモデルによって明らかにすることで、業務フローや画面構成を含めたシステム仕様が定まる(その逆ではない)。適切なデータモデルの確立に失敗したが故に、多くのプロジェクトが破綻したり、破綻しなくても使いにくいシステムしか生み出せていなかったりするのが現状である。

 前述したように、上記のモデルに従えば自治体システムが日本に1個あれば足りることがよく分かる。例えば住民が他の自治体に転出した場合、住民の世帯IDが切り替わるだけで住民IDは変わらない。転入先で所属可能な世帯が存在しないのであれば、転入先での新たな世帯が定義されその世帯IDが与えられる。ちなみに現在の仕組みでは、各自治体が独自の自治体システムを開発・維持しつつ、それぞれが固有の様式で住民データを管理している。これが自治体間のデータ連係をどれだけ複雑にしているか分からない。

ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)

特集

CIO

モバイル

セキュリティ

スペシャル

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNet Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]