1．デジタルチャネル高度化とシステム刷新の必要性

近年，金融業界ではデジタルチャネルへのシフトや高度化が急速に進み，インターネットバンキングは顧客接点の中核を担うシステムとなっている．利用される端末の多様化やサービス拡充の要求が高まる中で，迅速な機能追加や継続的なUX（User Experience：顧客体験）改善が求められる．また，不正送金などセキュリティリスクに対する社会的関心の高まりを背景に，開発アジリティの確保は金融機関にとって競争優位性を左右する重要な要素となっている．

三菱UFJ銀行が提供する三菱UFJダイレクト（以下，ダイレクト）は2,000万人超の顧客を有し，パソコンやスマートフォンを通じて口座残高・入出金明細の照会，振込をはじめ各種届出およびサービスの申込などを可能とする，まさに「銀行の顔」ともいえるシステムである．

しかしながら，銀行合併を経て長期にわたり機能追加と改修を繰り返す中で，システムはモノリシック構成のまま肥大化し機能間の依存関係が複雑化した．その結果，開発時の影響範囲が拡大し，開発効率および保守性が著しく低下していた．また障害対応や性能改善における柔軟性が損なわれ，安定運用と迅速なサービス提供を両立させることが困難な状況にあった．

これらの構造的課題を解消するため，三菱UFJ銀行ではシステムアーキテクチャを抜本的に見直す「次世代オンラインチャネルバンキングシステム構築」プロジェクトを立ち上げた．本プロジェクトは約3年半にわたって推進され，ピーク時には1,000名を超える体制を構築した．技術的にはフロントエンドをSPA（Single Page Application：単一ページアプリケーション）方式，サーバサイドをJAX-RS（Java API for RESTful Web Service：Java標準のREST API実装仕様）によるREST API構成とし，オンプレミス基盤上で分散構成を実現することで可用性と拡張性の両立を図った．

本稿では，まず現行システムの課題整理と新アーキクチャの設計方針を示す．続いて，開発プロセスにおける主要な検討内容および課題解消への取り組みを述べ，最後に成果の評価と今後の展望を考察する．これらを通じて，大規模金融システム刷新におけるモダナイゼーションの実践的知見を共有することを目的とする．

2．現行システムの課題分析

本章では，刷新対象となった現行ダイレクトの構造的課題を整理する．長期運用と度重なる機能追加の中で開発・保守・運用いずれの観点でも複雑性が増大しており，抜本的なアーキテクチャの再設計が求められる状況にあった．主な課題は，合併前の旧銀行フレームワークの混在，モノリシック構成による柔軟性の欠如，各機能の複雑化・肥大化の3点である．

2.1　旧銀行におけるフレームワーク混在

本システムは三菱UFJ銀行が統合する以前の旧行（旧東京三菱銀行・旧UFJ銀行）がそれぞれ独自に提供していたインターネットバンキングサービスを起源としている．2008年に完遂した銀行合併プロジェクト（Day2プロジェクト）において，両行のシステム統合が実施され，単一のオンラインチャネルとして再構築された．

しかしながら，合併前の旧行では異なるアプリケーションフレームワークを採用していた経緯があり，統合後もこれらの差異を十分に吸収できず，アプリケーション基盤として複数のフレームワークが併存する構成となった．その結果，開発プロセスや設計思想，コーディング構造が統一されず，開発者には複数技術の理解が求められるなど，生産性や品質の維持が困難となっていた．

この課題に対しては，開発体制をフレームワーク単位で分割する対応がとられたが，それによりシステム全体として統一的な設計思想を維持することが難しくなった．また，影響範囲の特定も煩雑化し，改修時には横断的な影響分析に多大な工数を要するだけでなく，調査漏れが発生するリスクも高まっていた．

このような背景から，アプリケーション構造や共通処理方式にも大きな乖離が生じていた．たとえばメモリセッションの保持・参照方式がフレームワークごとに異なるため，フレームワークを跨ぐ画面遷移を行う場合は，専用の「セッション管理テーブル」に情報を退避させる仕組みを追加する必要があった．さらに，共通利用可能な機能であっても，それぞれに同等の機能を実装する「二重開発」が常態化しており，結果として開発効率や保守性を大きく損なう要因となっていた．

