Skip to content
Published on

コアバンキング現代化戦略 — メインフレームからクラウドネイティブまで

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

はじめに

「コアバンキングを入れ替える」という言葉は、銀行ITで最も重い一文です。患者がマラソンを走っている最中に心臓移植手術を行うことに例えられます。それでも世界中の銀行がこの手術台に上がる理由は明確です。レガシーコアを維持するコストとリスクが、入れ替えるコストとリスクを上回る時点が来るからです。

本記事では、コアバンキング現代化の動因とアプローチを比較し、コア分解戦略、クラウドネイティブコアの潮流、韓国特有の規制環境、データ移行とカットオーバーのリスク管理、組織転換、そして繰り返される失敗パターンまでを整理します。特定ベンダーやソリューションの推奨ではなく、投資・法律上の助言でもありません。規制関連の内容は時期により変わるため、必ず最新の原文をご確認ください。

レガシーコアバンキングの現実

COBOLとメインフレームという遺産

世界の大手銀行のかなりの数が、いまだにメインフレーム上のCOBOLコアを運用しています。1970から80年代に構築されたシステムが増築を重ね、数千万行のコードベースになっているケースが珍しくありません。これらのシステムは「古いが壊れない」という逆説的な存在です。数十年の運用で実証された安定性とトランザクション処理能力は本物ですが、次のような構造的負担が蓄積していきます。

  • 人材の崖: COBOLと当該機関固有のフレームワークを知る人材が引退し、新規流入はほぼありません。「コードはあるのに理由を知る人がいない」化石化が進みます。
  • 変更コスト: 単純な商品条件の追加でも影響分析に数週間かかり、リリースは四半期単位に束ねられます。
  • 統合の壁: リアルタイムAPI、イベントストリーミングといった現代的な統合方式とのインピーダンスが大きく、ミドルウェア層が幾重にも積み上がります。

レガシーコアの典型的な構造

現代化の対象を正確に知るために、典型的なレガシーコアの姿を描いてみます。

 +--------------------------------------------------------------+
 |              モノリシックコア (メインフレーム/Unix)               |
 |                                                              |
 |  [オンライン領域]                    [バッチ領域]                |
 |   TPモニタ(トランザクション制御)        JCL/スケジューラ基盤        |
 |   預金/融資/外為トランザクションモジュール  日次/月次締めジョブ数千本   |
 |   (商品ロジック + 元帳更新 + 仕訳が     (利息、決算、レポート、      |
 |    1つのプログラムに混在)              照合、抽出が混在)           |
 |                                                              |
 |  [共有データ]                                                  |
 |   階層型/関係型DB + VSAM系ファイル + コードテーブル数千個           |
 |   モジュール間通信: 共有メモリ、ファイルIF、ポイントツーポイント電文    |
 +--------------------------------------------------------------+

この構造の問題は性能ではありません(性能はおおむね優秀です)。問題は結合度です。商品ロジック、計算、元帳記録、会計が一塊なのでどれか1つだけを変えることができず、数千本のバッチジョブがファイルインターフェースで絡み合っているため、影響範囲の分析自体が考古学になります。

韓国の次世代プロジェクトの歴史

韓国の銀行業界は独特な道を歩んできました。2000年代初中盤から「次世代」という名前で、メインフレームをUnix基盤(その後Linux・x86)へ転換するビッグバン型再構築を繰り返してきたのです。第1世代の次世代(2000年代)、第2世代(2010年代)、そして一部銀行の第3世代プロジェクトまで、通常3から5年の期間と数千億ウォン規模の予算が投入される超大型プロジェクトでした。その結果、韓国の都市銀行のコアはグローバル平均に比べて脱メインフレームがかなり進んでいる方ですが、「数年周期のビッグバン再構築」というモデル自体への疲労感(コスト、組織の消耗、ビッグバンカットオーバーのリスク)に対する問題意識も同時に積み上がりました。近年の話題がビッグバンではなく漸進的現代化とクラウド活用へ移った背景です。

現代化の動因 — なぜ今なのか

