http://www.asyura2.com/09/it11/msg/644.html
| Tweet |
株式日記と経済展望
http://www5.plala.or.jp/kabusiki/kabu242.html
http://blog.goo.ne.jp/2005tora/
--------------------------------------------------------------------------------
みずほ銀のシステム担当役員が障害発生を知るまで、最初のトラブル
から17時間かかった。再発する恐れはまだ残ると、本誌は断言する。
2011年6月21日 火曜日
システムを熟知する要員がおらず、みずほ銀行のトラブル処理は
混乱に混乱を重ねて３０もの不手際を重ねた。東京電力の原発も同じなのだ。
◆第1回 重なった30の不手際 ６月１３日 ITPRO
http://itpro.nikkeibp.co.jp/article/COLUMN/20110607/361134/?k2
東日本大震災から3日後の2011年3月14日。この日の午前に最初のトラブルは発生した。テレビ局が東日本大震災の義援金を番組などで呼びかけたところ、みずほ銀行東京中央支店のテレビ局の義援金口座（以下、口座a）に、振り込みが殺到した。
午前10時16分、振り込みによって生じた「取引明細」の件数が上限値を超え、口座aに対する「預金・取引内容照会」ができなくなった。取引明細は通帳の記帳に使う。
みずほ銀は口座aを、格納できる取引明細の上限値が小さい「個人・通帳口」として間違って設定していた（表-1）。
みずほ銀は口座の種類を二つの属性の組み合わせによって区別している。一つは「個人」か「法人」か。もう一つは、取引明細を通帳に記帳する「通帳口」か、記帳しない「リーフ口（ぐち）」かである。
これら二つの属性によって、格納できる取引明細の上限値が変わる。通常、義援金口座のような大量振り込みが予想される口座は、リーフ口として登録する。リーフ口の場合、取引明細が上限値を超えることはない。取引明細を保存しないからだ。
みずほ銀が口座aの開設手続きを実施したのは2005年9月のことである。この際、みずほ銀は口座aを「個人・リーフ口」にしていた。ところが2007年12月、テレビ局から「振り込み明細を通帳で把握したい」との要望を受け、「個人・通帳口」に変更した。
夜間バッチでも上限オーバー
午後3時以降に受け付けた振り込み依頼は、夜間バッチで入金処理する。午後10時7分、口座aの夜間バッチが異常終了した。
実は夜間バッチでも、一つの口座につき何件まで処理できるかを示す上限値の設定があった。口座aは、振り込み処理の前に明細を退避する準備処理で、この上限値をオーバーした。このとき、現場にいたシステム担当者は、このような上限値が勘定系システム「STEPS」に存在することを知らなかった（表-2）。
担当者は異常終了時のエラーメッセージなどから上限値の存在を突きとめ、上限値を拡大した。その後バッチ処理を再実行したが、また異常終了した。先の異常終了によって、一部の振り込みデータが欠落していた（表-3）からだ。
再実行には欠落データの復元が必要だ。結果的に、この復元に8時間を費やした（表-4）。復元作業の過程で、翌朝のオンライン起動に向けたタイムリミットの午前6時までに夜間バッチが完了しないのは確実になった。
みずほ銀のシステム担当役員である萩原忠幸常務執行役員は、15日午前3時30分頃になって初めて、IT・システム統括部から障害の報告を受けた。担当役員が障害発生を知るまで、最初のトラブルから17時間かかった（表-5）。（後略）
（私のコメント）
３・１１の東日本大震災は、日本の大企業が抱えている問題点を幾つも浮かび上がらせている。福島原発の大事故を防げなったのは人災的なものであり、東京電力は、そのような場面を想定した防災訓練も行なっていなかった。同じくみずほ銀行は、システムトラブルを引き起こして手作業で窓口業務を行なうようになり、頭取の辞任の大トラブルになってしまった。
東電の役員の中に原子力発電の専門家がおらず、みずほ銀行の役員の中にも情報システムの専門家がいなかったことが、トラブルを大きくしてしまった原因の一つにあるだろう。そして現場とトップとの距離が非常に大きくて、経営幹部は起きたトラブルに対して適切な対策をとることが出来ない。これらは災害が起きてからでは遅いのであって、システムを熟知した者によって指揮が取られなければ防げないだろう。
Tproの記事を読んでも、原因の始まりは『テレビ局から「振り込み明細を通帳で把握したい」との要望を受け、「個人・通帳口」に変更した。』事であり、そのことで上限値がオーバーしてしまった。そして現場では『現場にいたシステム担当者は、このような上限値が勘定系システム「STEPS」に存在することを知らなかった』『担当者は異常終了時のエラーメッセージなどから上限値の存在を突きとめ、上限値を拡大した。その後バッチ処理を再実行したが、また異常終了した。』事が混乱を拡大していく。
システムを現場担当者が熟知していれば、変更操作をせずにシステムを止めて混乱を最小限にすることが出来ただろう。最初からシステム設計が顧客の要望に応えられないのにリーフ口から通帳口に変更した事がそもそもの始まりだ。最初から通帳口では直ぐに上限値に達することは予想が出来たことだ。しかし現場は上限値のことを知らなかった。
考えてみれば、テレビ局の口座を通帳で見たいと言う注文が無茶なのであり、テレビで義援金を呼びかければ数十万件の振込みが殺到する。それを通帳で記帳することなど最初から想定していなかったのだろう。つまりシステム設計の段階からリーフ口から通帳口に設定の変更は出来るよう設計されていなかった。
問題の根源はこのような巨大システムの管理体制が杜撰なことであり、「みずほフィナンシャルグループなどによるシステムに関する内部・外部監査が機能していなかった」「みずほ銀はシステム監査において、「システム運用管理体制」のリスクを最高レベルとしていないなど、リスクの大きさを正しく把握することができていなかった。」と言う指摘は、電力会社の原子力発電のリスクの甘さも共通している。
現場の担当者はエラーのメッセージを読み誤り同じ間違いを繰り返した。更には設定変更などの誤操作を繰り返して対策を誤った。このようにコンピューター操作はシステム全体を熟知した者でないと、一旦トラブルと誤操作が回復を不可能にしてしまう。「TARGETやSTEPSの改良といったシステム上の手当が遅れたのは、システムの基本構造や処理方式などを熟知するシステム要員が決定的に不足していたのと、銀行実務を知る要員が減少していたためである。」
東京電力の福島原発事故にしても、全停電状態になればどのようなことが起きるか分かっている者がいれば、８時間以内に冷却水を入れなければメルトダウンを起こす事をに手を打っていれば大事故にならずに済んだのでしょうが、現場も東電本社も適切な手が打てなかった。社長や会長がそのことを知っていれば他に手はなかったはずだ。
私自身も外資系保険会社のコンピュータセンターに勤務していたことがありましたが、現場のオペレーターが出来るのは日常業務だけであり、トラぶったらおしまいだ。技術者もシステム全体を知らず根本に原因があれば小手先では解決は不可能だ。「3月の障害では経営陣のリーダーシップの欠如が被害を拡大させたからだ。 」と記事にもありますが、東電の福島原発でも同じことだ。
問題の根本解決は最高経営幹部自体が根本原因が分かる専門家である必要があり、自前で養成しても上手くは行かないだろう。外部から専門家を呼んで根本から再構築して立て直さないと同じ問題が起きるだろう。それは人事に問題があるのであり、年功序列人事では外部から専門家をスカウトすることは難しい。
日本の人事体系は年功序列であり、入社時の学歴で出世コースとその他に分けられる。出世コースに乗ると様々な部門を歴任してゼネラリストになりますが、スペシャリストは作らないようにしている。スペシャリストは専門家であり外部でも通用するから、会社側は転職されることを恐れるから社内で専門家を作らないような人事システムになっている。
メーカーなどでは最初から技術者として専門家を採用しますが、経営幹部になる事は極めて少なく、一流大企業で技術者が社長になる事は少なくなっている。調べると３割程度が理系出身者であり文系の社長が圧倒的に多い。理系の技術者は視野が狭く専門分野に閉じこもるからなのだろうか。「みずほ」にしてもITの事が分かる人材がいない。東電も原子力の専門家が経営陣にいない。マネジメントも分かり技術も分かる人材は非常に少ない。
欧米のようにマネジメントや技術の専門家を外部からスカウト出来れば新しい状況に対応が出来るのでしょうが、年功序列の大企業ではマネジメントの専門家も技術の専門家も育たない。「みずほ」のトラブルも福島原発災害も日本的なシステム障害でもあるのだ。
この記事を読んだ人はこんな記事も読んでいます（表示まで20秒程度時間がかかります。）
スパムメールの中から見つけ出すためにメールのタイトルには必ず「阿修羅さんへ」と記述してください。すべてのページの引用、転載、リンクを許可します。確認メールは不要です。引用元リンクを表示してください。
