週末の深夜作業はもう限界 証券取引所がクラウド移行で実践する「EBA」とは：技術的負債と組織の壁をどう超えるか
レガシーシステムの維持に追われ、技術的負債と組織の壁という二重苦に直面したLSEG（ロンドン証券取引所グループ）。クラウド移行の停滞を打破した「EBA」とはどのような手法なのか。
企業のクラウド移行において、つまずきの原因になるのは技術的な問題ばかりではない。組織の文化や体制といった、非技術的な要因によるところが大きい。IT部門はレガシーシステムの維持管理に追われ、週末の夜間にダウンタイムを伴うデプロイ作業を強いられている。部門間のサイロ化や優先順位の競合によって、新たな取り組みが頓挫することも珍しくない。
こうした課題を抱えていたのが、世界的な金融市場インフラおよびデータプロバイダーであるLondon Stock Exchange Group（LSEG：ロンドン証券取引所グループ）だ。同社は2025年時点で世界65カ国以上で事業を展開し、2万6000人以上の従業員を擁するグローバル企業だ。事業の継続性やスケーラビリティ、革新を生み出すインフラ構築のため、2020年からクラウド移行とそれを支えるための組織変革（クラウドジャーニー）を開始した。
しかし、その道のりは簡単ではなかった。アプリケーションの依存関係や複雑なデータ移行といった技術的負債に加え、部門ごとに異なる働き方をするサイロ化された組織構造が立ちはだかたる。
この状況を打破するため、同社は「EBA」（Experience-Based Acceleration）と呼ばれる手法を取り入れた。結果として、11回のEBAセッションを通じて26のプロセス改善を実現し、プロジェクトを停滞させていた50以上の重大なブロッカーを取り除くことに成功している。既存の枠組みを越えて成果を上げるEBAとは、具体的にどのようなものなのか。
アジャイルな課題解決手法「EBA」とは
本稿は、米国で開催されたAmazon Web Services（AWS）社のイベント「AWS re:Invent 2025」におけるセッション「LSEG's migration & modernization journey: blueprint for cloud success (MAM206)」の内容を基に、LSEGが実践したEBAの仕組みと、具体的なプロジェクトの軌跡を紹介する。
EBAとは、AWSが提供している、実践を通じて組織の変革を促すプログラムだ。開発、セキュリティ、運用など、システムに関わる全てのステークホルダーを同じ部屋に集め、2、3日間にわたって日常業務から離れ、特定のクラウドプロジェクトに専念する。これによって、通常であれば数週間から数カ月かかる承認プロセスを短縮し、意思決定の遅れを大幅に改善する。
LSEGは、この仕組みを利用して、自社の基幹システム群を次々とクラウドサービスに移行させた。その具体的なステップを示す3つの事例を紹介する。
事例1．レガシーアプリケーションの迅速なコンテナ化
LSEGが初めてEBAを適用したのは、外国為替取引のリスクを管理するアプリケーション「Consent Controller」の移行だった。当初、同社はこのシステムをオンプレミスシステムからそのままクラウドサービスに移行する「リフト＆シフト」の計画を立てていた。
3日間のセッションがスタートし、必要なメンバーがそろっていたため、リフト＆シフト自体は初日だけで完了した。そこでチームは、少し手が届きにくい「ストレッチゴール」を設定し、余った時間を活用してシステムのコンテナ化に着手した。
結果として、コンテナ化されたアプリケーションの配置やコンテナオーケストレーションツール「Kubernetes」を活用したコンテナシステムへのデプロイに加え、リレーショナルデータベース管理システム（RDBMS）「Oracle Database」から、オープンソースの「PostgreSQL」への移行、仮想マシンサービス「Amazon Elastic Compute Cloud」（Amazon EC2）でのテスト自動化までを期間内に達成した。この経験によって、単なる移行作業にとどまらず、新しい運用パターンの確立とチームのスキル向上という価値を生み出し、その後のプロセス改善へとつながっている。
事例2．障害注入テストによる可用性の証明
より難易度が高かったのは、クリアリングハウス（清算機関）部門の基幹を成す「担保管理システム」（CMS）の移行だ。このシステムはイングランド銀行を含む世界中の40以上の規制当局から監視される重要なインフラであり、目標復旧時間（RTO）2時間以内、データ損失を示す目標復旧時点（RPO）ゼロという厳しい要件が課されていた。
この要件を満たすため、LSEGはオンプレミスシステムとAWSの間を専用線で接続するネットワークサービス「AWS Direct Connect」による接続や、マルチリージョンでのシステム構成を採用した。しかし、そのシステムが本当に目標を満たせるかどうかを規制当局に対して証明する必要があった。
そこでLSEGは、EBAと、システムに意図的な障害を起こして堅牢（けんろう）性を高める手法「カオスエンジニアリング」を組み合わせるというアプローチを採用した。非本番環境にステークホルダーを集め、疑似的に障害を注入して耐性をテストするサービス「AWS Fault Injection Simulator」を用いて、実験を3日間で10回以上実施したのだ。Amazon EC2インスタンスの再起動やデータベースのフェイルオーバー（予備システムへの自動切り替え）、ネットワークの遅延や重大な帯域劣化など、さまざまな障害に対するシステムの復旧能力を確認し、要件を満たす証拠を収集した。
事例3．可観測性の刷新
3つ目の事例は、既存システムの運用監視システムの刷新だ。このプロジェクトの目的は、単に監視ツールを導入することではなく、AWS内のアプリケーションやインフラの運用状態を監視するシステム「Amazon CloudWatch」を活用して運用状態をリアルタイムで可視化する設定を構築することだった。
このセッションでは、これまで連携したことがなかった2つのアプリケーションチームが参加した。初日は部屋の反対側に座っていた両チームだったが、プロジェクトを進める中で、互いに分担して作業を進める必要性に気づいた。一方はリアルユーザーモニタリング（RUM）を、もう一方はエンドユーザーの操作をシミュレーションして稼働状態を監視する「CloudWatch Synthetics」による外形監視を担当し、それぞれが学んだ自動アラート設定などの技術を教え合うことで、設定した全ての目標を達成した。
EBAの特徴的な要素の一つに、「遊び心」の導入がある。ステークホルダーが集まる部屋に「スターウォーズ」や「夏休み」などのテーマを設け、参加者が仮装をして作業に取り組むこともあるという。一見すると開発業務には無関係に思えるが、こうした工夫が部門間の壁を低くし、初対面のメンバー同士が素早く連携して課題に立ち向かう土壌を作っている。
実践を通じたスキルの内製化と将来への展望
LSEGはこうした成功体験を重ね、自社内にEBAを推進する専門組織（Center of Excellence）を立ち上げた。クラウド移行で重要なのは、座学で知識を詰め込むことではなく、プロジェクトの実践を通じてスキルを習得し、それを組織内に広げていくことだ。
これらの活動を根底から支えているのは、経営層の強力な後押しだ。LSEGのマーケットおよびリスクインテリジェンス部門のCIO（最高情報責任者）は、セッションの最終デモに必ず参加し、直接フィードバックを提供することでチームを鼓舞している。失敗を許容し、新しい挑戦を促す文化を経営トップが自ら醸成することが、組織全体のデジタル変革を自律的に加速させる最大の原動力になる。
本稿は、AWS社が2025年12月10日に公開した動画「AWS re:Invent 2025 - LSEG's migration & modernization journey: blueprint for cloud success (MAM206)」を基に作成しました。
Copyright © ITmedia, Inc. All Rights Reserved.
本記事は制作段階でChatGPT等の生成系AIサービスを利用していますが、文責は編集部に帰属します。