私は日ごろから、銀行のモバイルアプリを使って入金や支払いをしたり、複雑な請求書を分割したり、必要なときに必要な場所で他のタスクを素早くこなしたりしています。
アプリのスピードと使いやすさは、銀行のすべてのソフトウェアが最新のベストプラクティスにもとづいた最先端技術を活用しているためではないでしょうか。しかし、これが本当だとしたら驚きです。顧客の期待に応えようとする中で、銀行はコアとなる勘定系システムをモダナイズすることなく、新しい機能やアプリケーションを提供しようとしてきました。
代わりに、これらの新しいアプリケーションの多くはパッチが当てられ、基幹システムの保守は難しくなり、変更するのがより複雑になっています。同時に、多くの銀行が多額のテクノロジー負債を抱える一方で、これらのシステムを構築した人材の多くが退職しています。その結果、銀行業界で求められている開発とイノベーションのペースを加速させるためには、脆弱な基幹システムをモダナイズする必要があります。
顧客の期待に応えようとする中で、銀行は中枢となる勘定系システムをモダナイズすることなく、新しい機能やアプリケーションを提供しようとしてきました
銀行業界のリーダーは、現在の勘定系システムが直面している課題を把握しており、モダナイゼーションがもたらすメリットについても理解しています。実際、アメリカの銀行の36%は、今後2年間でコアバンキングシステムの変革をサポートする社内ITシステムのモダナイゼーションを優先しています。*1
さらに彼らは、モダナイゼーションに伴うリスクも認識しています。ボストンコンサルティンググループの調査によると、デジタル変革の70％が目的を達成できず、しばしば深刻な結果を招くことを明らかにしました。*2（ボストンコンサルティンググループが「深刻な」という言葉を使うときは、多くの人が懸念します。）
では、日増しに高まる変革の必要性と、同時に存在する変革そのものが引き起こし得るリスクへの対応という難題にどう対処したら良いのでしょうか？
私が考える変革のカギは、目的に応じたインフラストラクチャーの選定、つまり現在と将来のビジネス目標を満たすように設計された信頼性が高くスケーラブルなインフラストラクチャーを選定することが必要になります。
多くの銀行は、コアとなる全コンポーネントをクラウドネイティブアプリケーションに完全にモダナイズすることを前提にIT環境を構築する必要があります。なぜなら、データセンターの閉鎖時期が迫っていたり、書き換えのためのIT予算が確保できなかったり、あるいは規制当局が短期間での進捗を要求したりと、さまざまな要件が存在するからです。
一方、現在銀行が利用するアプリは、クラウドサービス用に最適化されておらず、拡張性やゼロトラストが考慮されていません。そのため多くのアプリが意図せず動作し、クラウド料金の高騰やセキュリティの脆弱性など、管理における問題が生じています。
つまり、モダナイゼーションに向けたアプローチとしては、勘定系システムのモダナイゼーションを行うために、あらゆる変革のベストプラクティスを理解する必要があります。リーダーの多くは、どのプラットフォームが目的に合っているかを決める前に、変革のレベルを定める必要があります。例えば、再開発が必要なアプリがあれば、クラウドに移行するアプリもあるかもしれません。
そのため、勘定系システムのモダナイゼーションに必要なレベルを理解すれば、どのプラットフォームに構築すべきかの判断がつくようになります。
では、実際のユースケースでさらに説明しましょう。つい最近、私は、分散環境とオンプレミスのメインフレーム環境にコアアプリケーションを置いているお客様を支援しました。彼らはすべてのアプリケーションを最新版にアップデートする必要があることを理解していましたが、さまざまな優先順位を考えると、変革コストをできるだけ抑えなければなりませんでした。
最終的には、クラウドならでは利点であるレジリエンシー、レイテンシー、統合を評価し、クラウドへの移行を決定しました。しかし、すべてのアプリケーションを完全に書き換えることはできなかったため、4つの異なるプラットフォームを構築し、あらゆるモダナイゼーションに対応しました。目的に合わせたプラットフォームの変革レベルと戦略には、次のようなものがありました。
重要なのは、ほとんどの勘定系システムには、すでにコンテナ化されているか、あるいは容易にコンテナ化できる部分が少なくともいくつかあるということです。これは、私が「集中型コンテナプラットフォーム」と呼ぶ第5の目的に合ったプラットフォームを表します。
一例をあげると、別々のアプリケーションサーバーでかなりの並列処理を必要とするJavaワークロードをよく見かけることがあるでしょう。コンテナ化することで、より効率的なリソース利用や優れたスケーリングが可能になる一方で、アプリケーションをクラウドネイティブアカウントに対応させることはできません。私は、このようなアプリケーションの仲介役として、一元化されたコンテナプラットフォームを構築することを推奨しています。
アプリケーションポートフォリオを理解し、ワークロードの種類ごとに目的に合ったプラットフォームを構築することで、セキュアでコスト効率に優れ、パフォーマンスの高い環境で各アプリケーションをサポートすることができます。
必要な変革レベルと具体的なビジネスニーズや優先順位を比較し、どのプラットフォームがモダナイゼーションに適しているかを判断するのが重要です
目的に合ったインフラを選択し基幹システムをモダナイゼーションするにあたって、私たちが伝えたいアドバイスは、アプリケーションのポートフォリオ全体と、目指す変革のレベルについて検討してほしいということです。
なぜなら、必要な変革レベルと具体的なビジネスニーズや優先順位を比較することで、モダナイゼーションに適したプラットフォームを判断できるからです。これにより、パターンが浮かび上がり、構築する必要があるプラットフォームの具体的な数と種類を特定できるようになります。
アプリケーションを変革する際には、以下の4つのヒントを参考に、陥りがちな落とし穴を避けながら確実に変革を加速させましょう。
そのため、変革の必要性と変革自体のリスクに対処する準備ができているのであれば、目的に合ったアプローチを採用することで、モダナイゼーションに伴う多くのリスクを軽減し、信頼性と拡張性の高い変革を推進することができます。
Jonathan Cavell は、Kyndryl Consultでのアプリ、データ＆AIプラクティス担当リーダーです。
1 Driving customer experience through IT modernization, American Banker, 2023年5月
2 Flipping the Odds of Digital Transformation Success, Patrick Forth, Tom Reichert, Romain de Laubier, and Saibal Chakraborty, 2020年10月
