スポンサーリンク

今週の土日もみずほ銀行が止まるらしいよ

という会話を2018年や2019年の前半では、よく耳にしましたね。

 

とはいえ、

  • なぜみずほ銀行のシステムは、使えなかったのか?
  • その背景には、どんなことがあったのか?

知らない人がほとんどですよね。

システム停止の裏には、数万人のシステムエンジニアの汗と涙の結晶がありました。それをこの記事で紹介しようと思います。

 

申し遅れました。元業務系システムエンジニアのなかつです。

みずほ銀行(正確には、みずほ信託銀行も含む)は、2019年7月16日に新システムに完全移行となりました。

僕は職業柄「みずほのデスマーチ」の話は聞いていましたし、みずほ銀行に知人がいたので、業務側がどういうことになっていたかも知っています。

 

そこで、元業務系エンジニアの私から「なぜ、みずほ銀行のシステムは毎月停止したのか」をIT素人に向けて、超わかりやすく解説します。

具体的には、

  • みずほ銀行の歴史
  • みずほ銀行のシステム開発の歴史
  • 完了した後の考察
  • 現在のみずほ銀行は?
  • デスマーチプロジェクトに配属されたら

を順番に解説します。

 

この記事は10分で読めます。

システムやITに詳しくない人でも、理解できるようにわかりやすくしたので、ぜひ一読を!

スポンサーリンク

みずほ銀行の歴史について 〜巨大システムが必要になった経緯〜

みずほ銀行の歴史について

三大メガバンクには、それぞれ合併したという歴史があります。

みずほも例外ではなく、合併を繰り返して、現在の形となっています。

みずほフィナンシャルグループの場合は、中核であるみずほ銀行ができるまでに、大きな合併を二回繰り返しています。

 

みずほ銀行はもともと、「第一勧業」「富士」「日本興業」という三つの銀行でした。三つともみずほホールディングス(現:みずほフィナンシャルグループ)の所属銀行です。

その三つが2002年に合併します。合併理由として公表されたのは、『戦略IT投資の強化』でした。

この2002年の合併で誕生したのは、「みずほ銀行」と「みずほコーポレート銀行」です。

みずほ銀行の合併の歴史

 

その後2012年に「みずほ銀行」と「みずほコーポレート銀行」が合併し、現在のみずほ銀行の形となります。

みずほ銀行の合併の最終形態

歴史を振り返る上で大切なことは、「もともと3行あったのが、現在1行になっている」ということですね。

スポンサーリンク

みずほ銀行のシステム開発と障害の歴史 〜デスマーチの経歴〜

みずほ銀行のシステム開発と障害の歴史 〜デスマーチの経歴〜

みずほ銀行のシステム開発と障害の歴史を振り返ります。

全て説明すると、とても長くなるので大きな出来事を中心に説明していきますね。

 

そもそもこのシステム開発は、2002年の合併が原因となっています。

第一勧業」「富士」「日本興業」の三行は、それぞれ勘定系のシステムを保持していました。

そのせいで合併時には、それぞれのデータを引き継ぎ「みずほ銀行」の新システムに統合する必要があったのです。

(みずほ銀行とみずほコーポレート銀行の二つですが、システムはひとつに統合)

 

例えば、今までは三つの銀行で、それぞれ口座番号を管理していましたよね。

それが合併によって二つの銀行(みずほ、みずほコーポレート)で管理する必要があります。もし同じ口座番号が別々の銀行にすでにある場合、どうしましょうか?

など、合併のシステム統合では調整することも多く、とても時間がかかるのです。

 

その合併を理由に、みずほ銀行は世界と戦うためのIT投資としてシステム開発をスタートさせます。

まずは、2002年の3行合併時の様子から見ていきましょう。

2002年 合併時に大規模システム障害

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年にはあの災害によって再度、大規模障害を起こしてしまうのです。

2011年 2度目の大規模システム障害