2.2　完全モノリシック構成

現行システムは完全なモノリシック構成で構築されており，アプリケーション内部の高い結合度が大きな課題となっていた．業務機能間の依存関係がコードレベルで複雑に絡み合い，特定機能の改修が他機能へ影響を及ぼすリスクが常に存在していた．その結果，機能単位での再利用性はほとんどなく，テスト範囲も広範囲に及ぶため，改修のたびに品質確保・工期・コストのいずれにも大きな負担が生じていた．

併存していた各フレームワークは，いずれもJava EEを基盤とする三層アーキテクチャ（プレゼンテーション層／アプリケーション層／データ層）を採用しており，UIはサーバサイドでJSP（JavaServer Pages）により生成され，画面遷移のたびにサーバとの通信が発生する構造であった．この構成は2007年構築当時の技術水準では標準的であったものの，スマートフォンによるアクセスの増加やUX向上要求の高まりに対しては柔軟性・拡張性の両面で限界を露呈していた．これにより，機能単位での独立開発や段階的リリースといったモダンな開発アプローチを適用することが困難であり，結果として開発アジリティの阻害要因となっていた．

2.3　複雑化・肥大化

本システムは2008年の銀行合併プロジェクト完了後も継続的な開発需要が存在し，例年多数の開発プロジェクトが並行して進行していた．新規サービスの構築やUX改善，制度改定案件など多様な開発が積み重なった結果，アプリケーションの規模は急速に拡大した．合併プロジェクト直後には約1,200キロStep（Step：プログラム開発規模を表す指標）であったソースコードの規模は，2020年の本プロジェクト着手時には約4,200キロStepと3.5倍に肥大化していた．

長期運用の中で追加・改修が繰り返された結果，業務ロジックや画面制御，共通部品が複雑に絡み合い，構造上の一貫性が失われていった．特に既存コードを流用しながら条件分岐を追加する「継ぎ足し開発」が常態化し，影響範囲の特定が困難になるとともに障害発生時の原因究明にも多大な時間を要するようになった．

さらに，運用上は不要となった処理が削除されずに残存するケースも多く見られた．こうしたデッドロジックの蓄積は，コード全体の可読性・保守性を低下させる一因となり，肥大化を加速させた．たとえば，制度対応で追加した特定時刻以降のみ有効となる判定処理が運用後も残存するなど，時限的な実装が恒常的なコードとして残り続ける構造的課題も確認された．

このように，本システムはモノリシック構造の特性と長期的な改修蓄積が複雑に絡み合うことで，保守性・品質・開発効率のいずれにも深刻な影響を及ぼしていた．これらの構造的課題を解消することが，次章で述べるアーキテクチャ刷新の目的である．

2.4　現行システム課題のまとめ

本章では，現行システムが抱える構造的課題について整理した．旧銀行のフレームワーク混在による技術的分断，モノリシック構成に起因する高い結合度，そして長年の改修蓄積による複雑化・肥大化という3つの要素が相互に影響しあい，開発生産性や品質維持，迅速なサービス展開を阻害していた．

これらの課題は通常のシステム改修では解決できず，アプリケーション構造そのものを抜本的に見直すことが不可欠である．機能の独立性を確保し，疎結合化によって柔軟に拡張可能な構造へ転換することが本プロジェクトの最重要テーマとなった．

次章では，この課題を解決するために策定した刷新方針と，新アーキテクチャの設計思想について述べる．

3．新アーキテクチャ設計

第3章では，前章で整理した課題を踏まえ，本プロジェクトの刷新方針とアーキテクチャ設計について述べる．

本プロジェクトでは「独立・分散・標準化」をキーワードとし，業務機能の疎結合化とアプリケーション構造の単純化を推進することで，開発アジリティと保守性の両立を目指した．