動因具体的内容
コスト構造メインフレームのライセンス・保守コスト、変更単価の継続的上昇
人材リスクレガシー技術人材の引退、採用市場での不人気
俊敏性商品リリースサイクル短縮の要求(月単位から週・日単位へ)
競争圧力ネット専業銀行の登場 — 低いITコストと速い実験速度
チャネル変化モバイルファースト、オープンバンキング、組込型金融によるトラフィックパターンの変化
規制変化クラウド利用規制の段階的緩和、ネットワーク分離規制の合理化の流れ
データ活用リアルタイムデータに基づく個人化・リスク管理の要求

特に韓国ではネット専業銀行の衝撃が大きいものでした。最初からLinux・オープンソース基盤で構築された新興銀行が、既存銀行よりはるかに少ない人員とコストでコアを運用し、素早く商品を実験する姿は、「コアバンキングは本来重くて遅いもの」という通念を揺さぶりました。

動因を整理する際の注意点が1つあります。「古いから替える」は動因になり得ないということです。経営陣を説得し数年にわたる投資を正当化するには、各動因を測定可能な目標(商品リリースのリードタイムをN日短縮、運用コストをNパーセント削減、特定人材リスクの解消期限)へ翻訳する必要があり、その目標が以降のすべての段階における優先順位判断の基準になります。

アプローチ比較 — 4つの道

コア現代化のアプローチは大きく4系統に整理できます。

アプローチ概要長所短所/リスク適する場合
ビッグバン型次世代全面再構築後に一括切替一貫したアーキテクチャ、移行後の運用が単純カットオーバーリスク最大、数年間の価値凍結、予算超過が常連レガシーが限界で、組織が大型PJT経験を保有
漸進的ストラングラー機能単位で新システムがレガシーを侵食リスク分散、早期の価値提供、学習の反映新旧共存期間の複雑さ、長期化リスクドメイン境界が分離可能で長期ロードマップを維持できる
ハロー・ザ・コアコアを薄い元帳に縮小し、周辺機能を外へ抽出コア変更最小化でリスクを統制コア自体の延命にとどまる可能性コアが安定しており周辺の俊敏性が急務の場合
新規バンク並行(グリーンフィールド)別の新規バンク/ブランドを新コアで構築し顧客を移転レガシー制約のない設計、迅速な検証二重運用コスト、既存顧客移転の難題新事業・新セグメント攻略と並行する場合

実際のプロジェクトはこれらの混合です。たとえば「新規預金商品は新コアでリリース(グリーンフィールド) + 既存商品は満期到来分から新コアへ移管(ストラングラー) + レガシーは元帳機能だけ残して凍結(ハロー)」のような組合せが、現実的なロードマップとして頻出します。

ストラングラーパターンの構造

                     +---------------------+
     チャネル/対外系 ->|  ルーティングファサード  |
                     | (商品/口座基準で分岐)   |
                     +----+-----------+----+
                          |           |
            旧口座/旧商品   |           |  新口座/新商品
                +---------v--+     +--v-----------+
                | レガシーコア  |     |   新規コア     |
                | (凍結、縮小) |     | (成長、拡張)   |
                +---------+--+     +--+-----------+
                          |           |
                +---------v-----------v----------+
                |   統合元帳ビュー / 情報系同期      |
                |   (両側の残高・取引の単一ビュー)    |
                +--------------------------------+

ストラングラーの成否はルーティングファサードの設計にかかっています。どの口座がどちらのコアにあるのかをチャネルが知らなくて済むようにすること、そして両側にまたがる取引(旧口座から新口座への振込など)の整合性を保証することが核心の難題です。

コア分解戦略 — 何をどう切り分けるか

商品ファクトリの分離

レガシーコアが肥大化した主犯は、商品ロジックが元帳処理コードに埋め込まれているからです。現代的なコア設計は、商品定義(金利体系、手数料、条件、限度)をデータ・設定として外部化した商品ファクトリを置きます。新商品のリリースが「コードのデプロイ」ではなく「商品メタデータの登録」になることが目標です。前回の記事で扱った優遇金利ルールエンジンも商品ファクトリの一部と見なせます。

