/note/tech

DX推進をうたっても老朽システムは放置 経産省のレポートが暴く「不都合な真実」

要約:

■ 1. レガシーシステムモダン化委員会の総括レポート

  • 経済産業省・IPA・デジタル庁が事務局を務める「レガシーシステムモダン化委員会」が2025年5月に総括レポート『DXの現在地とレガシーシステム脱却に向けて』を公表
  • 2018年の「DXレポート」で「2025年の崖」として警鐘を鳴らしたレガシーシステム問題への対応が進んでいない現実を明らかにしている
  • 公表後1カ月程度で1万件を超えるダウンロードがあり、問題への関心の高さを示している
  • DXの成否を分けるのはAIへの投資額ではなく、レガシーシステムに含む自社独自の重要データを「使える状態」にできるかどうかである

■ 2. レガシーシステムの現状

  • 大企業の74%がレガシーシステムを保有していると回答
  • IT化の歴史が長い大企業、特に社会インフラ事業者に多い
  • 経産省の「DX推進指標」でも不要なITシステムの廃棄が進んでいない傾向が示されている
  • 負債化が進んだITシステムは規模が膨れ上がる傾向にあり、規模が大きいほど対応コスト・期間・リスクが飛躍的に増大する
  • 本格的なIT変革には、まず改革対象を絞り込み適正規模に縮小することが不可欠
  • 対策に本格的に取り組んだCIOの事例:
    • まず不要なシステムの廃棄から着手(使われていない帳票・画面を段階的に利用停止)
    • すぐに削除せず、表面上は使えない状態にしつつ1年間は復旧可能な状態を維持
    • 問い合わせや業務に支障がないものから順次削除し、大幅なシステム削減を実現

■ 3. 「既存システムは今のままでいい」という誤認

  • DXと称してAIやWebのユーザー接点部分の改革を推進する一方、「既存ITシステムは今のままでいい」と断言するCIOが存在する
  • システムモダナイズの最大の目的は企業の競争力確保である
  • システムモダナイズとは、企業が持つデータをAIが活用できる状態に転換することを指す
  • データが「使える」状態とは、精度・鮮度・粒度が適切に保たれていること
  • レガシーシステムが抱えるデータは企業独自の最も重要な資産である
  • データ活用を実現するアーキテクチャとしてオブジェクト指向技術(マイクロサービス)の適用が有効

■ 4. ウォーターフォールの基本と設計手法の変化

  • ウォーターフォールモデルはソフトウェア開発の基本であり、オブジェクト指向開発でも基本は同様
  • モノリスシステムとMSAの設計手法の主な違い:
    • データベース設計:
      • モノリスではデータベース設計が大きな比重を占める
      • オブジェクト指向ではデータはオブジェクト内にカプセル化され、APIを通じてのみアクセスするためデータベース設計の比率が極端に低下する
    • システム間接続:
      • 従来はトランザクションデータを基本に考える
      • MSAではAPI接続を前提に考える
    • トランザクション管理:
      • モノリスでは一括確定が比較的容易
      • MSAではサービスが分散するため、データ整合性を保つ新たな仕組みが必要

■ 5. 外部設計の「揺らぎ」問題と解消策

  • 外部設計工程が「揺らぐ」理由:
    • 外部設計は顧客の要求事項をまとめる段階だが、全ての要求が技術的に実現できるとは限らない
    • 実現困難な機能については内部設計以降の工程を先行実施し、実現可能性を見極める必要がある
    • この技術的実現可能性の確認プロセスが「揺らぎ」を生む
    • SIerが受託契約を結ぶには実現可能性の事前確認が不可欠であったため、この構造が定着した
  • 内製化を前提にすれば「揺らぎ」が解消できる:
    • 実現方式をほぼ見極められる内部設計までを含めて「設計工程」とすることで整理が明確になる
    • ユーザー企業が設計内容の妥当性を判断するスキルを持つことが前提
    • 「何を作るか」はユーザー企業が決め、「どう作るか」はSIerが担うという従来の役割分担の見直しが必要

■ 6. MSA時代の開発工程と設計の再定義

  • MSA時代の開発工程の整理:
    • 概要設計工程: 大まかな要件を定義する
    • 基本設計工程: 概要設計を実現するための設計(外部設計活動と内部設計活動を含む)
    • 開発工程: 基本設計に基づく開発
    • テスト工程: 開発成果物の検証
  • 基本設計工程内で技術的問題が発生した場合は概要設計に立ち戻ることで「揺らぎ」を吸収する
  • サブシステム単位の設計が基本になる:
    • 従来の大規模ITシステムは20〜30程度のサブシステムから構成されるモノリス構造だった
    • MSAではビジネスの成長に合わせてサービスを分割・拡張し、API接続で連携させる
    • 新たな開発方法論では、個々のサブシステム単位で直接設計に入ることが前提となる
    • 結果として大規模ITプロジェクトがなくなり、プロジェクト規模が適正化され成功確率が高まる
  • 「追認型マネジメント」への転換:
    • 各マイクロサービスを厳格に管理するよりも、チームごとの判断で柔軟にサービスを発展させ、全体の整合性を事後的に確認する「適応型のマネジメント」が求められる
    • 全体のマイクロサービス構成をある程度の粒度で把握する「追認型マネジメント」に変わる
  • 既存レガシーシステムの移行においては、巨大なモノリスシステムの「積み木崩し」が必要となるため、超大規模ITシステムの方法論も一部必要になる