ガバメントクラウドに見る「ボタンの掛け違い」
《本文》
■ 懸念されていた「移行の失敗」
「富士通に続き「間に合わない！」表明のベンダーも…「自治体システム標準化」問題、26年3月の本格稼働まであと半年！」[1]という記事が目をひいた。
記事の中で、下記の部分が状況を示している。
> 全国1741の市区町村と47都道府県が、役所の中核機能をつかさどる住民記録や税など20の基幹ITシステムを2026年3月までに一斉に「標準化」する、総予算7000億円超の壮大な計画。それが自治体システム標準化プロジェクトだ。3万4000を超えるシステムを対象とし、さらにその後これらのシステムをクラウドに移行する。日本のITの歴史の中でも最大の基幹系移行プロジェクトである。
> その移行現場では大混乱が起きている。前出の自治体は、大手自治体ITベンダーRKKCSの顧客。同社は10月1日、現在標準化作業を受注している全123団体のうち約半数に対し、政府が目標とする25年度末までの完了が間に合わない、と発表したのだ。
ガバメントクラウドはデジタル庁主導での国家プロジェクトのはずなのだが、その懸念はすぐにあらわになり、暗雲がたれ込み始めることとなったことはいくつかの記事で明らかである。
- 自治体システム標準化、政治主導で暗雲 [2]
- 自治体システム標準化に激震、富士通が約300自治体に期限内の移行断念を通知 [3]
- 自治体システム標準化に激震 富士通が期限内の移行断念と通知 [4]
思ったような効果が見込めない、あるいは現実を見てくれという要望も一部の自治体からは出ているのだと思う。下記の東京都の記事は「発言力」のある東京都だからこその記事だと思うが、同様の思いは各自治体でも同じようにあるのだと思う。
- ガバメントクラウド移行後、経費は減らず1.6倍に増加 [5]
- 東京都が自治体システム標準化で緊急要望、「期限第一」から「安全第一」へ転換求める [6]
■ 予想されたボタンの掛け違い
ほとんどの人は頻繁に引っ越しをするわけではないし、税金や手当などについて細かく見ているわけでもないだろう。しかし、国税や地方税、固定資産税や住民税、細々とした補助金（児童手当やその他の支援策）などは、それぞれの自治体で異なっていると言うことは知っているだろうか。
- 税務
- 国保
- 介護
- 生活保護
- 戸籍
- 子育て給付
- 固定資産評価
これらは法は同じでも、施行規則・条例・運用判断・例外処理が全部違うと言うことだ。
法律（全国共通）
↓
省令（全国共通）
↓
条例（自治体ごとに異なる）–ここから下が実際の運用
↓
内部規程（部署ごとに異なる）
↓
運用判断（職員ごとに異なる）
↓
例外処理（担当者が現場判断）
したがって「標準仕様書（共通の構造）を作れば大部分は共通化できるはず」と言うことはない。「これまで自治体ごとに作っていたパッケージを、全国向けに1つまとめれば良い」などと言うことはない。ここがボタンの掛け違いの根源的原因である。
上記の事を知っていれば
① 国が“標準化の対象”を誤解（法律→運用→ローカルルールの階層構造を無視）
② 自治体の“現場業務の多様性”を軽視（実務を知らないまま制度だけ先行）
③ ベンダー側が標準化を“パッケージ統一”として解釈（根本的にアプローチが違った）
④ スケジュール設計が非現実的（やるべき調整の工程が計画に載っていない）
と言うことが起きることは必然であり、予想できたことではある。
■ DevOpsが機能しなかった理由
こうしたシステム開発は一般的には下記の要素での検討が必要になる。
・業務プロセスの統一
・データ構造の統一
・API の統一
・地方条例の差異の吸収
・例外運用の“制度化”
これらは利害関係者間の密なコミュニケーションで成立する。
ここで言う利害関係者は、政府（国）、自治体、住民、ベンダーが主たるところである。
利害関係者間での意思疎通が必要である。局所的なコミュニケーションでは不十分である。
当然、（ベンダーを抜きにした）国と自治体、（グランドデザインを抜きにした個別の）自治体とベンダーの調整だけでは旨く行くはずもない。また、いわゆるウオーターフォール型のシステム開発のように仕様書を渡せばベンダーがすべてやってくれるわけがない。
お互いの認識をすりあわせる必要がある。
特に、システムを維持管理するべき主体である自治体は全体をとりまとめる必要がある。
その時の認識のずれがある可能性がある。
「そんなものを頼んだ覚えはない」、「そんなシステムでは使えない」という事を避けるべきであり、そのためには現場を巻き込んだ開発手法としてDevOpsが一般的なはずなのに、これが機能していない。なぜか。考えられることに「DevOps」という考え方があまり配慮されなかったと言うこと、あるいは現場の参画が限定的だったことか、実は現場が現場のことを知らなかったということが考えられる。
① Ops (自治体) がDevの場に参加していない。
DevOpsの本質は、「開発 (Dev) と運用 (Ops) の協働による、現場で動くシステムの実現」だが、
- 国：制度とガイドラインを作る側（Devの上流に相当）
- ベンダー：システムを作る側（Devの中流）
- 自治体：実際に使い、運用する側（Ops）
というDevとOps が一体で回るべきところが縦割りになると
- 国は「制度としての標準化」を設計
- ベンダーは「標準仕様に基づき実装」
- 自治体は「後から移行される存在」
となりOps (自治体) がDevの場に参加していない状態になる。
② 現場の参画が限定的
自治体の情報システム担当の多くはいくつかの特徴を持っている。
- 非ITエンジニア
- 数年で異動
- 実務経験が浅い
- 仕様をレビューするスキルが不足
- 既存システムをブラックボックスで運用してきた
すなわち標準化に対して十分な自己表現（要件提示）ができなかったと言うことが考えられる。
③ 実は現場が“現場のことを知らなかった”という可能性
自治体では
担当者は制度や条例の“断片”は知っている。しかし業務全体の「プロセス構造」までは把握していない上に「全体の業務フローを可視化する文化がない」。そのためベテランの“暗黙知”に依存する。従って業務全体の「プロセス構造」がわからないまま業務を進めるという悪循環に陥っている恐れがある。そのため、標準化の議論で「この業務は実際どう回っているのですか？」という問いに答えられない状況になる。
■ 浮かび上がる“構造的欠陥”
まずは問題点を再度整理しておこう。
◆ 責任の所在が曖昧（誰も「設計者」になっていない）
端的に言えば下記の通り
- 国は基準だけつくる
- 自治体は自分の事情を守ろうとする
- ベンダーは縦割りで受託開発
誰も“全体システムを設計しない”。すなわち「設計する人（Architect）」が欠落している。行政の人材不足である。
現場（自治体）の業務が可視化されていない
- 業務フローが図式化されていない
- 暗黙知が多い
- 法律 → 条例 → 内規 の変換がブラックボックス
- 実務が担当者依存
本来は“業務プロセスを先に設計し、その後にITで支える”べきだが“業務もITも曖昧なままベンダーに形を丸投げ”が起きている。
◆自治体の「裁量の多さ」が負債になっている
実際の運用がコントロールできていない。
税率、福祉制度などが独自施策であり条例もすべて自治体ごとにバラバラと言うゆがみがある。つまり、自治体の制度の多様さは自治体への権限委譲にはなるがIT的には負債になっている。
もっともデジタル庁での理念を見るとこの負債を“標準化で押しつぶそうとした”が、その理念は共有されず、現場の多様性を吸収できず、モデル化に失敗したと言える。[7]
◆ 国と自治体とベンダーが“対等に議論できない構造”
これは文化的な側面であろうが下記の特徴が見え隠れする。
- 国 → 権限はあるが現場を知らない
- 自治体 → 現場は知っているが設計言語を知らない
- ベンダー → 技術はあるが業務を知らない
- 住民 → 議論の輪に入っていない
理想を言えば、こうした国家プロジェクトであってもプロダクトチームの中に市民・現場を入れるべきなのだが実際は3者（国・自治体・ベンダー）が分断されている。
■ 処方箋
私自身はIT系の人間でシステム開発の現場に長く居た。そのため政治的な意思決定メカニズムやプロジェクト運営については教科書的な事以上のことは知らないし、助言もできない。とはいえ、Linuxなどのオープンソースなどに接してきた経験から、データ構造（プロトコルなども含む）、基底システムの構築を政府がしっかり行ない、そこに乗せるビジネスモデルの記述は、いわゆるテキスト（例えばJSON、あるいはLinuxでの定義ファイル）でできる様にしてしまえばかなり標準化はできるのではないかと思う。こうした考え方は現実的ではないかな？
とChatGPTに問いかけてみた。下記の回答を得たので参考までに。
① データ構造（スキーマ）・プロトコルの政府による統一
- 行政手続きの「意味モデル」＝データ項目とその意味の統一
- JSON／XML／GraphQL／スキーマ定義（OpenAPI, JSON Schema）で表現
これが行政DXの“OS”にあたる
➡ エストニアのX-Road、英国のGOV.UK API Design Standardsと完全に同じ発想
② 基底システムを政府が提供する（＝“共通基盤”）
- 認証
- APIゲートウェイ
- ログ・監査基盤
- データ連携のルールエンジン
- 共通UI/UX設計ガイドライン（GDSのService Manualのような）
➡ 民間ベンダーは“ここは作らなくてよい”。標準化と品質が跳ね上がる。
③ 各自治体・各業務のロジックはテキストとして書ける構造にする
- ルールや業務フローを「コード化」せず「設定」「記述」で管理する
（→ JSON定義ファイル、ポリシー記述、DSL）
エストニア・フィンランドではすでに Rules as Data / Regulations as Code という名前で取り組みが進んでいます。
以上
《参照》
[1]富士通に続き「間に合わない！」表明のベンダーも…「自治体システム標準化」問題、26年3月の本格稼働まであと半年！ 2025年11月21日
>全国1700以上の市区町村で約3万4000のシステムが動き、予算約7000億円を投じて進む自治体ITシステム標準化プロジェクト。ここへきて昨年の富士通に続き自治体システムでシェアの高いベンダーの1社が2026年3月末までの納期に間に合わないと発表。
https://diamond.jp/articles/-/376097
[2] 自治体システム標準化、政治主導で暗雲
出典：日経コンピュータ、2024年8月8日号
全国の自治体は2025年度末までに主なシステムを標準仕様に準拠させ、その上で政府運営の「ガバメントクラウド」に原則移行しなければならない。ところが今、この移行作業に暗雲が垂れ込めている。標準仕様の改版が続いた上に、岸田文雄政権の経済政策に伴うシステム改修が重なっているためだ。移行に関わる自治体職員、ベンダーなどの困惑は収まらない。このまま進めればシステム障害を含むトラブルも懸念される。「官製デスマーチ」の様相を呈する自治体システム標準化に、打開策はあるのか。
https://xtech.nikkei.com/atcl/nxt/mag/nc/18/073000435/
[3] 自治体システム標準化に激震、富士通が約300自治体に期限内の移行断念を通知
2024.09.27
自治体向けシステム大手の富士通が期限内の移行を事実上断念したことで、移行期限に間に合わない「移行困難システム」に該当する自治体は2024年3月公表の171団体・702システムから急増する見通しだ。2025年度末の期限そのものの見直しを求める声も強まるとみられ、期限内の自治体システム標準化は窮地に立たされている。
https://xtech.nikkei.com/atcl/nxt/column/18/00001/09791/
[4] 自治体システム標準化に激震 富士通が期限内の移行断念と通知
「対応SEの充足困難」と説明、3年半遅れる見通しも 2024.10.17
全国約1700の地方自治体で稼働する基幹業務システムの標準化を巡り、富士通と富士通Japanがシステム移行を担う約300自治体の作業を2025年度末の期限までに完了できないことが明らかになった。両社が関係自治体に通知した。
https://xtech.nikkei.com/atcl/nxt/mag/nc/18/020800017/100801147/
[5] ガバメントクラウド移行後、経費は減らず1.6倍に増加──東京都、国に“具体的な試算根拠”など要請 2025年06月02日
地方公共団体の基幹業務システムの標準化を巡っては、原則2025年度末までに、義務として「国が定める標準的な仕様に適合」させる必要があり、さらに努力義務としてガバメントクラウドへの移行を求めている。これにより国は「標準化移行後のシステム運用経費は18年度比で少なくとも3割の削減を目指す」と掲げている。
> しかし、都の調査結果では、都内自治体の運用経費は、移行前と比べて全体で約1.6倍に増える見込みと主張。また国は、クラウドを最適化することで中長期的には、ほとんどのケースでコスト削減を見込めると説明していたが、これについても「その試算根拠や実現に要する期間、条件などは具体的に示されていない」と都は指摘している。
[6] 東京都が自治体システム標準化で緊急要望、「期限第一」から「安全第一」へ転換求める 2024.10.18
要望書は「地方公共団体の基幹業務システムの標準化に関する緊急要望」と題したもの。要望書によると、東京都内では現在、2025年度末の期限までに間に合わない「移行困難システム」に該当するシステムが19自治体の36システムある。大手開発事業者の方針変更などによって今後大幅な増加が見込まれるとしている。
その上で東京都は、「一律の移行期限にこだわることなく、自治体や開発事業者の状況に応じた十分な移行期間を確保」するよう求めている。移行に関する経費についても、移行時期を問わず国が全額を負担することや、その旨を早期に明確化することを求めている。
https://xtech.nikkei.com/atcl/nxt/news/24/01674/
[7] デジタル社会の実現に向けた重点計画
業務改革（BPR）の必要性
以下のサービス設計12箇条に基づき、BPR（※1）に取り組みます。
1.利用者のニーズから出発する
2.事実を詳細に把握する
3.一気通貫で考える
4.全ての関係者に気を配る
5.サービスはシンプルにする
6.デジタル技術を活用し、サービスの価値を高める
7.利用者の日常体験に溶け込む
8.自分で作りすぎない
9.オープンにサービスを作る
10.何度も繰り返す
11.一遍にやらず、一貫してやる
12.情報システムではなく、サービスを作る