TOP業務システム> 単に基盤を移すだけではないマイグレーション手法の適用パターン




IT基盤を刷新する レガシーマイグレーション入門
IT基盤を刷新する レガシーマイグレーション入門

第6回:再構築後のシステムの価値を持続させる真のレガシーマイグレーション
著者:新日鉄ソリューションズ   荒木 義史   2006/8/4
1   2  3  次のページ
単に基盤を移すだけではないマイグレーション手法の適用パターン

   これまで5回にわたってレガシーマイグレーションに関する話題を取り上げてきた。最終回である今回はそれらをまとめて、レガシーマイグレーションを行う上でのポイントを紹介する。

   第1回「そもそも、レガシーマイグレーションとは何か」で触れたように、レガシーマイグレーションの一般的分類として「Rebuild」「Rewrite」「Rehost」の3手法をあげることができる。この分類は特にSI業界で統一された標準というわけではないが、いくつかのバリエーションが存在し、フロントの画面部分のみを変更する場合でも「Refront」や「Reface」とマイグレーションの1つとするベンダーもある。しかしこれら3手法は、どのベンダーでも一般的に用いている分類であると考えている。

   しかし、これら「Rebuild」「Rewrite」「Rehost」という分類は、基盤や言語を置き換えるだけの「Rehost」や「Rewrite」の安価短工期という特徴を強調するためには有効であるが、「Rebuild」については再構築と言い切ることでレガシーマイグレーションではないような印象を与えている面がある。中には、レガシーマイグレーションとは「Rehost」であると捉えているお客様もいる。しかしこれまでのシステム構築の経験から、当社は現在のレガシーマイグレーションについての一般的な捉えられ方について疑問を感じている。

SI経験から導きだした新しいレガシーマイグレーションの捉え方

   当社では、「レガシーシステム刷新プロジェクトに対して、レガシーという古い仕組みを新しい仕組みに変えていく」というメッセージを込め、レガシーシステムの刷新をレガシーマイグレーションではなく、「レガシーリエンジニアリング(LR)」と呼んでいる。

   また当社は「Rebuild」についても、SOA(Service Oriented Architecture:サービス指向アーキテクチャ)の考え方を取り入れ、単に機能だけではなく、セキュリティ・運用・インフラなどを含めた全体を対象とした「システムのトランスフォーメーション(変革)」であると捉えている。

   筆者によく寄せられる質問に、「『Rebuild』『Rewrite』『Rehost』というマイグレーションのパターンは、どのような場合にどういった適用をすべきか」というものがある。当社としては、「対象システム全体のアーキテクチャをどのような段階を踏んで、最終的にはどのような姿に持っていくのか」というロードマップを整理する中で、必要に応じて選択することを推奨している。

   構築事例の多さでいうと、企業にとってのコアコンピタンスな部分は再構築してノンコアでパッケージ化が困難な部分に対しては「Rehost」を適用することが多い。通常「Rewrite」については、「Rehost」を行う上でのバリエーションの1つとしてお客様側の言語スキルにそって選択することになる。

プロジェクトの進め方

   このような適用パターンを決定するために、当社ではレガシーシステム刷新プロジェクトの検討の出発点として、現行システムの診断とこれに基づくToBeモデル(対象の理想的な将来像・目標を表現するモデルであり、理想モデルともいう)の策定フェーズを設定しており、このフェーズを「基本構想フェーズ」と呼んでいる。

   この基本構想フェーズは、「現状評価(アセスメント)」「課題の分析と解決の方向性」「アーキテクチャ・デザイン(最適化計画)」という大きく3段階に分けて進める。

   図1に検討工程例を、図2に検討概要を示す。

検討工程例
図1:検討工程例
(画像をクリックすると別ウィンドウに拡大図を表示します)

検討概要
図2:検討概要
(画像をクリックすると別ウィンドウに拡大図を表示します)

   なお「現状評価(アセスメント)」は、「システムアセスメント」と「ビジネスアセスメント」によって構成される。

   「システムアセスメント」は、本連載の第5回「システム資産の棚卸」で紹介したシステム資産の棚卸作業が中心となるが、単に機械的にシステムの機能や構造を分析・評価するだけでない。現在に至るまでの開発経緯や、ライフサイクルに大きく影響する保守・運用に実態や標準化といった項目もあわせて相互影響を見極めるようにしている。

   「ビジネスアセスメント」は業務プロセスの面からシステム機能を整理し、システムへの新機能要求や改善要求を明確化させるタスクである。ビジネス面からの要求により、マイグレーションのやり方も変わってくるために実施する必要がある。

   「課題の分析と解決の方向性」では「システムアセスメント」と「ビジネスアセスメント」の評価結果を基にして、将来のビジネス環境の変化への追従性/ソリューションパッケージの適用可能性/オープン系システム基盤での高可用性の実現といった要件を考慮しながら、本質的課題を設定して解決策を検討する。

   「アーキテクチャ・デザイン」では、トータルコストを見据えてシステムの構造(アーキテクチャ)をデザインしていくが、システム全体のアーキテクチャ・デザインと、システムを継続的に維持運用し、拡張性を確保するためのエンジニアリングをセットで考えることが重要である。

1   2  3  次のページ


新日鉄ソリューションズ株式会社 荒木 義史
著者プロフィール
新日鉄ソリューションズ株式会社   荒木 義史
入社以来、製鉄所生産管理システムに対して、企画〜設計〜開発〜保守のソフトウェアライフサイクル全般に渡る業務に従事。現在は鉄鋼システムでの知見をもとにレガシーシステムを中心としたコンサルティング業務を担当。

この記事の評価をお聞かせください
ボタンをクリックしますとウインドウが開きます。

INDEX
第6回:再構築後のシステムの価値を持続させる真のレガシーマイグレーション
単に基盤を移すだけではないマイグレーション手法の適用パターン
  アーキテクチャの整理
  TCO削減のために考慮すべきシステムのライフサイクル
IT基盤を刷新する レガシーマイグレーション入門
第1回 そもそも、レガシーマイグレーションとは何か
第2回 ノンストップ稼動メインフレーム資産のマイグレーション 〜 大手鉄鋼会社の事例
第3回 Webシステム化によるサーバ統合で大幅コスト削減を実現
第4回 レガシーマイグレーションの落とし穴
第5回 システム資産の棚卸
第6回 再構築後のシステムの価値を持続させる真のレガシーマイグレーション