【保存版】失敗しないシステムマイグレーションの基本と注意点丨ベトナムオフショア開発 -NTQジャパン

【保存版】失敗しないシステムマイグレーションの基本と注意点

移住・移転・移動などを意味するマイグレーションは、IT用語としては既存システムやソフトウェア、データなどを別の環境に移転したり、新しい環境に移行することを意味します。単にシステム回りの機能・性能を向上させるだけではなく、デジタルトランスフォーメーション(DX)の第一歩としても効果的です。

株式会社アイ・ティ・アールが公開した国内IT投資動向調査報告書2022では、企業におけるDXの推進にかけるIT予算が増加する傾向が顕著に見られたと記載があります。一方、DXの第一歩として古くなったシステム(レガシー)による制約を脱却するためにマイグレーションを行う企業が増えています。そのため、DXの注目度が上がるなか、マイグレーションのニーズも高まっています。

本記事では、システムマイグレーションについて説明したうえで、開発ベンダーの視点からマイグレーションの工程や課題とその対策、システム運用との関連性を解説いたします。

マイグレーションとは？

マイグレーション(Migration)は、移住・移転・移動などを意味する英単語ですが、IT分野においては既存のシステムやソフトウェア、データなどを新しい環境に移し替えることを意味します。

現在、OSのサポート終了、保守費用の重さ、データ量の増加によるストレージの圧迫、クラウドサービス導入等、様々な理由からシステムのマイグレーションが行われています。これらの理由を受けて実行にうつされるマイグレーションは、インフラ環境の調整の利便性や運用コスト削減といったメリットがあることから、IT担当者や経営者が注目しています。

マイグレーションとコンバージョンで混乱する方は少なくないですが、IT用語として、コンバージョンはデータやファイルを別の形式に転換することを意味します。つまり、マイグレーションが新しい環境へ移行する手法であるのに対して、コンバージョンはシステム状態の転換を意味しています。

マイグレーションの工程

マイグレーションは通常、フェーズを複数に分けて進めます。フェーズの分け方はプロジェクトによって若干異なりますが、各フェーズにおける主な目標と内容に相違はありません。

今回は、最近よくあるオンプレミス環境からクラウドサービスへのマイグレーションを例に各工程での実施内容と留意点を解説します。

■企画

企画立案者はクラウドを理解したうえで、クラウド移行の目的を明確にし、期待効果を含めてマイグレーションの目標設定を行います。

企画における留意点で、一番大事なことは社内の合意を取りながら、今後の進め方や体制について計画を細かく決めていくことです。クラウドへのマイグレーションには多くの費用や時間がかかり、特に業務システムのクラウドへのマイグレーションは経営にも大きなインパクトがあります。

また、マイグレーションを成功させるためには、考慮すべき項目を整理し、重要な項目を見落とさないように検討を進めることがポイントです。考慮漏れがある場合、システムを本格的に稼働させる際にトラブルが起き、マイグレーションができず、レガシーを使い続けることになってしまう可能性もあります。それを避けるためにも企画立案者は一般的に下記のような項目を確認しておくことをおすすめします。

1. オンプレミス環境と比較した際のクラウドの利点や制約を把握すること

現在のオンプレミス環境とクラウドの利点を整理したうえで適切なクラウドベンダーを選択する必要があります。現在、クラウド市場で最も利用実績が多いAmazon Web Services(AWS)、Microsoft Azure、Google Cloud Platform(GCP)がお勧めですが、それぞれメリットとデメリットがあるため、目的にあった企業を選ぶ必要があります。

特に人気のあるAWSとAzureを下記のBlogで比較していますので、是非ご覧ください。

【NTQ Engineer Insight】大手クラウドサービス会社のAWSとAzureをを比較してみた

2. マイグレーションの目的を明確にすること

一般的にマイグレーション対象のシステムは関係者が多いため、クラウドへ移行する必要性を納得してもらわないと、承認と実施は困難になります。既存のシステムから移行する際、現場のオペレーションが変わることから反対する人が現れることも推定されます。納得を得るにはマイグレーションの目的を明確に伝えることが出来なければ、いけません。

また、マイグレーションを外部に依頼する場合、目的が明確に定まっていないと適切な開発ができずに案件の失敗につながる可能性が高くなります。

■戦略・分析

マイグレーションの対象と移行順序を決定します。具体的には、既存システムの現状把握、インフラ情報の収集、クラウドベンダーの選定、マイグレーション対象の整理、以降順序の設定の流れで進めます。

戦略・分析の段階では、まず、既存のシステムの現状を把握することが重要です。マイグレーションにおいては、新システムの主管部門、利用者数、今後の拡張計画を検討する必要がありますが、既存のシステムの機能・特徴を一覧化することで検討が容易になります。

次にインフラ情報の収集と整理を進める際、サーバ機器だけでなく、ストレージやネットワーク機器等、現状のインフラも一覧化して整理するようにしましょう。一覧化することで、保守期間によって必要となる入れ替えのタイミングを見積もることができます。

クラウドベンダーの選定にあたっては、ここまでで収集したシステムとインフラの情報を基にサービスレベル、性能、セキュリティ等の観点でクラウド環境の要求を明確化することが必要不可欠です。現状に紐づけて整理した重要な要件に基づいてクラウドベンダーを評価することで、今回のマイグレーションに最もふさわしいベンダーを選定することができるようになります。

ベンダー決定後のマイグレーション対象の整理では、移行可能性とそれに伴うリスクを整理することで、トラブルが起きる可能性が限りなく低いロードマップが策定できます。

