自治体標準化の「その先」へ

コラム

― パッケージ導入だけでは終わらない、本当のDXとは

はじめに

デジタル庁が主導する自治体情報システムの標準化・共通化は、全国1,700以上の自治体に適用され、いよいよ本格的な移行・稼働フェーズに入っている。

デジタル庁が2025年12月に公表したデータによれば、標準化対象となる34,592システムのうち、令和7年度末までに移行できなかった「特定移行支援システム」は5,009システム(14.5%)。さらに、そうしたシステムを1つでも抱える自治体は全国1,788団体中743団体――4割を超える自治体がこれから本番を迎える状況だ。

標準化パッケージの導入は、ゴールではない。本当の課題はむしろ、導入した後に始まる。

私はITエンジニアとして、自治体システムにとどまらず民間企業のシステム開発にも長年携わってきた。開発・保守・マイグレーション・パッケージ導入・運用はもちろん、客先折衝・提案・見積から要件分析・設計・開発・テスト・稼働後の運用保守まで、一気通貫ですべての工程を経験してきた。技術だけでなく、業務そのものへの深い理解も、その過程で積み上げてきたものだ。

その経験から言えることがある。パッケージを「入れただけ」では、職員の負担は減らない。市民サービスは向上しない。現場の業務を知り、技術を知り、全工程を知っているからこそ見える課題がある。 そのギャップを埋める知恵と技術こそが、いま自治体に求められているのだ。


第1章:「2025年度末完了」は最初から無理筋だった

デジタル庁が2025年12月に公表したデータがある。標準化対象となる34,592システムのうち、令和7年度末までに移行できず2026年度以降に持ち越しとなった「特定移行支援システム」は5,009システム、全体の14.5%に上る。

さらに深刻なのは、こうした遅延システムを1つでも抱える自治体が、全国1,788団体中743団体――実に4割を超えるという事実だ。

原因は明らかだ。期限の設定が短すぎた。ベンダーへの業務集中でリソースが逼迫した。メインフレームで稼働している旧来システムは移行難易度が極めて高い。これらは計画段階から予見できたはずの問題である。にもかかわらず「2025年度末完了」という目標が掲げられ、全国の自治体が一斉に動き出した結果がこの数字だ。

そして遅延だけでなく、移行できた自治体でも別の問題が噴出している。移行後の運用経費が急増しているのだ。 減るはずだったコストが逆に膨らみ、困惑する自治体が相次いでいる。


第2章:標準化パッケージが抱える構造的な問題

問題の根はさらに深いところにある。

そもそも標準化パッケージの多くは、運用を意識した設計思想で作られていない。標準仕様とは「最低限の機能要件」を定めたものに過ぎず、管理方法・操作性・確認手段・画面や帳票の作りといった運用に直結する部分は仕様に定義されていない。本来であれば、そこをベンダー間の競争と製品の優位性で補うべきだった。より使いやすいパッケージでなければ選ばれない、という市場原理が品質を担保するはずだったのだ。

しかし現実はどうか。令和7年度末という全国一斉の移行期限が設定されたことで、競争原理は事実上機能しなくなった。どのベンダーも同じ時期に受注が集中し、競合他社との差別化を図る必要がない状況が生まれた。その結果、リソース不足を理由にした必須要件のみの実装、標準仕様の都合の良い拡大解釈、そしてベンダー主導の価格設定による落札が横行した。しわ寄せは当然、現場に向かう。

パッケージそのものは「既存製品に必須機能を追加しただけ」のものが少なくない。管理できればよし、単件で確認できればよい、画面や帳票ではなく人間が読みにくいCSVファイルで出力できればよい――そういう発想で実装された機能が、自治体の現場に納品されている。

SIerもまた板挟みだ。現場から上がってくる運用改善の声をパッケージベンダーに伝えても、上層部で跳ねられる。機能改善の要望は受け入れられず、現場とベンダーの間で身動きが取れない。


第3章:「標準仕様」の解釈がバラバラという現実

もう一つ、現場で深刻な問題が起きている。デジタル庁が定める標準仕様そのものの解釈が、ベンダーによって異なるという問題だ。

標準仕様は、本来であれば全国共通のルールとして機能するはずのものだ。しかし実態は、仕様の記述に解釈の余地が生じ、ベンダーによって連携データの仕様が微妙に、あるいは大きく異なるケースが頻発している。「標準」と名のつくものが、標準として機能していない。