フロントエンドにはSPA構成を採用し，サーバサイドはJAX-RSによるREST APIで業務機能を提供する．これにより，画面開発と業務ロジックの独立性を高め，UI層・アプリケーション層を切り離した迅速な開発を可能とした．

また，オンプレミス環境上であっても分散アーキテクチャを実現するため，業務単位にVM（Virtual Machine：仮想マシン）を分割し，障害時の影響範囲を最小化する構成を採用している．

以降の節では，刷新方針の全体像と各層の設計内容，ならびにその開発プロセスについて説明する．

3.1　設計方針の全体像

本プロジェクトの目的は，長期運用により複雑化した現行のダイレクトを柔軟かつ持続的に進化可能な構造へ転換することである．

そのために掲げた基本方針は，「疎結合化による独立性の確保」と「標準化による開発効率の最大化」である．これらを両輪として，開発生産性・品質・可用性の同時向上を目指した．

刷新にあたっては，まず現行システムの密結合構造を解消するため，アプリケーションを業務単位で分割し，明確な機能の境界を定義した．これにより，影響範囲を局所化し，機能単位での独立した開発・リリースを可能とする体制を構築した．また，横断的に利用される処理を共通APIとして整理し，UI層からのアクセスを集約するBFF（Backends for Frontends）を設けることで，画面表示と業務ロジックの分離を実現した．

一方で，完全なマイクロサービス化を志向することは採用しなかった．金融業務に求められる高い信頼性や，オンプレミス環境における運用制約を踏まえると，過度な分散は管理コストを増大させる恐れがあるためである．そこで，本プロジェクトではモノリシックとマイクロサービスの中間的な「ハイブリッド構成」を採用し，業務単位での分割と共通基盤による統制を両立させる設計方針とした．このアプローチにより，疎結合化を進めつつも，全体統制と性能・安定性のバランスを維持している．

このように，本プロジェクトでは「独立・分散・標準化」を軸に，現実的な制約を踏まえたハイブリッド構成によるシステム刷新を推進した．次節では，このアーキテクチャ設計の概要と主要な構成要素について詳述する．

3.2　フロントエンド層の再構築

フロントエンドでは，従来のサーバサイドレンダリング方式（JSPベース）を撤廃し，Angular（Googleが開発したWebアプリケーションフレームワーク）を適用したSPA方式へと移行した．SPA化により，画面遷移時のサーバ通信を削減し，レスポンス性能およびユーザ体験の向上を実現した．また，画面編集や制御といったUIロジックをフロント側で完結させることで，サーバサイドとの責務分解を明確化した点に特徴がある．

画面からのデータ取得はすべてBFF層を介して行う設計とし，UI仕様変更に伴うAPI影響を最小化した．BFF層は画面単位のAPI集約ポイントとして機能し，データ整形や複数APIの呼び出しを担う．これによりUI開発と業務API開発を独立したスプリントで開発することが可能となり，開発効率が大幅に向上した．

一方でUIとBFF間のインターフェース定義が多岐にわたるため，初期段階では仕様調整に一定の工数を要した．特に，チーム間のコミュニケーション不足によりインターフェース不整合が発生し，不具合として顕在化するケースも頻発した．

3.3　API層の二層分割設計

サーバサイドの再構成にあたり，API層をBFF層とBackendAPI層の二層に分割した．BFF層は画面単位で最適化されたAPI群を提供し，ユーザ操作に即した応答データを返す．UI層からのリクエストパラメータチェックや画面に応答するデータの編集などUI特有の処理を集約することで，UI仕様変更に柔軟に対応できる構成とした．

一方，BackendAPI層は業務ドメイン単位で独立した業務API群として構成し，各業務機能を担当するVMに論理分割した．これにより，特定業務の修正やリリース時に他領域への影響を最小化し，障害発生時の切り分けや再展開も容易となった．業務単位でのVM分割は，影響範囲の局所化とスケール制御の柔軟性を両立する効果がある．

