過去2回に渡り、レガシーマイグレーションの手法、およびリライトの勘所について紹介をした。システムは利用されて初めて価値が出るものであり、今回は最終回として、稼働後の保守運用を見据えた視点からマイグレーションの勘所をご紹介したい。
システム変更箇所はどこなのか？
可能な限り現行資産を有効活用するマイグレーションは、リホスト/リライト/リビルドのいずれの手法を採用しても、現行機能の担保が大前提となる。その前提によって、低コスト・短納期でシステム構築を行い、利用ユーザは変更負荷無く業務継続を実現できる。
では、マイグレーション後のシステムにおける保守運用面に影響は無いのだろうか？答えはノーだ。システムを実現するテクノロジーが変わる事により、具体的にはシステム構造や利用プロダクトが変わってしまうためである。つまり、システム保守運用においては採用手法やプロジェクト個別の状況に大小違いはあれど、変わらなければならない部分が出てきてしまう。ここではまず、多くのマイグレーションプロジェクトに共通するであろうシステム変更箇所について示す。
アプリケーションアーキテクチャの主な変更箇所
まず、アプリケーションアーキテクチャの主な変更箇所として、「ミドルウェア/フレームワーク」「文字コード」「プロダクトライフサイクル」の3点を指摘したい。
- ミドルウェア/フレームワーク
- ビジネスロジックは、リホストではそのまま、リライトでは新言語に書き換えられるが、共通的な動作基盤である、ミドルウェア/フレームワーク上で動作する事になる。レガシーシステムとオープンシステムで提供される機能は同じでも、ミドルウェア/フレームワークでのコンポーネント構造、処理方式等は異なる場合が多い。
新システム稼働後のシステム改修、構成変更や障害対応などの保守運用をスムースに行うためにも、現システム・新システム間の機能対比を静的構造（コンポーネント図等）、動的構造（コントロールフロー図等）で把握しておく事が重要だ。 - 文字コード
- 多くのレガシーシステムで使われるEBCDICやEBCDIKは、移行後のオープンシステムでJIS、S-JIS、EUC、Unicodeなどに変更される。実は、この部分は唯一と言っていいほど業務面に影響が出てしまう箇所である。各文字コードの詳細な対応表はここでは割愛するが、コード体系の違いによりデータのソート順（並び替え順）に違いが出てしまうケースがある。少量のデータ数での画面表示等であれば問題は小さいが、大量データや、データ連携での出力ファイル、帳票出力などは業務上問題となる可能性がある。
しかし、システム構築期間中に全レコードのソート条件をテストする事は非現実的であり、稼働後の保守運用にて対応せざるを得ない。 - プロダクトライフサイクル
- ほぼ1つのベンダープロダクトで構成されるレガシーシステムと違い、オープンシステムは複数ベンダーから提供されるプロダクトで構成される。更にプロダクト間の依存関係も有り、動作保障が取れるプロダクトバージョンも指定される。新システム稼働後の保守運用における不具合修正の適用やバージョンアップ対応には注意が必要であることは言わずもがなであるが、更にはベンダ毎のプロダクトライフサイクル（製品バージョンアップ/保守期間）についても把握しておく方が良いだろう。
インフラアーキテクチャの主な変更箇所
一方、インフラアーキテクチャの主な変更箇所として、「分散/クラスタ」に関する点に注目したい。
- 分散/クラスタ
- 基本的には1つの筐体に全てのシステム機能が配置されるレガシーシステムと、複数のサーバ筐体にシステム機能を分散して配置されるオープンシステムという違いがある。更に、レガシーシステムはハードウェアのMTBF（平均故障間隔）がオープン系サーバのそれよりも長いと言われている。
稼働後の保守運用においては、構造的に分散/クラスタ化されている箇所に着目し、特に性能、可用性（信頼性）、拡張性の非機能部分に注意を払いたい。具体的にはシステム機能配置と、スケールアップ/スケールアウトの余地について把握しておくと良いだろう。
保守運用で考えるべきこと
上記で示した変更に限らないが、マイグレーションではシステムアーキテクチャの変更を伴い、稼働後の保守運用に影響があることがお分かり頂けたであろう。そして、保守運用については、自社メンバによる内製主体の場合はメンバのスキル移行や組織体制、アウトソーシング主体の場合は現行保守運用ベンダからのスイッチも事前準備が必要となる。
マイグレーションプロジェクトにおいて、システム稼働後が本番である。マイグレーションによって生じた変更箇所を見抜き、十分な準備をされたい。