プロジェクトオーガナイザの吉田聖書です。
今回は、去る2月28日に発生した
みずほ銀行のシステム障害を取り上げます。
とは言っても、私自身は
みずほ銀行のシステム構築に
関わったことはありませんので、
経験上考え得るいくつかの可能性から
考察してみたいと思います。
みずほ銀行は数年前に
メインのシステムを全面刷新しましたが、
その時は、まとめて移行するのではなく
何回かに分けて少しずつ移行していって、
大きなトラブルなく移行が完了しました。
2002年の最初の統合の時は、
システム全体を一遍に移行して
大トラブルになったので
きっとその反省を踏まえたのでしょう。
慎重にやった成果が出たと感心していた
その矢先にこのトラブルです。
やっぱりという思いもありながら
残念な気持ちにもなりました。
今回は報道を見る限りでは
大きなトラブルが3つ重なった
不幸な事故だと見えています。
1つはトランザクション
つまり業務取引の件数が
想定している処理能力を超えてたために
システム停止してしまったということ。
2つ目はそのシステム停止に引きずられ、
ATMがキャッシュカードや通帳を
飲み込んでしまったということ。
3つ目はATMの不具合に際して、
顧客対応が後手に回ったということです。
1つ目の事故は、
想定業務量という性能要求のミス
だと最初は考えたのですが、
どうも、月末にやらなくてもいい
口座データの移行処理を
わざわざ業務量の多い月末に
計画したということのようです。
これはさすがにエンジニアのせいではない
のではないかと思います。
2番目の事故に至っては、
システムに障害が発生した場合に
一部の取引を絞るという
フォールトトレラントな設計によって
一部のATMを停止してしまったようです。
縮退運転する発想自体は問題ないものの、
不正防止のためという理由をつけて
処理中だったキャッシュカードや通帳を
飲み込んだままにする
という仕様だったようです。
これは業務設計ミスでしょうか。
サービスレベル要求のミス
という感じもします。
3番目の事故は、
勘定系システムの問題ではなく
完全に業務というかサービスの問題で、
こういうサービスレベルだということが
事前に顧客に知らされていなかったのは
残念だなと思いました。
顧客は必要があるからATMに行くわけで、
中には急を要する人もいたでしょう。
もし休日の顧客対応がこのレベルだと
事前に知らされていたのであれば
休日にATMを利用すること自体が
リスクですから、それを避けるために
平日のうちに用事を済ませておくことも
できたかもしれません。
システムトラブルというと、
作った人に目が行きがちですが、
システムを構築したエンジニアは
悪くないと思います。
エンジニアとしては
上から仕様が下りてきたら
その通りに作らざるを得ない
という側面があるので、
責められないだろうと思うのです。
いやいや、
エンジニアであっても
仕様のリスクを察知したり
欠陥を指摘したり、
逆に提案すべきじゃないの？
という声もあるかもしれませんが、
小規模なシステムならともかく
これだけ大規模なシステムとなると
商流も深くなっているでしょうから、
簡単に提案なんてできないし
提案が届く保証もないのです。
銀行側には業務設計あるいは
サービスの企画の問題として
改善をしていって欲しいと
顧客の一人として願っています。
※ この記事は、先日公開した以下の音声コンテンツを基に編集したものです。
関連記事
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。