---

2018年9月に遡るが、当時の経済産業省のデジタルトランスフォーメーションに向けた研究会のレポート[1]において「2025年の崖」というセンセーショナルな言葉とともに、既存システムの改革を進めなければ2025年以降年間最大12兆円の経済損失が生じる恐れがあると警告を発したことにより、日本の産業界で大きな波紋を呼んだことは記憶に新しい。

以降、多くの金融機関では、ITモダナイゼーションの実現に向けたプロジェクトに取り組んできたが、特に保険会社における基幹業務システムは、構築から約40年以上が経過していることが多く、長年にわたり複雑な仕様を実現してきた先人達が工夫と知恵を重ねて作りあげたロジックで、安定したシステム稼働を実現しており、誰も理解していない仕様やロジックが存在していることが多く、これがモダナイゼーションを行う際の品質確保の難所となる。

本書では、保険会社の基幹業務システムのモダナイゼーションを題材として、システム構築時の品質確保のために、特にテスト工程に焦点を当てて成功の要諦を論じたい。

[1]https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.html

モダナイゼーションという大規模刷新

保険会社の基幹システムの多くは、1980年代に導入されたオンラインシステムであり、約40年以上にわたって改修が続けられてきた。その結果、システムは肥大化し、全貌を把握することが困難になっている。さらに、メインフレームの担い手の退職や高齢化、古いプログラミング言語を知る人材の確保が難しい状況が続いており、業務やシステムの品質を維持・改良することが困難となっている。このような問題を解決するために、多くの企業がモダナイゼーションを通じてIT資産を時代に合わせた変換を実施している。

モダナイゼーションは、大規模なシステム刷新を伴うことが多く、開始時に計画した通りに進まないことがある。遅延が発生することもあり、場合によってはプロジェクトが停止することもある。

モダナイゼーションの対応手法

モダナイゼーションの対応手法は大きく4種類に分類され、費用・期間・開発人員・技術力の確保等を踏まえた実現性を考え見て慎重に検討する必要がある。

＜手法＞

1.   リホスト：既存プログラムに極力手を加えず、新しいプラットフォームへ移行する手法

2.   リライト：既存プログラムを、オープン言語を用いてそのまま再記述し機能を再現する手法

3.   ラッピング：業務ニーズに合わせてシステム間のインターフェイスを再構築し、既存アプリケーションをうまく再利用する手法

4.   リビルド：新規システムを構築するために要件定義を実施し、既存システムを全く新しいシステムに再構築する手法

では、モダナイゼーションを成功させるためには、どのようにしていけばよいのか。リホスト手法を用いたモダナイゼーションを例にして考えてみる。

既存プログラムとデータから非互換となる箇所を抽出すること

リホスト手法では、既存プログラムに極力手を加えず、新しいプラットフォームへ移行することになるが、コード体系（EBCDIC⇔ASCII）の非互換に影響するプログラムへの対応を避けては通れない。具体的には、膨大なプログラムの中からEBCDICコードを意識したロジック（図表1）を洗い出すことを意味しており、分析量と分析精度への対策が必要である。

次に、データの観点で見ると、プログラム同様に、コード体系（EBCDIC⇔ASCII）の非互換に影響するデータへの対応が必要となる。具体的には、COPY句に定義された項目属性ごとに変換・無変換を定義し、既存システムに存在する全てのデータを１つ１つコード変換することとなる。いわば、データコンバージョンを行うことであり、プログラム同様に分析量と分析精度への対策が必要である。

加えて、データに関して特質すべきことは、マルチレイアウト・データ(図表2)である。実は、モダナイゼーションにおいて、このデータの移行をしっかり実現することが成功に向けて重要となる。

マルチレイアウト・データのコード変換がモダナイ攻略の鍵

マルチレイアウト・データ(図表2)は、メインフレームのデータレコードの構成として活用されており、目的別に分けられたデータセット内に異なるレイアウトを格納する方式である。例えば、保険契約のマスタデータを例にすると、契約レコード内に保険種目別に異なる項目を持つことが可能となり、保険種目に応じてレイアウトを使い分けることができる。

