2025年の崖を越えるには

「将来の成長、競争力強化のために、新たなデジタル技術を利用したこれまでにないビジネスモデルを創出・柔軟に変革するデジタルトランスフォーメーション（DX）が必要である」という大きな潮流がある。^※1

この潮流に乗るユーザ企業においては、レガシーシステムからの脱却（刷新、流用等）が課題となる。なぜなら、DX推進には新たなデジタル技術の活用に向けたシステムの拡張性や柔軟性が必要であるが、既存のレガシーシステム（老朽化・複雑化・ブラックボックス化したシステム）は拡張性や柔軟性に乏しく、DXの推進に支障をきたすためである。

前回のレポート『2025年の崖を越えるには ～レガシーシステム脱却におけるポイント～』(2019年3月)では、レガシーシステムからの脱却は、老朽化・複雑化・ブラックボックス化したシステムならではの難しさがあるため、品質、コスト、スケジュール面でクリティカルな問題が発生し、失敗する事例があることを紹介した。その対応方針の１つとして、段階開発（1段階目：現行システムのマイグレーション、2段階目：業務機能の強化）が考えられることも併せて紹介した。

しかし、段階開発の１段階目である現行システムのマイグレーションは、「ステークホルダのマイグレーションに対する認識」と「レガシーシステムのマイグレーションの実態」の乖離があるため、十分な対策をとらないままプロジェクトを進めてしまい、プロジェクトが困難な状況に陥るケースがある。そのため本稿では、レガシーシステム脱却に向けたマイグレーションが陥りがちな状況、及びその要因と対策について考察する。

＜ステークホルダのマイグレーションに対する認識＞

• 現行資産を流用できるため、コストやスケジュールを抑制可能
• 現行システムと同一仕様を製造するため、同等のシステムの製造は容易
• 要件・仕様については現行システムを踏襲することで容易に定義可能

＜レガシーシステムのマイグレーションの実態＞

• 現行資産を流用できず、コストやスケジュールを抑制できない
• 度重なる変更等でシステムの全容を把握出来ず、現行システムと同等のシステムの製造は困難
• 要件・仕様がブラックボックス化しており、現行システム踏襲では要件・仕様の定義が困難

マイグレーションは現行システムの要件を変更せず、システムを新しくする取り組みである。

しかし、一概にマイグレーションといっても、マイグレーション後のシステムの状態やマイグレーションの手法などは様々である。そのため、まずはマイグレーションが目指すべき状態及び最適な手法を整理する。

上述の通り、レガシーシステム脱却すなわちレガシー状態解消にはリビルドが最適である。しかし、レガシーシステムのマイグレーションをリビルドで進める場合、プロジェクトの各フェーズで問題が発生し、『レガシー状態の解消不可』または『プロジェクトそのものが頓挫』する状況に陥ることがある。

その要因として、リビルドによるレガシー状態解消の理解が得られない、スコープの肥大化、要件・仕様の把握不足といったことが考えられる。

• リビルドによるレガシー状態解消の理解が得られない

リビルドは現行システムと要件を変更せずにシステムを刷新する手法であり、業務改善や業務改革は達成されない。そのため、多額の投資が必要となるリビルドによるレガシー状態解消に対してユーザ企業の経営層から理解が得られず、リビルドからリホストに方針変更せざるを得ない状況に陥る。

• スコープの肥大化

リビルドは設計～基盤の全レイヤを刷新するため、他手法と比較してスコープが肥大化する傾向がある。スコープの肥大化により、計画フェーズで開発期限や開発予算の超過が判明し、リビルドからリホストに方針変更せざるを得ない状況に陥る。

• 要件・仕様の把握不足

現行システムの要件・仕様不足により、設計工程で仕様が確定できないためリビルドからリホストに方針を変更せざるを得ない状況に陥る。または、テスト工程で多数の仕様漏れや仕様齟齬が多発するため、不具合が収束せずプロジェクトを中止せざるを得ない状況に陥る。

レガシーシステムのマイグレーションプロジェクトを成功させるには、『レガシー状態を解消できない』または『プロジェクトそのものが頓挫する状況に陥らない』ための対策が必要である。

本稿では対策として、「レガシー状態解消の必要性の訴求」「現行システムの調査・分析」「マイグレーション手法の組み合わせ」「要件・仕様の把握不足」を紹介する。

「4.マイグレーションを成功させるための対策」を有効に機能させるためには、適切なタイミングで実施する必要がある。そこで、対策を実施するタイミングを整理する。

＜企画フェーズにおける対策＞

現行システムの調査・分析により正確に現状把握し、必要に応じてマイグレーション手法の組み合わせによりスコープ肥大化を抑制する。その上で、ユーザ企業の経営層にレガシー状態解消の必要性を訴求し、承認を得る。

　① ユーザ企業が現行システムの調査を行い、レガシー状態の可能性を調査する。レガシー状態の可能性が判明した場合、ベンダ企業に調査を依頼する。

　② 上記①を受けて、ベンダ企業が現行システムを調査・分析し、レガシー状態を詳細に把握する。

　③ 上記①、②の結果、スコープ肥大化リスクが判明した場合、サブシステム単位でマイグレーション手法を組み合わせることにより、スコープ肥大化を抑制する。（企画フェーズではサブシステム単位のマイグレーションの組み合わせを想定）

　④ ユーザ企業の経営層にレガシー状態解消の必要性を訴求し、レガシー状態を解消する方針の承認を得る。

＜計画フェーズにおける対策＞

必要に応じてマイグレーション手法を組み合わせることにより、スコープ肥大化を抑制する。

　⑤ 上記③でスコープが十分に抑制できない場合、さらにスコープを抑制する必要があるため、マイグレーション手法を機能単位で組み合わせることにより、スコープ肥大化を抑制する。

＜実行フェーズにおける対策＞

必要に応じて現行システムの要件・仕様を復元する。

　⑥ 上記②の現行システムの調査・分析の結果、要件・仕様の不明箇所が判明した場合、現行システムのソースコード等を基に、要件定義工程内で現行システムの要件・仕様を復元する。

上記の対策を踏まえたレガシー状態解消プロジェクトの具体的な推進イメージをまとめる。

本稿では前回のレポートで紹介したレガシーシステムの段階開発(1段階目：現行システムのマイグレーション、2段階目：業務機能強化)における、1段階目の現行システムのマイグレーションについて深堀し、陥りがちな状況の要因と対策について考察した。

現行システムのマイグレーションによりレガシーシステムから脱却するには、上流での舵取りが重要である。具体的には、プロジェクトの道筋をつけるために、現行システムの調査・分析によりレガシー状態を正確に把握した上で、必要に応じてマイグレーション手法の組み合わせ等によるスコープコントロールを行うとともに、経営層にレガシー解消の必要性を訴求し承認を得るといった取り組みが必要になる。

また、現行システムの設計書は最新化されていないため、要件定義や設計を始める前に現行システムの要件・仕様が不明確な箇所を復元する取り組みが必要である。

本稿を参考にして頂き、2025年の崖を乗り越え、更なる飛躍の一助として頂ければ幸いである。