ここまでで明らかにしてきたマイグレーションの対象、ロードマップに基づく移行コストの概算、マイグレーション方法等の情報を踏まえれば、実現性の高い順序、ロードマップを策定することができます。

■PoC(概念実証)

本番と近い環境で実際のサービスを利用し、計画で予想できない影響や問題になりそうなことを確認します。

この段階では、関係者にPoCの目的を共有し、検証した内容を一緒にレビューします。また、PoCの結果に基づいて、定期的に検証する項目とその優先順位を調整し、必要に応じて項目の変更、追加を行います。

納期と予算に制限があり、PoCをしない企業もありますが、NTQとしてはプラットフォームに関する懸念点を検証するためにも実施したほうがいいと考えています。

■設計・移行

ここまでの結果に基づいて、詳細な設計作業、標準化作業を実施し、個別システムのマイグレーションを実施します。

設計では、全体に影響を及ぼす箇所については、個別の移行プロジェクトに入る前に設計を完了させるほうがいいです。また、要求されるサービスレベルを実現できるアーキテクチャを類型化することも重要です。用途ごとに複数のアーキテクチャを用意することができればベストです。

旧システムから新システムへの移行する際は、データの互換性に注意しながら、進めましょう。

■運用・改善

移行後、新しいシステムでサービス運用を開始します。マイグレーションの効果を最大化するために運用で見つかった課題に応じてシステムの改善を行うべきです。

改善にあたっては、効果測定とマイグレーションのレビューという習慣を社内に定着させながら、システムの最適化を進めることが重要だと考えます。

サービス停止時間やメンテナンス時間等、異常が発生するデータを確認しながら、懸念が発生する原因を調べて対応する方法から始めるのがいいでしょう。また、クラウドの課金額からも、大きい変動がある場合に異常があると推測できます。

マイグレーションの課題と対策

■既存システムの設計書や仕様書が不足している

マイグレーションにおいて、既存システムの状況を整理することが重要なのは、先述の通りです。特にシステムの構成を理解することはマイグレーション後のシステムが旧システムと最低限同様の機能を有することを保証するために非常に重要です。そのため、マイグレーションを進めるにあたっては、一般的に旧システムの設計書や仕様書を参照します。

既存のシステムも開発したシステムだから仕様書や設計書があるものだと安心されている方も多いですが、マイグレーション対象のシステムは、何年も前に開発されたシステムであることが多く、設計書や仕様書が紛失していることがあります。また、メンテナンスや応急処置の対応した際、内容が更新されていないことで仕様書や設計書が実態と乖離していることもありえます。このような状況において、なんとか構成を理解するためにヒアリングしようとしてもメンテナンスを実施した元担当者が退職し、マイグレーション対象のシステムの構成がブラックボックス化してしまっているケースが散見されます。

こうした場合、旧システムの設計書・仕様書がない場合、戦略・分析フェーズでの解析に時間をかけ、システム構成を明確にしましょう。解析には時間がかかるため、実装しながら、テストで何とか調整することを前提にそのままマイグレーションを進めようとしてしまう企業も少なくありません。しかし、システム構成を十分に理解しないうちにマイグレーションを行うと予想できない問題が後からたくさん出る可能性が非常に高いです。特にマイグレーション後の保守フェーズまで問題が解決できないケースもあります。

■旧システムのワークフロー理解が難しい

マイグレーションの対象になるシステムは多くの場合、業務システムのような大規模なシステムです。大規模なシステムは多くの開発者が設計、開発に携わったことで複雑になっており、ワークフローの完全な理解には多くの時間と多くの工数がかかります。

もちろん、設計書には業務機能の記載はあります。しかし、業務自体の説明はないため、システムで実現しようとする業務を完全に理解するのは難しいです。実際、システムを新しく設計、開発する工数よりもシステム理解そのものにかかる工数が多くなるパターンが多いです。特に、システムで実現したい業務が複雑な場合や会社固有のものである場合、業務を知らない開発者に任せると、やりたかったことが全くできないシステムが完成する可能性もあります。

対策として、早い段階で業務を理解してもらうように開発を依頼する会社に促しましょう。説明資料として、画面の遷移、インプットする情報の流れ、締め処理の一覧等を準備しておくとスムーズな理解が促せます。

■マイグレーションの中で発生するすべての問題を想定することが難しい

先述の通り、マイグレーションの対象になるシステムは多くの場合、業務システムのような大規模なシステムです。そのため、現行のシステムが大規模で複雑なものである可能性が高く、そうした場合には計画段階ですべての問題をリストすることが難しくなります。

全体に影響を及ぼす箇所をうまく移行してから、個別のシステムの移行を進めることで不足の問題が出た場合の影響を最少化することが対策になります。

また、予想外の問題が発生しやすくなる理由として、新しいシステムのアーキテクチャに移行した後のシステムのマッピングが難しいことがあげられます。

対策として、旧システムの構造と新しいアーキテクチャの両方を理解することが必要です。

■期待ほどマイグレーションの効果が出ない

マイグレーションには大きな期待をしがちですが、単にオンプレミスからクラウドに移行しただけでは、システムのパフォーマンスの改善、コストの削減を通したビジネスのDX推進にはつながりません。また、マイグレーション後、CPU、メモリ、ストレージ容量、デイスク使用率等のリソース管理の対象も多くなり、システムの監視が複雑になります。

運用監視、セキュリティ対策等、総合的な視点から最終的な目的を決定し、それを満たす具体的なサービスを提供できるパートナーを選びましょう。