ガバメントクラウドと連携できないシステムの行方

自治体の基幹業務が標準準拠システムへ移っても、独自施策のシステムや庁内の周辺システムがすべて同時に移るとは限りません。残るシステムを直ちに廃止するのではなく、どのデータを、いつ、どの方法で受け渡すかを見直す必要があります。
この記事のポイント
- 基幹業務の移行の遅れ(特定移行支援システム)と、周辺システムの連携の未整備は、別の問題として扱う。
- 残るシステムは、必要な項目・更新頻度・照合番号・停止時の業務を確認し、改修・統合・廃止を判断する。
- 手作業のCSV連携などの暫定運用は、改修か統合かを決める期限と担当を定め、恒久化させない。
移行の遅れと連携の未整備は別の問題
標準化対象の基幹業務システムが、個別開発や事業者の作業遅延などの事情で2025年度末までに移行できなかった場合、特定移行支援システムとして個別に移行計画と期限を扱います。デジタル庁によると、2026年3月末時点で対象34,366システムのうち10,013システムが該当します。一方、基幹業務は移っても、庁内の独自施策や帳票、情報連携の仕組みがつながらない場合があります。両者を同じ「移行失敗」と呼ぶと、対策を誤ります。
周辺システムは接続方法と役割を見直す
残ったシステムについて、標準準拠システムから必要な項目、更新頻度、照合に使う番号、連携が止まったときの業務を確認します。既存のファイル連携を改修する、標準のデータ要件に合わせて受け取り方を変える、機能を統合する、利用が少なければ廃止する、といった判断があります。ガバメントクラウド上へ同居させることだけが選択肢ではありません。外部に残すなら、権限、暗号化、監視、障害時の復旧手順も合わせて設計します。
暫定運用にも終わりを決める
連携が間に合わず手作業のCSV受け渡しでつなぐ場合は、項目の対応表、受け渡し時刻、エラー時の連絡先、二重登録を防ぐ手順を残します。そのまま恒久運用にすると、制度改正や標準仕様の更新のたびに人手の照合が増えます。次の更改までに改修か統合かを判断する期限と担当を決め、移行後の実データで件数と不一致を検証します。
最初に作るのは連携の一覧
基幹業務から周辺システムへ渡すデータを一つずつ洗い出し、用途、管理者、方式、失敗時の影響を並べます。Aikenのような業務システム開発・データ移行の支援先と検討する場合も、この一覧が改修範囲を具体化します。制度上の移行期限と接続方式は自治体と所管機関の最新資料を確認し、個別計画として進めます。
参考・関連リンク