元帳の分離と薄いコア

 [伝統的モノリシックコア]            [分解されたコア]
 +--------------------+        +------------------+
 |  チャネル処理        |        |  商品ファクトリ     |  <- 商品定義/ルール
 |  商品ロジック        |        +------------------+
 |  利息/手数料計算     |        +------------------+
 |  元帳記録           |   =>   |  価格/利息エンジン  |  <- 計算専任
 |  顧客情報           |        +------------------+
 |  会計仕訳           |        +------------------+
 |  レポート           |        |  薄い元帳(コア)    |  <- 残高/取引記録のみ
 +--------------------+        +------------------+
                               +------------------+
                               |  顧客マスタ(別置)   |
                               +------------------+
                               +------------------+
                               |  会計ハブ(別置)    |
                               +------------------+

分解の原則は「元帳は最後まで小さく硬く」です。残高と取引記録という本質だけを残し、計算(利息・手数料)、判断(限度・条件)、表現(レポート・照会)をすべて外へ出す方向です。元帳が小さいほど検証が容易になり、検証が容易なほど移行が安全になります。

イベント駆動の統合

分解されたコンポーネントはイベントで結ぶのが現在の定石です。元帳で確定した取引をイベント(例: 入金完了、口座解約)として発行すると、情報系へのロード・通知・会計ハブ・リスクシステムがそれぞれ購読します。

  [元帳コア] --発行--> [イベントストリーム (Kafkaなど)] --購読--> [情報系ロード]
                                              +--購読--> [通知/プッシュ]
                                              +--購読--> [会計ハブ]
                                              +--購読--> [FDS/リスク]

ただし金融ドメインでイベント駆動統合を行う場合は、一般的なWebサービスより厳格な規律が必要です。

  • 元帳コミットとイベント発行の原子性: アウトボックスパターン(元帳トランザクションの中でイベントをテーブルに記録し、別のリレーが発行)が事実上の標準です。
  • 順序と冪等性: 同じ口座のイベントは順序が保存されなければならず(口座キーによるパーティショニング)、購読側は重複受信を前提に冪等に設計します。
  • 再処理可能性: 購読システム障害時に特定時点から再消費できる必要があり、イベントスキーマの後方互換を管理します。

分解順序の決定基準

何から切り離すかは、次の2軸で評価するのが実用的です。

評価軸問い例
分離の容易さ元帳トランザクションとの結合が弱いかレポート/照会(容易) vs 出金検証(困難)
変更頻度ビジネス要求で頻繁に変わるか商品条件/優遇金利(高い) vs 仕訳規則(低い)

変更頻度が高く分離が容易なもの(照会API、商品ルール、通知)から始めて早期の成果を作り、分離が難しく変更が少ない元帳本体は最後に扱うのが定石です。逆に最も難しい元帳から手を付けるプロジェクトは、価値を届けないままリスクだけ積み上げて推進力を失いがちです。

クラウドネイティブコアバンキングの潮流

2010年代後半から「コアバンキングをSaaS/クラウドネイティブへ」という潮流が本格化しました。代表的に挙げられるプレイヤーの特徴を、知られている範囲で整理すると次のとおりです(特定ソリューションの推奨ではなく、機能や戦略は変わり続けるため公式資料の確認が必要です)。

  • Thought Machine (Vault Core): クラウドネイティブ設計と、スマートコントラクトと呼ばれる商品定義方式(商品ロジックをコード契約として記述)を打ち出す新興コア。大手銀行の次期コア実験事例として頻繁に言及されます。
  • Mambu: SaaS型コアバンキングの代表格で、コンポーザブルバンキング(必要な機能を組み合わせる)を標榜します。ネオバンク・フィンテックの迅速なローンチ事例が多くあります。
  • Temenos、FIS、Finastraといった伝統的強者も、クラウド移行版を投入して対応しています。

クラウドネイティブコアの共通パターンは次のとおりです。

  1. 商品定義のコード化/設定化: 商品をコアの外の宣言的定義として扱い、リリースサイクルを短縮します。
  2. APIファースト: すべての機能がAPIとして公開され、チャネル・パートナー統合が容易です。
  3. 水平スケーリング: 口座単位のパーティショニングで、ノード追加により処理量を拡張します。
  4. リアルタイム元帳: 日次バッチ中心の設計を減らし、利息計上などもリアルタイム・準リアルタイムへ移行する傾向があります。