このマルチレイアウト・データを、前述のコード体系の非互換（EBCDIC⇔ASCII）に対応するために、変換・無変換を定義することになるのだが、既存プログラムからどういうパターンとレイアウトが使われているのかを分析・調査する必要があり、正しく変換するための鍵となる。

テストは”非互換”に着眼して計画すること

通常のシステム開発では、単体テストおよび機能テストを実施し、システムテストとして業務シナリオ・ケースを網羅的に実施することで、システム品質を確保するが、リホスト手法では、既存プログラムに極力手を加えず、新しいプラットフォームへ移行するため、設計間および設計⇔ロジック間の整合や、ロジック単体の正しさを改めて検証することに意味はない。

しかしながら、実際のプロジェクトでは、テストを網羅的に実施しないことによる心理的な不安、従来の品質担保の手法・指標の観点から実施することが目的となってしまい、テストデータを網羅的に準備するためのタスクを含むテスト環境の構築に労力がかかる割に、得られるものが少ないという罠にはまる。

罠にはまらないためにも、リホスト手法におけるテストでは、全ての業務シナリオおよびケースを実施することを前提とするのではなく、”非互換”（通常変換ができないもの）を検証することにフォーカスすることが重要であり、検証として何をどうやって比較するのかを計画時に決めておくことが、テスト工数および必要期間の見積りの精度を上げることに寄与する。

また、モダナイゼーション後のシステム維持および保守運用の手順は、脈々と受け継がれているので、全容の洗い出しには相応の時間を確保することが必要である。

必要なのは”現行システムに関する知識”の確保と準備

大規模なプロジェクトでは、PoCやパイロットを実施することが多いが、どうしても「やりやすい機能で、やれる範囲で」となる。しかし、これでは本質的な意味がなく、表面的な対応に過ぎない。そのため、実際に非互換プログラム・データに焦点を当てたテストを行おうとすると、未知の問題が顕在化し、テストが思うように進まなくなることがある。例えば、テストデータの準備方法、画面操作や処理の実施手順、実行時に発生する問題のトラブルシューティングなど、現行システムで起きる事象に対しての知識が不可欠である。

 

しかし、近年では現行システムの知識を保有する担当者が退職し始めており、特にベンダー管理に特化しているような組織はなおさら待ったなしの状況である。担当者の経験と知識に頼るだけでは成り立たないことを想定しておく必要がある。

ボリュームゾーンはAIやツールを活用で戦うこと

冒頭に書いたとおり、日本の保険会社には100年を超える歴史を持つ企業もあり、ビジネス規模が大きくなればなるほど、基幹業務システムは肥大化の一途を辿っている。そのため、ロジックとデータは天文学的な量になっていることが想定され、設計書や有識者に頼るというのは、もはや現実離れしている。

さらに、前項で述べた有識者の退職に加え、プログラムとデータの分析量と分析精度を確保するためには、早い段階からAIやツールを使って効率的かつ正確に分析をすることが肝要であり、分析した結果に基づいた非互換対応を実施することが必要である。分析の観点には、存在しているが既に使われていない、参照されていない不要な資産を特定し、モダナイゼーションの対象から外すという母数の削減を狙うことを忘れてはいけない。

おわりに

モダナイゼーションは、IT資産の引越しであり、時代に合わせた変化をもたらす一大イベントであることから、開始段階で綿密な計画が必要である。

例えば、データのコード変換を実施するためのセキュアな環境構築、移行計画（基幹システムは長期期間止められない可能性が高いため、移行にかかる期間、移行の方式を含めた段取り）、性能対策（クラウドリフトするケースが多いため、メインフレームと比較するとどうしても性能面の劣化がでてしまうための対策）、プロジェクト期間が長いことによる現行システムからの追い付き対応など、様々な側面からモダナイゼーションをするための計画を作る必要がある。早い段階から有識者の確保、AIやツールの導入により、現行システムの知識・知見はもちろんのこと、新旧のテクノロジーの違い（文字コード）を理解した上で、分析量と分析精度への対策を講じておくことが成功に向けた要諦である。