脱ホスト・脱レガシー言語の現実解 — 段階移行か一括刷新かの判断基準

「2025年の崖」が経産省によって警告されてから7年が経過した2026年、問題は解消されるどころか深刻化が続いている。DX着手率が約73%に達した一方、成果が出ている企業は約28%にとどまり、レガシーシステムを抱えたまま「DX中」を続ける企業は後を絶たない（IPA「DX動向2025」）。脱ホスト・脱レガシー言語のプロジェクトに限れば、「始めたが止まった」か「始める前に断念した」という二択になりやすく、経営の意思決定が改めて問われる局面にある。その核心は、「一括刷新か段階移行か」という問いに経営として答えを出すことだ。

移行手法は大きく3つに整理できる。第一は「リホスト」で、COBOLなどのアプリケーションをそのまま残し、稼働基盤だけをメインフレームからオープン系サーバーやクラウドへ移す方式だ。導入コストは3手法の中で最も低く移行期間も短い反面、技術的負債の根本解決にはならず、COBOL技術者不足の問題を先送りするにすぎない。第二は「リライト（再設計）」で、JavaやPythonなど現代言語で一から組み直す手法だ。保守性と拡張性が大幅に向上し、生成AIとの連携も容易になるが、工数とコストは大きく膨らむ。第三が「ビッグバン（一括刷新）」で、既存システムを停止し新システムへ一気に切り替える方式であり、最もリスクが高い選択肢として位置づけられる。

ビッグバン方式が失敗する理由は構造的だ。数十年にわたり改修を重ねた基幹系COBOLシステムは、仕様書が現実と乖離しているか、そもそも存在しない場合が多い。担当技術者の頭の中にある暗黙知が唯一の仕様書であり、その技術者が定年退職を迎えつつある企業は少なくない。さらに規模が大きくなるほど要件確定から稼働まで数年を要するため、プロジェクト開始時点と稼働時点でビジネス要件が変化してしまう。コスト超過・機能不足・稼働遅延の三重苦を同時に抱えるリスクが、ビッグバン方式には構造的につきまとう。

対照的に、段階的モダナイゼーションが実際に機能するのは「失敗の単位を小さくする」という原則があるからだ。全体を機能単位またはサブシステム単位に分解し、独立性の高い部分から移行を開始する。移行済み部分と既存系の並行稼働期間を設けることで、問題が発生しても既存系に戻せる状態を維持できる。一回の移行フェーズを90〜180日以内に収め、「何が完了し何が残っているか」を経営が定量的に把握できる粒度で進めることが、投資の可視性を高め追加予算の承認を得やすくする。

「段階移行か一括刷新か」を経営が判断するための軸は3つある。第一は「システムの複雑度」で、COBOLのコード行数が100万行を超える場合、または他システムとのインターフェースが200本を超える場合は、ビッグバン方式のリスクは許容できないと考えるべきだ。第二は「技術者の在庫」で、現行システムを理解する社内・ベンダー技術者の定年退職が3年以内に集中する場合は、段階移行でも速度を引き上げる必要がある。第三が「ビジネス中断の許容度」で、月次・年次決算処理や法定業務が乗っているシステムは稼働停止ウィンドウが極めて限られており、一括切り替えのタイミング設計が事実上困難だ。この3軸で整理するだけで、大半のケースで「段階移行以外の現実解はない」という結論が先に出る。

当研究所がヘルスケア経営の現場から企業変革の支援に知見を展開してきた経験において、レガシー刷新プロジェクトが止まる原因の多くは技術的な問題ではなく、意思決定の構造にある。「誰が何をもって完了とするか」が経営レベルで定義されないまま始まったプロジェクトは、スコープが膨張し、ベンダーとの認識ズレが積み重なり、経営の関与が薄れたところで止まる。現場で検証済みのことしか提案しないという姿勢のもと、当研究所では移行方式の選定より先に「プロジェクトの意思決定構造」を設計することを起点としている。経営がチェックポイントを定期的に持てない規模・期間のプロジェクトは、最終的に経営が主体性を失うという結末に至りやすい。

脱ホスト・脱レガシー言語の判断は、技術選定の問題ではなく経営意思決定の問題だ。段階か一括かを決める前に、プロジェクトの完了基準と経営の関与構造を先に設計することが、刷新を「動くプロジェクト」にするための最も確実な一手となる。自社のレガシー刷新戦略を経営の視点から整理したい場合は、当研究所の経営層ブリーフィング（ https://fujii-consulting.jp/contact ）でご相談いただきたい。現場実装の知見をもとに、御社の規模・システム構造・リスク許容度に合わせた移行設計を具体的に提示する。