ただし冷静に見るべき点もあります。大手既存銀行が全元帳を新興SaaSコアへ移し終えた完結事例はまだ多くなく、部分導入(特定商品群、新規ブランド)で検証中という段階が一般的です。「クラウドネイティブコア = 即導入可能な完成品」ではなく「有望だが検証コストが大きい選択肢」と見るのが実務感覚に合います。

韓国の特殊性 — 規制環境という変数

韓国でコア現代化を設計する際、規制環境は欠かせません。大きな流れだけ押さえると次のとおりです(詳細要件は改正が頻繁なため、必ず金融委員会・金融監督院の最新原文と有権解釈を確認する必要があります)。

  • 電子金融監督規程: 金融会社ITの安全性基準を定める中核規程です。人員・組織、設備、情報処理システム、災害復旧(重要業務の復旧目標時間など)に対する要求事項があり、アーキテクチャ設計の制約条件になります。
  • ネットワーク分離(網分離): 内部業務網とインターネットの分離を求めてきた規制で、開発生産性(オープンソース活用、SaaS開発ツール)に大きな影響を与えました。近年は規制サンドボックスと段階的改善を通じ、クラウド開発環境や生成AI活用などへの例外と合理化が進んできました。
  • クラウド利用規制: かつては重要システムのクラウド利用が事実上困難でしたが、規程改正を経て、重要度評価と事前報告体系を基盤にクラウド活用範囲が段階的に広がってきました。ただし勘定系級の中核システムのパブリッククラウド全面移行は、依然として保守的に接近するのが業界の一般的な姿です。

戦略的含意は明確です。韓国での現実的な経路は「周辺系(チャネル、情報系、新事業)からクラウドへ、勘定系は分解と標準化を先に」となる場合が多く、規制変化の速度がロードマップの主要変数であることを最初から計画に織り込むべきです。

データ移行戦略 — 元帳を運ぶ技術

コア現代化の最大の難関はコードではなくデータです。数千万の口座、数十億件の取引履歴、そして「今この瞬間も変わり続ける」残高を運ばなければなりません。

二重記帳 (Dual Write / Parallel Run)

  フェーズ1: レガシーがマスター、新コアはシャドウ
  [取引] --> [レガシー元帳 (確定)] --複製/再生--> [新元帳 (シャドウ)]
                                                  |
                       [日次全件照合: 残高/利息/手数料の比較レポート]

  フェーズ2: 信頼確保後に役割を交代 (商品群/顧客群単位)
  [取引] --> [新元帳 (確定)] --複製--> [レガシー元帳 (シャドウ、非常用)]

  フェーズ3: レガシー凍結、照会専用で保存後に廃棄

核心となる規律は次のとおりです。

  1. 並行検証は全件で: サンプル検証は罠です。利息計算のように条件の組合せが多い領域は全口座比較が原則であり、差異の件には分類コードを付けて収束の推移を管理します(「差異ゼロをN日連続維持」のような基準でカットオーバーゲートを定義)。
  2. 再生(replay)可能な移行: 初期ロード + 変更分同期(CDC) + カットオーバー直前の最終同期という3段構造にし、どの段階でも失敗時に最初から再実行可能でなければなりません。
  3. 意味変換の仕様化: レガシーの状態コード、日数慣行、切捨て方針が新コアと1:1とは限りません。マッピング規則を仕様書にし、変換ロス(例: レガシーにしかない特殊状態)の処理方針を業務部門と合意しておきます。
  4. 履歴の扱い: 全取引履歴を新コアへ移すか、照会専用アーカイブに置いて新コアは起算残高から始めるかは、コスト・規制上の保存義務・顧客体験を併せて検討して決定します。

並行照合クエリの姿

全件照合の実体は意外なほど素朴なSQLです。新旧元帳を日次で比較する骨格の例は次のとおりです。