2011年 2度目の大規模システム障害

比較的に新しい年代なので、覚えている人も多いのではないでしょうか?

東日本大震災が発生して、3月15日から募金を集め始めた途端にシステム障害になった事件です。

募金口座だけでなく、ATM停止など一般ユーザも被害を受ける障害にユーザは大混乱。

 

その様子が以下の通りです。

三月は年度末ですので、その影響はとてつもなかったです。

  • ATMの利用停止
  • 未送信仕向為替が16万件
  • 為替処理が大幅遅延
  • 取引明細の一部欠落
  • 口座振替の処理漏れ

などがあり、口座の残高と振込額が一致しないという事態も多数ありました。

口座残高が合わないって怖くないですか?しかも年度末に。

 

そんな、みずほ銀行の大規模障害の詳しい情報を知りたいひとはこちらから!

>>https://www.mizuhobank.co.jp/release/bk/2011/pdf/news110520_3.pdf

障害が起きた背景

障害が起きた原因は、「人的ミス」だと言われています。

人的ミスの理由として説明されたのは「振込処理の上限件数を設定していなかった」とのことでした。

 

募金などで大量に振込が発生する時は、振込処理の上限件数の設定値を上げるというオペレーションが必要だったのです。

振込処理の上限件数の設定値が上げられていなかったため、「人的ミス」となったようです。

 

残りふたつの3大メガバンクである「三菱UFJ」「三井住友」では、大規模な遅延やATMの突発停止などが起きませんでした。

 

システムの内部調査の結果、

  • みずほ銀行」と「三菱UFJ」、「三井住友」のシステム構成が異なっていたため、みずほ銀行だけ大規模障害を発生させてしまった。

という結論になりました。

 

つまり人的ミスもあったが、「実際にはシステムの作りかたが悪いよね?」となってしまい、みずほ銀行には、さらにシステム開発を早急に進める必要が出てきました。

その後

大規模障害を引き起こしたみずほ銀行は、システム全体を総点検します。そして障害が発生した箇所以外の部分も、システム改修をすることになりました。

 

ここから「みずほのデスマーチ」が始まるのです。

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

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次請け会社まであるとの噂もあります。

中抜きされまくって最後の作業者にたどり着くころには、新卒の初任給以下となっていることもあったそうです。

 

そんな安い金でたくさん働かないといけないんですから、デスマーチになるわけですよね。

2014年 システム開発の完了を延期

サクラダファミリア

2014年にみずほ銀行は、システム開発の完了が遅れることを発表しました。

当初、2016年の3月と言っていたところ、9ヶ月遅延すると宣言し、システムエンジニア界隈はざわざわ...

 

この頃から、みずほのシステムは”サクラダファミリア”と言われるようになりました!(もう少し前から言われていたかもしれませんが。)

2016年 伝説のPM募集

PMとはプロジェクトマネージャの略で、プロジェクトを統括する役目の人です。

遅延を発表していたプロジェクトがPM募集しているとのことだったので、当然世間は「ざわざわ」していました。

エンジニアがざわざわする

フリーランスの募集サイトで見つかった、おそらくみずほ銀行のシステム開発だと思われる求人です。

  • 国内銀行勘定系システム再構築プロジェクト全体PM募集
  • 大手ベンダーをプロジェクトマネージャとしてのベンダーに適切な指示をし成功に導いてきた実績
  • 統制がとれていない現状から、マネジメントの基盤作りプロジェクトに浸透されるためタフなメンタルが必要
  • 単価:月に、~130万円程度

参考文献:https://developers.srad.jp/story/15/01/16/0353222/

 

「統括していた人」がなんらかの理由で、いなくなったことが考えられます。

こんな大規模システムで統括する人がいないのは、パイロットの居ない飛行機と一緒ですよね。

そうです。墜落するってことです。

2016年の年末 二度目の開発完了延期を発表

2016年の年末 二度目の開発完了延期を発表

