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

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

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

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

リスト

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

移行ツールを使ってオープン化に挑戦

　HS情報システムズは実績から当然の結果といえるが、本丸のメインフレーム移行を担当することになったTISは、何か決め手になったのか。

　調達を控えた機構では、複数のベンダーにRFI（Request For Information：情報提供依頼書）という形で調査依頼した。「リライトでもリスクは大きい。リホストすべき」という意見や「オープンCOBOLを使うべき」といった意見もあった中、TISが提示したのが、専用のリライトツールを使って行うというものだった。サンプルプログラムを使って実施して見せるなどフィジビリティを示し、「これならいける」と踏んでリライトを前提とした調達を行い、TISを調達先に選んだ。

　スケジュールは、2016年10月にスタートし、保守期限ぎりぎりの2018年1月にカットオーバーするというもの。本来であれば、もう少し余裕を持ちたいところだったが、規模が大きいだけに「それ以上の前倒しは無理だった」という。

　参考となる前例がなく、複数のプロジェクトを複数で進行させる難易度の高いプロジェクトだったが、「プロジェクトが暗礁に乗り上げるような、大きな問題は最後まで発生しなかった」という。

　その要因として考えられるのが「ベンダー2社の対応が良かったことはもちろんだが、マルチベンダープロジェクトということで、機構側がオーナーシップを取り、工夫を凝らしてベンダーに相対したことが良かった」と林氏は分析している。

　人員はピーク時で1000名以上という大規模プロジェクトとなったが、機構側も増員して15名のプロジェクト専任チームを組織、さらにコンサルタント会社や有識者にも協力を仰いだ。機構の命運を握るプロジェクトということで、経営層の理解を得られた結果だ。

マルチベンダープロジェクトの管理体制

　複数のプロジェクトを同時に走らせるだけに、管理体制が気になるところだ。当然プロジェクトごとにPMは存在するが、マルチベンダーで進めているので、作法の違いから管理の要件がばらばらになってしまう恐れがあった。そこで、まず取り組んだのがプロジェクト共通の管理要件を定めることだった。報告、進捗管理基準、課題のエスカレーションルール（報告規則）などを定義した。使うツールには固執せず、各社に任せた。

　会議は頻繁に行った。担当者が集まって行う進捗管理は毎週行い、Face to Faceで進捗を報告した。さらに月次で各プロジェクトのマネジャークラスが集まって行う進捗状況を確認する会議、機構とベンダーの経営層によるステアリングコミッティは2月に1回開かれた。機構内では、理事長を本部長とする「サーバー化推進本部」を立ち上げ、月次で状況報告するようにした。

　こうして、悪い情報も、現場だけでなく経営層にも早めに認識させるようにしたことで、問題を小さいうちに解決できる仕組みが構築された。

　今回のレガシーマイグレーションプロジェクト、「リライト」を採用したため、作業の多くがCOBOL to Javaの変換作業に費やされた。PoC（Proof of Concept：概念実証）で移行ツールの実現性を担保しながら移管していくという地道な作業の繰り返し。ただし、製品で暗黙的にやってくれるソートなど、基盤に近い部分にはツールで変換できない部分があるので、こちらはスクラッチで開発することで対応した。

　変換作業で苦労した部分といえば「プログラムの仕様をみているだけではわからない、見えない壁が存在すること」だったという。例えば、「ホストの場合、配列の定義で宣言していないイレギュラーな配列でも処理が落ちないなど、柔軟に対応してくれる部分があるが、Javaでは定義通りでないとエラーになってしまう」といったことだ。こういった見えない障害をひとつひとつPoCで確認していった。

　更改前のシステムは、メインフレーム1台に、金融機関向けにHTML画面で処理できるようにしたリッチクライアントのフロントサーバーとなるセンターサーバー、メインフレームでできる機能を一部先行してサーバーに切り出した既存サーバーなどで構成されていた。総合オンラインシステム全体で2000万ステップ、ホストが10数メガステップなので、既存サーバーでも数百万ステップという、相当な規模だった。

図2：レガシーマイグレーションの概要（資料提供：住宅金融支援機構）
拡大画像表示

　更改後はLinuxベースの物理サーバーが62台、VMwareベースの仮想サーバーで110台、データベースはOracle Databaseという陣容。システムの設置場所も新しいデータセンターに移し、そこからサービス利用するというプライベートクラウド型の料金体系にした。基本的には従量課金だが、「毎月動かす基盤は決まっているので、ほぼ固定料金」で賄われている。

　今回のマイグレーションプロジェクト、確実に成功に導くために様々な工夫を凝らしたという。大規模なレガシーマイグレーションを検討している企業には、参考になるはずなので紹介しておく。

【次ページ】プロジェクトを成功に導いた工夫とは