-- 日次残高の全件照合: レガシースナップショット vs 新コアスナップショット
SELECT COALESCE(l.account_no, n.account_no)      AS account_no,
       l.balance                                  AS legacy_balance,
       n.balance                                  AS new_balance,
       COALESCE(l.balance, 0) - COALESCE(n.balance, 0) AS diff,
       CASE
         WHEN l.account_no IS NULL THEN 'NEW_ONLY'    -- 新側にのみ存在
         WHEN n.account_no IS NULL THEN 'LEGACY_ONLY' -- レガシーにのみ存在
         WHEN l.balance <> n.balance THEN 'MISMATCH'
         ELSE 'OK'
       END AS recon_status
  FROM legacy_balance_snapshot l
  FULL OUTER JOIN new_core_balance_snapshot n
       ON l.account_no = n.account_no
      AND l.snapshot_date = n.snapshot_date
 WHERE l.snapshot_date = DATE '2026-06-12'
   AND (l.balance IS DISTINCT FROM n.balance
        OR l.account_no IS NULL OR n.account_no IS NULL);

-- 差異の分類集計: 収束推移の管理用
SELECT recon_status, diff_reason_code, COUNT(*) AS cnt,
       SUM(ABS(diff)) AS abs_diff_sum
  FROM daily_recon_result
 WHERE snapshot_date = DATE '2026-06-12'
 GROUP BY recon_status, diff_reason_code
 ORDER BY cnt DESC;

ポイントは差異事由コードです。「切捨て方針の差」「レガシーの特殊状態」「タイミング差(未決取引)」のように差異を分類しておけば、どの差異が設計上の許容(文書化された差異リスト)で、どの差異が欠陥なのかを追跡できます。差異レポートが毎日自動で出力され、推移グラフが右肩下がりであること。これが並行検証が生きている証拠です。

カットオーバー設計

カットオーバー方式内容リスクプロファイル
一括(ビッグバン)週末などに全体切替短期間高強度、ロールバックの窓が狭い
商品群単位例: 新規積立から切替新旧共存の複雑さ、リスク分散
顧客群単位例: 新規顧客から同一顧客の複数口座の分離問題
満期ロールオーバー満期到来時に新コアで再契約最も遅いが最も安全な軸

どの方式でも、ロールバック計画はカットオーバー計画と同格の成果物でなければなりません。「いつまでに、どの条件が崩れたら、どの手順で戻すか」をリハーサルで検証していないロールバック計画は、ただの文書です。大型移行では通常、切替リハーサルを複数回(データ全件移行リハーサルを含む)実施し、リハーサルごとに所要時間を測定してカットオーバータイムラインの余裕を確認します。

カットオーバー週末のタイムライン例

ビッグバン要素を含む切替の最終週末は、通常次のような時間表で動きます。

 金曜日の営業終了
   T+0h   : レガシー日次締めの正常完了を確認 (先行ゲート)
   T+1h   : 新規取引の遮断(サービス告知)、チャネルをメンテナンスモードへ
   T+2h   : 最終変更分の同期(CDCドレイン)、両元帳の静止点を確定
   T+3h   : 全件照合の実行 (残高/未払利息/限度/状態)
   T+6h   : 照合結果の判定会議 -> GO / NO-GO 決定
   [GO]   : ルーティング切替、新コアで取引開始(内部検証取引を先行)
   T+8h   : チャネルの段階的オープン(職員 -> 一部顧客群 -> 全体)
   T+24h  : 初営業日のモニタリング体制(ウォールーム)稼働
   T+72h  : 安定化判定、ウォールーム解除またはロールバック判断の期限
 [NO-GO] : 事前定義されたロールバック手順を発動、レガシーへ復帰し原因分析

この時間表で最も重要な行はGO/NO-GO判定会議です。判定基準(照合差異の許容値、必須シナリオの通過率)が事前に文書で合意されていてこそ、午前4時の疲弊した会議室で即興的な決定が下されるのを防げます。

リスク管理 — 段階別ゲート

現代化プログラムは段階別ゲート(go/no-go)で統制します。

 [ゲートの例]
  G1 設計検証     : 主要取引シナリオの新コア処理検証(PoC)、性能目標の合意
  G2 並行開始     : シャドウモード稼働、全件照合体制の稼働
  G3 部分カットオーバー : 低リスク商品群の切替、運用体制(監視/障害対応)の検証
  G4 本カットオーバー   : 中核商品群の切替、ロールバックリハーサル完了が前提条件
  G5 レガシー凍結  : 新規取引の遮断、照会専用への転換、保存計画の確定

各ゲートの判定基準を定量化することが重要です。「並行照合の差異0件をN日連続」「新コアのP99応答時間目標の充足」「障害模擬訓練の通過」といった基準がなければ、ゲートはスケジュール圧力に突破されます。

