現時点で原因未特定の状況で、月末までの報告はかなり厳しいねぇ…。末端エンジニア、一日が48時間くらいになっていそうな…。これがエンドレスエイトってやつか(違)。 /
— 間宮健太郎/土野魔魅@ぼちぼち旅行がしたいです (@mami_tuchino) August 23, 2021
みずほ銀行システム障害 一連のトラブルと合わせ処分へ 金融庁 | NHKニュース https://t.co/E37vWTQexh
人の不幸は蜜の味。。というわけではなく
みずほの障害を明日は我が身をとらえ
他社で起こっている障害からIT（社内SE/情シス）が学び活かそう
ということで、みずほ銀行の５回における障害を分析し自分なりの学びを整理してみました。（この記事を公開した直後にも残念ながら６度目の障害に見まわれています。現場SEファイト！）この記事を参考に、【自社の仕組みで類似する課題を事前に手を打つ】お役に立てればと思います。
みずほの障害から学んだ教訓の結論です。
・複雑化した組織・業務で出来上がるのは複雑化した仕組み
・利害関係者が多い場合は横ぐしの機能が必要
・そもそもの旧システムがなぜ横行しているのか議論が必要
・くさいものに蓋をするといつか爆発する
・ベンダーはやっぱり文章を書くことが仕事で課題は社内ＳＥが自ら解決するしかない
この結論に至った経緯と詳細を、以下の内容に沿って解説していきます。
みずほ銀行の５回の障害経緯
みずほ銀行の障害の構造
みずほ銀行の障害システムベンダー
みずほ銀行の障害の原因と打ち手
社内ＳＥ・情シスがみずほ銀行の障害から学ぶべき事
を整理しました。
みずほ銀行の障 みずほ銀行の５回の障害経緯
みずほ銀行では、２００２年以降７回、２０２１年に入り５回の障害が発生しています。まずは、この７回は顧客影響の発生する影響度MAXの障害であり、おそらく内部では、ここまでは至らないものの相当数の障害が発生し奮闘しているものと予想できます。
２４日追記：
引用元：https://www.47news.jp/6701003.html
みずほ銀行は23日、一部の現金自動預払機（ATM）が一時利用できなくなる障害が起きたと発表した。正午ごろから全国で最大130台が停止し、午後1時半ごろまでに復旧したが、うち8台で現金がのみ込まれる
２００２年のシステムリリース後の障害
これはよくある話ですね。大なり小なりシステム障害はリリースにはつきものです。ただし、リリース後にシステム障害が多発する原因は、一般的に
・システム構造の複雑さ＝管理できない
・テストの甘さ＝品質よりもスケジュール優先
→みずほの例はこれでは？
・想定の甘さ＝そもそも適切な有識者を巻き込み意見交換ができてない
→頭と組織がカチカチだと柔軟に人を巻き込み意見交換なんてできず、、、結局みんな関わりたくない責任取りたくない、、、となり有益なノウハウ・知見が共有されず穴だらけの仕組みに、、、
２０１１年の義援金の障害
これは、想定外のトランザクションが発生したものと思います。（想定外で片付けるのは個人的に腑におちませんが）現代では、クラウドを利用し無尽蔵とは言わないですが、スケールアップも可能です。スケーリングできない構成のそもそもの対応・検討が必要です。
２０２１年２月・３月ATMにカード・通帳を取り込む仕様
１５年以上前に海外留学していた時に、スウェーデン人の友達がATMにカード食べられた。。。といっていた話を思い出します。みずほのこの障害はただただ悲しくなります。理由は、ATMが世に出回ってから、おそらく類似する問い合わせ・指摘は歴史の中であったのではないでしょうか？仕様不備を内部で気づいた人も沢山いたのではないでしょうか。
そうなると課題は、完全にマネージメント・リスク管理です。
・そういった声が通らない風土？組織？
・風通しの悪い習慣？
・リスクマネージメントの観点から頻度と優先度の判断ミス
といった原因です。
大企業になればなるほど、抜本的な改革は難しいですが、だから何？という感じですね。
現場レベルでできることは、きちんと上司にエスカレする。エスカレしてその人がその上でエスカレしなければその人の責任です。とにかく、下の人は上の人（ポイントは、横でも下でもないですよ。なので飲み会とかで話しても効果なし）にエスカレーションすることです。できれば週次報告とかで文章に残すのも尚おすすめです。
万が一、エスカレしても動いてくれない上司を見つけた場合、部署移動（なかなかできないので転職の方が現実的）を視野にいれましょう。その人は、お客様やあなたを見て仕事をしていません。上司の顔色を見て仕事しています。
こういった文化の企業を一個人で変革するにはあまりにも人生の多くを失う気がします。。。
２０２１年８月 全店取引停止
この障害は以前とは比べ物にならないほど重要性があります。理由は、この事象が障害報告・打ち手の提示の後に起こっていることです。
６月にみずほ銀行はこれまでの障害の報告書と改善の対策を打ち出し、９月末まで体制の強化が完了すると発表しているからです。その人材に配置も、対外的に９月に完了報告とすると発表している場合、内情的には今時点では終わっているはずではないでしょうか。もちろん、その新しい人事でプロジェクトがスタートしていないかもしれませんが、組織変革と合わせ、優先度高のリスクの洗い出しと暫定対応は必須ではないでしょうか。（偉そうなことを言っていますが、王道のアプローチで私も過去に自分の作った仕組み・人の作った仕組みをこの王道のやり方で安定化させてきました。規模は４０００億なんて全然いかないですが）
なので、、、そうなると打ち手事態に課題があったのではと感じます。じっくり、原因分析と合わせて後ほど深堀しましょう。
みずほ銀行の障害に関連したシステム構造と担当ベンダー
みずほ銀行のシステム障害の深堀に入る前に障害に関連したシステム構成・ベンダーに関しても触れておきます。
みずほ銀行システム統合の歴史（三行合併の歴史）
・富士銀行
・第一勧業銀行
・日本興業銀行
統合し、みずほファイナンシャルグループとなりました。このビジネスの動きに合わせシステムも統合されました。
みずほ銀行のベンダー体制
それぞれの銀行が違うベンダーの仕組みによりシステム運用をしていました。
・富士銀行＝IBM
・第一勧業銀行＝富士通
・日本興業銀行 ＝日立
このバラバラの仕組みの構図も、どの企業買収での発生する構図と思います。しかし、みずほのユニークな点・他とは違う点は以下です。
みずほ銀行システム統合の特質すべき点
後ほどの障害分析で非常に重要な要素になるのでみずほ銀行のシステム開発の他と異なる点も解説します。
大手ベンダーが銀行システム開発を分担しあう体制は異例中の異例である。
なぜ異例なのか。特に大規模システム開発においては、システム開発時の責任を明確し、問題発生時の原因究明をスムーズに行うことが必要となる。
このため、「基幹システムは一社のベンダーがすべての責任を持って作り上げる」のが通例だ。こうした通例に反して、四行のベンダーが入り組むことになった。
なお、四社は「ITゼネコン」と呼ばれる元請けベンダーだが、これらの会社の下には二次請け、三次請けといった下請け企業が多数名を連ねている。
引用元：https://boxil.jp/beyond/a3316/?page=4
この時点で開発のコミニケーションの複雑さを感じます。同時に色濃く政治を感じます。
みずほ銀行システム統合の歴史
これをふまえシステム統合でどのように構図が変化したかを見ていきます。
ちなみに、先ほどご紹介した障害への歩みとしては以下です。
みずほ銀行のシステム構造・ベンダー構成
システムの話に戻ります。以下が新しい仕組みの構成とベンダーの役割の範囲です。
| システム名 | ハードウェア | ITインフラ開発ベンダー | アプリ開発ベンダー |
|---|---|---|---|
| 流動性預金 | IBM（メインフレーム） | IBM | 富士通 |
| 定期預金 | Linux（富士通・日立） | 富士通・日立 | 富士通 |
| 自行内接続 | Linux（富士通・日立） | 富士通・日立 | 富士通 |
| 他銀行接続 | Linux（富士通・日立） | 富士通・日立 | NTTデータ |
| 融資・外国為替 | Linux・UNIX（日立） | 日立 | 日立 |
| 信託 | Linux・UNIX（日立） | 日立 | IBM |
うまく落としどころを探った感は否めないですね。何を目的に分配したのか。。。臭いですね。
役割をもっとわかりやすく書くと、以下の３つです。
①IBMのメインフレームの上に
→富士通開発の流動性預金アプリ
②富士通・日立管轄のLINUXの上に
→富士通開発の定期預金 アプリ 、自行内接続 アプリ
→NTTデータ開発の他銀行接続アプリ
③日立のLINUXの上に
→日立開発の融資・外国為替アプリ
→IBM開発の信託アプリ
といった構成です。
＊ちなみにこの仕組み４０００億かかっているそうです。。。
みずほ銀行の障害の原因と打ち手
みずほ銀行の障害発生ポイントの洗い出し
上記情報を元に障害発生ポイントを赤字にします。
もっとわかりやすく書くと、
①IBMのメインフレームの上に
→富士通開発の流動性預金アプリ＊2011年障害義援金の支払い、３月ATMと推測
②富士通・日立管轄のLINUXの上に
→富士通開発の定期預金 アプリ 、自行内接続 アプリ
＊３月３日の障害
→NTTデータ開発の他銀行接続アプリ
＊3月12日の障害？
つまり、どのベンダーとか特定のハードアプリというよりも全体的に起きているとわかります。
言い換えると、特定の開発やソリューション、ハードウェアではない共通の要素が根本原因と考えるのが妥当です。
みずほ銀行の障害分析報告
みずほ銀行が２０２１年６月に提出した調査報告書は１６７ページにも及びます。
調査報告書はこちらからダウンロードできます。できますは、正直、何のための報告かが重要です。
障害を解消するため
信頼を回復するため
この２つかなと思います。(一般的に）
この１６７ページでは誰にも何も伝わりません。コンサルに根こそぎやられた感がものすごくします。
この報告をもとに、外部だけではなく、内部の人にも伝え行動を起こさせるツールとなるべきですが、、、、だれも１６７ページは理解できません。もし、内部でそのような資料があれば共有してほしいですね。
ちなみに、２月２８日ATM障害の一部抜粋です。P33です。
この章のタイトルは以下です。
INDEX FILEの容量オーバー
エラーハンドリングが適切でなかった
等々事象が記載されています。4000億の仕組みとは言え障害の様子は小さい仕組みと同じですね。
それらのシステム事象ををふまえた原因は以下と記載されています。
社内SEの経験からすると、事象に対する原因ではなありますが、これは根本原因ではありません。
この対応をしていると、後手後手にまわり社員が疲弊していく構図ができあがるのが王道です。。。
第３者委員会がまとめた報告書によると
と結論付けています。。。
いやいや、みずほの報告書ではシステムにも十分問題あるように聞こえますが、、、
システム障害はなぜ起きるのか？
わたしの上司がよく言っていたのは、
システムは人と人のはざまで起こる
システム障害は人が作る
でした。
今回の構図で行くと、
・過去の利害関係を捨てきれずプロジェクト体制を構築
・過去の仕組みを捨てきれず落としどころを探る感じのシステム構成
結果、
・複雑化するシステム開発
・増加する利害関係者
・反比例する責任感
となっているのではないでしょうか？
この結果を象徴するのが２０２１年５回目の障害のみずほ会見内容です。
社内ＳＥ・情シスがみずほ銀行の障害から学ぶべき事
自戒を兼ね、みずほ銀行のシステム障害から学び自社のシステム改善に生かせる事を整理しました。
・複雑化した組織・業務で出来上がるのは複雑化した仕組み
・利害関係者が多い場合は横ぐしの機能が必要
・そもそもの旧システムがなぜ横行しているのか正論の議論が必要
・くさいものに蓋をするといつか爆発する
・ベンダーはやっぱり文章を書くことが仕事で課題は社内ＳＥが解決するしかない
複雑化した組織・業務で出来上がるのは複雑化した仕組み
複雑化した、業務・組織を前提にしたシステム開発はそもそも無茶があります。システムは、システムである程度繰り返される業務・標準化された業務をスケール可能で高速化できるものです。
ここをそもそも根本的に理解する必要があります。
シンプルなシステムにするためには、標準化がつきもの、、、この当たり前が意外とできていません。組織、業務上の複雑性も、システムで何とかできるとか期待された妄想をしている方たまにいます。
利害関係者が多い場合は横ぐしの機能が必要
やむなく関係者が増える場合、システムの障害は人のはざまで起こることを念頭に、そのコミニケーション・認識齟齬をどう埋めるか？事前に準備が必要です。
この対策なくプロジェクトをパラで走らせれば結果サイロ化した連動しない仕組みができ、障害がそこに生まれるのはあたりまえです。
そもそもの旧システムがなぜ横行しているのか正論の議論が必要
システム開発において、聖域をつくれば足元をすくわれます。今回のみずほの例でいえば、なぜメインフレームでなければいけないか？もっと早くに再構築できなかったのか？さまざまな、そもそも問うべべき疑問があります。こういった当たり前の違和感を内側に入ると盲目になりがちです。社内SE/情シスはこの当たり前を問う力が必要になります。
社内SEの仕事の重要な要素に調整がありますが、
調整するのと同じくらい
調整そもそもすべきかを問う
のも大事な仕事です。
あわせておすすめ記事
社内SEに特に求められる調整力とは？調整の仕方・鍛え方
くさいものに蓋をするといつか爆発する
システムの世界では、臭いものにふたをするといつか爆発します。時間はわかりません。もしかしたらあなたがその企業を離れた時かもしれませんし、いる間かもしれません。
がしかし、経験上いつか足元をすくわれます。（だれかが）
責任感のない社内SEでは、腫れ物にでも触るかのようにそーーと触れないようにする方も結構います。あなたの息子・娘がその後始末をするかもしれませんよ。。。。
あるべきは、課題を一度しっかり洗い出し（全て）優先順位を決め取り組むしかりません。この課題の洗い出し、ステークホルダーとの認識合わせのあるなしで社内SEの仕事の質はかわります。理由は、この活動により事業施策とシステム保守施策の優先度をどうするかステークホルダーに判断をゆだねることができます。一気にすべてはできませんが、必ず解決のステップはできます（お金をかければ）。
ベンダーはやっぱり文章を書くことが仕事で課題は社内ＳＥが解決するしかない
ベンダーと社内SEでは責任感が全く違います。どこまで言っても社内SEが責任感を持ち自分事として自分の頭で考え行動する必要があります。
社内SEたる誇りが障害解消には必要だとうことですね。
みずほの障害では、もちろんみずほが好きで一生懸命頑張っている方を多数いらっしゃるとはおもいます。障害が長期化するとそういった気持ちの方も、疲弊し離れていく傾向にあるので早期の解決を願います。
余談：もしいかが事実だとそもそも責任感を持ったエンジニアが社内にいないのがみずほの問題だったりして。。。。
みずほ銀行システム障害の原因を自分事として分析した結果｜SE向けまとめ
みずほ銀行の障害は、社内SEには非常に示唆を含んだ内容です。隣の庭の事と捉えず自分事としてとらえ、今回の学びを参考に自社のやるべきことを洗い出してみるのがおすすめ（やるべき）です。
この事象を、自分事としてとらえることができるか？が大きな差につながります。今マネージメント層でない方でも、今回の内容を元に自チーム・自プロジェクト単位でも分析してみるのはいかかでしょうか。
学びの内容
・複雑化した組織・業務で出来上がるのは複雑化した仕組み
・利害関係者が多い場合は横ぐしの機能が必要
・そもそもの旧システムがなぜ横行しているのか議論が必要
・くさいものに蓋をするといつか爆発する
・ベンダーはやっぱり文章を書くことが仕事で課題は社内ＳＥが自ら解決するしかない