1. まとめトップ

この記事は私がまとめました

kazumi012さん

なぜこうなるのか?

まあ色々な所でさんざん指摘されていますが、責任の所在がハッキリしていないからです。
 今回の場合、あくまでも外野から見ている(故に守秘義務等一切に抵触しない)範囲で言えば、ベンダーが多すぎます。

各ベンダーに加えてクライアントである銀行内での派閥も・・・

そもそもみずほ銀行の前身は、第一勧業銀行・富士銀行・日本興業銀行の合併あたりから始まってるわけです。
合併はしたもののこいつらは仲が良くなくて、社内でどこの銀行出身がリーダーとるかで血みどろの社内政治闘争が繰り広げられてます。それを反映して、社内の電算システムも、キメラ合体させ田つぎはぎのを使ってます。どの派閥も譲らなかったせいです。当然、死ぬほど古いプログラムを切り貼りして継ぎ合わせて使ってるので、もう誰も全体像はつかめないし改造するのも難しい状況ですし、触らぬ神に祟りなしみたいな状態でした。

記憶している人もいるかと思いますが、東日本大震災直後の2011年3月にみずほ銀行の子の電算システムは大規模な障害を起こしてます。8000億円規模の決済遅延を起こして、預金者に不便をかけました。当然金融庁の調査とかも入ってるんですが、その結果として「組織の上層部が派閥闘争しすぎで、仲悪すぎて、現場も混乱してひどい騒ぎです、いい加減にせえよ」といわれます(勧告というのを受けちゃいました)。金融庁にここまで言われるなんてよっぽどです。ゴイスー。

まあ、しかし、今まで派閥闘争してたひとは1mmも反省してないので、新しいシステム開発などできるわけもないのでした。そもそも、業務の要件をまともに定義できる人もいないのです。というのも、いくつもの派閥が自分たちに都合のいいような仕様を押し付けようとするからです。というか、もはや都合がいいとか悪いではなく、敵対派閥が進めようとした作業の妨害をしたり、仕様変更したりするのが、社内での出世ゲームになっていたのでした。コワイネ。

日本では古いほうがエライ。それは実にシンプルに帰属意識や誇りに結びつく。
今をときめく日本銀行よりも第一銀行(第一国立銀行)の方がエライのよ。
つまり第一勧銀の方が富士よりも格が上だと思ってたりする。
んで、明治期創業の三行がプライドを漲らせたママで
1. 一般人相手の預金業務を第一勧銀の富士通システムにする
2. 企業相手の貸付業務を興銀の日立システムにする
3. 信託業務は富士の日本IBMシステムにする
4. 与信管理とか項目名どうする?
5. 合併元それぞれの銀行マンがそれぞれのシステム担当者に違うこと言う

吸収合併の歴史

さて、みずほ銀行の吸収合併は、こんな感じ。

みずほコーポレート銀行<改名=富士銀行←日本興業銀行
みずほ銀行<改名=(第一勧業銀行←富士銀行のリテール部門)←(みずほ統合準備銀行←日本興業銀行のリテール部門)
で、記憶に新しい2011年の東日本大震災システムトラブルの影響で、

システム刷新して再発防止するぜ!というのが2012年スタートの話。

みずほ銀行<改名=みずほコーポレート銀行←みずほ銀行 (一体化して再発防止)
みずほコーポレート銀行にみずほ銀行が吸収合併されて、

みずほコーポレート銀行はみずほ銀行に改名。

はい、クソメンドクサイですね。

各ベンダーの担当分野

1. 一般人相手の預金業務を第一勧銀の富士通システムにする
2. 企業相手の貸付業務を興銀の日立システムにする
3. 信託業務は富士の日本IBMシステムにする
4. 与信管理とか項目名どうする?
5. 合併元それぞれの銀行マンがそれぞれのシステム担当者に違うこと言う

ようするにざっくり言うと
・BtoC = 第一勧銀 (元みずほ銀行) = 富士通
・BtoB = 日本興業銀行 (興銀、元みずほコーポレート) = 日立
・信託 = 富士銀行 = IBM
ってことですね。
さらにそれぞれのシステムについて詳しく解説すると…

勘定系(ホスト)…富士通
営業店端末システム…富士通
インターネットチャネル(ダイレクトバンキング)…IBM
情報系システム…IBM
周辺系(中継系)…IBM
外部接続系…日立
コーポレート銀行勘定系…日立

どうすればよかったのか?

三菱東京UFJ銀行の開発はちゃんと終わりました。あそこも無茶やりました。
ポイントは、どの派閥が主導権を握って、有無を言わせないか。
クライアント(依頼主)側の命令系統がキッチリしてるかどうかが全て。

1. 経営トップが先頭に立ってシステム導入の陣頭指揮を執り、全社の理解を得ながら社員をプロジェクトに巻き込む
2. 複数のシステム開発会社を比較し、最も自社の業務に精通している業者を選ぶ
3. システム開発会社を下請け扱いしたり、開発費をむやみに値切ったりしない
4. 自社のシステム構築に関する力を見極め、無理のない計画を立てる
5. 社内の責任体制を明確に決める
6. 要件定義や設計など上流工程に時間をかけ、要件の確定後はみだりに変更しない
7. 進捗は自社で把握、テストと検収に時間をかける
8. システムが稼働するまであきらめず、あらゆる手段を講じる
9. システム開発会社と有償のアフター・サービス契約を結び、保守体制を整える
10. 「うっかり」ミスを軽視せず、抜本的な対策をとる

1