組織と人材の転換

技術移行より難しいのが組織の移行です。

  • デュアルスキル期間の設計: 新旧システムが共存する数年間、レガシーを知る人材と新技術人材の両方が必要です。レガシー人材を「移行のドメイン専門家」として再配置する経路(ドメイン知識の文書化、新コアの業務検証担当)を作れなければ、移行後半にレガシー知識が蒸発する事故が起きます。
  • 運用モデルの転換: 分解されたコアは運用方式も変えます。中央運用チームの一括バッチ管制から、サービス単位のオンコールとSREプラクティスへの転換が伴わなければなりません。
  • 業務部門との共同所有: 商品ファクトリは「ITが作り、現場が使う」道具です。商品定義の責任を現場へ移すプロセス(検証環境、承認ワークフロー、教育)までがプロジェクトの範囲です。
  • 外注依存度の管理: 韓国の次世代プロジェクトは伝統的に大手SI中心で遂行されてきました。漸進的現代化は数年間持続する内製化能力を要求するため、「プロジェクトが終われば去る人材」構造では運用フェーズが持ちません。中核コンポーネント(元帳、商品ファクトリ)の設計・運用能力は内製化し、外注は境界の明確なモジュールに限定するソーシング戦略が必要です。

組織転換の進捗は技術の進捗より測定が難しいですが、少なくとも「新コアの障害を内部人材だけで診断・復旧できるか」という問いには、段階ごとに答えられなければなりません。

失敗パターン — 繰り返される罠

  1. 機能等価性の呪い: 「現行と100パーセント同一に」を目標に据えると、レガシーの偶然の挙動(バグ的仕様を含む)まで複製することになりコストが爆発し、現代化の意味が消えます。差異許容リストを作り業務部門と合意する作業が必須です。
  2. ビッグバン日程の政治化: カットオーバー日が経営発表で先に固定され、品質がスケジュールに従属するパターンです。ゲート基準の定量化と「日程より基準」原則のガバナンス合意がワクチンです。
  3. 並行検証の省略: スケジュール圧力でシャドウ運用期間を削ると、カットオーバー後に利息決算・月次締めのような低頻度イベントで潜伏欠陥が爆発します。最低1回の四半期決算を並行期間に含めるのが安全です。
  4. データ品質の過小評価: レガシーデータの整合性問題(孤児レコード、コード不一致)は移行ツールではなく業務判断を要求します。データクレンジングをプロジェクト初期に別トラックで始めなければ、終盤のボトルネックになります。
  5. 新技術万能論: イベントソーシングやMSAといったパターンを「それ自体が目的」として導入すると、分散システムの複雑さが元帳整合性リスクに直結します。コアの本質(お金が合わなければならない)に寄与するかが、すべての技術選択の基準であるべきです。
  6. ベンダーロックインの再生産: メインフレーム依存から逃れようとして、特定クラウド・特定SaaSコアにより深く依存するケースです。脱出コスト(データ搬出、商品定義の移植性)を契約段階で評価すべきです。
  7. 非機能要件の後回し: 性能・災害復旧・セキュリティ要件を「後で合わせればいい」と先送りすると、終盤の性能テストでアーキテクチャレベルの手戻りが発生します。初期のPoC段階からピーク負荷と障害シナリオを含めるべきです。
  8. 移行組織の二元化対立: 新コア開発チームとレガシー運用チームが別の報告ラインに分かれ、情報が途切れるパターンです。照合差異の原因分析には両側の知識が必要なので、共同目標(差異収束指標)を持つ混成組織が効果的です。

進捗を測定する指標

数年にわたるプログラムは「感覚」ではなく指標で管理すべきです。実務で有用な指標セットは次のとおりです。

カテゴリ指標見る理由
価値提供新コアでリリースされた商品数、商品リリースのリードタイム現代化がビジネスに届いているか
侵食の進捗新コア処理取引の比率(件数/金額)、移管口座の比率ストラングラーの実際の進度
品質並行照合差異件数の推移、差異事由別の分布カットオーバーの準備度
安定性新コアの可用性、P99応答時間、障害件数運用面の信頼形成
レガシー縮小レガシー変更依頼件数、バッチジョブ数、ライセンスコスト凍結が実際に起きているか
組織新スタック保有人材の比率、レガシードメイン知識の文書化率人材の崖への対応

