【連載】銀行業界に見るレガシーモダナイゼーションのアプローチ　～第１回　レガシーモダナイゼーションの形態、その利点・考慮事項・リスクを掘り下げる

銀行業界では、世界的にレガシーモダナイゼーションが急速に進行している。

レガシー、すなわち古くなったIT資産やアプリケーションを、ビジネスモデルの変化やテクノロジーの進化に応じて、より最新の“なにか”に置き換えることを意味する。“なにか”は製品、アーキテクチャ、アプリケーション、コード、プロセス、テクノロジー等、さまざまな粒度の言葉になり得る。

レガシーモダナイゼーションについては、アプリケーションの行き先を中心にしたアプローチが多く語られてきたが、実態はそこまで単純ではなく、既存のシステムが老朽化・複雑化した経緯や、インフラストラクチャ、運用、人材等の最適化も含めた検討が必要である。

本稿では、筆者が担当する銀行業界を例に、世界の銀行がどのようなレガシーモダナイゼーションを実施しているのかを類型化し、その利点・考慮事項・リスクについて掘り下げる。他の業界にもヒントとして活用いただけると思う。

レガシーモダナイゼーションの背景　

世界中の銀行業界は、顧客の需要の変化、社会や経済的な圧力、テクノロジーの進化や他業種による業界の破壊“Disruption”により、多くの課題に直面している。

銀行が成長するためには、変化するダイナミクスに対応し、主要な機能を強化する必要がある。しかし多くの場合、従来の基幹システム（銀行におけるコアバンキング）は、モノリシックなアーキテクチャやテクノロジーの制限により、これらの変化に対応できるようにはなっていない。

たとえば、フィンテックやエコシステムパートナーと提携して新しいサービスを提供しようとしても、老朽化したコアバンキングとは技術的に連携が難しいといったこともよくある。

またコアバンキングシステムは、長年機能を継ぎ足してシステム構造が複雑となり、保守コストが高止まりしているものも少なくない。経済産業省がDXレポートで指摘した「2025年の崖」も近く、技術者の確保やスキル継承も難しくなっている。

銀行業界が今後成長していくためには、主要な機能、すなわちコアバンキングがアジリティや柔軟性を獲得することが重要になっている。新しいサービスの提供、Time to Market（市場投入までの時間）の短縮、保守・開発コストの削減、人材の獲得など、多くの課題をレガシーモダナイゼーションが解決することが期待されている。

レガシーモダナイゼーションの形態

では、世界の銀行はどのようにレガシーモダナイゼーションを進めているのだろうか。

海外を含めた銀行のモダナイゼーションの実態を研究すると、おおむね以下の10の形態に類型化できる。ここでは、銀行がどのような背景・課題・目的をもってそのパターンを選択したかを整理した。

基幹システムに対する状況や課題は複雑に絡み合っているため、これらのパターンを組み合わせて適用したり、ロードマップに従って段階的に適用することもある。

Consolidation ―統合　

・銀行の合併・分割の歴史を経て複数の基幹システムが存在し、機能・アプリケーション・データが冗長化。また、基幹システムに引きずられて業務運用・システム運用もそれぞれ実施されており、運用コストが高止まり。

・機能・アプリケーション・データが重複しないよう再編成を行い、単一の基幹システムに統合。その結果、業務運用・システム運用も統一され、全体的な保守コストの抑制を実現。

Externalization ―外部化

・市場や業務ニーズへの対応・規制対応により、長い年月をかけて基幹システムに機能を追加。コア機能と非コア機能（たとえばCRM、顧客コミュニケーション、値決め、担保査定、現地通貨決済など）が混在。

・本来コア業務とは切り離せる機能について、外部システムとして分離。依存関係／結合度をなくして非コア機能の柔軟性を高めるとともに、基幹システムの過負荷な状態を解消。

Rip & Replace ―置換

・小規模銀行において既存の基幹システムに最小限の機能しかなく、システム資源も限られていて拡張性に限界。基幹システムに新たな機能を追加して、銀行のケーパビリティを拡大することを標榜。

・新機能を実装した新基幹システムを別個に構築し、既存機能は新システムに移行。もともと有していなかった機能の新規追加となるため、低リスクで銀行機能の強化を実現。

Progressive Replacement ―漸進的置換

