ITエンジニアのキャリアに本気で向き合うメディア
ITエンジニアのキャリアに本気で向き合うメディア
目次
■キャリアとスキルアップ
2022.10.06 2024.06.27 約4分
2021年2月から2022年2月までの間に合計11回発生したみずほ銀行のシステム障害は、様々な「誤解」が流布しています。 みずほ銀行のシステム障害を追いかけ続けてきた「日経コンピュータ」の記者が、システム障害の真相やそこから得られた教訓について解説します。我々ITエンジニアが、より良いシステムを作る為に、みずほ銀行のシステム障害から何を学ぶべきなのでしょうか。
中田 敦と申します。14年ほど日経コンピュータに所属しており、うち4年間をシリコンバレー支局で過ごしました。普段は、海外ネタの方を追いかけている記者です。その記者がなぜ、みずほ銀行の本を書いたかについては後ほどご説明しますね。2022年出版の「ポストモーテム みずほ銀行システム障害 事後検証報告」は、2020年出版の「みずほ銀行システム統合、苦闘の19年史」の続編だと思われがちですが、我々日経コンピュータは、みずほ銀行が大きなシステム障害を起こすたびに書籍を出版しているので、実は4冊目になります。
 |
 |
 |
 |
私自身は海外技術、とくにGoogleウォッチャーとしてGoogleの量子コンピュータの記事を書いていたような人間です。2011年3月に、みずほ銀行のメイン記者である副編集長が国外出張中であったことをきっかけに、みずほ銀行システム障害との付き合いがはじまりました。私のようなGoogleウォッチャーが執筆したことで良かった点などもありますので、のちほど紹介いたします。
ITエンジニアではない一般の方だと「ATMが壊れたんでしょ？」みたいな感想を持つ方がいらっしゃいます。これは全く誤解です。ATMが壊れたのではなく、ATMが繋がってる先の勘定系システムの「トラブル」が発生し、様々な影響が出たというのが真相になります。
およそ12ヶ月間の期間に11回のシステム障害が発生したという点が特徴的です。トラブルを一覧にしたものは書籍で紹介しているので、よろしければご覧ください。本当に大きな障害から、非常によくある軽微なハードウェアのトラブルまでいろいろとありました。
みずほ銀行は発足以来、およそ20年間に4種類の大きなトラブルを経験します。
システム統合の際、無茶なスケジュールを組んだ結果、テストが不十分だったことが原因でATMや口座振替、振込みができないというトラブルが起きました。当時は他のメガバンクでもこうした銀行統合に関するトラブルは起きていました。
2011年3月の東日本大震災発生直後に義援金の振り込みが殺到した結果、当時の勘定系システムがダウンし、ATM障害が発生しました。当時の勘定系システムは1988年に稼働を開始したもので、かなり老朽化していました。1988年に想定しなかった「携帯電話を使った振り込み」が大量に発生した結果、システム上限がオーバーしてしまったものです。
1999年にみずほ銀行の前身である第一勧業銀行・富士銀行・日本興業銀行の旧3行が合併を発表した時点で勘定系システムの老朽化が指摘されていたので、2003年には刷新する予定でいました。しかし、結局刷新に20年近くもかかってしまったというものです。
このように過去のシステムトラブルは背景や原因がはっきりしており、今回の連続システム障害とは全く別物です。今回のトラブルは発生原因が非常にわかりづらい点が特徴的だと考えています。2021年に金融庁が実施したみずほ銀行に対する業務改善命令では、システムに関するリスクや専門性の軽視、IT現場の実態軽視、みずほ銀行の体制の問題を指摘しているのですが、非常に抽象的です。我々は過去のトラブルと「同じ過ち」を犯したのではなく、別の原因なのではないかと認識しています。
MINORI って旧3行のシステムをツギハギしたシステムでしょ？という誤解がありますが、みずほ銀行は、MINORI を作る際に要件定義から完全にやり直しています。ソースコード自体も旧システムから全く引き継いでいないのです。
みずほ銀行は2004年までに、片寄せによるシステム統合を終わらせています。
2004年以降、改めてシステムを全面刷新する際に、みずほ銀行・みずほコーポレート銀行・みずほ信託銀行の3行のシステム統合が必要でしたが、ここの片寄せは事情があり実施できませんでした。
まず、第一勧業銀行由来のシステム（STEPS）が老朽化したことで、2011年に大規模なシステム障害が発生したわけですから、STEPSは全面刷新するしかなく、片寄せができなかったんですね。
では、みずほコーポレート銀行のシステム（C-base）に片寄せすれば良いのでは？という話もありますが、C-base は大企業向けの取引に特化したシステムだったので、中小企業や個人を対象とした口座数が非常に多いみずほ銀行の業務を片寄せするのは難しいし、できなかったわけです。
さらに、みずほ信託銀行のシステムでは信託業務専用なので、メガバンクである みずほ銀行の業務をそちらに片寄せすることは不可能です。
つまり MINORI における片寄せは、非現実的であり、MINORI の片寄せが直接的なシステム障害の要因であると結びつけることはできないでしょう。
MINORI の設計は2004年に遡りますが、時期を考えるとやむを得ない選択肢だったのかなと思います。2000年代は、さまざまなITベンダーや銀行が、それまでメインフレームで稼動していた勘定系システムのオープン化を試みていましたが、尽く挫折していました。結果的にメガバンクのオープン化はほとんど進みませんでしたので、みずほがメインフレームを選択したのは間違いではなかったでしょう。
COBOLという言語であるから、何か問題が起きるというわけではないんですよね。プログラミング言語に罪はなく、ちゃんと作ればどの言語でも作れます。COBOLで問題になっているのは、古さゆえにドキュメントがなく、中身がブラックボックスになっていることや、メンテナンスが難しい点です。ただ、今回のケースがCOBOLが原因であるというのは、ちょっと無理筋なところがあります。
正直批判としては妥当です。実際マルチベンダーで開発されたものなので、誤解とは言いがたいものがあります。とはいえ、他のメガバンクでもマルチベンダーは当たり前なんです。
メガバンクの勘定系システム開発において、基本は内製です。コーディングそのものはやらないにしても、要件定義や設計は銀行本体や情報システム子会社が担当するのが当たり前です。
マルチベンダーだから、ベンダーが悪かったから、が直接的な原因というのは厳しいでしょう。
むしろ、内製をしている銀行本体や情報システム子会社のマネジメント力、ベンダーマネジメントや開発力に起因するのではないかと考えています。
ただし、勘定系のコアの部分でミドルウェアやデータベース管理システムまでバラバラなのは、みずほ銀行だけです。このあたりが開発や運用を難しくした面は、否めないでしょう。
表に出ない話題ですが、みずほ銀行は MINORI で、SOA（サービス指向アーキテクチャ）と自称するアーキテクチャを導入し、サブシステムを疎結合にすることで耐障害性を高めようとしました。しかし、それ自体がシステムの複雑化を招き、システム障害を起こしたのではないかという指摘があります。ただこれについては、金融庁が半年以上も調査した結果、証拠が見付かっていません。
正直、根本原因を突き詰めることが妥当なのかは疑問があります。とはいえ、原因は何かをざっくり言えば「運用軽視」であることは、間違いないでしょう。最も顧客被害の大きかった2021年2月の障害は、5000件近くの通帳やカードがATMに取り込まれてしまい、利用者がATMの前で立ち往生したトラブルですが、この背景にも非力なシステム監視の仕組みがあったと考えています。圧倒的なオブザーバビリティ不足が、システム障害の長期化やシステム障害を繰り返す原因になってるといえるでしょう。
みずほ銀行は、2000年頃からシステム刷新やシステム統合、つまり20年近くずっと開発をしていたので、運用体制を整える力を蓄えることができず、また十分な投資をしてこなかったのです。本当にやらかした悪いやつがいるのでは？という視点もありますが、我々は犯人探しをするよりも「教訓」を得てより良いシステムを作ることが重要ではないかと考えています。書籍が「ポストモーテム」というタイトルになった所以でもあります。
たしかにそれが原因である部分は大いにありますし、金融庁も指摘しています。しかし、企業文化や経営陣を変えれば、システム障害は止まるのでしょうか。システム障害には必ず技術的な原因があります。心を入れ替えるだけでは変わりません。
とはいえ、企業文化や経営陣の意識が変わらなければ技術的な問題の克服は不可能という側面はあり、そこは否定しません。むしろ日経コンピュータは長らく、みずほ銀行のシステム障害に関して、経営陣に経営を変えるべきであると指摘しつづけていた歴史があります。一方で、MINORIの開発において当時の経営陣はかなり頑張ってシステムを勉強していた節があることも伝えておきたい部分です。
組織面の改善は不可欠です。「こんな複雑なシステムは運用できない」「設計を変えてくれ」といえる心理的安全性の高い体制をつくれるかは課題でしょう。
ポストモーテムの結論としては「みずほ銀行は Google に学べ」というチャレンジングなテーマ設定をさせていただきました。Googleウォッチャーである私から見て、Google は AIやビッグデータだけでなく、システム運用や安定稼働の部分でIT業界全体に与える影響が非常に大きいという認識です。
その中心にあるのが、クラウドネイティブの動きです。
Google が生み出した Kubernetes がシステム構築運用の中心に来ているので、 Kubernetes を軸に開発や運用論そのものが Google 主導になっているのです。運用の現代化 = Googleのマネをしましょうということになり、その象徴がSREです。他のメガバンクでも一様にSREを学びはじめています。みずほが他メガバンクと異なる点、欠けている点は、オブザーバビリティであり、ポストモーテムに代表される「失敗に学ぶ文化」だと考えています。
実は、みずほ銀行はそこまで酷くないというか、もっとヤバイ組織が山ほどあるのが日本の真の恐怖なんじゃないかと思っています。
我々が2020年の書籍を出版したときに、ある大きな伝統的な組織の情報システム部門の方からコンタクトがありました。その方が我々の書籍に対し「これゲラを見せてるんじゃないの？」と、驚かれたんですね。ゲラというのは、出版前にみずほ銀行の方に内容チェックをしてもらうということなのですが、我々は一切そういったことはやっておらず、ジャーナリズムに則って記事を出してるのですけども。
その方曰く「みずほの役員や社長がシステムに詳しすぎる。信じられない」と。
みずほ銀行は、さまざまなシステム障害を起こし大変叩かれていますが、それよりもひどい状況にある組織というのは、日本の中に山ほどあるんですよね。
ぜひ、みずほ銀行の今回のシステム障害を教訓にして、日本全体でより良いシステムを作っていくために考えていきたいというのが我々の一番大きなメッセージです。
運用担当者、運用担当部門が、いわゆるオペレーターだと思われていたんです。要は、運用担当は誰かが決めた手順に従ってオペレーションをするだけであると、みずほ銀行が認識していたことが大きな問題だったわけです。
その状況を改善するために、まずは保守運用を開発からきちんと分離して、開発と同権限を持たせたうえで Dev と Ops を連携させていく順序になろうかと思うんですね。
では開発設計側で、運用設計どうしていたんだというところなんですけども、開発側も運用設計のノウハウをきちんと持っていなかったし、重視する姿勢が不足したというのは、みずほ銀行の中でも率直に反省の声として聞かれますね。
つまり、開発に必要なスキルセットや設計に必要なスキルセットと、安定稼働運用のために必要なスキルセットが違っていること、そして安定稼働や運用のためのスキルセットを身に付けなければいけないという発想そのものが設計側になかった。設計していれば運用もできるだろうという発想で、なんとなく設計していたのでしょう。
—決められた手順書はありながらも、システム障害に対する訓練なんかしなくても大丈夫だろうという意識があったのでしょうか。
訓練 = 手順が正しいかを確認する作業 だと思っている金融の方ってすごく多いんです。そもそも問題をあぶり出し、より良くしていくっていう発想がない。そこを変えるために経営側がコミットしていく必要があるでしょうね。
— Google の SRE の考え方では、開発段階で運用を意識したアーキテクチャ設計を選択することが重要だと理解しています。登壇の中にあった「運用軽視の改善策として、開発と運用を分離すること」と相反する部分があるため補足が欲しいです、ときていますね。
中田：DevOps のレベルに到底達していない場合、まず運用の立場を上げる必要があります。
実は、東京証券取引所が2005年に大きなシステム障害を起こして外部からCTO、CIOを招いたときに、まずおこなったのが開発と運用の分離でした。
運用を下に見ているような古いIT組織の場合には最も必要なことです。開発・運用どちらも大事で、かつ連携を深めていかなきゃいけないよねとなれば、DevOps のような方法を試していくと良いでしょう。
書籍でも、失敗から学んでいくというスタンスを取り入れて欲しいと書いているので、ぜひ実現して欲しいとは思いつつ、正直難しいだろうとは思っています。
想定していないことが当たり前に起こるVUCA時代において、PDCAサイクルをガッツリ回す企業経営の是非については、皆さんお考えがあるでしょう。私たちがDX文脈でも経験したように、対応できない企業は滅んでいくしかありませんからね。
これは金融庁や、みずほ銀行内のアンケート調査でも指摘されていることは間違いないですね。
—みずほ銀行に限らず、日本の伝統的な企業で心理的安全性が高い企業の方が少ないかも知れません。広い意味で心理的安全性を高めるためにどうすべきかも教えていただけますか？
まだまだ取材が足りていないので、今後ですね、SREを実践している企業などに取材をして、ぜひ知見を日経コンピュータ、日経クロステックで報道してまいりたいと思っております。「うちに取材に来い」という方をお待ちしています！
転職は思ったよりも、時間がかかる
年収800万円以上のハイキャリアでも、42%が転職に1年以上かかっています。
技術力が高いほど、転職先が限定される
スキルや志向が明確なほど、マッチするポジションは限定されます。
ハイキャリアでも、面接には落ちる
素晴らしいキャリアでも面接に落ちることは珍しくありません。メンタル対策や面接の振り返りをサポートします。
自分のペースで進めたいなら「スカウトをON」
エージェントに頼らずスカウトメールから直接応募も可能です。
Forkwellエージェントは、企業選びから面接対策まで、あなたの転職活動を徹底的にサポートします。「経験チャート」機能を利用すれば、たった3分であなたの経歴を作成できます。
日経クロステック／日経コンピュータ 副編集長
『日経Windowsプロ』『日経コンピュータ』などの記者やシリコンバレー支局長を経て、2019年4月から現職。 著書に『GE 巨人の復活』（日経BP）など
