なぜ政府におけるレガシーシステム刷新は失敗するのか（そして、実際に機能する方法とは）

日本の中央省庁や地方自治体には、数十年前に構築された基幹システムが今なお社会インフラとして稼働しているケースが少なくありません。これらのシステムは、現代的なデジタル体験には適合していないものの、日々の行政サービスを確実に支え続けています。

しかし課題が顕在化すると、しばしば次のような発想に行き着きます。

「古いシステムをすべて新しく作り直そう」

一見合理的に見えるこの判断が、日本の政府ITプロジェクトでは高い確率で失敗します。その理由を理解することが、より良い解決策への第一歩です。

なぜ政府はレガシーシステムを置き換えようとするのか

全面刷新が魅力的に見える理由は明確です。

保守・運用が困難になっている
ベンダーサポートの終了
技術者の高齢化・人材不足
国民からのデジタル化要求の高まり

民間企業であれば、大きな痛みを伴いながらも刷新が成立する場合があります。しかし日本の行政においては、同じアプローチが予算超過、監査リスク、長期遅延、あるいは「静かに止まるプロジェクト」を生みがちです。

日本の政府において刷新が失敗する理由

1. レガシーシステムは法制度に支えられた社会インフラである

多くの行政システムは:

24時間365日の安定稼働が求められる
法令・省令・条例に基づく業務を支えている
停止や大幅変更が想定されていない

短時間の停止であっても、国民生活や行政手続きに深刻な影響を及ぼし、説明責任や監査対応が発生します。この構造自体が、全面刷新を極めて高リスクな選択肢にしています。

2. 制度知・業務知がシステムそのものに埋め込まれている

レガシーシステムには:

長年の制度運用の判断
例外処理や現場対応の積み重ね
法解釈の実装結果

がコードとして蓄積されています。これらは文書化されていないことも多く、システムを作り直すことは、制度知を失うリスクを伴います。

3. 日本の調達・予算制度とソフトウェア開発は本質的に相性が悪い

日本の行政調達では一般的に:

仕様を事前に確定する必要がある
複数年度契約になりやすい
途中変更が困難

一方で、ソフトウェア開発は仮説検証と改善の連続です。このギャップが、刷新プロジェクトを初期段階から不安定にします。

4. 失敗の責任は可視化され、成功は当たり前と見なされる

行政においては:

失敗は強く可視化される
成功は評価されにくい

この非対称性が、大胆な意思決定を抑制し、結果として中途半端な設計や妥協を生みます。

5. Big-Bang型の切替はほぼ機能しない

一度に切り替えるということは:

大規模データ移行
全職員への同時教育
複数部局の業務変更

を同時に行うことを意味します。日本の行政組織構造において、この同時達成は現実的ではありません。

では、何が機能するのか：全面刷新を避けたモダナイゼーション

参照アーキテクチャ：レガシーを維持したまま進化させる

flowchart TB
    Citizens["国民・事業者"]
    Channels["デジタルチャネル\n(Web / モバイル / ポータル)"]
    Gateway["APIゲートウェイ / 連携レイヤ"]
    Workflow["ワークフロー / ケース管理"]
    Data["共通データモデル\n(マスターデータ)"]
    Legacy["既存基幹システム\n(メインフレーム / ERP / 登録系)"]

    Citizens --> Channels
    Channels --> Gateway
    Gateway --> Workflow
    Workflow --> Data
    Data --> Legacy

    Gateway --> Legacy

この構成により、日本の行政機関は既存システムの安定性と監査性を維持したまま、新しいデジタルサービスを段階的に追加できます。