特に「レガシー変更依頼件数」は隠れた名指標です。現代化が進行中なのにレガシーの変更が減らないなら、新機能が依然としてレガシーに入っているという意味であり、侵食ではなく二重投資が起きているという警告です。「レガシー新機能凍結」の宣言と例外承認手続きが、この指標を生かします。

用語集

用語英語意味
次世代Next-generation projectコア全面再構築型大型プロジェクトの韓国式通称
ビッグバンカットオーバーBig-bang cutover一時点での全体切替方式
ストラングラーStrangler fig pattern新規がレガシーを漸進的に侵食する転換パターン
商品ファクトリProduct factory商品定義をデータ/設定として外部化した構成要素
薄い元帳Thin ledger残高・取引記録の本質だけ残した最小コア
二重記帳Dual write / parallel run新旧元帳へ同時記録しながら検証する期間
全件照合Full reconciliationサンプルではなく全件の比較検証
カットオーバーゲートCutover gate段階進行の定量的判定基準
シャドウモードShadow mode新コアが確定権限なしに並行計算のみ実施
満期ロールオーバー移行Rollover migration満期到来契約から新コアへ移転
網分離Network separation業務網とインターネット網の分離規制
ウォールームWar room切替直後の集中監視・意思決定体制

ロードマップの例 — 仮想の中堅銀行5か年

仮想のシナリオで全体像を描いてみると次のとおりです。

 1年目: 基盤構築
   - コアドメイン分析、元帳/商品/計算の境界定義
   - APIゲートウェイ・イベントストリームの構築、レガシーへのアダプタ装着
   - データクレンジングトラックの開始、クラウドガバナンス(規制対応)の体系化

 2年目: 周辺から転換
   - 情報系・チャネルのクラウド転換、レガシー負荷の軽減
   - 商品ファクトリ第1次構築、新規預金商品1種を新コアでパイロット

 3年目: シャドウ並行
   - 新コアのシャドウモード稼働、全件照合体制の運用
   - 四半期決算を1回以上、並行検証で通過

 4年目: 段階カットオーバー
   - 低リスク商品群から順次切替、満期ロールオーバーを並行
   - ロールバックリハーサル、災害復旧切替訓練の通過をゲートとして運用

 5年目: レガシー凍結と整理
   - 残余商品の切替完了、レガシーは照会専用で保存
   - 運用モデル転換の完了(SRE体制)、振り返りと標準化

もちろん現実のスケジュールは、規制変化、組織能力、優先順位によって大きく変わります。要点は期間ではなく構造です。価値が早期に出る順序(周辺 → 新商品 → 並行 → 段階切替)と、各段階の定量ゲートがロードマップの骨格にならなければならないということです。

もう1つ付け加えると、ロードマップは一度描いて終わりの成果物ではありません。規制緩和の速度、新コアの検証結果、市場状況(金利環境、競合動向)に応じて毎年再評価する、生きた文書として運用すべきです。ただし再評価が頻繁でも、ゲート基準自体を緩める方向の修正は警戒すべきです。日程は動いても品質基準は動かないという原則が、プログラムの信頼を守ります。

おわりに

コアバンキング現代化は技術プロジェクトというより、リスク管理プログラムです。ビッグバンか漸進かは宗教論争ではなく、組織のリスク受容能力とドメイン分離可能性に対する工学的判断の問題です。明確なのは方向性です。元帳は小さく硬く、商品はデータとして、統合はイベントで、移行は並行検証とともに。そしてどれほど華麗なアーキテクチャを描いても、最後の問いは前の2本の記事と同じです。「この転換の過程でお金が狂いうる経路はどこか?」その問いに段階ごとに答えられるプログラムだけが、心臓移植を完走します。

本シリーズの前2編(預金システムアーキテクチャ、利息計算エンジン)で扱った元帳設計と検証の規律は、結局この現代化の旅路で新旧システムを比較可能にする共通言語でもあります。コアを替えようとする組織であれば、まず現在のコアをその言語で説明できるかどうかから点検することをお勧めします。

参考資料

Discuss on Twitter • View on GitHub