1. はじめに
「将来の成長、競争力強化のために、新たなデジタル技術を利用したこれまでにないビジネスモデルを創出・柔軟に変革するデジタルトランスフォーメーション（DX）が必要である」という大きな潮流がある。※1
この潮流に乗るユーザ企業においては、レガシーシステムからの脱却（刷新、流用等）が課題となる。なぜなら、DX推進には新たなデジタル技術の活用に向けたシステムの拡張性や柔軟性が必要であるが、既存のレガシーシステム（老朽化・複雑化・ブラックボックス化したシステム）は拡張性や柔軟性に乏しく、DXの推進に支障をきたすためである。また、レガシーシステムを把握している人材の退職等により保守継続が困難になり、業務基盤を維持することさえ出来なくなる。
このように、レガシーシステムからの脱却は喫緊の課題であるが、得てして容易ではない。本稿ではレガシーシステムからの再構築が通常のシステム再構築と比較して、なぜ難しいのか、それに対してどんな手を打ったらよいのか考察していきたい。
2. レガシーシステムからの再構築はなぜ難しいか
レガシーシステムからの再構築は、スコープ、ベンダ選定、要件・仕様のすり合わせ、リスク管理面に難しさがあり、品質、コスト、スケジュール面でのクリティカルな問題が発生しがちである。
スコープによる難しさ
通常のシステム再構築と比較して、スコープが肥大化し、難易度が高くなることが多い。なぜならば、通常のシステム再構築のスコープは「業務課題の解決」を主目的とすることが多いが、レガシーシステムからの再構築のスコープは「業務課題の解決」に「老朽化・複雑化・ブラックボックス化の解消」が加わるためである。
そのため、スコープの調整により難易度を下げることが必要であるが、ステークホルダー間の調整が難しい。
＜想定される問題例＞
- 「業務課題の解決」を同時に進めることとした場合、複雑化・ブラックボックス化した部分に機能追加が発生する等、難易度が高くなり品質問題が発生する。
- 計画当初はマイグレーションを主目的にしていても、ユーザ部門からの強い要望により「業務課題の解決」も求められることにより、当初予定していた期間で収まらなくなり、稼働日に影響を及ぼす。
- 開発コストの抑制や期間短縮のため、既存資産の流用にこだわり、複雑化・ブラックボックス化が解消しない。
- 開発コスト抑制のため、複雑化・ブラックボックス化した一部機能は既存資産をそのまま移行（言語を変えず、内容も見直さない）し、新システムでも利用することとしたため、複雑化・ブラックボックス化が解消できない。
ベンダ選定の難しさ
通常のシステム再構築では、既存ベンダ企業は、業務知識を有する等、適切な選択肢の１つであるが、レガシーシステムからの再構築では、必ずしも適切な選択肢とは言えないこともある。なぜならば、既存ベンダはレガシーシステムの複雑化・ブラックボックス化した箇所に対して中途半端な理解であるケースがあり、そういった状態ではプロジェクトが円滑に進むことが少ないためである。
＜想定される問題例＞（既存ベンダ企業の選択が間違っているわけではない）
- 既存ベンダ企業はレガシーシステムに対して中途半端な理解の状態であり、全容を把握している人材がいないことにより、影響調査漏れにより、対応工数の見極め、フィージブルなスケジュールの策定、品質の担保等、全てに問題が発生する。
- 既存ベンダ企業でレガシーシステムの全容を把握している人材が不足していることにより、一部の有識者に影響調査、仕様検討、レビュ等が集中し、有識者が機能せずスケジュール遅延、品質の低下が発生する。
要件・仕様のすり合わせの難しさ
通常のシステム再構築と異なり、レガシーシステムの設計書は存在しないまたは最新化されていないことが多い。そのため、要件・仕様の拠り所が無く、ユーザ企業とベンダ企業の間で認識齟齬が発生しがちである。
＜想定される問題例＞
- 設計工程では、現行踏襲に甘んじてユーザ企業からの表面的な要件の確認に留める上に、現行の要件・仕様の理解も十分でないことから、機能要件が十分に伝わらないことによりスケジュール遅延や品質問題が発生する。
- テスト工程では、設計工程での認識齟齬を引きずった結果、スケジュール遅延や品質問題が発生する。
- ユーザ企業の「現行踏襲」または「現行から××と変える」といった要件に対して、ベンダ企業が「現行」を具体化せず、設計工程での認識齟齬を引きずった結果、受入テスト工程にて品質問題が発覚し、稼働日延伸につながる。
リスク管理面の難しさ
通常のシステム再構築と比較して、不確定要素が多いため、リスク抽出やリスク分析が難しくなる。また、リスクへの影響を見誤ることで、リスク対応が後手に回る。
＜想定される問題例＞
- 前述したような既存資産を流用することに伴う影響調査漏れ等のリスク抽出漏れにより、問題発生時に対応が後手に回り、スケジュール遅延や品質問題が発生する。
- 複雑化・ブラックボックス化した既存資産の影響調査工数が増大するリスクの抽出漏れにより、対応が後手に回りスケジュール遅延が発生する。
3. レガシーシステム再構築プロジェクトにおけるポイント
レガシーシステムからの再構築プロジェクトを成功させるためには、上述したような発生しがちな問題を抑えることがポイントとなる。
グランドデザインフェーズにて現実的な再構築方針を選択した上で(No.1)、経営層のコミット(No.2)、プロジェクトへの落とし込み（No.3～5）、ベンダ選定時の評価方法（No.6）、現行システムの調査（No.7）、リスクの洗い出し（No.8,9）といった対策が必要になる。
図表1. レガシーシステム再構築のポイント
4. おわりに
DXを推進するユーザ企業にとって喫緊の課題であるレガシーシステムからの脱却は、老朽化・複雑化・ブラックボックス化してしまったシステムならではの難しさがあり、品質、コスト、スケジュール面でクリティカルな問題が発生し、うまくいかないプロジェクトが多い。
レガシーシステムからの再構築の難しさは、主にプロジェクトの上流フェーズに集中しており、再構築プロジェクトの開発が本格化する前に、前述したポイントであげたような対策により道筋をつけることが重要になる。本稿を参考にして頂き、2025年の崖を乗り越え、更なる飛躍の一助として頂ければ幸いである。
※1 経済産業省 『DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～』
http://www.meti.go.jp/press/2018/09/20180907010/20180907010-3.pdf