・既存の基幹システムの老朽化が進み、既存のアプリケーションに関するドキュメントの欠如、知識やスキル不足への対応が課題。既存のアプリケーションを保守するより、実態の業務プロセスに合わせたアプリケーション開発、またはパッケージ導入の方が低リスクと判断。

・業務ドメインごと、または一定のドメイングループの単位で、徐々にアプリケーションを置き換え。前述のRip & Replaceとは異なり、すでに保有している機能の置き換えとなるため変更のリスクがあり、リスクを最小限におさえるために比較的長い期間が必要。

Re-Host ―リホスト　

・既存のアプリケーションに成長性や拡張性が見込めないが、最低限の保守として製品バージョンのサポート終了や規制への対応が必要。または、基幹システム全体のモダナイゼーションを将来の目標としているが、時間的制約によりアプリケーションの見直しを含めた十分な期間が取れないため、まず基盤のみをスコープとして対応。

・アプリケーションは原則変更せずに基盤のみを同製品でバージョンアップすることで、リスクを最小化しつつ期間内に対応。

Re-Platform ―プラットフォーム変更

・前述したRe-Hostと同様の課題に加え、現在使用しているプラットフォームの所有コストの高止まり、テクノロジーや機能の廃止、別のプラットフォームで最新のテクノロジーやサービス（たとえば、仮想化、コンテナ、マネージド・サービスなど）を受けられるメリットを確認。

・アプリケーションは原則変更せずに、実行環境を異なるプラットフォームに変更することで、システム資源の最適化によるコストの抑制とともに、最新テクノロジーによる効率化を享受。

Upgrade ―アップグレード

・基盤保守として製品の販売終了や規制への対応が必要。基幹システム全体のアーキテクチャは大きく変更せず、しかし現行システムで利用されている製品、プログラム言語等の継承にはこだわらずに将来に向けてビジネスニーズに合うものを採択。

・ビジネスニーズや方向性に合わせて、製品を最新化し新機能を獲得したり、人材確保のためにアプリケーションコードを変更（たとえば、COBOLからJavaへ）したりして将来に備え。

Re-Architecture ―リアーキテクチャ

・基幹システムの維持保守が最重要の経営課題となっており、期間とコストをかけて事務やシステム全体のアーキテクチャを抜本的に見直す必要性や、組織としての意思がある。

・基幹業務・基幹システム全体の最適化・最新化を意図し、業務をビジネスプロセスから見直して、基盤からアプリケーションまで広範に再構築。基幹システムのアジリティや柔軟性の課題を解決するとともに、プロジェクト期間を通して新基幹システムに携わる技術者の再教育を実現。

Digital Transformation ―デジタルトランスフォーメーション

・現在の銀行の機能やサービスに加え、いわゆる「デジタルバンク」機能を提供して顧客やパートナー企業との連携を強化し、市場の地位を獲得する狙い。

・チャネルと基幹システムの間にデジタルプラットフォーム層を設けて、基幹システムに手を入れることなく柔軟に対応可能な構成を実現。他業種との連携が容易になることで、銀行業を超えた顧客体験の提供も可能。

API Enablement ―APIの有効化　

・銀行のシステムへの接続仕様を外部の事業者に公開することで、外部の事業者と連携して利便性の高い高度な金融サービスを展開する「APIのオープン化」への対応。

※日本では2017年5月に「銀行法等の一部を改正する法律」 が成立し、オープンAPI体制の整備が必要。

・基幹システム機能を呼び出せるAPIを開発し、APIゲートウェイを介して外部に提供。前述のDigital Transformationを加速する手法の1つでもあり、外部事業者との連携によるビジネ機会を強化。

日本の大規模な銀行では、1990年代～2000年代に銀行の統合が盛んに行われ、複数の基幹システムのConsolidationもしくはRe-Architectureでモダナイゼーションを実現していった。

一方で地方銀行などは、単独ではRe-Platformや、複数銀行が共同体となってUpgradeないしRe-Architectureを進めているところもある。

レガシーモダナイゼーションは一足飛びには実現が難しく、企業や組織は自身のニーズ・目標・要件（To-Be）に対し、現在の基幹システムやこれを運用する事務・ITのスキルや人材の状況（As-Is）を明確にし、どのようなロードマップでアプローチしていくのか、適切な選択をすることが重要になる。

第2回では、適切な選択のヒントとなるよう、主要なパターンの利点や考慮事項、リスクについて掘り下げる。