全4446文字
PR

レガシーをクラウドに移行するには、物理サーバーやミドルウエアの対応が必要だ。メインフレームの移行では、既存のサービスやツールを適用できないケースに注意しよう。システムが部分最適化されている場合、どこからクラウドへ移行するかを検討する。

 DX(デジタルトランスフォーメーション)に向けてレガシーシステムを解体するには、現在のレガシーシステムがどうなっているかを把握することが第一歩だ。仕様書や設計書がない、もしくはそれらが最新化されておらず「本番環境で動いているシステムだけが手がかり」では把握が難しい。

 今回は、レガシーシステムの全容を把握する際のポイントを解説する。そこから見えてきたDX化に必要になる人材像やスキルも合わせて解説する。

ほとんどの業務がレガシー上で稼働

 DXの推進において、現在動いているシステムやデータをすべて捨て、最新の技術を使ったパッケージやカスタム開発でリビルドし、全システムを刷新できるなら既存システムを把握する必要はない。しかし、現行の全業務を整理してシステム化の要件をまとめ、ビジネスプロセスを全面刷新するために数年かけてシステムを構築するのは非現実的である。

 また、既存システムに新しいパッケージを導入する際に、業務側から「今行っている業務はそのまま再現してほしい」という要望が上がることがある。その場合、パッケージに合わせて業務を変えるのではなく、既存のビジネスプロセスをそのまま踏襲し、パッケージが提供する機能でカスタマイズして業務要件を実装することになる。

 今後は、さまざまなSaaS(ソフトウエア・アズ・ア・サービス)や、ローコード・ノーコードのソリューションを使い、システム開発・保守の簡素化が進むことも考えられる。この場合でも、既存業務を見直す必要があるが、ほとんどの業務がレガシーシステム上で稼働している。つまり、DX推進においては、レガシーシステムの内容を把握し、どう刷新するかが鍵になる。

クラウド化の難所

 レガシーシステムを把握する方法として、アプリケーションが出力するログをすべて収集し、どのモジュールやロジックがコールされたかを確認する方法がある。また、APM(アプリケーションパフォーマンス管理)のソフトウエアで全トランザクションとコールされたモジュールを判別し、可視化して全量を把握する方法もある。

 APMは本来システムのどこにボトルネックがあるかを把握するために使われるが、どのロジックが呼ばれていないかをシステマティックに判別するのにも有効である。ただし、この時点では既に使われていない不要なロジックの判別には使えるものの、ロジックの中身まで把握するのは困難である。

 DXに向けたレガシーシステム活用において、レガシーシステムのクラウド化を妨げる難所は大きく3つある。