第4回 今度こそリスク取り大胆な刷新と統合を
みずほフィナンシャルグループ（FG）が背水の陣でシステム統合に臨む。 大規模障害を招いた直接の原因は、システム部門の不手際だった。システム全体の仕様や機能をつかみきれず、障害後には運用ミスを重ねた。だが根本的な原因は、経営陣のITガバナンスの欠如にある。老朽化したシステムの刷新を怠り、障害対応では経営判断が後手に回った。 そこで、みずほ銀行とみずほコーポレート銀行のシステムを2013年にも統合させ、みずほ信託銀行のシステムの一部も取り込む（図）。併せてみずほ銀とみずほコーポ銀を合併させる方針だ。 2002年4月のみずほ発足以降、FG傘下の各銀行は勘定系などのシステムをそれぞれ別々に保有してきた。経営体制についても、FGとみずほ銀、みずほコーポ銀のトップを旧第一勧業銀行、旧富士銀行、旧日本興業銀行の出身者が分け合ってきた。これらをシンプルに改め、システム障害の再発を防ぐ狙いだ。 老朽システム
第3回 抜本的解決へのサービス停止も後手に
夜間バッチの遅れが解消されず、さらにATMの全面ダウンも引き起こしたことから、みずほ銀は3月18日、抜本的な障害対応に乗り出すことを決めた。 障害対応にシステムのリソースを集中するため、18日から22日にかけて、店舗外ATMやインターネットバンキングなどの停止を決めた（図）。さらに3連休の間はすべてのATMを止めることにした。 18日午後1時30分、みずほ銀本店ビル22階に、障害対策チームのオペレーションルームを設けた。そこに、みずほ銀のIT・システム統括部とシステム運用部、みずほ情報総研、システム運用を担うみずほオペレーションサービスの担当者が集まった。障害発生から5日後にようやく、3社の障害対策チームが一本化した（表-28）。 これに前後して、手動で行っていた夜間バッチを効率化するため、TARGETを改良し、処理を自動化できるようにもした。 18日からの巻き返しによって、19日午後7時
第2回 読み誤りや誤削除など人為ミス続発
みずほ銀のSTEPSは1988年に稼働を開始した。当時は、ATMの24時間稼働も、インターネットバンキングも、携帯電話を用いた振り込みサービスも存在しなかった。 その後、これらのサービスを追加する一方、みずほ銀はバッチ処理の上限値の設定を、23年間一度も見直さなかった（表-18）。 さらに、携帯電話での振り込みといった新サービスを導入する際に、夜間バッチの負荷テストを行っていなかった（表-19）。 みずほフィナンシャルグループなどによるシステムに関する内部・外部監査が機能していなかった（表-20）ため、こうした問題に気付くこともなかった。 みずほ銀はシステム監査において、「システム運用管理体制」のリスクを最高レベルとしていない（表-21）など、リスクの大きさを正しく把握することができていなかった。 夜間バッチが異常終了した原因は、口座bの振り込みデータを振り分ける（分割する）処理で、上限値
第1回 重なった30の不手際
東日本大震災から3日後の2011年3月14日。この日の午前に最初のトラブルは発生した。テレビ局が東日本大震災の義援金を番組などで呼びかけたところ、みずほ銀行東京中央支店のテレビ局の義援金口座（以下、口座a）に、振り込みが殺到した。 午前10時16分、振り込みによって生じた「取引明細」の件数が上限値を超え、口座aに対する「預金・取引内容照会」ができなくなった。取引明細は通帳の記帳に使う。 みずほ銀は口座aを、格納できる取引明細の上限値が小さい「個人・通帳口」として間違って設定していた（表-1）。 みずほ銀は口座の種類を二つの属性の組み合わせによって区別している。一つは「個人」か「法人」か。もう一つは、取引明細を通帳に記帳する「通帳口」か、記帳しない「リーフ口（ぐち）」かである。 これら二つの属性によって、格納できる取引明細の上限値が変わる。通常、義援金口座のような大量振り込みが予想される口座
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
