レガシーを“終わらせる”GovTech：使わなくなった行政システムの賢い終活術

どうも〜おかむーです！今日はちょっとマニアックに「既存の行政システムをどうやって安全に、かつ市民に迷惑かけずに終わらせるか」を扱いますよ〜

• 3行要約

- レガシーの放置はコストとリスクの温床。撤去・移行を設計する「終活」が重要

- エストニアの相互運用基盤や、ノルウェーの失敗事例から学ぶガバナンスと技術戦略

- 日本は法的期限、資金化、API・データカタログで“計画的廃止”を制度化すべき

結論

レガシーをただ置き換えるのではなく「計画的に終わらせる」プロセスを制度化しよう。要するに、廃止計画（sunsetting policy）を技術・調達・予算・市民UXの4軸で仕込めば、長期コストとリスクを大幅に下げられるということです。

レポート本文

なぜ“終活”が必要か

真面目な話をすると、古いシステムを放置すると維持費がかさむだけでなく、セキュリティ脆弱性やデータサイロ化を生むんですよね。NAO（英国会計検査院）が示すように、ガバナンス不備やスコープ膨張がプロジェクト失敗の大きな要因です（参考：NAO insight）。

成功事例：エストニアの仕組みから学ぶ

エストニアはe-Estoniaで有名ですが、鍵は中央のデータ交換レイヤ（X-Road等）と強力なデジタルID、そしてサービスを薄く分離する設計です。要するに、アプリケーションをインターフェース化しておけば、内部を入れ替えても外部は影響を受けにくいということです（eesti.ee, e-estonia.com）。これにより個別サービスの廃止や刷新がスムーズになります。

失敗から学ぶ：ノルウェーのケースや一般的な失敗要因

ScienceDirectのノルウェー事例研究や業界の失敗分析（42Gears, WalkMe）が指摘するのは、次の点。

• ガバナンスが曖昧で責任が分散する
• 要求が揺れ動きリソースが分散する
• 技術的負債の棚卸が不十分

これ、ぶっちゃけ計画的に“いつ終わらせるか”を決めてないのが根本です。

技術的な終活手法（実装レベル）

• APIと契約（SLAs）を先に定義：内部実装を変えても外部依存は壊さない
• データカタログ＋移行マップ：どのデータをどのシステムに移すか明確化
• Stranglerパターン導入：新サービスが古システムの機能を段階的に奪っていく
• コンテナ化・CI/CD・機能フラグで段階的切替：ブルーグリーンやロールアウトで市民影響を最小化
• 永続化・アーカイブポリシー：法定保存期間や監査要件に合わせた長期保存設計

要するに、終わらせるにもちゃんと技術の段取りが必要だということです。

市民UXと透明性

市民視点では「いつまで使えるのか」「代替手段は何か」が大事。移行中はUXの落ち込みを許さないために、明確なロードマップと暫定UX（レガシー互換APIや移行ツール）を用意すると信頼が保てます。

日本への具体的示唆

• 法制面：古いシステムに「廃止期限」を定める法律やガイドラインを作る
• 財務面：レガシー廃止基金（自治体向け）を用意して、短期的コストを補助
• 技術面：政府共通のインタオペ層（APIゲートウェイ、データカタログ）を強化。エストニアのX-Roadの発想は参考になる
• 調達面：調達契約に“廃止・移行計画”を必須化。ベンダーの出口戦略を評価指標にする
• ガバナンス：廃止責任者（sunsetting owner）を組織で定め、進捗をオープンにする

これ、シンガポールに住んでた頃に見た「サービス化」と似てるんですが、向こうは廃止・移行を前提に作っている点が違いました。真似できるところ多いです！

まとめ

• レガシーは放置が最大の敵。計画的な廃止を制度化しよう
• 技術的にはAPI化、データカタログ、Stranglerパターン、段階的デプロイが有効
• 日本は法的期限・資金支援・調達ルールで“終活”を後押しすべき

おかむーから一言

2度起業してコードも書いた僕から言うと、作るのは簡単、終わらせるのが本当に難しいんですよ。テクノロジーで社会をアップデートするなら、最後まで責任を取る仕組みを作ろうぜ！