レガシー・マイグレーションのノウハウ＆ドゥハウ。 計画時サービスからメインサービスまでシステムズの業務をご案内。

■マイグレーションTOP  >  マイグレーション広告アーカイブ  >  雑誌記事：ニッキンFIT2013春

ニッキンFIT2013春

F

O

C

U

S

システム更改の手段としての
マイグレーション

既存資産の整理・明確化の重要性について考える

　新規投資の抑制やコスト削減を強いられてきた企業が、システム見直し・再構築を迫られた場合、何を重要視すべきであろうか。全面再構築からプラットフォームのみの移行までのさまざまな手法が存在するが、どの手法を選択するにせよ、“既存資産の見える化”は、新規システムと企業競争力強化をリンクさせるために不可欠だ。システム更改を成功させるための一手段としてマイグレーションを考えてみたい。

システムの再構築は一筋縄ではいかない

　調査会社IDC Japanの調べでは、2012年のパブリッククラウドサービス市場は前年比46%増の見込みで、2016年には2011年の4. 7倍になると見られている。また、国内データセンターのアウトソーシング市場は、2012年は1兆1300億円規模に達し、今後も成長を続ける見通しだ。このほか、BI(ビジネスインテリジェンス)やBA(ビジネスアナリティクス)といったキーワードが注目されていることを加味すると、システムの仮想化、データの可視化、運用の低コスト化などの動きが顕著になっていくであろう。
　こうした時代の流れに伴い、自社のシステムの見直し・再構築の手段を検討する企業の動きも活発になっている。しかし、一方で、システム更改を進めるには何からどのように手を付ければいいのかに悩む企業も少なくないのである。長く使い続けてきたシステムは老朽化し、度重なる改修による追加や修正で肥大化・複雑化している。システムだけでなく人材のレガシー化も進み、システムを理解できる要員が社内にいないケースも増えている。汎用機など大型コンピュータのレガシー化だけにとどまらない。クライアント/サーバー型の旧いオープンシステムがあったり、サポートの切れたWindowsシステムがあったり、さらにはOSS（オープンソースソフトウェア）やERPのシステムがあったりと、システム更改そのものの多様化も進んでおり、既存システムの見直しは思っているほど簡単にはいかない、というのが正直なところであろう。

再構築の手法を決めるためのアセスメント

　システム再構築を検討する際、システムやデータ資産の移行には、変換ツールを使ってアプリケーションプログラムソースを書き換えて変換する「リライト」、現行の業務仕様をもとに新たにソフトウェア仕様を設計し作り直す「リビルド」、エミュレータや仮想化技術を活用してアプリケーション資産を新しいプラットフォームにそのまま載せ換える「リホスト」ほか、さまざまな手法があり、これらを総称してマイグレーションと呼ぶこともある。それぞれの長所や短所を踏まえた上で、コストやリスク、さらにはシステム部門だけでなく、経営・営業の視点なども考慮して、新規スクラッチ開発なのか、マイグレーションなのか、パッケージ導入やクラウド運用なのかを決めていくことになる（図1）。

図1：システム更改の方策検討の流れ

　しかし、いずれの方法を選択するにせよ、その前に行わなければならないことがある。それがアセスメントであり、その分析・評価手続きに欠かせない資産の棚卸である。
　既存資産を入念に分析し、稼動・不稼動および重複プログラムの洗い出しを行うことは、自社の資産の見える化を行うことにほかならない。有効資産と不要資産を正しく把握することは、無駄なハードウェアリソースの排除や日常の運用管理の効率化の点でも影響をもたらす。例えば、未使用あるいは重複しているプログラム資産を削除することで、システムのパフォーマンスの向上が期待できる。また、運用保守の基礎資料として活用することで、標準化や手順化に役立ち、運用管理の効率化も可能になる。アプリケーション資産だけでなく、サーバーやネットワーク・端末などのハードウェア構成、さらには利用状況などについても調査しておきたいところだ。マイグレーションの手法を検討する前に、マイグレーションをするしないに関わらず、このアセスメントは新システムでの運用に不可欠の大きなポイントになるということである。

マイグレーションの落とし穴

　既存システム資産を明確化し、経営方針や業務特性、コストなどからマイグレーションを適用することになったあとでも、マイグレーション特有のさまざまな課題が待ち受けている。
　まず、マイグレーションベンダに見積もりを依頼すると、各社で費用が大きく異なるケースがある。マイグレーションの費用はどう算出されているのであろうか。移行計画に一切タッチしないベンダもある。また、変換ツールを使って移行するだけでサンプリングテストのみで完了、というベンダもあり、プログラム1本あたりの変換費用だけを算出している。また、テストには疎通テストと比較検証テストがある。後者は、トラブルの原因の多くが把握でき品質を左右する重要なテストだが、これを行わないベンダもある。十分なテストが行われないことで、かえってコストが高くついたというケースも出ている。安価なマイグレーションの見積には必ず理由があり、単に費用だけで判断しないことが大切だ。
　また、マイグレーションは基本的に現行保証である。例えば、メインフレーム系のデータベースで浮動小数点6桁まで出ていたのが、新しいRDBにすると十数桁まで値が出てしまう、ということがある。新機能の追加により、新たな問題も発生する可能性がある。運用面についても、現在の延長線上で対応できると考えがちだが、ミドルウェアやハードウェアの変更、性能向上などに伴い、運用の見直しが必要な機能も多く存在する。
　このほか、マイグレーションには付きものなのが、ステークホルダーの反対である。SIベンダやユーザ部門、子会社などとの調整は欠かせない。

マイグレーションも“始まりが肝心”

　これまで述べたように、システム見直し・再構築には、さまざまな観点からの考察と準備が必要である。特に最初の段階、すなわち方向性の診断や現行資産の棚卸が成功を左右するため、豊富な経験とノウハウを備えたベンダの支援は重要だ。
　40年を超えるシステム構築のスキルとノウハウを持つシステムズは、国内外で11の特許（2013年3月現在）を取得し、北海道での自治体クラウド開発実証事業の一環として行われた利用実証にも参加するなど、その技術は広く認められている。前述したソフトウェア資産の棚卸や移行性検証、移行計画の作成といった上流工程に重きを置いたエンジニアリング型のマイグレーションサービスの提供が特徴だ（図2）。さらに、4GLやPL/Iなど第4世代言語、異言語からの移行や、サポートが終了したVisual Basicベースで構築されたソフト資産からの脱却の悩みについても、豊富な実績により、最適な解決策を提案している。

図2：システムズが提供するマイグレーション