基幹システムの保守期限、属人化、データ連携の難しさが同時に表面化すると、経営会議では「全面刷新するか、延命するか」という二択になりがちです。 しかし、対象範囲も依存関係も曖昧なまま一括更改を決めると、事業部門は将来の要件を先回りして詰め込み、IT部門は停止できない機能を抱え、移行リスクと費用の見通しが立たなくなります。

2025年5月に経済産業省が公表した「レガシーシステムモダン化委員会総括レポート」は、古い技術や製品を使っていることだけを問題にするのではなく、 ビジネスの変化に追従しにくい状態を捉え、IT資産の可視化、経営層のコミットメント、情報システム部門の自律性、事業部門との連携などを重視しています。 2026年にIPAが公開したDX-IT推進指標案も、DX戦略とITシステム・データの関係を整理し、全社最適の投資判断と再レガシー化の防止につなげる考え方を示しています。

つまり、モダン化は「新しい技術へ置き換える大規模案件」ではなく、事業が変わる速度にITを合わせ続けるポートフォリオ運営です。 本記事では、経営者、IT責任者、業務部門が同じ材料で判断し、小さく確かめながら前へ進むための5ステップを整理します。

課題：刷新対象が「システム名」だけで語られている

「販売管理を刷新する」「基幹をクラウド化する」といったシステム名だけでは、投資判断に必要な解像度が足りません。 一つのシステムの中に、競争力へ直結する機能、法令・契約上維持すべき記録、他で代替できる共通機能、ほとんど使われていない機能が混在しているためです。

また、利用部門が把握する業務価値と、IT部門が把握する技術的な変更困難性は同じではありません。価値が高くても安定して変更できる機能は急いで置き換える必要がない場合があります。 反対に、利用者が少なくても多数の連携先を止める単一障害点なら、先に境界を整理すべきです。年齢、言語、稼働場所だけでレガシー判定をしないことが出発点になります。

基本構造：価値・変更困難性・移行リスクの3軸で見る

各IT資産を、少なくとも次の3軸で同じ尺度に置きます。第一は事業価値です。売上、顧客体験、供給継続、重要な経営判断のどこを支えるかを明らかにします。 第二は変更困難性です。変更のリードタイム、試験可能性、仕様の把握度、データ取り出しや連携のしやすさ、特定要員・ベンダーへの依存を確認します。 第三は移行リスクです。停止許容時間、データ整合性、切戻し、並行稼働、取引先や周辺システムへの影響を見ます。

米国CIO CouncilのApplication Rationalization Playbookも、アプリケーション台帳を作り、事業価値、技術適合性、総保有コストを評価して、維持・廃止・移行などの選択へつなぐ手順を示しています。 評価結果は「全件を同じ方式で刷新する」ためではなく、資産ごとに扱いを変えるために使います。

実践手順：段階移行へつなぐ5ステップ

1．業務能力とIT資産の対応を可視化する

まず、システム一覧を更新する前に、顧客から価値を受け取り提供する業務の流れを確認します。その上で、アプリケーション、データ、連携、インフラ、運用手順、契約、担当者を業務能力へひも付けます。 台帳には責任者、利用部門、重要データ、連携先、保守期限、主要変更の履歴を含めます。完全な構成管理データベースを最初から目指すのではなく、優先判断に必要な項目から始めます。

2．3軸で評価し、優先順位を合意する

事業価値、変更困難性、移行リスクを、経営・業務・IT・運用の関係者がそれぞれ根拠付きで評価します。点数だけで自動決定せず、評価差の大きい項目を対話の材料にします。 「価値が高く変更困難性も高い」「保守期限が近く代替がある」「利用実態が乏しい」といった群に分け、先に調査する対象、廃止候補、安定維持する対象を明確にします。

3．資産ごとに扱いを選ぶ

選択肢は全面再構築だけではありません。現状維持、契約・基盤の更新、再ホスト、技術基盤の置換、構造改善、製品・サービスへの置換、再設計、統合、廃止などがあります。 目的は「クラウド化率」や「新技術の採用数」ではなく、変更リードタイム、品質、データ利用、運用負荷など、解消したい制約を改善することです。

4．境界を切り、戻せる単位で移行する

優先対象を、利用者群、業務イベント、データ領域、API、地域、商品など、責任と効果を測れる単位へ分けます。最初の単位では、移行前後の受入条件、データ照合、監視、切戻し条件を定義します。 重要データを一度に移すより、読取り経路の分離、連携の仲介、限定利用者での並行運用など、失敗時に影響を閉じ込められる順序を検討します。

5．成果と再レガシー化の兆候を追う

移行完了ではなく、事業側の成果と変化への追従力を定期的に確認します。変更要求から提供までの時間、リリース失敗と復旧、手作業・二重入力、データ品質、運用工数、利用率などを、当初の制約と結び付けて追います。 デジタル庁の2026年改定DS-100は、サービス・業務改革と情報システムの整備・管理を一体として扱う共通ルールを示しています。民間企業がその手続をそのまま採用する必要はありませんが、企画から運用まで責任と判断をつなぐ視点は参考になります。

注意点：モダン化を再び固定化の案件にしない

  • 技術名で廃止を決めない：古くても安全に変更・試験でき、事業に適合している資産は、安定維持が合理的な場合があります。
  • 台帳作成を目的化しない：項目を増やす前に、どの投資判断・停止判断へ使うかを決めます。
  • 総保有コストだけで比べない：移行中の二重運用、教育、業務変更、データ浄化、切戻しの費用とリスクを含めます。
  • ベンダーへ判断を丸投げしない：技術選択の支援は受けても、事業価値、許容停止、残すデータ、受入条件は自社が責任を持ちます。
  • 一度の審査で終わらせない：保守期限、利用量、事業戦略、障害、契約変更を契機に優先順位を更新します。

最初の90日で作るべき成果物

最初の30日で、重要な業務能力と主要IT資産の対応、責任者、停止影響を可視化します。次の30日で、3軸評価と根拠をそろえ、廃止候補、詳細調査対象、安定維持対象を分けます。 最後の30日で、優先対象を一つ選び、移行境界、受入条件、切戻し、成果指標を含む小さな実行計画を作ります。

この期間に全社の完全な将来像を確定する必要はありません。重要なのは、推測だった依存関係を検証し、一つの判断を実行可能な単位へ変え、次の評価へ使える事実を増やすことです。

まとめ

レガシー刷新は、古いものを一括で新しくする作業ではありません。業務能力とIT資産を対応付け、事業価値・変更困難性・移行リスクで優先順位を決め、資産ごとに扱いを選び、戻せる単位で移行し、変化への追従力を測り続ける経営プロセスです。

FourthWallは、経営、業務、IT、運用の対話を設計し、IT資産の可視化から優先順位、段階移行、効果測定までを一貫して支援します。大規模更改の前に、まず「何を変えられる状態にしたいのか」を明らかにすることが、失敗しにくい第一歩です。

参考資料

本記事は公開資料に基づく一般的な情報提供を目的とし、個別企業の投資判断、契約、会計、法務に関する助言ではありません。実際の計画では、事業特性、法令・契約、データ、セキュリティ、可用性の要件を関係専門家と確認してください。

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る