ミズホのようにならないためには、どういう設計でプログラムすればよかったんだい？

すべての合併会社のスケープゴードにされているから、今の形が正解なんじゃね？

「みずほの例もありますしね、、、」

日本中で何万回もリフレインされたフレーズ。自分も上司への言い訳に使った。

永遠に小刻みにトラブルを繰り返して欲しい。愛着も湧いてくる。現預金者は多少のことでは動じないし、こんなみずほが大好き。

ミズホの実情は知らんし、設計やコードの問題でもなかろ。
SIも中のベンダや人が入れ替るから、同一SIの定期更改程度でもリスク大。

基本的には３行の旧システムはそのままに、３行間の他行処理を
自行扱いとして運用すれば当面のリスクは少ないし、合併初期はそうした筈。

次段階は３行のクラウド移行で開発物は各行共用を前提として元SIも可。
旧システムと並行した冗長運用をしながら、移行開発に貢献大なSI主導で
統合先４行目システムを新規口座向けに立ち上げるとか。

実際のリスクは大差ないだろうけど、地銀等の他行向けクラウドサービス提供を通して、
事前に５行目以降の合併準備を進めておける利点があるから開発投資効率がいいかなと。