では、その仕様差異が発生したとき、誰が解決するのか。

デジタル庁ではない。各省庁の協議会で議論されていると思われるが、仕様書のバージョンを引き上げるにはスケジュールへの影響もあるため、待っていられない。現場に降りてくる言葉は「自治体内のシステム間で調整を」という逃げ言葉だ。調整の責任は自治体内に押し付けられ、最終的にはシステム間の橋渡しを担うベンダーのいずれか、あるいは双方が費用負担なしに泣き寝入りを強いられる構図が生まれている。

標準化の恩恵を受けるべき自治体とベンダーが、標準化の歪みによって最もしわ寄せを受けている。 これが現実だ。

こうした仕様差異・連携データ仕様の不整合は、パッケージ納品前に気付けるケースも多々ある。導入後の保守・運用・連携対応まで一貫して関わる立場だからこそ、はっきりと見える課題だ。私たちが課題の洗い出しにこだわる理由の一つがここにある。


第4章:パッケージの外側に、解決策がある

では、どうするのか。

パッケージそのものを変えることはできなくても、その外側でできることは数多くある。たとえば、こういったことが改善の対象になりうる。

データの入出力部分に変換処理を外付けし、職員が扱いやすい形に整える。CSVファイルでしか出力できないデータをPDF帳票に自動変換する。バッチ処理の並列化やSQLのチューニングで処理速度を改善する。不必要なパッケージ処理を無効化し、システム全体の負荷を下げる。インフラの設計を見直し、クラウドとオンプレミスの最適な構成に組み直す。そして、その自治体の業務に合った運用マニュアルを整備し、職員が迷わず使える環境を作る。

これらは「パッケージだから無理」と諦められがちな課題だ。しかし技術的には十分に手が届く領域であり、私たちはその課題の洗い出しから改善提案・実装まで、一緒に考えることができる。

パッケージは変えられなくても、現場は変えられる。


第5章:課題の洗い出しから始める、私たちのアプローチ

私たちが大切にしているのは、パッケージを「入れた後」の現場に寄り添うことだ。

まず行うのは課題の洗い出しだ。どの業務でどんな非効率が生じているか。どこで職員の手作業が増えているか。運用コストの増加はどこから来ているか。現場の声を丁寧に拾い上げ、技術的な観点から原因を特定する。

次に改善策の設計と実装だ。インフラの再設計、外付けシステムの開発、運用フローの見直し、チューニング――課題に応じて最適な手段を組み合わせる。特定のメーカーやベンダーに依存しないマルチベンダーの立場だからこそ、しがらみなく最善の選択ができる。

そして継続的な保守・改善だ。システムは生き物だ。業務が変われば要件も変わる。その変化に柔軟に対応し続けることが、長期的なコスト削減と職員満足度の向上につながる。


おわりに:「標準仕様だから、パッケージだから仕方ない」は、終わりではない

標準化対応を終えた自治体も、これから迎える自治体も、現場で同じような声を聞く。

「標準準拠システムだから、これ以上は変えられない」「パッケージだからカスタマイズできない」「ベンダーに確認したが対応不可と言われた」――。

しかし、本当にそうだろうか。

パッケージそのものに手を加えることはできなくても、その周囲には改善の余地が十分に残されている。 インフラの構成を見直す、業務フローとシステムのギャップを外付けで補う、連携仕様の不整合を補完する、運用をチューニングする。こうした取り組みの積み重ねが、職員の日常業務を確実に楽にする。

職員の皆さんに伝えたいのはこういうことだ。「パッケージだから」という言葉で諦めないでほしい。 改善できることは必ずある。その課題を一緒に洗い出し、具体的な改善策を提案し、実装まで責任を持って対応する。それが私たちの役割だと思っている。

またパッケージベンダーやシステムインテグレーターの皆さんへも、一言申し上げたい。インフラ・外付け対応・連携仕様の調整・運用チューニングといった領域は、パッケージ導入の守備範囲を超えることも多い。そうした場面で、特定メーカーに依存しない独立した立場から課題解決に加わることが私たちの強みだ。競合ではなく、現場を一緒に前に進めるパートナーとして声をかけてほしい。

「どこに相談すればいいか分からない」という自治体担当者も、「導入後の課題を抱えている」というベンダーも、まずは話を聞かせてほしい。課題の整理から一緒に始める。