システム構築/プロジェクトマネジメント システム構築/プロジェクトマネジメント記事一覧へ

[ザ・プロジェクト]

金融機関の大規模レガシーマイグレーション、その成功のポイントとは

住宅金融支援機構が挑んだメインフレーム基幹システムのオープン化

2018年6月21日(木)杉田 悟(IT Leaders編集部)

日本は、メインフレームの残存数が世界トップクラスといわれるレガシー大国だ。2000年代初頭の「オープン化」の波で多くの企業が脱レガシーを果たしたが、金融など安定性、安全性を重要視する一部の企業では、未だにメインフレームが企業システムの屋台骨を支えている。それだけに、まだまだ需要が残されているのが「レガシーマイグレーション」。ここに紹介する独立行政法人 住宅金融支援機構は、金融機関としては珍しい、大規模システムのレガシーマイグレーションを実施、2018年1月に無事新システムを稼働させている。模範となる前例がない中、失敗すると多方面に影響を与える基幹システムのオープン化を成功させた同機構の取組は、レガシーマイグレーションを検討している企業の良い模範となるはずだ。

プロジェクトを成功に導いた工夫とは

 まずは、トランザクション単位で試験ケースを作って投入し、結果を出す。その結果を期待値として、次に新システムにも同じテストを行い、結果が一致するかを確かめる新旧比較。リライトツールへの依存度が高いだけに、ツールの品質によっては、計り知れないほどのテストケース数となる。

 そこで、ツールの品質をPoCである程度確保したうえで、結合レベルの試験からトランザクション単位に流して、新旧が一致するかを確認するようにした。不具合は1000個ほど見つかったが、シビアなエラーではなかったという。多くがリビルド系の部分などの不具合で、TISが提供したリライトツールそのものに問題はなかった。機構としては、「リライトツールの品質は良かった」と評価している。

 新旧比較の後には、結合テストと総合テストとなるわけだが、本来であれば総合テストは、職員も参加してテストケースを準備したうえで打鍵テストを行うのだが、これだけの規模ともなるとケースのバリエーションが多すぎてすべてのパターンを網羅すると現場の負担が大きすぎる。そこで次の工夫を考えた。

 移行リハーサルも兼ねて、旧システムのある時期のデータベースを、いったん全部新システムに移管、移管後は生のトランザクションを入れて稼働させた。これを3カ月間行った。3カ月分のトランザクションがあれば、少なくともその間に起こるあらゆるイベントのバリエーションが網羅できるという考え方だ。

 オンライン電文はトータルで335万件、そのうち新旧で結果の不一致があったのがオンライン系で4万件くらい。不一致がすべて不具合というわけではないので、解析して不一致で良いもの、不具合のものを切り分けながら品質を高めていった。

 旧システムのバッチデータもとっておき、49万件のジョブを新システムで処理し直し、その出物を比較するということも行った。また、「機構のシステム部門だけでなく業務部門の職員も協力して、職員の勘所で打鍵テストを行い、品質を高めた」

 試験したのは夏だったが、その年の3月末のデータを旧システムに残しておいた。そのデータを使って通常とは異なる月次処理、年次処理のテストを行ったことも、工夫した点のひとつ。

 そして、最後に待っていたのが並行稼働。林氏は「システムの移管作業よりも、この並行稼働の仕組みを作る方が大変だった」と振り返る。

図3:カットオーバー前後3カ月に行われた正逆の並行稼働(資料提供:住宅金融支援機構)
拡大画像表示

 2017年10月から12月にかけての、カットオーバー3カ月前からの並行稼働(順並行)では、旧システムを正、新システムを副として実施。旧システムが処理したデータを新システムに転送、新システムでは転送されてきたデータをインプットにして、処理結果を出力した。リハーサル5回、うち本当の移行を模したリハーサルは3回行い、品質を徐々に向上させていった。

 2018年1月のカットオーバーからの3カ月間は逆並行の並行稼働。今度は新システムを正、旧システムを副として、新システムの入力データを旧システムに転送、旧システムでは転送データをインプットにして、処理結果を出力した。新システムの障害の早期検知とともに、いざという時の代替手段として旧システムを並行稼働させた。

 3月、新システムの安定稼働が確保されたところで、長年にわたって総合オンラインシステムを支えてきた旧システムは、その役割を終えた。

徹底した安全志向で次なるステージに

 今回、同業種の前例がほとんどなかったこと、万が一システムに障害が起これば機構だけでなく金融機関や消費者にまで影響を与えることを考慮して、知恵を出し合いながら徹底した安全志向で進めた。

 稼働後、初期障害は何度か起こったものの、「通常のシステム開発プラスアルファくらいの障害で済んだ。一番大きかったのが、非機能の問題が起こらなかったこと」だという。

 メインフレームからオープンシステムになると、当然外部からも狙われやすくなるのでセキュリティリスクは高まる。「特にセキュリティ設計には気を使った」というように、データは暗号化してやりとりし、データベースにも暗号化されたものを格納している。入口対策だけでなく、内部漏洩にも備え、アクセスコントロールも利かせている。セキュリティに万全はないので、引き続いての対策が求められることになる。

 このようにして、プロジェクトは成功裏に終わったわけだが、林氏は「総合オンラインシステムの課題のひとつである保守性の向上については、まだ道半ば」と先を見据えているようだ。「今回は、期間に制約があったのでリライトを選択した。本格的なリファクタリングについては今後着手していきたい」。

 住宅ローン政策のインフラともいうべきシステムなので、「今後成長、発展させていくことのできる基盤やアプリケーションにリファクトしていくため、少しずつドメインを分析しながら発展させていくイテレーションのスタイルを取る」と、あくまでも慎重に取り組む姿勢を崩さない。

バックナンバー
ザ・プロジェクト一覧へ
関連キーワード

住宅金融支援機構 / 金融 / メインフレーム / モダナイゼーション / 基幹システム / 不動産 / レガシーマイグレーション

関連記事

トピックス

[Sponsored]

金融機関の大規模レガシーマイグレーション、その成功のポイントとは [ 3/3 ] 日本は、メインフレームの残存数が世界トップクラスといわれるレガシー大国だ。2000年代初頭の「オープン化」の波で多くの企業が脱レガシーを果たしたが、金融など安定性、安全性を重要視する一部の企業では、未だにメインフレームが企業システムの屋台骨を支えている。それだけに、まだまだ需要が残されているのが「レガシーマイグレーション」。ここに紹介する独立行政法人 住宅金融支援機構は、金融機関としては珍しい、大規模システムのレガシーマイグレーションを実施、2018年1月に無事新システムを稼働させている。模範となる前例がない中、失敗すると多方面に影響を与える基幹システムのオープン化を成功させた同機構の取組は、レガシーマイグレーションを検討している企業の良い模範となるはずだ。

PAGE TOP