「今週の土日もみずほ銀行が止まるらしいよ」
という会話、2018年や2019年の前半でよく耳にしましたね。
とはいえ、
- なぜみずほ銀行のシステムは、使えなかったのか？
- その背景には、どんなことがあったのか？
知らない人がほとんどですよね。
システム停止の裏には、数万人のシステムエンジニアの汗と涙の結晶がありました。それをこの記事で紹介しようと思います。
申し遅れました。システムエンジニアのなかつです。
みずほ銀行（正確には、みずほ信託銀行も含む）は、2019年7月16日に新システムに完全移行となりました。
僕は職業柄「みずほのデスマーチ」の話は聞いていましたし、みずほ銀行に知人がいたので、業務側がどういうことになっていたかも知っています。
そこで、元業務系エンジニアの私から「なぜ、みずほ銀行のシステムは毎月停止したのか」をIT素人に向けて、超わかりやすく解説します。
具体的には、
- みずほ銀行の歴史
- みずほ銀行のシステム開発の歴史
- 完了した後の考察
- 現在のみずほ銀行は？
- デスマーチプロジェクトに配属されたら
を順番に解説します。
この記事は、たった10分で読めます。
システムやITに詳しくない人でも、理解できるようにわかりやすくしたので、ぜひ一読を！
リンクで飛べる目次
みずほ銀行の歴史について 〜巨大システムが必要になった経緯〜
三大メガバンクには、それぞれ銀行が合併してできた歴史があります。
みずほも例外ではなく、合併を繰り返して現在の形となっています。
みずほフィナンシャルグループの場合は、中核であるみずほ銀行ができるまでに、大きな合併を二回繰り返しています。
みずほ銀行はもともと、「第一勧業」「富士」「日本興業」という3つの銀行でした。3つともみずほホールディングス（現：みずほフィナンシャルグループ）の所属銀行です。
3つの銀行は2002年に合併します。合併理由として公表されたのは、『戦略IT投資の強化』でした。
この2002年の合併で誕生したのが、「みずほ銀行」と「みずほコーポレート銀行」です。
その後2012年に「みずほ銀行」と「みずほコーポレート銀行」が合併し、現在のみずほ銀行の形となります。
歴史を振り返る上で大切なことは「もともと3行あったのが、現在1行になっている」ということです。
みずほ銀行のシステム開発と障害の歴史 〜デスマーチの経歴〜
みずほ銀行のシステム開発と障害の歴史を振り返ります。
全て説明すると、とても長くなるので大きな出来事を中心に説明していきますね。
そもそもこのシステム開発は、2002年の合併が原因となっています。
「第一勧業」「富士」「日本興業」の三行は、それぞれ勘定系システムを保持していました。
そのせいで合併時には、それぞれの勘定系データを引き継ぎ「みずほ銀行」の新システムに統合する必要があったのです。
（みずほ銀行とみずほコーポレート銀行の二つですが、システムはひとつに統合）
今までは三つの銀行で、それぞれ口座番号を管理していましたよね。
それが合併によって二つの銀行（みずほ、みずほコーポレート）で管理することになります。もし同じ口座番号が別々の銀行にすでにある場合、どうしましょうか？
など、合併のシステム統合は調整することも多く、とても時間がかかるのです。
合併を理由に、みずほ銀行は世界と戦うためのIT投資としてシステム開発をスタートさせます。
まずは、2002年の3行合併時の様子から見ていきましょう。
2002年 合併時に大規模システム障害
「第一勧業銀行」「富士銀行」「日本興業銀行」の三行をみずほのシステムに一本化することは説明しましたよね。
合併して、システムを統合して準備OK！
「いざ！開業だ！」となった初日から、大規模な障害が発生してしまいました。
開業初日から障害が発生してしまった原因は、どこにあったのでしょうか？
障害が起きた背景
開発中にシステムの方針が変わることで、スケジュールが大幅に遅延しました。
その結果、テストの工程を十分にすることができずそのまま開業。
開業初日から「ATMでの障害」「引き落としの不具合」「口座振替の遅延発生」によりユーザを大混乱させた。
二重引き落とし2万件。ATMでは合併前の銀行のカードを使って現金を引き出すことができないなど、利用者の信頼が落ちるような障害ばかりでした。
口座振替の遅延事象は、1日で10万件。
その後も遅延が重なり4月5日（開業から5日後）には、250万件の口座振替が遅延しました。
その後
開業した4月1日から障害の復旧に取り組みました。そのおかげで、4月30日の月末処理は無事乗り切れました。
しかし、そんなみずほ銀行に待っていたのは非常なる現実でした。
- 金融庁と日銀による1ヶ月の立入検査
- 立入検査の結果、業務改善命令が出された
さらに利用者を困らせるような事態に。
この事象を詳しく知りたい人はこちらをどうぞ。
＞＞http://www.shippai.org/fkd/cf/CA0000623.html
その後、世界と戦うためにシステム開発を進めるみずほ銀行でしたが、2011年にはあの災害によって再度、大規模障害を起こしてしまうのです。
関連記事
＞＞みずほ銀行システム統合、苦闘の19年史の書評【ITに関わる全ての人へ】
2011年 2度目の大規模システム障害
比較的に新しい年代なので、覚えている人も多いのではないでしょうか？
東日本大震災が発生して、3月15日から募金を集め始めた途端にシステム障害になった事件です。
募金口座だけでなく、ATM停止など一般ユーザも被害を受ける障害にユーザは大混乱。
その様子が以下の通りです。
みずほ障害の影響で別銀行からの振込が二日経ってもみずほ口座に反映されない(＞人＜;)
— わたぼう (@wataboufx) March 23, 2011
みずほシステム障害 復旧のめど立たず、個人や企業に打撃: 15日から続くみずほ銀行のシステム障害は、顧客の口座に給与を振り込めない事態に発展。3連休後に完全復旧できるめども立っていない。
http://bit.ly/ec7sRw— こうやん@池袋でプログラミングスクール開講中 (@kou_yan) March 18, 2011
三月は年度末ですので、その影響はとてつもなかったです。
- ATMの利用停止
- 未送信仕向為替が16万件
- 為替処理が大幅遅延
- 取引明細の一部欠落
- 口座振替の処理漏れ
などがあり、口座の残高と振込額が一致しないという事態も多数ありました。
口座残高が合わないって怖くないですか？しかも年度末に。
そんな、みずほ銀行の大規模障害の詳しい情報を知りたいひとはこちらから！
＞＞https://www.mizuhobank.co.jp/release/bk/2011/pdf/news110520_3.pdf
障害が起きた背景
障害が起きた原因は、「人的ミス」だと言われています。
人的ミスの理由として説明されたのは「振込処理の上限件数を設定していなかった」とのことでした。
募金などで大量に振込が発生する時は、振込処理の上限件数の設定値を上げるというオペレーションが必要だったのです。
振込処理の上限件数の設定値が上げられていなかったため、「人的ミス」となったようです。
残りふたつの3大メガバンクである「三菱UFJ」「三井住友」では、大規模な遅延やATMの突発停止などが起きませんでした。
システムの内部調査の結果、
- 「みずほ銀行」と「三菱UFJ」、「三井住友」のシステム構成が異なっていたため、みずほ銀行だけ大規模障害を発生させてしまった。
という結論になりました。
つまり人的ミスもあったが、「実際にはシステムの作りかたが悪いよね？」となってしまい、みずほ銀行には、さらにシステム開発を早急に進める必要が出てきました。
その後
大規模障害を引き起こしたみずほ銀行は、システム全体を総点検します。そして障害が発生した箇所以外の部分も、システム改修をすることになりました。
ここから「みずほのデスマーチ」が始まるのです。
＼予約と購入はこちらからどうぞ！／
2012年 1年かけてシステムを総点検
2度の大規模障害を起こしてしまったみずほ銀行は、システムの全面刷新・統合に乗り出します。
システム全面刷新の主な目的として、
- みずほ銀行とみずほコーポレート銀行の合併によるシステム統合
- 2011年3月に発生した大規模障害を起こさないような強いシステムを構築
- 世界と戦うためのITシステムを開発
が挙げられます。
まずは「今のシステムがどうなっているのか？」を把握する必要がありますよね。
システムの総点検を担当したのは、「富士通」「日立」「日本IBM」「NTTデータ」の4社です。
複数社で開発を行うことをマルチベンダーと言うのですが、普通は多くても2社程度なんですよね。
※ベンダーとはシステム開発会社のことです。
なぜ、4社のベンダーが、みずほ銀行のシステムを検査するのでしょうか？
それは次のような、歴史的背景があったからです。
歴史的な背景
合併前の三行のシステムを作った、担当ベンダーは以下のようになっていました。
- 第一勧業銀行 → 富士通
- 富士銀行 → 日本IBM
- 日本興業銀行 → 日立
そのため、総点検は「富士通」「日本IBM」「日立」「NTTデータ」の四社で担当することになってしまいます。
また、三行統合時からもめていた開発ベンダーの枠で、再度揉めました。
なぜ、揉めるのでしょうか？その理由は次の通りです。
- 自社製品を使って欲しいから
- 担当ベンダーが決まって、下請けのポジションに回りたくないから
- 自社で作ったシステムをできるだけ直したくないから
つまり、みずほ銀行のシステム開発を自社で受注することで、莫大なお金が手に入ります。
だから、どの開発ベンダーも引きたくないのです。
富士通や日本IBM、日立は自社の製品としてサーバなどを持っています。そのためみずほ銀行との関係が深くなれば、自社のサーバーを買ってもらえる可能性が上がるわけですよね。
サーバくらい、どこのでもいいでしょ。ってみなさん思うかもしれません。
しかし、銀行のシステムはとてつもなく大きいので、サーバーの価格は少なくとも数億円〜数十億円の価格だと考えています。
この価格なら、サーバを売りたくなるのもわかりますよね？
そんな政治的な理由もあって、2012年の一年間を使って「システム総点検」と「ベンダーの政治都合を調整」しました。
一年間を検査や調整に使って決まったのは、以下の通りです。
やばい決定3つ
- ハードウェアと開発ベンダーはそれぞれ別で発注し、機能ごとに委託先は変更する
- 超大型で総額4000億円を超える、金融系勘定システムの刷新プロジェクトとなる
- 富士通、日立製作所、日本IBM、NTTデータの4社に分割発注で、技術者を確保する
この3つの決定がのちに問題となる「みずほのデスマーチ」の原因となるのでした。
やばいポイント！
僕がシステムエンジニアなので、一般の人にもわかるように「やばいポイント」を紹介しておきますね。
ハードウェアと開発ベンダーはそれぞれ別で発注し、機能ごとに委託先は変更する
機能ごとで開発先が変わるのはよくないです。だいたいまとまりません。
テストの時になって「その機能で、なんでこのデータ作ってるの？」みたいな認識の差異が発覚して、大変なことになります。
エンジニアの人は、「機能ごとに委託先を変更する」と見たら「あ、やばいかも」と疑いましょう。
指揮命令権が決まっているなら問題ないでしょう。
例えば、三菱UFJの場合は、東京三菱（旧IBM）が権限を全て握っていたので問題が起きませんでした。
今回のみずほシステムの場合はベンダーを統括して、指揮命令する企業が決まっていなかったのが問題です。
超大型で総額4000億円を超える、金融系勘定システムの刷新プロジェクトとなる
総額4000億円ってどのくらいの規模だか、ピンと来ませんよね。
なので、最近の主な建築物と総事業費をまとめました。
| 建築物 | 費用 |
| みずほ銀行システム | 4000億円半ば |
| 東京タワー | 33億円 |
| 東京スカイツリー | 650億円 |
| 東京都庁 | 1600億円 |
| ディズニーシー | 3350億円 |
みずほのシステムを再構築してる間に、スカイツリーが7本立てられると言われています。
ちなみにタイムリーな話題を出しておくと、ZOZOの最大の買収金額が4007億円なんて言われていますね。
そのくらい大きなシステム開発は日本、世界でみても稀なものです。つまり責任逃れや自分の利益を追い求める人も出てくるわけですよね。
富士通、日立製作所、日本IBM、NTTデータの4社に分割発注で、技術者を確保する
技術者を確保するわけなんですが、この4社だけでは、とてもまかないきれません。
どうするかというと、外注するわけです。
これだけ大きな規模の開発なので、7次請け会社まであるとの噂もあります。
中抜きされまくって最後の作業者にたどり着くころには、新卒の初任給以下となっていることもあったそうです。
そんな安い金でたくさん働かないといけないんですから、デスマーチになるわけですよね。
あわせて読みたい！
＞＞【IT業界の闇デスマーチを語る】やばいプロジェクトに配属されたらやるべきこと！
2014年 システム開発の完了を延期
写真はサグラダファミリアです。
2014年にみずほ銀行は、システム開発の完了が遅れることを発表しました。
当初、2016年の3月と言っていたところ、9ヶ月遅延すると宣言し、システムエンジニア界隈はざわざわ...
この頃から、みずほのシステムは”サグラダファミリア”と言われるようになりました！（もう少し前から言われていたかもしれませんが。）
2016年 伝説のPM募集
PMとはプロジェクトマネージャの略で、プロジェクトを統括する役目の人です。
遅延を発表していたプロジェクトがPM募集しているとのことだったので、当然世間は「ざわざわ」していました。
フリーランスの募集サイトで見つかった、おそらくみずほ銀行のシステム開発だと思われる求人です。
- 国内銀行勘定系システム再構築プロジェクト全体PM募集
- 大手ベンダーをプロジェクトマネージャとしてのベンダーに適切な指示をし成功に導いてきた実績
- 統制がとれていない現状から、マネジメントの基盤作りプロジェクトに浸透されるためタフなメンタルが必要
- 単価：月に、～130万円程度
参考文献：https://developers.srad.jp/story/15/01/16/0353222/
「統括していた人」がなんらかの理由で、いなくなったことが考えられます。
こんな大規模システムで統括する人がいないのは、パイロットの居ない飛行機と一緒ですよね。
そうです。墜落するってことです。
2016年の年末 二度目の開発完了延期を発表
一度目の開発完了延期は、当初2016年の春に開発完了だったものが、9ヶ月延びて2016年の12月に延びたものでした。
しかし、またもみずほ銀行はやってしまうのです。
二度目の延期は、2016年の12月完了予定から、さらに数ヶ月遅れることを発表しました。
この時の世間の反応は、「もう完成しないんじゃないか」という心配の声でした。
2017年 開発完了と移行計画を策定
二度の遅延を経て、みずほ銀行の勘定系システムは完成しました。
「完成したシステム」と「現行で動いているシステム」を入れ替える必要が出てきました。
超大規模なシステムのため、システム切り替えの期間も長くする必要があります。
そのため、以下のようなスケジュールとなりました。
- 2017年から2019年の2月にかけて、みずほ銀行のシステム移行
- 2019年2月から7月でみずほ信託銀行のシステム移行
約2年にも及ぶシステム移行のスケジュールは、史上初の出来事だと思います。
この約2年間で毎月のようにシステムが止まっていたのは、「超大型システムの移行」が原因だったというわけです。
「毎月みずほ銀行が止まるから使えない」と言っていた人も、大変さが伝わったでしょうか？
（だからと言って、止まるのはかわいそうでしたけど。）
僕は三井住友なので、影響はありませんでした。
2019年7月 システム移行完了
無事、2019年7月にシステム移行が完了しました。
これでみずほのシステム刷新が、全て終わったことになりますね。
2012年から始まった、みずほ銀行のシステムの刷新。
一説には、システム開発までに、20万人月かかったと言われています。（1人が1ヶ月働くと、1人月とカウントされる）
開発のピーク時には、7000人〜8000人が携わったと言われてもいますね。
それだけ人とお金がかかったみずほ銀行のシステムは、歴史に残るシステム開発を乗り越えたと言えるでしょう。
みずほ銀行の現在は？
2019年7月に移行が完了したみずほ銀行のシステムですが、今はどうなのでしょうか？
少しツイッターを探したので、それを下に貼りますね。
みずほ銀行のサービス改悪がすごい。あんなにシステム移行で迷惑かけてこれは心臓がつよいな。客に迷惑かけるのに慣れてるみたい。特典、月に二回コンビニで手数料なしで下ろせます。
— なまうえお (@kanisunQ) November 14, 2019
みずほ銀行のATMで「お預け入れ」のボタンが非表示になっているのだが不具合なのだろうか。先程午後4時過ぎの話。並びなおして別のATM端末を確認したらちゃんと表示されているが、別のボタンが非表示。銀行系システムで不具合の予感を感じると不安大きいな。 pic.twitter.com/XGxrofFbk4
— 子育て主婦_momo (@luxurymomo) November 15, 2019
#みずほ銀行 をメインで使うのやめるのも含めて考えるか。特典は改悪されるし、いつまでたってもアプリは使いづらいし。実店舗にも用事はないし。システム改修の時はなんとか我慢したけど、それに見合うメリットがなくなってきた。どこかネット銀行を検討してみるか…
— とみぞう (@tomizou1973) November 13, 2019
これからもみずほ銀行を使う人は、気をつけてくださいね！
というわけで簡単に当記事をまとめます！
- 大規模障害を2回発生させる
- 合併が内面的にうまくいかずデスマーチ化
- 2019年7月にシステム移行が完全に終了！
追記：2020年2月28日 みずほ銀行で発生したATM障害について
2週間で4回も。。。
みずほ銀行でシステムエラーが発生！！！
— ☆ターナー♪ (@8bGgcee) March 13, 2021
みずほのATM障害が2021年2月28日に起きたのでその状況や原因をまとめてみます！
※3月12日に詳細が書いてある記事があったので、参考にわかりやすく説明しますね。
みずほ銀行のATM障害は地銀の首脳も呆れる「初歩的なミス」な原因
今回のミスを一言で表すと「システムの負荷がかかりすぎて、ATMで障害が発生した」となります。
みずほ銀行は1月にデジタル口座（紙を使わない口座）のサービスを開始。
デジタル口座のサービス開始に伴い、1年以上記帳がない口座を6回に分けてデジタル口座へ移行する予定を立てました。
2月末に「デジタル口座の移行」と「通常の月末処理」が重なり大量のデータを扱うこととなりシステムがパンクすることに。
「月末はシステム負荷がかかりやすい状態、そんなタイミングで”移行”を計画したのは......」と銀行関係者。
つまり、月末に移行計画を立てること自体が「初歩的なミス」であったと周囲は認識している様子です。
過去2回の障害よりも軽微だった？
2019年にシステム移行が完了してから、障害時には異常部分を切り離す設定になっています。
そのため、今回だと”定期預金取引”の異常なのでATMが落ちたというわけです。
これだけ見ると”大震災の募金”、”銀行統合時"の障害に比べると被害は少ないように思えます。
しかし、実際にはATMからキャッシュカードや通帳を取り出せず、すぐに返却できない状況となりました。
これは5244件も発生しており、被害も甚大です。
またATMの電話を使用した問い合わせには9割以上出れず、ATMの前で数時間待たされた顧客も。
どうすれば障害は発生しなかったのか？
2019年のシステム移行の際にこのようなパターンを想定してシステムを作っていなかったことから問題は始まると考えています。
「ATMで障害が発生した時の動線が考えられていなかった。」これに尽きるでしょう。
障害時の各行のATM動作は以下の通り、
- 三菱UFJはキャッシュカードや通帳を取り込む可能性あり
- 三井住友は原則吐き出す設定
ATM障害時の動作に偏りがあるのは少し違和感を感じる。
とはいえ正解もないので、もしATMが停止した場合はどのような対応をするか各行には決めておいてほしいところです。
（もしかするとみずほ銀行も決まっていたかもしれませんが。）
根本的な原因である「初歩的なミス」に関しては、急ぐ理由があっても安全に進めるべきだったと言われるでしょう。
※3月中に紙の通帳数を減らすためにデータ移行を急いだとのこと。
遅くなっても、お金がかかってもセーフティに進めてほしい願ってます。
あわせて読みたい！
＞＞みずほ銀行システム統合、苦闘の19年史の書評【ITに関わる全ての人へ】
