全10866文字
PR

2019年7月に完了したみずほ銀行のシステム統合。20年にも及ぶその苦闘を「日経コンピュータ」の記事で振り返る。2012年8月2日号はみずほ銀行が2度目の大規模障害を受けて1年がかりでシステムの総点検に乗り出したことや、勘定系の全面刷新を始めたことを報じた。

 システム全面刷新・統合をなんとしても成功させ、信頼回復に努めたい─。2度の大規模システム障害を引き起こしたみずほフィナンシャルグループのシステム関係者が、重い口を開き始めた。みずほがシステム関連の個別取材に応じるのは、2011年3月のトラブル以後、初めてのことだ。

 みずほは1年間がかりで再発防止策を講じ、現在は大手銀初となる勘定系システムの全面刷新・統合を進める。

 大規模障害の再発は本当に防げるのか。世界最大規模となることが確実な刷新・統合プロジェクトを、やり抜けるのか。そして長年の課題である、ITガバナンスを強化できるのか。みずほ復活に向けた再挑戦を追う。

1年かけてシステムを総点検

 分担の誤謬――。2011年3月の大規模システム障害でみずほ銀行(BK)が陥ったのは、勘定系という巨大システムを維持する上で避けて通れない、人や組織の役割分担がもたらす落とし穴だった。

 大手銀行の勘定系は、5000万ステップを超えるプログラムや、数十のサブシステムが複雑に絡み合う超巨大システムだ。みずほはサブシステム単位で担当者を置き、システムの開発や運用にあたってきた。さらに、情報システム部門は要件定義、システム子会社のみずほ情報総研はシステム設計、ITベンダーはコーディング、といった具合に実務作業を分担していた。

 作業の分担化が進むにつれ、システムの全体像を把握できる人がいなくなった。その結果が2011年3月のシステム障害だ。夜間バッチ処理の異常終了がもたらす影響や2次障害を想定できず、障害の大規模化と長期化を招いた。

 「個別のシステムには担当者がいて、それぞれのシステムの詳細を把握していた。しかし銀行業務は何十というシステムを連携させる必要がある。その全体を俯瞰する責任者がいなかった」。みずほフィナンシャルグループ(FG)IT・システム企画部でシステムリスク管理室に所属する田中伸一参事役はこう振り返る。

 システムの全体像を把握するのはITガバナンスの基本である。ITガバナンスの不全こそが、大規模障害の真因であった。

システムの全体像を可視化

 ITガバナンスを立て直すため、みずほは2011年3月のトラブル以降、1年間にわたり再発防止策に取り組んできた。

 その象徴が、図1に示す「データフロー図」を作成したことだ。「振り込み」「預金」「支払い」「税金」など15種類の決済業務を対象に、システム内をデータがどのように流れるのかを可視化した図である。

図1●みずほが作成した「データフロー図」
図1●みずほが作成した「データフロー図」
システムの全体像を把握するために、「振り込み」「預金」「支払い」「税金」などの15の決済業務を対象に、データの流れを可視化する資料を新規に作成した
[画像のクリックで拡大表示]

 BKのサブシステムを網羅し、それぞれがどう連携しているのかがつかめるようにした。外部システムから受け取ったデータをどんな流れで処理して、その結果をどの外部システムにいつ送るのかが一目で分かるようにもしてある。

 データフロー図は、FGやBKのシステム部門を中心に、利用部門やみずほ情報総研が総出で作成した。システム部門がたたき台を作り、利用部門やみずほ情報総研の担当者が参加する「ウォークスルー」を通じて内容をブラッシュアップした。

 15種類のデータフロー図を作るのに、およそ3カ月かかった。最初のバージョンは2011年秋に完成させた。その後、3カ月かけて内容を見直し、2度目のウォークスルーを経て最終的に2012年3月に改訂版を仕上げた。

 今までもシステム単位の仕様書は整備していた。業務の流れを示す資料もあった。だが、データの流れに注目して、システム全体を貫くデータフロー図を作成したのは、これが初めてだった。「一部の人間の頭の中にだけ存在したデータの流れを可視化することで“組織知”とすることができた」。FGの高取亮IT・システム企画部企画チーム次長はこう語る。

リミット値を洗い出し

 BKの勘定系システム「STEPS」は、第一勧業銀行(当時)が24年前に開発したシステムだ。当時のシステム構築に携わった担当者が引退するに従って、システムのどこに超えてはならない「リミット値」が存在するのか、あるシステムのエラーがシステム全体あるいは外部システム、顧客サービスにどのような影響を与えるのかが、すぐには分からない状態になっていた。データフロー図を作ることではじめて、みずほはシステム障害で顕在化した問題点を修正できるようになった(図2)。

図2●みずほが取り組んだ再発防止策のポイント
図2●みずほが取り組んだ再発防止策のポイント
2011年3月のシステム障害で顕在化した問題点を改善した
[画像のクリックで拡大表示]

 例えば、システム全体を対象にリミット値を洗い出した。リミット値には、1口座当たり1日に最大何件処理できるかといった処理件数を示すものと、一連の処理を何時までに終わらせなければならないかという時間上の制限(時限)の二つがある。みずほは処理件数と時限の両面から、データフロー図を基にリミット値を見直した。さらに、リミット値に関するエラーが発生した時、その後の処理にどんな影響を及ぼすかを確認した。

 リミット値は勘定系やインターネットバンキングといったシステム単位で把握するだけでは不十分だ。例えば2011年3月のシステム障害で問題となった大量振り込みは、インターネットバンキングではリミット値の範囲内だったが、その後の夜間バッチ処理でリミット値をオーバーした。

 「商品やサービスを強化するたびに、様々なシステムや機能を追加しており、システムの全体像が分かりにくくなっていた。データフロー図を作ることで、ようやく全体像を把握できるようになった」(IT・システム企画部の高橋達浩副部長)。