一度目の開発完了延期は、当初2016年の春に開発完了だったものが、9ヶ月延びて2016年の12月に延びたものでした。

しかし、またもみずほ銀行はやってしまうのです。

 

二度目の延期は、2016年の12月完了予定から、さらに数ヶ月遅れることを発表しました。

この時の世間の反応は、「もう完成しないんじゃないか」という心配の声でした。

2017年 開発完了と移行計画を策定

2017年 開発完了と移行計画を策定

二度の遅延を経て、みずほ銀行の勘定系システムは完成しました。

 

「完成したシステム」と「現行で動いているシステム」を入れ替える必要が出てきました。

超大規模なシステムのため、システム切り替えの期間も長くする必要があります。

 

そのため、以下のようなスケジュールとなりました。

  • 2017年から2019年の2月にかけて、みずほ銀行のシステム移行
  • 2019年2月から7月でみずほ信託銀行のシステム移行

 

約2年にも及ぶシステム移行のスケジュールは、史上初の出来事だと思います。

この約2年間で毎月のようにシステムが止まっていたのは、「超大型システムの移行」が原因だったというわけです。

 

「毎月みずほ銀行が止まるから使えない」と言っていた人も、大変さが伝わったでしょうか?
(だからと言って、止まるのはかわいそうでしたけど。)

僕は三井住友なので、影響はありませんでした。

2019年7月 システム移行完了

2019年7月 みずほ銀行のシステム移行完了

無事、2019年7月にシステム移行が完了しました。

これでみずほのシステム刷新が、全て終わったことになりますね。

 

2012年から始まった、みずほ銀行のシステムの刷新。

一説には、システム開発までに、20万人月かかったと言われています。(1人が1ヶ月働くと、1人月とカウントされる)

開発のピーク時には、7000人〜8000人が携わったと言われてもいますね。

 

それだけ人とお金がかかったみずほ銀行のシステムは、歴史に残るシステム開発を乗り越えたと言えるでしょう。

みずほ銀行の現在は?

みずほ銀行の現在は?

2019年7月に移行が完了したみずほ銀行のシステムですが、今はどうなのでしょうか?

少しツイッターを探したので、それを下に貼りますね。

ざわざわ

これからもみずほ銀行を使う人は、気をつけてくださいね!

というわけで簡単に当記事をまとめます!

みずほ銀行のシステム開発のまとめ
    • 大規模障害を2回発生させる
    • 合併が内面的にうまくいかずデスマーチ化
    • 2019年7月にシステム移行が完全に終了!

みずほ銀行のシステム構築のような、デスマーチ案件に配属されたら...

IT業界の闇デスマーチプロジェクトに配属されたら

デスマーチはIT業界の中で、結構多発しますね。

残念ながらみずほ銀行のシステムに携わったひとで、自ら命を絶ってしまった人もいます。

 

正直金融系なんて、ほぼデスマーチですよ。なぜかって?

  • テストがバカみたいに厳しい
  • 企業体制が古くて、稟議に時間がかかる
  • 金がもらえるからいろんな企業が参画する

しかも言語はCOBOL。。。他のプロジェクトじゃ使えない化石言語です。

 

じゃあ、もし金融系のプロジェクト、ならびにデスマーチに配属されたらどうしたらいいのでしょうか?

答えは簡単で、いますぐ辞めて違うところ行こう!です!

デスマーチプロジェクトでの対策を以下の記事にまとめたので、命を守るために一読を!(デスマーチに耐える方法も一部載せています!)

 

\やばいデスマーチはいますぐ逃げよう!/

 

あわせて読みたい!

>>【退職代行の体験談】EXITを利用して入社9日の会社を辞めた時の流れ!【失敗?】

>>【超厳選】利用者が選んだ!本当に信頼できる、おすすめの退職代行業者ランキングTOP3選【会社を辞める時が来た】

スポンサーリンク

Twitterでフォローしよう

おすすめの記事