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

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

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

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

リスト

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

写真1：住宅金融支援機構情報システム部長廣瀬眞司氏

　住宅金融支援機構の新基幹システムがカットオーバーしたのが2018年1月。COBOLベースのホストコンピューターを3年3カ月かけてLinuxベースのオープンシステムにマイグレーションした。「金融機関での主だった事例がなかったため、実施するにあたっては色々と検討を重ねた。情報システム部門の人員体制もこのために増強を図るほどの大型プロジェクトだった」と話すのは、情報システム部長の廣瀬眞司氏。

　住宅金融支援機構は、長期固定金利の住宅ローン「フラット35」でお馴染みの、国土交通省、財務省所管の独立行政法人。2007年に廃止された住宅金融公庫の業務を継承する形で、同年に設立されている。

　今回、その住宅金融支援機構がオープン化を図ったのが「総合オンラインシステム」。住宅ローンの融資から返済管理まで一括して担っている、機構にとっては基幹中の基幹システムだ。

　レガシーマイグレーションの顛末の前に、まず総合オンラインシステムが住宅金融支援機構でどのような役割を担っているシステムなのかを説明しておく。

住宅ローン政策を支える重要インフラ

　住宅ローンには変動金利と固定金利がある。金融機関にとって、短期プライムレートによって動くとされる変動金利はリスクが少なく、貸し付けやすい。一方、固定金利は経済情勢に応じた金利が取れないのでリスクとなる。そうした金融機関のリスクを吸収するのが住宅金融支援機構となる。

　住宅金融公庫では、金融機関を窓口にして直接融資していたが、機構になってからは「住宅ローンの証券化」という形で民間金融機関による長期固定金利の住宅ローンの供給を支援している。金融機関が個人に固定金利の住宅ローンを貸し出すと、これは金融機関の債権となる。この時点で金融機関は金利上昇リスクを負うほか、支払いが滞るリスクも負っている。

　住宅金融支援機構は、この金融機関の債権を買い取る。金融機関は機構へリスクを移転できるので、貸し出しやすくなる。一方機構は、買い取った債権を担保として「証券化」する。証券は市場で投資家に売買されるので、個人が支払った住宅ローンの元金や利息の一部は結果的に投資家に流れることになる。

　この固定金利ローンの融資から返済までの管理を、契約する600もの金融機関と連携して行っているのが総合オンラインシステムとなる。フラット35の場合、返済期間は35年に及ぶが、その期間約200万人におよぶ対象者を管理し続ける。

　総合オンラインシステムは、委託先である約600の金融機関に設置してある端末と接続されており、端末のオペレーションは顧客窓口となる各金融機関が行っている。

　総合オンラインシステム以前は、個人融資、団体融資、債権管理など、様々な手法で必要に応じて構築してきた複数のサブシステムが点在、それらをつないで使っていた。データも分散しており、残高管理や元帳といった顧客データは当時800あった委託先の金融機関で管理していた。機構（当時は住宅金融公庫）は各金融機関から統計、レポートをもらい、その内容を自分たちのシステムに登録するという形で運用していた。

写真2：住宅金融支援機構情報システム部総合オンラインシステムグループグループ長林秀樹氏

　「複数のサブシステムを1台のメインフレームに集約すること、各金融機関に散らばったデータを機構のシステムで一元管理するというのが総合オンラインシステムの始まりだった」（情報システム部総合オンラインシステムグループグループ長林秀樹氏）という。

　2000年に完成した総合オンラインシステムは、2010年の老朽化によるホストtoホストでの基盤更改を経て現役で運用を続けていたが、2018年3月にインフラの保守期限切れが迫っていた。そこで、一度目の基盤更改を終えた2010年過ぎ辺りから、今後どういう方針にするべきか、様々な組織で議論を重ねた。

リホストか、リライトか、リビルドか

　まず考えるべき方針は、再度ホストtoホストの基盤更改を行うのか、あるいはサーバー化するかだ。既存の総合オンラインシステムは、度重なるカスタマイズでプログラムが複雑化、肥大化していたので、ホストを継続するとなるとスクラッチを再度行うしかなかった。そのことが決め手となって、2012年にはホストを捨てサーバー化するという方向性が定まった。

　サーバー化が決まったところで、次に考えなければならなかったのが再構築の手法。一般的にレガシーマイグレーションには「リホスト」「リライト」「リビルド」とういう3つの開発パターンがある。リホストは、現行の業務仕様、アプリケーションは変更せずにインフラのみをサーバー化する方式、リライトは業務仕様はそのままにOSやデータベースなどをオープン形式に書き換える方式、リビルドは業務仕様から見直し再構築する方式。メインフレームに外部システム向けの接続インタフェースを設ける「ラッピング」というマイグレーション方式もあるが、サーバー化が前提のためこちらは対象外。

　「この時点で金融機関での参考になる事例がほとんどなかった」ため、どの方式が良いのか判断に苦慮した。話し合いは2013年まで続いたが、最終的に、2つのポイントが方向性を決めた。

　1つ目が「保守性の向上」。近年は地域創生や子育て支援など、国の政策を推進するために、住宅ローンの金利を引き下げる機会が増えている。大きな自然災害が起きた際には、被災者支援で金利を引き下げる場合もある。そのようなイレギュラーに柔軟に対応できるシステムにしていかないと、「機構の存在意義である、住宅ローンを通じて国民の住生活の向上に貢献することができない」（林氏）ため、「保守性を向上させること」がマイグレーションの絶対条件だった。「リホスト」するということはすなわち、「保守性の向上」を先送りにするということになるという考えから「リホスト」が候補から外された。

　次に「保守期限」の問題。前述の通り、既存システムの保守期限が2018年3月で切れることは決まっていた。約3年3カ月という微妙な残り時間、仮に保守が切れた状態でプロジェクトがとん挫してしまったら、無保守で従来システムを運用することになる。「金融機関として、無保守のハードウェアを一瞬たりとも走らせることは許されない」という強い意思のもと「期間内で確実にサーバー化できる」ことが必要条件となっていた。そこで、「リビルド」より確実性の高い「リライト」が選ばれることになった。

　マイグレーションプロジェクトの事業者選定は入札で行われた。機構は本丸のメインフレーム移行のほか、センターサーバーの更改や既存サーバーの移行、テスト推進、システム基盤の構築、ネットワークの構築、システム運用とプロジェクトを7つに分離分割してマルチベンダーでの調達をかけた。結果、TISとHS情報システムズの2社がそれぞれ複数ずつを落札した。TISは新規、HS情報システムズはメインフレームの保守・運用を行っていた事業者だ。