リライトマイグレーションプロジェクトにおけるアセスメントの必要性

皆さん、こんにちは。
TIS株式会社で「Xenlon～神龍　モダナイゼーションサービス」の営業を担当している藤原と申します。

私はこれまで様々な企業に向け、脱レガシーを目的としたリライトマイグレーション(以下、リライト)の提案を経験してきました。どの企業も、基幹業務を含む重要なシステムの移行検討にあたり、「リライトで上手く行くか。成功するのか。」といったプロジェクト(以下PJ)の実現性に対する懸念を抱かれます。
ほとんどの企業がリライトの経験がない、もしくは進め方を知らないため、これは当然のことです。
その懸念や不安を解消するために、当社では現状分析・実機検証など複数のメニューを用意し、アセスメント実施をお勧めしています。アセスメントを通じて、事実を基にリライトの実現可能性を評価・向上することにより、事前にPJ遂行上のリスク低減が図れるからです。
今回はアセスメントの必要性について、当社サービスのステップを基に例を交えながらご紹介します。

①移行対象資産・範囲の明確化

リライトPJでは「現行資産の移行」が主要な要件となるため、第1ステップとしてはPJ要件を固めるべく、移行対象となる資産・範囲を明確化します。
PJ期間・工数の過剰の要因となる不要な資産は除外し、逆に要件を満たす上で把握されていない不足の資産が無いかを調査することにより、移行対象資産の候補と範囲を具体化します。

注意すべきポイントは、出来るだけ不足の資産、「漏れ」を無くすことです。
必要な資産の見落としは、PJの現状分析(要件定義)工程での移行方式およびテスト方針の再検討、またテスト工程での追加作業・手戻り等、PJの遅延リスクになり得るからです。
「漏れ」の例としては以下のようなものがあります。
1)外部接続の仕組み、アーキテクチャが移行対象から漏れている
2)資料が無く、用途が不明な資産がある
3)必要と想定されていた資産が未使用で、実際に必要な資産は別にある

システムや組織の変遷がある中で長年培われてきた資産には、企業として把握しきれていないものが少なからず存在します。
過去に実際にあったケースは、3点目の例に近く、テスト工程で必要資産(未把握運用資産)が判明したことにより、テスト計画の見直しとともに追加テスト作業が発生しました。

この第1ステップではアセスメントの現状分析メニューを実施します。
当社独自の資産分析ツールと移行経験を通じたノウハウにより、現行プログラムソースや資材を客観的に分析・評価し、「漏れ」を無くします。

②移行課題の分析・対策の検討

第2のステップとして、PJ本工程で致命的となるような技術リスクが発生しない様、移行課題を抽出・分析し、対策を検討します。
PJの開発工程において、想定外の変換課題の判明による追加作業の発生や、アーキテクチャ移行方式の再設計というようなPJ遂行に影響が出るリスクの発生を避けるためです。

リライトPJではプログラム言語およびアーキテクチャの環境差異による移行課題が発生し得るため、事前に出来るだけ課題を抽出し、対策を練っておくことが重要です。
具体的対策例としては以下のようなものがあります。
1)実際のプログラム変換結果とその評価を基にした変換ツールのチューニング要素の具体化
2)環境差異(DBアクセス・文字コードなど)を吸収するための部品開発などリビルド要素の明確化
3)階層型またはネットワーク型DBからリレーショナルDBへの移行方式の検討

このステップではパイロット変換およびアーキテクチャ分析メニューを実施します。
実際のプログラム変換を通じた適合性評価とともに、アーキテクチャも含めた移行課題を抽出・分析し、リライト・リビルド・既存製品活用等、課題毎の対応方針および対策を具体化します。

③対策の検証・実現性の評価

第3のステップではPJの実現性を定量的に評価するために、第2ステップで具体化した対策を検証します。
課題が出た際は更なる対策を検証し、PJの開発工程の作業計画に盛り込みます。
プログラムとしての性能か、あるいはDBアクセス等アーキテクチャ要素によるものか、など課題の原因に応じて、変換ツールのチューニングテーマの整理やアーキテクチャ部品の設計など、PJでの対応を具体化します。

検証例としては以下のようなものがあります。
1)DB更新機能を含むバッチ処理の品質検証
2)夜間など限られた時間内で完了が必要な大量データのバッチ処理の性能検証

このステップではプロトタイプ検証メニューを実施します。
移行先アーキテクチャを適用した環境を準備し、実際に変換したプログラムを用いて特定機能の動作品質や性能を検証し、現行システム実行結果を基準に評価します。
※検証用のデータをご提供頂く必要があります。

企業によっては、懸念となる機能を絞込み、先行でプロトタイプ検証を希望されるケースもあります。
ある企業の例では数十万件のDBデータを検索するバッチ処理の性能検証を実施。
現行よりも十分に短い時間で処理が行えた結果を評価し、リライトを脱レガシーの主軸として検討を進められ、プロジェクト化の判断に至りました。

この例の様に、移行後も特に重要となる機能や品質・性能などの評価項目を軸にサービスメニューの実施ステップを選択することで、企業内での評価・判断に必要な結果が得られやすくなります。

企業の関心や検討内容に合わせて複数メニューを用意しておりますが、アセスメントを実施したからといって必ずしもPJで起こり得る全てのリスクを評価できるわけではありません。ソースの記載に課題があるものの現行の環境ではエラーとならず気づかれなかったもの(現行実装依存)や、テスト工程でのデータ不備によるエラーなど、アセスメント実施時点では発見・予測し得ないものもあります。
ただ、アセスメントを通じてPJ開始後に大きな課題を初めて認識するようなリスクを無くすことで、PJを安心して進めることが可能です。これまでの当社実績で本稼働における重障害は発生しておりません。

おわりに

今回はリライトPJにおけるアセスメントの必要性についてご紹介しました。
COBOLやPL1等のレガシー資産を保有される企業には、当社アセスメントサービスを活用して、将来の脱レガシーに向け余裕をもって計画や体制を準備しておくことを勧めます。
「現行資産の移行」が主要な要件となるリライトPJは、テストデータ準備など現行システムでの作業も必要であり、資産を保有する企業と当社のような移行ベンダーとの共同作業となります。
リスクの低減だけでなく、アセスメントを通じてリライトPJの進め方を事前に理解し、必要な体制等を考慮して計画しておくこともPJのスムーズな進行と成功要因の一つとなると考えます。
今回のコラムが、皆様の脱レガシーに向けた検討の一助になれば幸いです。

「Xenlon～神龍　モダナイゼーションサービス」製品ラインナップ

「Xenlon～神龍　モダナイゼーションサービス」シリーズはTIS独自のリライト手法によるマイグレーションを中心としたモダナイゼーションサービスで企業のDX推進をご支援します。