さらに，BackendAPI層の内部はAPIサービス層とBusinessLogic層へ分割した．APIサービス層は業務機能単位でBusinessLogic群を統合し，トランザクション制御やAPIのインターフェースに対する処理を担う．一方でBusinessLogic層はDBリソースへのアクセスや業務チェックなどの単一責務処理を集約し，再利用可能な最小単位の業務ロジックとして共通化を図った．この設計により，業務処理の粒度を適切に保ちながら，ロジックの重複実装を防ぎ，テスト容易性と保守性を大幅に向上させている．

BFF，BackendAPIはJAX-RSを用いてRESTfulなインターフェースを実装した．トランザクション管理，例外ハンドリング，ログ出力などの共通処理はフレームワーク層で一元化し，個別業務での重複実装を排除した．これにより保守コストを削減するとともに，全体として一貫した品質を確保できるようになった．さらに，APIレスポンス形式やエラーハンドリングを統一し，他システム連携時の再利用性も向上している．

3.4　システム基盤構成と可用性設計

ダイレクトシステムは銀行システムの中でも可用性・性能といった非機能要件の水準がきわめて高く，セキュリティや耐障害性を考慮し，オンプレミス環境上に構築する方針とした．その上で，高可用性と性能を両立させるため，BFFサーバ10台，BackendAPIサーバ16台による分散構成を採用した．各サーバ群はロードバランサ（負荷分散装置）配下に配置し，いずれかのサーバ障害時でもピークトラフィックを処理可能なリソースを確保している．

フェイルオーバー（障害発生時の自動切替）機能により，障害時には即座にノード切替が行われ，無停止運用を実現可能とした．また，各APIをステートレスに設計することで，アプリケーションのセッション管理をBFF層に集約するとともに，セッション管理方式を従来のメモリセッションからDBセッション方式へと移行した．これにより，トランザクション単位で任意のサーバで処理を実行できるようになり，可用性と柔軟性を両立する構成となった．

この結果，計画停止時間を最小限に抑制しつつ，障害時においても高い可用性を維持できる基盤を確立した．オンプレミス環境における高可用性・分散構成は，今後のクラウド移行やハイブリッド構成を検討する上でも重要な技術的基盤となる．

3.5　開発効率化とアジリティ向上施策

アーキテクチャ刷新にあわせて，開発プロセスの効率化およびアジリティ向上にも取り組んだ．CI/CD（Continuous Integration / Continuous Delivery）パイプラインを導入し，ソースコードのビルド・静的解析，単体テスト，デプロイといった一連の工程を自動化した．これにより，従来は手動で実施していた検証・配置工程を短縮し，変更内容を迅速に反映できる開発サイクルを実現した．

現時点で自動化対象は限定的であり，結合テストや本番環境デプロイは依然として手動工程を残しているものの，開発リードタイムの短縮や変更リスクの低減といった効果を確認している．今後はコンテナ技術の導入など，さらなる自動化と品質担保の両立を図ることが課題となる．

4．開発プロセスと課題対応

本章では，アーキテクチャ刷新を実現する過程で直面した開発上の課題と，それに対する対応・教訓について述べる．本プロジェクトは約3年半に及ぶ大規模開発であり，ピーク時には1,000名を超える体制で進行した．アーキテクチャの刷新だけではなく，開発プロセスの変革も求められたことが特徴である．

4.1　開発体制とプロセス設計

プロジェクト初期段階では，アーキテクチャ方針の策定を優先し，策定以降は業務ドメイン単位に開発チームを編成して段階的な実装・結合を進めた．UI層とサーバサイドを明確に分離した開発ラインを設け，フロントとサーバサイド双方の専門性を最大限に活かす体制とした．

一方で，大規模な開発チームが並行して開発を進めるためには，多くの処理方式検討を先行して確定せざるを得ず，初期フェーズに負荷が集中しボトルネックとなっていた．そこでアーキテクチャ横断的な判断を担う「アーキテクチャチーム」を組成し，代表機能を題材に疎結合化方式やAPI設計指針を先行確定した．これらを「開発ガイドライン」として標準化し各業務チームが準拠可能な共通基盤を整備することで大規模体制下でも整合性と開発効率を両立できる体制を実現した．

