見出し画像

みずほ銀行のシステム障害

yunyun

これについては、日経クロステックの記事

https://xtech.nikkei.com/atcl/nxt/column/18/00565/00033/

がわかりやすくてよかった。本も出てるらしいから今度買ってみようと思う。

みずほ銀行システム統合、苦闘の19年史

個人的に「これは不味かったんだろうな」と思ったのは以下。

・インターディベロップデザイナーというツールでソースコードを自動生成した
・ソースコードはCOBOL
・テストケースも自動生成した
・「サービス志向アーキテクチャ」なる設計でシステムを細分化したのはいいが、各部品はOSも開発会社も異なるバラバラ設計
・コスト削減を意識しすぎた
・「1日当たりの更新件数が64万2969件を超えると、それ以上は更新できなくなる」ようなつまらない制限があることも問題だし、それを把握していなかったのは致命的

自動生成したコードは誰が理解する？

みずほ銀行のシステムの一部は、インターディベロップデザイナー（富士通株式会社）というソフトで自動生成しているらしい。

https://pr.fujitsu.com/jp/news/2014/08/28-1.html

これは、仕様と説明を日本語で書くとプログラムのソースコードを自動生成してくれ、さらにテスト用のデータも生成してくれるというもの。夢みたいな話だ。でも、今回の件においてはあまりうまくいっていないことは明白。まず、ソースコードがCOBOL。このソフトは、JAVAなどにも対応しているはずなのに。はっきり言って僕はCOBOLが嫌いだ。一般的に、COBOLは好かれる奴じゃない。可読性も良くないし、文法にしがらみが多すぎる印象なのだ。銀行系は昔からCOBOLらしいが、もういい加減変えれば良かったのに、と思う。

そして一番の問題。自動生成したソースコードは、生成された時点でだれも理解できていない。仕様書が曖昧で、勘違いしたソースコードが生成されているかもしれないし、質も良くないかもしれない。生成後にかならずチェックする必要がある。これを、多くのプログラマに嫌われているCOBOLでやるのだ。プログラマからすればこれはいじめである。そして、テストはソースコードを理解したうえで作られるべきであり、自動とはいえプログラマの仕事は大変だ。

テストは単体では楽だけど巨大システムでは大変

プログラムのテストで言うと、単体テストはそれほど重要でもないし大変でもない。例えば、僕が描いているビットマップファイルに円を描き込む関数はこんな感じ（あくまで例。これでやるとドットが飛ぶので。）。

/*
*動作 :指定色で円を描く
*      色はBMPCOLOR *bmpcolorで指定する
*引数1:BmpImage *bmpimage
*引数2:円の中心 x座標。左下から0起算
*引数3:円の中心 y座標。左下から0起算
*引数4:半径 r
*引数5:色データ
*返値 :問題なければ1を返す。エラーは0を返す。
*問題 :Windows用のビットマップ専用である
*/
int BmpImage_circle(BmpImage *bmpimage, int x, int y, int r, BMPCOLOR *bmpcolor){
	
	int x1, y1;
	double tmp;
	
	if( bmpimage==NULL || bmpcolor==NULL ) return 0;
	if( x<0 || y<0 || r<0 ) return 0;
	
	for(x1=0;x1<bmpimage->biWidth;x1++){
		tmp = sqrt( r*r - ((x1-x)*(x1-y)) );
		y1 = tmp + y;
		BmpImage_pset(bmpimage, x1,  y1, bmpcolor);
		y1 = y - tmp;
		BmpImage_pset(bmpimage, x1,  y1, bmpcolor);
	}
	
	return 1;
}

この処理は、主に座標指定のミスが問題になるので、関数先頭で異常値は最初から弾く。こうすることでテストで負数の座標などが与えられれば即わかるわけだ。さらに、各変数の性質をコメントに書いておくとより良い。例えば、
引数2:円の中心 x座標。左下から0起算
の記述により、1が最小値ではないことが明示されるし、幾何学的性質もわかる。だけど、テストはこれだけじゃダメだ。実は、このコードは座標に21億4748万3648以上を指定すると、意図に反して処理を行わないというバグ？がある。これがバグなのか、仕様なのかは呼び出し元次第なので、そこを「わかった上で」テストする必要がある。

こういうテストは、プログラムをわかった上でやらないとできないのだ。巨大なシステムで、しかも部品が大量にある場合、実際には発生しうる業務の組み合わせを大量に試す必要があるけど、このテストは慎重に作られなければならない。

Screenshot 2021-08-21 at 16-41-11 使用言語は？削減コストの総額は？クイズ形式でみずほシステム統合の謎に迫る！～バーチャル記者黒須もあ（β）が動画で解説

明らかに、みずほ銀行はこの点を軽視している（スクショはhttps://xtech.nikkei.com/atcl/nxt/column/18/00565/00033/より）。

コスト（人件費）の削り方

引用元記事

https://xtech.nikkei.com/atcl/nxt/column/18/00565/00033/

によると、当初は720億円のコスト削減が期待されており、

Screenshot 2021-08-21 at 16-39-35 使用言語は？削減コストの総額は？クイズ形式でみずほシステム統合の謎に迫る！～バーチャル記者黒須もあ（β）が動画で解説

うち、保守・メンテナンス費用が500億円を占めているとみずほ銀行は認識していたようだ。つまり、単純に言えば500億円分のプログラマやSEなどを解雇できたってことだ。

これはつまり、システムを理解している人も、いざというときに改修できる人も500億円分いなくなってしまったということ。上層部はどれだけ給料をもらっているか知らないけど、どれだけ現場のシステム担当者を舐めてたんだろうと思う。

表面的なテストだけ通った脆弱なシステムを、銀行上層部は満足げに眺めていたんだろうか。それとも、システム自体見ていないのか。いずれにしても、技術者軽視のシステムだったのは間違いないだろうと思う。さぞや満足だろう。高級をとる技術者を解雇できたわけだ。自分たちの給料は増えたのか、ちょっと気になるところだが表には出まい。

それにしても、上層部が無能で現場を引っ掻き回して優秀な人間を解雇した上で肝心な仕事もふっとんだ事案があったような気がするけど、何オリンピックだったけ・・・？

いいなと思ったら応援しよう！