超ド底辺地方公務員の管理人です。
さて・・・
2026年、新しい年が明けました。
本来であれば「新システム稼働で業務効率爆上がり！ 」と言いたいところですが・・・
現場に漂っているのは新年を祝う空気などではなくどす黒い絶望と、
どこに向けたらいいのか分からない怒り、
そして「以前のシステムを返してくれ」という悲痛な思いです。
なぜ、これほどまでに現場が疲弊しているのか。
それは、2025年末までに強行された「自治体システムの標準化・共通化」という、
国家規模の壮大な「無理ゲー」のツケが、今まさに末端の職員に回ってきたからに他なりません。
1. 逃げ場のない「片道切符」の強制移行
管理人が勤務する自治体でも、2025年末に基幹業務システムが「標準システム」へと移行しました。
1月の仕事始めからこの「標準化共通化システム」を使っているのですが、
正直に申し上げましょう。
「使いにくい！」以上。
そもそも、この移行プロセス自体が狂気の沙汰であった。
国が進めるこの施策はほぼ強制であり、地方自治体に拒否権などない。
しかも、十分な検証期間すら与えられないまま、文字通りの「片道切符」で移行させられたのである。
本来、大規模な基幹システムの刷新には、慎重な「並行稼働検証」が不可欠だ。
特に自治体業務には、月次や年次といった周期的なバッチ処理がある。
新旧システムに同じデータを流し込み、処理結果が1円の狂いもなく一致するかを確認するプロセスこそが生命線なのだが、我々にはその機会すら与えられなかった。
「動かなかったらどうするのか？」なんて関係なし。
国は無言で「期限までに移行せよ」という旗を振り続ける。
これはもはや、ブレーキの壊れたダンプカーで雪道を爆走させられているようなものである。
2. 「走りながら飛行機を修理する」開発現場の地獄
さらに混乱に拍車をかけたのが、開発と並行して進む「法改正」だ。
システムを構築している最中にも、国は次々と新しい制度や法改正をぶち込んでくる。
仕様が確定しないまま開発を進めざるを得ず、
ベンダーは新旧両方のシステムを同時に改修するという離れ業を強いられるのである。
このような極限状態で、使い勝手の良いUIや洗練された操作性が生まれるはずがない。
一般の方からすれば「国が主導するんだから、さぞかしスマートなシステムだろう」と思われるかもしれない。
しかし現実は否である。
3. ガバメントクラウドの理想と「歪んだ」現実
今回の標準化の要となるのが「ガバメントクラウド（Gov-Cloud）」である。
その多くはAWS（Amazon Web Services）を利用した構成である。
デジタル庁は「クラウド化でコスト削減」を掲げてるが、
これもまた現場の視点で見ると首を傾げざるを得ない。
管理人が、デジタル庁が標準化で「OK」を出している某ベンダーの構成図を覗き見たとき・・・
ナニコレ？？？状態だった。
そこにあったのは、AWSが推奨する「Well-Architected（最適化された構成）」から大きく逸脱した、お世辞にも美しいとは言えない構成図だったからだ。
クラウドの利点であるスケーラビリティを無視し、ただ物理サーバーをクラウド上に置いただけのような、コスト効率を度外視した「とりあえず動く」構成。
これでは、運用コストが下がるどころか、跳ね上がるのは火を見るより明らかである。
まさに、高級食材（AWS）を買い込みながら、
調理法を間違えて消し炭にしているようなものである。
4. セキュリティという名の「データ抽出妨害」
そして、現場の職員を最も絶望させているのが、
無駄に高すぎるセキュリティの壁が生んだ「自由度のなさ」である。
最大の悲劇は「DB（データベース）への直接アクセスができない」ことだ。
これまでのシステムでは、標準機能で対応できない複雑な集計や、
イレギュラーなデータ抽出が必要な際、
管理人のような少しITに明るい職員がODBC接続等でSQLを叩き、サッとデータを引いてくることができた。
それが現場の「痒い所に手が届く」運用を支えていたのである。
しかし、新システムではこれが許されない。
「セキュリティ確保」の名のもとに、職員はシステムが用意した貧弱な「汎用データ出力機能」に依存せざるを得なくなった。
しかし、この機能がまた絶望的に使えない。
CSV出力の「三重苦」
- 業務に合わない： 出力項目が固定されており、特定の業務で必要なデータが揃わない。
- データ定義がない： 出力されるCSVにヘッダー定義やデータ型情報がないため、Excelに取り込むたびに「ここは文字列、ここは日付」と手動で定義し直す必要がある。
- 相手が変わらない： システムは変わっても、提出先である国や県が求める「提出フォーマット」は以前のまま。結局、不親切なCSVを手作業で加工して資料を作るという、不毛な作業時間だけが激増している。
DBに直接ODBC接続できれば、型変換など気にせず一瞬で終わった作業が、
今では数時間を要する大仕事になっている。
これが「DX」による効率化なのか？
5. 仕事のやり方を置き去りにした「機能だけの標準化」
ブログランキングにご協力ください！
結局のところ、今回の「標準化」は、システムの「機能」だけを無理やり型に嵌めたに過ぎない。
本来、機能の標準化を行うのであれば、それ以上に「仕事のやり方（業務フロー）」を国が責任を持って標準化すべきだったはずだ。
現状は、各自治体が長年培ってきた効率的な業務フローを無視し、
使い勝手の悪いシステムに合わせて「人間が不便なやり方に合わせる」という本末転倒な状況に陥っている。
国はシステムの機能要件を提供することには執心したが、
業務をどう回すべきかという定義を放棄したのである。
本来なら、国が業務のやり方そのものを定義し、使い勝手の良い「SaaS」を構築して自治体に使わせるべきだった。
そうすれば、自治体ごとにベンダーと格闘し、高額なクラウド費用に頭を抱える必要もなかったはずである。
6. まとめ
さて、この「すこぶる使い勝手の悪い」システムと心中せざるを得ない我々職員に、
救いはあるのだろうか？
以前のようにシステムそのものを改修することは、もはや自治体にはできない。
とりせる選択肢としては・・・
- 期待を捨てる： 「システムが良くなる」という幻想を捨て、不便であることを前提に業務を設計する。
- 中間処理の自動化： システムから吐き出される不親切なCSVを、PythonやRPA、あるいはExcelのマクロを駆使して「成形するツール」を自作する。
しかしいずれも効率がが悪い。
おわりに
いったい、自治体システムの標準化・共通化とは誰得だったのだろうか？
あまりにも期間が短すぎ・・・
ベンダーでは死人がでるとまで言われていた。
コストだけがかさんで、お世辞にも使い勝手が良いとは言えないシステムだけが残る。
機能仕様を標準化するという旗印は良かったかもしれないが・・・
SaaSでない以上、ベンダロックインも回避できない。
２０年～３０年後を見据えたときに、地方のベンダーが消滅し、
システムが維持できなくなることを踏まえれば、
確かにどこかのタイミングで標準化は必要だったと思うが、
もう少し時間を掛けて、やるべきプロジェクトであったことは間違いない。
コメント