ただし，体制プロセス面での整備が進んだ一方で，既存システムの複雑性や設計上の制約が依然として開発を阻害する要因となっていた．次節ではその分析段階で顕在化した課題について述べる．

4.2　現行システム分析の課題

ダイレクトは約20年にわたり段階的な改修を繰り返してきた結果，同一機能が複数個所に重複実装され，モジュール境界も不明瞭な状態であった．機能単位の責務分離がされておらず，業務ロジックや画面制御，データアクセスが密結合したコード構造となっていたため，現行資産の解析には想定を大きく上回る労力を要した．仕様書も長年の改修により記載レベルが定まっておらず，形式上は存在していても実装と乖離したものが多く見られ，「現行仕様の正確な挙動は当時の担当者しか把握していない」領域が存在していた．

さらに旧行由来のフレームワークが併存していたことにより，同一の業務処理であっても呼び出し構造や例外処理方式などの根幹となる部分が異なり，単一の分析手法では全体を網羅できなかった．分析のためのツール化も困難で，結果として各業務チームが手作業によるコードトレースを行う必要が生じた．

このような状況の中，機能をAPI単位に分解し新アーキテクチャ上の配置を定義する「API粒度設計」を進めたが，現行コードの整理と分析の非効率性が大きなボトルネックとなった．本工程は想定をはるかに超える期間を要した．また，難易度が高く基準の浸透も進まず，手戻りが発生したことで，プロジェクト全体の進行にも影響を及ぼした．結果として，当初計画していたリリース時期を3カ月延期せざるを得なかった．

4.3　API共通化の難航と組織的課題

本プロジェクトでは，刷新方針の中核テーマの1つとして「API共通化による再利用性の向上」を掲げた．現行システムでは，同一の処理が各業務単位で重複実装されており，再利用性の低下や仕様の不整合が課題となっていたためである．特に，複数の業務で共通して利用される基盤的なAPI群を整備することで，品質向上と保守性効率化を図る狙いがあった．

しかし実際には，SQLレベルでの微妙な差異や，既存処理の依存関係が複雑に絡み合っており，表面上「同一」に見える機能も統合が困難であった．さらに，プロジェクト全体では15を超える業務サブチームが並行して開発を進めていたため，設計思想や方針の統一が難しく，共通化方針を徹底できなかった．共通化推進のための横断チームを設けたものの，判断権限やスキルのばらつき，各チームの開発スケジュール圧迫などから十分な統制が発揮できず，結果的に中途半端なレベルでの共通化にとどまった．

その結果，本来はシステム全体で再利用されるべきベース機能が，チームごとに類似実装として点在し，後続開発の混乱を招く結果となった．共通化を進めること自体が目的化し，「共通化」の観点が不明確でチームごとの認識齟齬がうまれた．

本経験を通じて，共通化は「技術ルールの制定」だけで達成できるものではなく，分析・設計・レビューを主導できる権限とスキルを持つ中核チームの存在が不可欠であることを痛感した．また，共通化はあくまで目的ではなく，秩序ある分離の結果として位置づけるべきであり，今後はドメイン単位での最適化と，横断的な非機能領域に限定した選択的共通化を方針とする教訓を得た．

4.4　品質課題と構造的要因

品質面においても，プロジェクト終盤まで課題が残り続けた．大規模な結合テストを経たものの，リリース後には想定を上回る不具合が発生し，稼働初期には短期間で複数回の改修リリースを余儀なくされた．これらのトラブルの要因は単なるテスト不足ではなく，現行システムが抱えていた構造的複雑性の表出であったと捉えている．

長年の拡張により業務ロジックが多層的に依存し，機能間の責任分解が曖昧なまま新アーキテクチャへ移行した領域では仕様の整合崩れや暗黙的依存の顕在化が相次いだ．また銀行システム特有の複雑性として，顧客属性や商品性の多様性，さらにはすでに廃止済でテスト環境では再現ができないデータが本番には残存していることなど，業務構造と歴史的データの複雑さが絡み合った不具合も多く発生した．

