2025年の崖を越えるには
~レガシーシステム脱却に向けたマイグレーションのポイント~

企業戦略事業本部
マネージングイノベーションユニット
シニアコンサルタント 小野 真也

1. はじめに

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

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

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

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

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

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

<レガシーシステムのマイグレーションの実態>

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

2. レガシーシステム脱却に向けたマイグレーション

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

2.1. レガシーシステム脱却に向けたマイグレーションが目指すべき状態

本稿では、レガシーシステム脱却後の目指すべき状態を拡張性や柔軟性がある状態(レガシー状態解消)とする。なぜならば、DX実現には新たなデジタル技術(例:AI、ビックデータ、アナリティクス等)の導入が必要であり、システムには拡張性や柔軟性が求められるためである。

図1. レガシーシステム脱却に向けたマイグレーションにて実現すべき状態
図1. レガシーシステム脱却に向けたマイグレーションにて実現すべき状態

2.2. レガシー状態解消に最適なマイグレーション手法

一概にマイグレーションといっても様々な手法があり、代表的な手法として「リホスト」「リライト」「リビルド」の3種類が存在する。これらの手法のうち、拡張性や柔軟性があるシステムの実現には、設計~基盤の全レイヤを刷新する「リビルド」が最適であると考えられる。

図2. マイグレーションの種類
図2. マイグレーションの種類

3. レガシーシステム脱却に向けたマイグレーションで陥りがちな状況と要因

上述の通り、レガシーシステム脱却すなわちレガシー状態解消にはリビルドが最適である。しかし、レガシーシステムのマイグレーションをリビルドで進める場合、プロジェクトの各フェーズで問題が発生し、『レガシー状態の解消不可』または『プロジェクトそのものが頓挫』する状況に陥ることがある。その要因として、リビルドによるレガシー状態解消の理解が得られない、スコープの肥大化、要件・仕様の把握不足といったことが考えられる。

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

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

・スコープの肥大化

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

・要件・仕様の把握不足

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

図3. リビルドによるレガシーシステム脱却が陥りがちな状況
図3. リビルドによるレガシーシステム脱却が陥りがちな状況

4. マイグレーションを成功させるための対策

レガシーシステムのマイグレーションプロジェクトを成功させるには、『レガシー状態を解消できない』または『プロジェクトそのものが頓挫する状況に陥らない』ための対策が必要である。本稿では対策として、「レガシー状態解消の必要性の訴求」「現行システムの調査・分析」「マイグレーション手法の組み合わせ」「要件・仕様の把握不足」を紹介する。

図4.リビルドによるレガシー状態解消が失敗する要因と対策
図4.リビルドによるレガシー状態解消が失敗する要因と対策

4.1. レガシー状態解消の必要性の訴求

ユーザ企業の経営層にリビルドによるレガシー状態解消の理解が得られない場合、レガシー状態を解消できないリスクがある。

その対策として、本稿ではレガシー状態解消の必要性を経営層に訴求することを挙げる。対策のポイントは、DX実現といったシステムの将来像を明示した上で、一足飛びのDX推進はスコープ肥大化等によりプロジェクトが頓挫するリスクが高く、レガシー状態では最新デジタル技術の活用が困難と示すことである。

図5. システムの将来像とロードマップのイメージ(例)
図5. システムの将来像とロードマップのイメージ(例)

4.2. 現行システムの調査・分析

現行システムのレガシー状態を十分に把握しないままリビルドによるマイグレーションを進めた場合、スコープの肥大化や要件・仕様の把握不足により、レガシー状態を解消できない、またはプロジェクトが頓挫するリスクがある。

その対策として、本稿では現行システムの調査・分析※2を挙げる。対策のポイントは、レガシー状態を正確に把握するため、現行システムの設計書の更新状況、仕様とプログラムの乖離、プログラムの複雑化状況等を正確に把握できるような調査・分析観点(ユーザ企業、ベンダ企業それぞれの観点)を事前に決めた上で調査を進めることである。

図6. 現行システムの調査・分析観点(例)
図6. 現行システムの調査・分析観点(例)

4.3. マイグレーション手法の組み合わせ

レガシー状態解消にはリビルドが最適であるものの、リビルドはスコープ肥大化の傾向があるため、開発期限や開発予算超過を招き、レガシー状態を解消できないリスクがある。

その対策として、「4.2.現行システムの調査・分析」によりスコープ肥大化が判明した場合、リビルド以外のマイグレーション手法を組み合わせてスコープ肥大化を抑制することが挙げられる。対策のポイントは、スコープを抑制するため、サブシステム毎のレガシー状態、利用頻度、重要度等を基準に、サブシステム単位でマイグレーション手法を組み合わせることである。さらに、スコープを十分に抑制できない場合、機能単位でマイグレーション手法を組み合わせることである。

図7. マイグレーション手法の組み合わせ例(機能単位)
図7. マイグレーション手法の組み合わせ例(機能単位)

4.4. 現行システムの要件・仕様の復元

現行システムの要件・仕様を正確に把握できないまま開発を進めると、要件定義・設計工程にて要件・仕様を確定できないリスクやテスト工程にて仕様漏れが多発するリスクがある。

その対策として、「4.2.現行システムの調査・分析」により要件・仕様の把握が困難な箇所が判明した場合、現行システムの要件・仕様を復元※3することが挙げられる。対策のポイントは、現行システムは設計書が最新化されていないため、動いている現行システムを正として、通常の開発工程の下流から上流に向かって復元を進めることである。

図8. 現行システムの仕様の復元(例)
図8. 現行システムの仕様の復元(例)

5. 対策の進め方

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

図9.マイグレーションを成功させるための対策の実施タイミング(例)
図9.マイグレーションを成功させるための対策の実施タイミング(例)

<企画フェーズにおける対策>

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

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

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

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

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

<計画フェーズにおける対策>

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

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

<実行フェーズにおける対策>

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

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

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

図10.レガシー状態解消プロジェクトの具体的な推進イメージ
図10.レガシー状態解消プロジェクトの具体的な推進イメージ

6. おわりに

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

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

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

Page Top