結合テストは約14カ月にわたり，18万件超のテストケースを計画し実行したが，それでも品質課題は残った．結合工程では累計15,000件を超える不具合を摘出し，修正とその影響確認の繰り返しにより，テスト進捗にも遅延が生じた．結果としてはリリース直前まで品質強化対応を継続することとなり，品質確保の難易度がシステム規模と複雑性の指数関数的な増大に比例することを改めて実感する結果となった．

その後，品質分析から改善策を検討し順次実施した結果，稼働後1年半を経た現在では障害件数が当初比95％以上減少し，安定稼働フェーズへと移行している．

しかし根本的な原因は，業務構造そのものの複雑性に起因していると痛感している．本経験から，品質向上はテストやアーキテクチャ設計の工夫だけでは達成できず，業務設計・組織構造・開発プロセスを一体として最適化する視点が不可欠であると教訓を得た．

4.5　教訓と今後の改善方針

本プロジェクトを通じて得られた最大の教訓は，システム刷新における成功の鍵が「技術」そのものではなく，「組織とプロセス」にあるという点である．

当初はモノリシックな構造を疎結合化し，技術的な合理化を図ることが主眼であった．しかし実際の推進過程では，現行分析の難しさ，API共通化の停滞，品質課題の長期化など，いずれも技術設計だけでは解決できない構造的・組織的課題に直面した．これらの経験を通じて，技術刷新を支える基盤として，組織横断での意思決定や，品質はテスト工程に依存するものではなく，設計段階からプロセス全体を通じて向上させる仕組みの定着が不可欠であると再認識した．

今後の改善方針としては第一にアーキテクチャ標準化と設計ガイドラインを形式知として継続的に保守し，属人性を排除する体制を強化すること．第二に，品質をテストフェーズではなく，開発工程全体で向上を図るアプローチを定着させること．第三に，プロジェクト完了後も技術負債を可視化し，段階的に解消していく継続改善の仕組みを確立させることである．

5．プロジェクトの評価・今後の展望

本プロジェクトで得た成果と課題の評価を行い，今後の展望を述べる．

5.1　成果の概要

本プロジェクトにおける成果は，システム構造の可視化と責務分離の明確化により，特にフロントエンドの開発自由度が大幅に向上した．UI/UX改善案件では従来困難であったアジャイル開発の導入が進み，短期間での機能改善のサイクルが実現している．これにより，ユーザ体験を重視する領域において変化の強く俊敏に対応できる開発基盤を確立することができた．

5.2　現時点での評価と課題

疎結合化アーキテクチャの実現により，各業務サービス間の依存度が低下した．これにより，修正時の影響調査プロセスが効率化され調査の迅速化に加えて，影響範囲そのものの縮小による無影響確認の省力化が実現できた．

また現行システムで長年の課題であった肥大化についても，疎結合化と並行して業務シンプル化による不要機能の削除やデッドロジックの一掃を行った．その結果，システム全体の開発規模を当初比60％まで削減することができた．

一方で，開発アジリティやコスト効率の観点では，依然として課題が残る．API分割と疎結合化によって構造上の柔軟性は確保されたものの，ドキュメントの肥大化や共通仕様管理に要するコストが増大し，結果的に開発スピードは当初想定ほど向上していない．BackendAPIの共通化が不完全であることや，疎結合化に伴う開発ルールの複雑さも，効率的な開発を阻む要因となっている．

これらを踏まえると，本プロジェクトの成果は「刷新の完了」ではなく，「変革のための基盤づくり」と位置づけられる．技術的な独立性を実現した今こそ，その構造を最大限に活用できる開発組織・運用プロセスへの転換が求められる．

5.3　アジャイル開発によるUX改善の実現

前節で述べたように，技術的な刷新を通じて，構造的な独立性と柔軟性を備えた開発基盤を確立した．これを活かし，リリース後は「開発プロセスの変革」に向けた取り組みとして，アジャイル開発の導入を開始した．

従来のウォーターフォール型開発では，要件定義からリリースまでに長期間を要し，UI/UXの改善サイクルが制約となっていた．これに対し，UI層を独立して開発できるようになったことで，ビジネスチームと開発チームが一体となったアジャイルチームの発足が可能となった．

アジャイルチームでは，短期の開発サイクルを繰り返しながら，UX向上を目的とした機能改善を継続的実施している．初期段階では限定的な領域での運用にとどまったものの，改善効果が定量的にも確認され，ユーザ体験の向上と開発スピードの両立を実現した．アジャイルチームは発足当初から拡大を続け，小さな成功体験の積み重ねが開発文化そのものの変革へとつながりつつある．

5.4　今後の展望

現在，本システム単体の改善にとどまらず，銀行全体のリファレンスアーキテクチャ策定の検討に着手している．これまで各システムが個別最適で構築されてきた結果，重複機能や責務の曖昧な領域が存在していた．今回刷新したAPI層・BFF層で得られた知見をもとに，業務ドメインごとの明確な役割・責務を再定義し，システム横断での機能配置適正化を図る計画である．この取り組みは単一プロジェクトを超えた「構造的な全体最適化」へと発展させるものである．

さらに，新規構築される一部サービスでは，コンテナ技術を活用した共通APIアーキテクチャの導入を検討している．これによりデプロイの俊敏性やスケーラビリティを確保しつつ，オンプレミス環境におけるリリース制約や構成変更の手間を軽減することが期待される．すべての機能が独立したマイクロサービスとして実装するのではなく，業務特性に応じて粒度を調整するハイブリッド型アーキテクチャを志向している．これにより，変化の激しい領域では俊敏性を，安定性を重視する領域では堅牢性を維持しながら全体としての整合性と保守性を両立させることが可能となる．

今後はリファレンスアーキテクチャとコンテナ基盤を両輪として，機能配置の是正とアーキテクチャの再利用性を同時に高めていく方針である．本刷新プロジェクトの意義は，単なる技術移行にとどまらず，銀行システム全体の構造的課題を可視化し，次なる進化への道筋を示したことにある．アーキテクチャ刷新は終着点ではなく，より柔軟で俊敏なシステム運営を実現するための出発点である．ここで得られた知見を礎に，今後も業務・技術が一体となった継続的なモダナイゼーションに取り組んでいく．

6．結論

本稿では，三菱UFJダイレクトのアーキクチャ刷新プロジェクトの取り組みとその成果を報告した．本プロジェクトでは銀行合併を経て長期運用される巨大化・複雑化したモノリシック構造を，疎結合化・階層化することで開発影響の局所化と開発アジリティの向上を目指したものである．

結果として，UIと業務処理層を明確に分離した疎結合アーキテクチャを実現し，システム構造の透明性と可用性を大幅に向上させた．特にBFF層の導入によるフロント開発の独立性向上や業務ドメイン単位での仮想マシン分割による影響範囲の局所化は設計上の大きな成果であった．

一方で，API共通化の難航や品質課題など課題も明確になった．これらは単なる技術的問題にとどまらず，組織構造，意思決定プロセス，人材スキルなど，大規模開発特有の「構造的複雑性」に起因するものであり，アーキテクチャ刷新の本質的な難しさを示唆している．

本プロジェクトを通じて得られた最大の成果はこうした課題を顕在化させ，次なる変革への基盤を築けた点にある．特に品質分析の過程では，単なるリファクタリングでは，解決し得ない業務構造・責務分担の再設計の必要性を明らかにし，銀行全体を俯瞰したリファレンスアーキテクチャ策定へと発展している．また技術的側面としてはコンテナ基盤上での業務APIの最適配置やハイブリッド型マイクロサービス化の検討も進めており，柔軟で再利用性の高い基盤構築を目指している．

本プロジェクトは終着点ではなく，さらなる変革への起点である．本稿で示した経験と知見が，同様の課題に直面する大規模システム刷新プロジェクトにおいて，現実的な指針の一助となることを期待する．